Quy trình hoạt động Kerberos

Comments

Kerberos không xây dựng các giao thức chứng thực phức tạp cho mỗi máy chủ mà hoạt động dựa trên một máy chủ chứng thực tập trung KDC (Key Distribution Centre). KDC cung cấp vé cho việc chứng thực người dùng và bảo mật truyền thông bởi khoá phiên trong vé gồm 3 giai đoạn và 6 bước trao đổi như sau.

Client chứng thực AS (Authentication Server – biết khoá mật của tất cả người dùng được lưu giữ trên một cơ sở dữ liệu tập trung )

AS_REQ là yêu cầu người dùng xác thực ban đầu(khởi tạo dich vụ) yêu cầu này được chuyển trực tiếp tới các thành phần được gọi là KDC Authentication Server (AS).

AS_REP là trả lời của máy chủ xác thực để yêu cầu trước đó. Về cơ bản nó chứa TGT (mã hóa bằng cách sử dụng khóa TGS bí mật) và khóa phiên (được mã hóa bằng khóa bí mật của người dùng yêu cầu)

  • Client xác thực TGS (Ticket Granting Server – cung cấp vé dịch vụ cho phép người dùng truy nhập vào các máy chủ trên mạng)

TGS_REQ là yêu cầu từ khách hàng đến Cấp vé máy chủ (TGS) cho một vé thông hành. Về cơ bản nó chứa TGT (mã hóa bằng cách sử dụng khóa TGS bí mật) và khóa phiên (được mã hóa bằng khóa bí mật của người dùng yêu cầu)

TGS_REP là trả lời của Cấp vé máy chủ để yêu cầu trước đó.Nằm bên trong là vé dịch vụ theo yêu cầu (được mã hóa với khóa bí mật của dịch vụ) và phiên dịch vụ một khóa tạo ra bởi TGS và được mã hóa bằng khóa phiên trước đó được tạo ra bởi AS.

Khách hàng truy cập và được cấp phép sử dung dịch vụ

AP_REQ là yêu cầu khách hàng gửi tới một máy chủ ứng dụng để truy cập vào một dịch vụ. Các thành phần là các dịch vụ bán vé thu được từ TGS với thư trả lời trước và nhận thực một lần nữa được tạo ra bởi khách hàng, nhưng lần này được mã hóa bằng khóa phiên dịch (tạo ra bởi TGS);

AP_REP là trả lời rằng các máy chủ ứng dụng cung cấp cho khách hàng để chứng minh nó thực sự là máy chủ của khách hàng là mong muốn. Gói này không phải lúc nào cũng được yêu cầu. Các khách hàng yêu cầu máy chủ cho nó chỉ khi xác thực lẫn nhau là cần thiết.

Lưu ý tất cả các trao đổi giữa các máy đều dược đóng dấu thời gian Timestamp

Trong kịch bản này, người dùng C đăng nhập vào máy trạm client và yêu cầu truy nhập tới máy chủ V.

Giai đoạn thứ nhất

Kết nối với AS để lấy về vé xin truy nhập TGS, ticket-granting-ticket (TGT)

Truyền thông với AS thường là giai đoạn khởi đầu của phiên đăng nhập, nhằm lấy về dữ liệu chứng thực (TGT) cho TGS, để sau đó lấy về chứng thực cho các máy chủ khác mà không phải nhập lại khoá bí mật của client. Khoá bí mật của client được sử dụng cho cả việc mã hoá và giải mã.

Người sử dụng nhập tên và mật khẩu tại máy tính của mình (máy khách).

Phần mềm máy khách thực hiện hàm băm một chiều trên mật khẩu nhận được kết quả sẽ được dùng làm khóa bí mật của người sử dụng.

Phần mềm máy khách gửi một gói tin (không mật mã hóa) tới máy chủ dịch vụ AS để yêu cầu dịch vụ. Nội dung của gói tin là: “người dùng U muốn sử dụng dịch vụ”. Cần chú ý là cả khóa bí mật lẫn mật khẩu đều không được gửi tới AS.

AS kiểm tra nhận dạng của người yêu cầu có nằm trong cơ sở dữ liệu của mình không. Nếu có thì AS gửi 2 gói tin sau tới người sử dụng:

  • Gói tin A: “Khóa phiên TGS/Client” được mật mã hóa với khóa bí mật của người sử dụng.
  • Gói tin B: “Vé chấp thuận” (bao gồm chỉ danh người sử dụng (ID), địa chỉ mạng của người sử dụng, thời hạn của vé và “Khóa phiên TGS/Client”) được mật mã hóa với khóa bí mật của TGS.

Giai đoạn thứ hai

Trao đổi với máy chủ cấp vé dịch vụ TGS, lấy về service ticket truy nhập máy chủ V:

Khi nhận được 2 gói tin A và B, phần mềm máy khách giải mã gói tin A để có khóa phiên với TGS. (Người sử dụng không thể giải mã được gói tin B vì nó được mã hóa với khóa bí mật của TGS). Tại thời điểm này, người dùng có thể nhận thực mình với TGS.

Khi yêu cầu dịch vụ, người sử dụng gửi 2 gói tin sau tới TGS:

  • Gói tin C: Bao gồm “Vé chấp thuận” từ gói tin B và chỉ danh (ID) của yêu cầu dịch vụ.
  • Gói tin D: Phần nhận thực (bao gồm chỉ danh người sử dụng và thời điểm yêu cầu), mật mã hóa với “Khóa phiên TGS/Client “.
  • Khi nhận được 2 gói tin C và D, TGS giải mã C, D rồi gửi 2 gói tin sau tới người sử dụng:
  • Gói tin E: “Vé” (bao gồm chỉ danh người sử dụng, địa chỉ mạng người sử dụng, thời hạn sử dụng và “Khóa phiên máy chủ/máy khách”) mật mã hóa với khóa bí mật của máy chủ cung cấp dịch vụ.
  • Gói tin F: “Khóa phiên máy Server/Client” mật mã hóa với “Khóa phiên TGS/Client “.

Giai đoạn thứ 3

Khi nhận được 2 gói tin E và F, người sử dụng đã có đủ thông tin để nhận thực với máy chủ cung cấp dịch vụ S. Client gửi tới S hai gói tin:

  • Gói tin E thu được từ bước trước (trong đó có “Khóa phiên máy Server/máy Client” mật mã hóa với khóa bí mật của S).
  • Gói tin G: phần nhận thực mới, bao gồm chỉ danh người sử dụng, thời điểm yêu cầu và được mật mã hóa với “Khóa phiên máy Server/Client”. Sever giải mã “Vé” bằng khóa bí mật của mình và gửi gói tin sau tới người sử dụng để xác nhận định danh của mình và khẳng định sự đồng ý cung cấp dịch vụ:
  • Gói tin H: Thời điểm trong gói tin yêu cầu dịch vụ cộng thêm 1, mật mã hóa với “Khóa phiên Server/Client “. Máy khách giải mã gói tin xác nhận và kiểm tra thời gian có được cập nhật chính xác. Nếu đúng thì người sử dụng có thể tin tưởng vào máy chủ S và bắt đầu gửi yêu cầu sử dụng dịch vụ. Máy chủ cung cấp dịch vụ cho người sử dụng
5/5 - (1 bình chọn)
TRƯƠNG THÁI KIỆT

TRƯƠNG THÁI KIỆT

https://thaikiet.com

thaikiet.com là nơi lưu trữ những kiến thức tổng hợp và chia sẻ cá nhân về Mạng Máy Tính, Quản Trị Hệ Thống và Bảo Mật. Với tiêu chí là cùng chia sẽ cùng thành công!

Mail: [email protected]

Bài viết cùng chuyên mục

Ngăn chặn user cài đặt phần mềm trong Domain

Ngăn chặn user cài đặt phần mềm trong Domain

Trong thực tế, khi các bạn đã xây dựng hệ thống DC, vẫn có 1 số phần mềm có thể cài đặt được bởi quyền của user như zalo..., bạn có thể chặn người dùng cài đặt bằng các bước đơn giản bên dưới. Mở...

Di chuyển thư mục lưu trữ active directory trên DC

Di chuyển thư mục lưu trữ active directory trên DC

Khi chúng tôi cài đặt thư mục hoạt động, nó cung cấp tùy chọn chọn đường dẫn thư mục để sao chép các tệp cơ sở dữ liệu thư mục hoạt động (Thư mục NTDS). Lời khuyên của tôi là luôn sử dụng một phân...

0 Comments

0 Lời bình

Gửi Lời bình

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *