Tải bản đầy đủ - 0 (trang)
CHƯƠNG 3. XÂY DỰNG MÔ PHỎNG QUÁ TRÌNH XÁC THỰC KERBEROS KHI NGƯỜI DÙNG THUỘC NHIỀU NHÓM

CHƯƠNG 3. XÂY DỰNG MÔ PHỎNG QUÁ TRÌNH XÁC THỰC KERBEROS KHI NGƯỜI DÙNG THUỘC NHIỀU NHÓM

Tải bản đầy đủ - 0trang

của tất cả nhóm bảo mật mà người dùng thuộc về. Kích thước của token tăng lên

khi người dùng được thêm vào các nhóm bảo mật bổ sung, được đại diện bởi

một SID bổ sung trong mã thông báo.

Nếu người dùng là thành viên của nhóm trực tiếp hoặc theo tư cách thành

viên trong nhóm khác, thì SID cho nhóm đó được thêm vào token của người

dùng. Có một giới hạn tích hợp trong đó Microsoft nói rằng số lượng SID có thể

được chứa trong token access bị hạn chế đến 1024

Cách Windows phân bổ bộ nhớ cho Access Token có thể gặp thêm vấn đề

quyền truy cập token. Kích thước mặc định của Access Token của người dùng là

4K. Số lượng chính xác của bộ nhớ thành viên nhóm bổ sung (và do đó SID bổ

sung) góp phần vào dung lượng bộ nhớ trong Access Token mặc định 4K ban

đầu này thay đổi một chút tùy thuộc trên loại nhóm - Global, Domain Local,

Built-in, Local hoặc Universal. Tuy nhiên, trung bình khoảng 80 nhóm sẽ hồn

tồn lấp đầy access token có kích thước 4K bộ nhớ này. Khi người dùng vượt

q con số này, Windows sẽ khơng tăng kích thước của token theo số lượng cần

thiết cho mỗi SID bổ sung được thêm vào. Thay vào đó, Windows phân bổ 4K

bộ nhớ khác, do đó nhân đơi kích thước của Access Token. Tương tự, với xấp xỉ

160 tổng số thành viên nhóm, Access Token của người dùng sẽ tăng thêm một

lần nữa 4K từ 8K đến 12K. Dung lượng bộ nhớ nhỏ này có vẻ khơng phải là vấn

đề, nhưng cách các ứng dụng khác nhau lưu trữ các access token này và các giới

hạn được xác định xung quanh bộ nhớ của chúng, nó có thể trở thành một vấn đề

quan trọng. Điều này đặc biệt đúng trong các tổ chức lớn với hàng ngàn người

dùng với tiềm năng nằm trong hàng trăm nhóm.

Kerberos Token size

Giá trị MaxTokenSize nên được set về mức cao nhất 64K (0x0000FFFF).

Với windows server 2012 và cao hơn, Microsoft đã thay đổi giá trị mặc định

của MaxTokenSize là 48K do HTTP header. Kerberos ticket trong một http

requests được mã hóa ở dạng Base64.

Nếu set MaxTokenSize với giá trị cao hơn 48K có thể gây ra một số vấn

đề với HTTP request cùng Kerberos authentication.

Access token (Group Membership)



31



Số lượng nhóm giới hạn là 1015 (or 1010) nhóm của một người dùng.

Nếu như một người dùng là thành viên của nhiều hơn 1015 nhóm, người dùng sẽ

gặp lỗi "STATUS_TOO_MANY_CONTEXT_IDS".

Hiện nay như bạn có thể biết, kích thước tối đa của Access token mặc định cho

gói xác thực Kerberos (tức là Kerberos SSP) là 8000 byte trong Windows 2000

và là 12.000 byte trong Windows Server 2003/8.

3.1.2. Các dấu hiệu sự cố kích thước Access token

Các sự cố xuất phát giới hạn Access token Kerberos có thể được chia

thành hai loại:

- Với TGT khi mà người dùng đăng nhập lúc đầu quá lớn

- Vé phiên được tạo (lưu lượng TGS) khi người dùng yêu cầu quyền

truy cập vào tài nguyên mạng quá lớn

Một trong những trường hợp này làm cho kích thước vé Kerberos là một

vấn đề. Nhóm dấu hiệu đầu tiên là khi số lượng SID trong TGT q lớn. Có một

giới hạn tích hợp về số lượng SID có thể được chứa trong Access token. Giới

hạn đó được giới hạn ở 1024. Mặc dù nó cho phép vượt qua con số này trong

Active Directory, nhưng hậu quả là người dùng không thể đăng nhập. Những

giới hạn của access token cũng có thể ảnh hưởng đến các ứng dụng khác.

Sự cố access token cũng có thể gây ra từ chối các sự cố dịch vụ với Máy

chủ IIS 6.0, máy chủ web của Microsoft. IIS 6.0 có giới hạn request headers của

máy chủ http mặc định là 16K, vượt q mức người dùng có kích thước access

token kerberos là bất cứ thứ gì vượt quá con số này. Với xấp xỉ 4K bộ nhớ cho

80 nhóm, giới hạn này bị vượt quá bởi tất cả người dùng có hơn 320 SID. Người

dùng có access token trên 16K bị từ chối khi xác thực với máy chủ IIS 6.0.

Kích thước access token q lớn cũng có một số hậu quả khác:

1. Access token phải được đánh giá trong quá trình đăng nhập của

người dùng trước khi đăng nhập có thể được hồn thành. Bởi vì

điều này, khi số lượng thành viên nhóm bảo mật tăng lên, quá trình

đăng nhập mất nhiều thời gian hơn

2. Để xác định quyền truy cập, vé phiên Kerberos chứa access token

của người dùng được gửi đến mọi máy tính mà người dùng truy



32



cập. Do đó, kích thước của access token có tác động trực tiếp đến

lưu lượng mạng.

3. Mỗi máy nhận vé Kerberos có kích thước được xác định trước

trong registry LSA\Kerberos\Paramameter. Nó được gọi là

MaxTokenSize. Cài đặt này giới hạn việc tạo access token trên

Kerberos (mặc định 12.000 byte XP/Windows 2003). Khi đạt đến

giới hạn bộ đệm này, nó sẽ dẫn đến các sự cố tạo access token của

Kerberosbase.

4. Kích thước headers HTTP do vé phiên Kerberos lớn được truyền

cũng có thể có tác động trực tiếp đến tải lưu lượng mạng. Nếu cần

kích thước bộ đệm HTTP lớn hơn, băng thông mạng sẽ bị ảnh

hưởng.

3.1.3. Kịch bản Kerberos Token Bloat

Vấn đề này có lẽ được minh họa rõ nhất bằng một ví dụ, vì vậy chúng tơi sẽ

chia sẻ một ví dụ bao gồm 2 tình huống:

 Chủ tài khoản người dùng tên miền U từ miền A đăng nhập vào máy

Ma, trong đó máy này Ma cũng thuộc về miền A (tức là được nối

miền với miền A)

 Sau đó, cùng một người dùng U này tiến hành sử dụng ứng dụng

máy khách-máy chủ với thành phần máy chủ được lưu trữ trên máy

Mb, trong đó máy Mb được nối với miền B

Kịch bản 1: Đăng nhập tương tác vào máy trên Miền A

Đây là những gì xảy ra khi tài khoản người dùng miền A cố gắng đăng nhập

tương tác vào máy tham gia tên miền Ma

1. Chủ tài khoản người dùng tên miền U gọi Secure Attention Sequence

(SAS) trên máy bằng cách nhấn Alt-Ctrl-Del.

2. Sau khi gọi SAS, Winlogon chuyển sang màn hình đăng nhập và gửi

GINA để thu thập dữ liệu đăng nhập.

3. GINA thu thập và trả lại dữ liệu đăng nhập của người dùng vào Winlogon,

sau đó gửi dữ liệu tới LSA bằng cách gọi LsaLogonUser.



33



4. LSA ngay lập tức chuyển đổi mật khẩu văn bản gốc của người dùng thành

khóa bí mật bằng cách chuyển nó qua chức năng băm một chiều.

5. LSA sau đó tạo dữ liệu xác thực trước bằng cách mã hóa dấu thời gian

bằng khóa bí mật được lấy từ mật khẩu của người dùng.

6. LSA sau đó gọi Kerberos SSP và gửi tin nhắn KRB_AS_REQ (bao gồm

dữ liệu xác thực trước này) đến dịch vụ xác thực KDC của người dùng.

7. Dịch vụ xác thực KDC, sử dụng danh tính người dùng (UPN) có trong

KRB_AS_REQ để xác định vị trí người dùng trong cơ sở dữ liệu tài

khoản của họ (Active Directory).

8. KDC sau đó sử dụng mật khẩu băm của tài khoản để cố gắng giải mã dữ

liệu xác thực trước.

9. Nếu KDC có thể giải mã thành cơng dữ liệu xác thực trước, thì nó sẽ tiến

hành đánh giá dấu thời gian. Nếu dấu thời gian vượt qua bài kiểm tra,

KDC có thể xác thực người dùng.

10.Nếu người dùng được xác thực, KDC sẽ xác định tất cả các nhóm người

dùng thuộc (trực tiếp hoặc gián tiếp) và đóng gói chúng trong PAC.

11.KDC sau đó xây dựng TGT cho người dùng, chèn PAC này vào đó và trả

lời lại bằng thông báo KRB_AS_REP, bao gồm TGT này cho người dùng.

12.LSA sau đó gửi tin nhắn KRB_TGS_REQ đến dịch vụ cấp vé KDC, để

yêu cầu vé phiên cho người dùng nhập học vào máy tính này.

13.Vì máy tính này thuộc cùng một miền, KDC sau đó xác định tất cả các

nhóm local security (trong miền này) mà người dùng thuộc về (trực tiếp

hoặc gián tiếp.)

14.Sau đó, nó sao chép dữ liệu từ PAC được lưu trữ trong TGT vào PAC mới

được tạo cho vé phiên này và thêm tất cả các nhóm local security miền đã

xác định vào PAC này.

15.Sau đó, nó tạo ra một vé dịch vụ tốt để được nhận vào máy tính này, chèn

PAC mới vào đó và trả lời lại bằng tin nhắn KRB_TGS_REP, trong đó có

vé dịch vụ này.



34



16.Khi nhận được vé phiên người dùng cho máy tính này, LSA sẽ giải mã nó

bằng khóa bí mật của máy tính và trích xuất PAC (chứa dữ liệu ủy quyền

của người dùng.)

17.Sau đó, nó truy vấn cơ sở dữ liệu Security Accounts Manager (SAM) cục

bộ để xác định xem người dùng có phải là thành viên của bất kỳ nhóm

local security nào của máy (trực tiếp hay gián tiếp.)

18.Nếu nó tìm thấy bất kỳ nhóm local security nào mà người dùng có thể là

thành viên, thì nó sẽ thêm danh sách các nhóm được lấy từ PAC.

19. Sau đó, nó tạo access token cho người dùng này và chuyển lại cho

Winlogon.

20.Winlogon sau đó tạo một trạm cửa sổ và một số đối tượng máy tính, đính

kèm access token của người dùng và bắt đầu tiến trình shell được chỉ định

cho người dùng này.

Access token của người dùng sau đó được kế thừa bởi bất kỳ quy trình ứng

dụng nào mà người dùng bắt đầu trong phiên đăng nhập. Những điểm quan

trọng cần lưu ý ở đây là trong quá trình tạo PAC cho vé phiên:

1. Tư cách thành viên được lấy từ PAC trong TGT

2. Chỉ những nhóm local domain thuộc miền miền máy tính (và trong đó

người dùng là thành viên trực tiếp hoặc gián tiếp) mới được đưa vào.

Bây giờ, hãy giả sử rằng người dùng là thành viên của 10 nhóm Universal, 15

nhóm local và 25 nhóm local domain từ miền máy tính (trong trường hợp này

giống như miền người dùng).

Trong trường hợp này, PAC trong vé phiên này có tất cả 50 nhóm bảo mật và

kích thước token Kerberos kết quả sẽ vào khoảng 1200 + (40 * 25) + (8 * (15 +

10)) byte = 2400 byte, dựa trên công thức đề xuất của Microsoft, các chi tiết

được cung cấp dưới đây.

Vì 2400 byte thấp hơn giới hạn MaxTokenSize là 12000 byte, người dùng

không gặp phải bất kỳ vấn đề nào với đăng nhập.

Kịch bản 2: Đăng nhập mạng vào máy trên Miền B



35



Bây giờ chúng ta hãy giả sử rằng ngay sau khi đăng nhập, người dùng U

khởi chạy phía máy khách của ứng dụng máy chủ-máy khách, phía máy chủ

đang chạy trên một miền được nối với máy Mb trong miền B (tức là máy được

nối với miền B.)

Giả sử rằng ứng dụng máy chủ-máy khách này sử dụng SSPI để xác thực

mạng, thích sử dụng Kerberos và máy khách biết SPN của phía máy chủ của

ứng dụng.

Đây là những gì xảy ra trong kịch bản này:

1. Người dùng khởi chạy phía máy khách của ứng dụng.

2. Phía máy khách của ứng dụng thiết lập kết nối socket với máy chủ

3. Mỗi bên máy khách và máy chủ tiến hành gọi

QuerySecurityPackageInfo() để xác định kích thước token tối đa

cho Kerberos

4. Sau đó, mỗi bên máy khách và máy chủ tiến hành gọi

AcquireCredentialsHandle() chuyển qua tên của gói Kerberos, để

có được một điều khiển cho thơng tin đăng nhập trước đó của họ

5. Sau đó, máy khách gọi LaunchizeSecurityContext() để cung cấp

cho SSP cơ hội chuẩn bị token gửi đi (token này không bị nhầm lẫn

với token truy nhập của windows“Windows access token”

6. Sau đó, client truyền token thông báo kết quả đến máy chủ

7. Khi máy chủ nhận được token này, nó gọi AcceptSecurityContext()

để chuyển token đến SSP của nó.

8. Sau khi vượt qua thành cơng chức năng AcceptSecurityContext() ở

phía máy chủ, hệ thống sẽ tạo một phiên đăng nhập mạng mới cho

máy khách.

9. Phía máy chủ sau đó sẽ gọi ImpersonateSecurityContext() để yêu

cầu SSP đặt token cho phiên đăng nhập của máy khách (trên máy

chủ)

10. Cuối cùng, khi hồn thành, phía máy chủ sẽ gọi

RevertSecurityContext() để ngừng việc mạo danh người gọi



36



Bây giờ, trong trường hợp ta chưa biết các trao đổi liên quan đến Kerberos

cần thiết ở đâu trong mô tả ở trên, câu trả lời là chúng được SSP tự động xử lý ở

giữa các bước 5 - 8 ở trên vì SSP tóm tắt chi tiết cụ thể về giao thức.

Chúng ta giả định rằng người dùng là thành viên của 10 nhóm Universal,

15 nhóm Local và 25 nhóm Local domain từ tên miền người dùng (trong trường

hợp này giống như tên miền người dùng).

Bây giờ, chúng ta cũng giả sử rằng người dùng này cũng là thành viên của

300 nhóm domain local security trong miền máy chủ.

Trong trường hợp này, PAC trong vé phiên này sẽ chứa tất cả 325 nhóm

security và kích thước token Kerberos sẽ có khoảng 1200 + (40 * 300) + (8 *

(15 + 10)) byte = 13500 byte

Vì 13500 byte vượt quá giới hạn MaxTokenSize 12000 byte, nên người

dùng thực sự sẽ không thể đăng nhập và Kerberos SSP rất có thể sẽ gây ra lỗi

trong khi gọi hàm AcceptSecurityContext() trên máy chủ.

Kết quả cuối cùng là người dùng sẽ không thể xác thực thành công với máy

chủ và nếu máy chủ này đang chạy Windows Server 2008, bạn có thể thấy thơng

báo sau trong nhật ký sự kiện Kerberos

3.2. Giải pháp khắc phục vấn đề

Để giảm kích thước vé Kerberos, bạn có thể:

1. Giảm số nhóm của thành viên

2. Dọn dẹp lịch sử SID

3. Giới hạn số lượng người dùng được định cấu hình để sử dụng

"trusted for delegation". Tài khoản được định cấu hình để sử dụng

"trusted for delegation" với các yêu cầu bộ đệm cho mỗi SID có thể

tăng gấp đơi.

Tăng kích thước thông qua Registry key với MaxTokenSize

Khi Windows 2000 ban đầu xuất hiện, kích thước tối đa của token cụ thể

của gói xác thực Kerberos được mã hóa cứng là 8000 byte trong phiên bản RTM

của Windows 2000. Nó xuất hiện từ năm 2001 Microsoft đã phát hành Hotfix,

cho phép quản trị viên tăng giá trị này, dựa trên Registry key có tên

MaxTokenSize



37



Hình 3. 1. Khắc phục lỗi kerberos 1

Mặc dù giá trị này về mặt lý thuyết có thể định cấu hình thành giá trị lên tới

65535 byte. Một người dùng có thể trong 1.015 nhóm + 9 BuiltIn-groups = tối

đa 1.024 nhóm.

Ngày nay, kích thước tối đa mặc định của token cụ thể của gói xác thực

Kerberos là 12000 byte trong Windows Server 2003 và Windows Server 2008 và

48.000 byte trong Windows Server 2012.

Microsoft cũng đã cung cấp các cách hiệu quả để thêm Registry key này

vào các máy tính trong một miền. Các tùy chọn bao gồm ứng dụng tệp ADM

dựa trên GPO trong Windows Server 2003, sử dụng tiện ích mở rộng phía máy

khách Registry trong Windows 2008 và sử dụng cài đặt GPO mới được xác định

trong Windows Server 2012.

3.2.1. Đặt kích thước tối đa cho bộ đệm token Kerberos

Trong Windows Server 2012 và Windows 8, Microsoft đã giới thiệu GPO

mới để giúp dễ dàng đặt khóa đăng ký này trên nhiều máy tính. Cài đặt mới này

nằm trong System > Kerberos và được gọi là “Set maximum Kerberos SSPI

context token buffer size”



38



Hình 3. 2. Khắc phục lỗi Kerberos 2

3.2.2. Khuyến cáo của Microsoft về tính tốn kích thước Token

Để giúp các tổ chức giải quyết vấn đề này, Microsoft cung cấp công thức

sau để giúp xác định kích thước tối đa token của một người dùng tên miền cụ

thể:

Token Size = 1200 + 40d + 8s

Công thức này sử dụng các giá trị sau:

d: Số lượng nhóm domain local mà người dùng là thành viên cộng với số

lượng nhóm universal bên ngồi miền tài khoản của người dùng mà người dùng

là thành viên cộng với số lượng nhóm được thể hiện trong SID.

s: Số lượng nhóm security global mà người dùng là thành viên cộng với số

lượng nhóm universal trong miền tài khoản của người dùng mà người dùng là

thành viên.

1200: Giá trị ước tính cho vé vượt ngưỡng. Giá trị này có thể thay đổi, tùy

thuộc vào các yếu tố như độ dài tên miền DNS, tên máy khách và các yếu tố

khác.

Một số cơng cụ tính tốn kích thước token:

Có 3 cơng cụ được sử dụng phổ biến:

- Tokensz - Một công cụ dòng lệnh miễn phí được cung cấp bởi Microsoft



39



- CheckMaxTokenSize - Tập lệnh miễn phí được nhân viên Microsoft ghép

lại

- Get-TokenSizeReport - Một tập lệnh miễn phí có nguồn gốc từ

CheckMaxTokenSize bởi một nhà tư vấn độc lập



Hình 3. 3. Check token size report

3.3. Triển khai giao thức xác thực kerberos

3.3.1. Triển khai Active directory domain service trên Windows Server 2012

Tại server manager chọn Dashboard chọn Add roles and features



Hình 3. 4. Triển khai giao thức kerberos 1



40



Next đến đây chọn Active Directory Domain Services



Hình 3. 5. Triển khai giao thức kerberos 2



Hình 3. 6. Triển khai giao thức kerberos 3



41



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

CHƯƠNG 3. XÂY DỰNG MÔ PHỎNG QUÁ TRÌNH XÁC THỰC KERBEROS KHI NGƯỜI DÙNG THUỘC NHIỀU NHÓM

Tải bản đầy đủ ngay(0 tr)

×