PEAP-MSCHAPv2 với Active Directory, và vì sao nó không đi cùng Entra ID

Ghi chú đọc tài liệu, không phải kết quả thử trên hệ thật. Nguồn chính: ClearPass 6.8 Deployment Guide của HPE và bộ slide cộng đồng về tích hợp Azure (2021). Mỗi ý có chú thích số trang ở cuối bài; đoạn nào chưa kiểm chứng được thì ghi rõ.

PEAP dựng tunnel TLS (chỉ server trình chứng chỉ) rồi xác thực người dùng bên trong tunnel, thường bằng mật khẩu. Lý do người ta chọn nó: dùng luôn tài khoản sẵn có trong Active Directory (tên đăng nhập và mật khẩu), khỏi cấp smart card hay chứng chỉ cho từng người, từng máy¹.

Hai điều nên biết trước khi đọc tiếp:

• Người phán đúng/sai là domain controller, không phải ClearPass. Chặng cuối là NTLM tới DC; AD hỏng hay ClearPass chưa join domain thì PEAP gãy dù phần TLS hoàn toàn bình thường¹.
• PEAP không đi được với Entra ID / Azure AD. Cách đám mây lưu mật khẩu không hợp với EAP-PEAP² — bỏ AD tại chỗ thì đường đi thực tế là EAP-TLS.

Chi tiết

Đây chính là đánh đổi cốt lõi so với EAP-TLS: không phải dựng hạ tầng cấp chứng chỉ cho từng client, đổi lại độ mạnh phụ thuộc vào mật khẩu người dùng.

Ba vai trong một phiên 802.1X

Vai	Là ai
Supplicant	thiết bị client: laptop, tablet, điện thoại
Authenticator	thiết bị mạng chặn cửa: Aruba Mobility Controller hoặc Instant AP
Authentication server	ClearPass Policy Manager, nơi xử lý và trả accept/reject

Trình tự bắt tay PEAP-MSCHAPv2 với Active Directory

Deployment Guide đi hết 41 bước. Gom lại còn sáu chặng¹:

1. Hỏi danh tính (ngoài tunnel). Authenticator gửi EAP-Request hỏi identity; supplicant trả về EAP Identity Response — đây là Outer Identity, và nó đi chưa được mã hoá. Authenticator chuyển tiếp cho ClearPass.
2. Tra Active Directory lần một. ClearPass tra LDAP vào authentication source đã cấu hình để tìm tên người dùng cùng vài thuộc tính cơ bản như sAMAccountName.
3. Dựng tunnel TLS. ClearPass báo muốn dùng EAP-PEAP. Supplicant gửi ClientHello; ClearPass trả ServerHello, Certificate, ServerKeyExchange, ServerHelloDone. Bước này lặp nhiều lượt vì chứng chỉ phải cắt thành mảnh cho vừa giới hạn kích thước của một EAP message. Supplicant đáp ClientKeyExchange, ChangeCipherSpec, Handshake, ClientFinished; ClearPass chốt bằng ChangeCipherSpec và ServerFinished.
4. EAP chạy lại từ đầu, lần này bên trong tunnel. ClearPass lại hỏi identity; danh tính lần này là Inner Identity và được tunnel bảo vệ. ClearPass tra LDAP lần hai.
5. MSCHAPv2 và NTLM. ClearPass gửi MSCHAPv2 challenge. Nhận được đáp án, ClearPass gộp tên người dùng, MSCHAPv2 response, MSCHAPv2 challenge và NetBIOS name của domain, rồi nộp cả cụm đó cho domain controller qua NT LAN Manager (NTLM). Domain controller là bên thực sự phán quyết đúng/sai, không phải ClearPass.
6. Chốt phiên. Domain controller báo thành công; chuỗi MSCHAPv2 success đi ngược ra. ClearPass gửi RADIUS Access-Accept kèm EAPOL success và key material; authenticator và supplicant chạy four-way handshake rồi lưu lượng mã hoá mới bắt đầu chảy.

Hai hệ quả thực tế rút ra từ trình tự này:

• Outer identity lộ ra ngoài tunnel, nên nó thường được đặt ẩn danh; chỉ inner identity mới là danh tính thật.
• Xác thực cuối cùng là NTLM tới domain controller — hỏng AD, sai NetBIOS name domain, hoặc ClearPass chưa join được domain thì PEAP-MSCHAPv2 gãy, dù phần TLS hoàn toàn bình thường.

Chỗ đứng trong danh sách phương thức của ClearPass

Deployment Guide 6.8 nói có thể dùng đồng thời nhiều giao thức xác thực, và liệt kê: PEAP, EAP-FAST, EAP-TLS, EAP-TTLS, EAP-PEAP-Public¹. Đáng chú ý là TEAP không có trong danh sách này.

Giới hạn khi danh tính chuyển lên đám mây

Chặng 5 ở trên giải thích luôn vì sao PEAP không đi được với Entra ID / Azure AD: nó kết thúc bằng NTLM tới domain controller, tức là phụ thuộc vào cách lưu mật khẩu của thư mục kiểu cũ. Tài liệu tích hợp Azure nói thẳng rằng PEAP được thiết kế cho NTLM/Kerberos, không tương thích với SAML/OAuth 2.0, và cách mật khẩu được lưu trên đám mây không tương thích với EAP-PEAP².

Đây là lý do tồn tại của Azure AD Domain Services: kéo dài hỗ trợ xác thực kiểu cũ². Bỏ AD tại chỗ mà vẫn muốn 802.1X thì đường đi thực tế là chuyển sang EAP-TLS.

Chưa kiểm chứng. PEAP không phải RFC chuẩn của IETF; đặc tả nằm ở tài liệu Microsoft [MS-PEAP] và các bản draft IETF đã hết hạn. Tôi chưa đối chiếu điều này với tài liệu gốc.

So sánh: EAP-TLS cần chứng chỉ ở cả client; TEAP là chuẩn IETF cho kiểu “tunnel + phương thức bên trong”.

Nguồn

Footnotes

1. ClearPass 6.8 Deployment Guide, tr. PDF 18, 36, 303–309 ↩ ↩² ↩³ ↩⁴

2. ClearPass Microsoft Azure Integration — Part 1 (slide cộng đồng, 2021), tr. PDF 4, 10 ↩ ↩² ↩³