Cấu hình LDAPS (Port 636) trên Windows Server bằng AD CS

Tóm tắt nhanh (TL;DR)

Để cấu hình LDAPS (LDAP an toàn) trên Windows Server, bạn cần:

1. Cài đặt vai trò (Role): Cài đặt “Active Directory Certificate Services” (AD CS) trên một máy chủ (thường là Domain Controller).
2. Cấu hình AD CS: Cấu hình nó thành một “Enterprise Root CA”.
3. Tạo Template: Mở certtmpl.msc, nhân bản (Duplicate) template “Kerberos Authentication”. Đặt tên mới (ví dụ: CongTy-LDAPS), đảm bảo EKU có “Server Authentication” và cấp quyền “Autoenroll” cho nhóm “Domain Controllers”.
4. Phát hành Template: Mở certsrv.msc, phát hành (Issue) template mới tạo.
5. Kiểm tra: Chạy gpupdate /force trên các DC. Dùng LDP.exe kết nối tới FQDN của DC qua port 636 với tùy chọn SSL, sau đó thực hiện Bind (ràng buộc) bằng tài khoản AD để xác minh.

LDAPS là gì? Tại sao phải cấu hình LDAPS?

Nếu bạn đang quản trị một hệ thống Active Directory (AD), bạn gần như chắc chắn đang sử dụng LDAP. Giao thức LDAP (Lightweight Directory Access Protocol) là cách mà các máy tính và ứng dụng “hỏi” cơ sở dữ liệu AD (ví dụ: “Thông tin user này là gì?”, “User này thuộc nhóm nào?”).

Vấn đề: Theo mặc định, LDAP (trên port 389) là một giao thức văn bản rõ (plain text).

Điều này có nghĩa là bất kỳ ai có thể “bắt gói tin” (packet sniffing) trên mạng của bạn đều có thể đọc thấy toàn bộ thông tin truy vấn, bao gồm cả tên người dùng và mật khẩu nếu ứng dụng đó sử dụng phương thức “Simple Bind”. Đây là một rủi ro bảo mật nghiêm trọng.

Giải pháp: LDAPS (Port 636)

LDAPS chính là LDAP được “bọc” trong một lớp mã hóa SSL/TLS. Nó mã hóa toàn bộ phiên giao tiếp giữa ứng dụng và máy chủ Domain Controller (DC).

Việc cấu hình LDAPS là một yêu cầu bắt buộc trong các môi trường doanh nghiệp hiện đại vì:

• Bảo mật: Chống lại các cuộc tấn công sniffing, đảm bảo thông tin nhạy cảm (như mật khẩu reset) được truyền đi an toàn.
• Tuân thủ (Compliance): Nhiều tiêu chuẩn bảo mật như PCI-DSS hay HIPAA yêu cầu mã hóa toàn bộ dữ liệu nhạy cảm “đang truyền” (in-transit).
• Yêu cầu ứng dụng: Nhiều ứng dụng và dịch vụ hiện đại (bao gồm cả Azure AD Connect, VMware vCenter, hoặc các máy chủ Linux) bắt buộc phải có LDAPS mới cho phép kết nối.

Bài viết này sẽ hướng dẫn bạn cách cấu hình LDAPS một cách “chuẩn” nhất: sử dụng chính vai trò AD CS của Windows Server để tạo ra một Certificate Authority (CA) nội bộ và tự động cấp chứng chỉ cho các Domain Controller của bạn.

Lưu ý: Bài viết này dành cho On-Premises (AD CS)

Hướng dẫn trong bài viết này tập trung chi tiết vào cách cấu hình LDAPS cho môi trường Active Directory On-Premises (tại chỗ) bằng cách cài đặt vai trò AD CS trên Windows Server.

Nếu bạn đang sử dụng dịch vụ Microsoft Entra Domain Services (Azure AD DS) trên đám mây, quy trình sẽ hoàn toàn khác và không cài đặt bất kỳ vai trò nào. Đối với Azure, bạn sẽ cần:

• Tạo một chứng chỉ (Self-signed hoặc từ CA công cộng).
• Xuất chứng chỉ đó ra file .PFX (bao gồm cả private key).
• Upload file .PFX này trực tiếp lên giao diện portal của Microsoft Entra.
• Kích hoạt (toggle) tính năng “Secure LDAP” trong cấu hình dịch vụ.

Yêu cầu tiên quyết (Bắt buộc)

Trước khi mở Server Manager, hãy đảm bảo bạn nắm rõ các yêu cầu sau. Bỏ qua bước này là nguyên nhân của 90% các lỗi cấu hình LDAPS thất bại.

• Quyền hạn: Bạn cần đăng nhập bằng tài khoản thuộc nhóm Enterprise Admins để cài đặt và cấu hình Enterprise CA.
• Máy chủ: Bạn cần một máy chủ Windows Server (ví dụ: 2016, 2019, 2022) đã được nâng cấp lên Domain Controller (DC). Trong hầu hết các mô hình vừa và nhỏ, người ta thường cài đặt vai trò CA ngay trên một trong các máy chủ DC.
• IP tĩnh: Máy chủ DC (và cũng là máy chủ CA) phải được đặt IP tĩnh.

Yêu cầu kỹ thuật của chứng chỉ (Certificate)

Đây là “trái tim” của LDAPS. Để một Domain Controller tự động kích hoạt port 636, nó phải tìm thấy một chứng chỉ hợp lệ trong kho lưu trữ (Certificate Store) của nó. Chứng chỉ đó PHẢI đáp ứng 2 yêu cầu sau:

1. Enhanced Key Usage (EKU): Chứng chỉ phải chứa mục đích sử dụng (EKU) là Server Authentication (OID: 1.3.6.1.5.5.7.3.1).
2. Subject Name (CN) hoặc Subject Alternative Name (SAN): Trường Tên Chủ Thể (CN) hoặc Tên Thay Thế (SAN) của chứng chỉ phải chứa tên FQDN (Fully Qualified Domain Name) của máy chủ Domain Controller.
   • Ví dụ: Nếu DC của bạn tên là DC01 và domain là congty.local, FQDN sẽ là DC01.congty.local.

Tin tốt là, bằng cách cài đặt “Enterprise CA” như hướng dẫn dưới đây, các yêu cầu này sẽ được tự động đáp ứng.

Bước 1: Cài đặt vai trò Active Directory Certificate Services (AD CS)

Bước đầu tiên là cài đặt vai trò AD CS. Chúng ta sẽ thực hiện việc này trên máy chủ Domain Controller mà bạn đã chọn.

1. Mở Server Manager.
2. Chọn Manage -> Add Roles and Features.

   

3. Nhấn Next cho đến khi bạn đến phần Server Roles.
4. Tick chọn vai trò “Active Directory Certificate Services”.

   

5. Một cửa sổ pop-up sẽ hiện ra yêu cầu thêm các tính năng (features) đi kèm. Nhấn Add Features.

   

6. Nhấn Next, bỏ qua phần Features.
7. Tại phần Role Services, chỉ tick chọn “Certification Authority”. Các dịch vụ khác (như Web Enrollment, Online Responder) là không cần thiết cho mục đích cấu hình LDAPS cơ bản.

   

8. Nhấn Next và sau đó nhấn Install.
9. Chờ quá trình cài đặt hoàn tất, sau đó nhấn Close. Đừng rời khỏi Server Manager.

Bước 2: Cấu hình AD CS (Tạo Enterprise Root CA)

Sau khi cài đặt xong, bạn sẽ thấy một biểu tượng cờ vàng cảnh báo trong Server Manager. Đây là lúc chúng ta cấu hình vai trò vừa cài.

1. Nhấn vào biểu tượng cờ vàng và chọn “Configure Active Directory Certificate Services…”.

   

2. Credentials: Đảm bảo bạn đang dùng tài khoản Enterprise Admin. Nhấn Next.
3. Role Services: Chọn “Certification Authority” và nhấn Next.
4. Setup Type: Đây là lựa chọn quan trọng. Hãy chọn “Enterprise CA”.

   

   • Enterprise CA: Tích hợp hoàn toàn với Active Directory. Nó có thể tự động cấp phát (auto-enroll) chứng chỉ cho các máy tính trong domain và các máy tính trong domain cũng tự động tin tưởng CA này. Đây là lựa chọn bắt buộc cho kịch bản của chúng ta.
   • Standalone CA: Hoạt động độc lập, không cần AD. Bạn phải tự tạo và duyệt chứng chỉ thủ công.
5. CA Type: Chọn “Root CA”. Vì đây là CA gốc đầu tiên và cao nhất trong hệ thống của bạn.

   

   Ghi chú chuyên sâu: Chọn Root CA hay Subordinate CA?

   • Root CA (CA Gốc): Chúng ta chọn cái này trong hướng dẫn vì đây là CA đầu tiên, đơn giản và nhanh nhất để hệ thống hoạt động.
   • Subordinate CA (CA Trung gian/Cấp dưới): Trong môi trường production lớn, theo “best practice”, bạn nên có một cấu trúc 2 tầng (2-tier). Tầng 1 là Root CA (offline, tắt đi để bảo mật) và tầng 2 là Subordinate CA (online, làm nhiệm vụ cấp phát chứng chỉ hàng ngày). Nếu tổ chức của bạn đã có cấu trúc này, bạn sẽ chọn “Subordinate CA” ở bước này và trỏ nó về Root CA của bạn.

6. Private Key: Chọn “Create a new private key”.
7. Cryptography: Giữ nguyên các tùy chọn mặc định an toàn.
   • Hash algorithm: SHA256 (Không dùng SHA1).
   • Key length: 2048 (hoặc 4096 nếu bạn cần bảo mật cao hơn).
8. CA Name: Đặt một cái tên định danh cho CA của bạn.
   • Lời khuyên: Tên này là VĨNH VIỄN và không thể thay đổi. Hãy đặt tên ngắn gọn, không dấu, không khoảng trắng. Ví dụ: CongTy-CA.
9. Validity Period: Đặt thời hạn cho CA gốc. 5 hoặc 10 năm là phổ biến.
10. Database: Giữ nguyên đường dẫn mặc định.
11. Confirmation: Xem lại tất cả các lựa chọn của bạn và nhấn “Configure”.

    

Sau khi cấu hình thành công, dịch vụ AD CS sẽ khởi động. Hệ thống của bạn giờ đã có một CA nội bộ.

Bước 3: Tạo và phát hành Certificate Template cho LDAPS

Đây là bước mà nhiều hướng dẫn cơ bản bỏ qua, nhưng lại là bước quan trọng nhất để đảm bảo cấu hình LDAPS chạy ổn định và đúng ý.

Mặc dù việc cài Enterprise CA có thể tự động cấp một chứng chỉ cho DC, chúng ta nên tạo một template (khuôn mẫu) tùy chỉnh để kiểm soát chính xác chứng chỉ nào được dùng cho LDAPS.

1. Trên máy chủ CA, mở Start Menu, gõ certsrv.msc để mở “Certification Authority”.
2. Trong cây thư mục bên trái, chuột phải vào Certificate Templates -> chọn Manage. Thao tác này sẽ mở cửa sổ “Certificate Templates Console”.
3. Trong danh sách các template, tìm template có tên “Kerberos Authentication”.
   • Tại sao lại là template này? Vì nó chứa sẵn cả 2 EKU quan trọng: “Server Authentication” và “Client Authentication”, và được thiết kế cho các Domain Controller.
4. Chuột phải vào “Kerberos Authentication” và chọn “Duplicate Template”.

   

5. Cửa sổ Properties của template mới sẽ hiện ra. Hãy tùy chỉnh:
   • General Tab:
     

     

     • Template display name: Đặt một tên dễ nhớ, ví dụ: CongTy-LDAPS.
     • Tick chọn “Publish certificate in Active Directory” (Rất quan trọng).
   • Request Handling Tab:
     • Tick chọn “Allow private key to be exported”. (Hữu ích nếu bạn cần backup chứng chỉ này).
   • Subject Name Tab:
     

     

     • Đảm bảo tùy chọn “Build from this Active Drectory information” được chọn.
     • Subject name format: “DNS name”. (Điều này đảm bảo FQDN nằm trong chứng chỉ).
   • Security Tab:
     
     • Đây là bước then chốt để tự động cấp phát.
     • Nhấn Add… -> gõ “Domain Controllers” -> OK.
     • Chọn nhóm “Domain Controllers” trong danh sách.
     • Bên dưới, tick chọn “Allow” cho các quyền: Read, Enroll, và Autoenroll.
6. Nhấn Apply và OK để lưu template. Đóng cửa sổ “Certificate Templates Console”.
7. Quay lại cửa sổ “Certification Authority” (certsrv.msc).
8. Chuột phải vào Certificate Templates (một lần nữa) -> New -> Certificate Template to Issue.
9. Trong danh sách hiện ra, tìm và chọn template bạn vừa tạo (CongTy-LDAPS) và nhấn OK.

   

Bạn vừa hoàn tất! Bạn đã “ra lệnh” cho CA của mình rằng: “Hãy tự động tìm tất cả các Domain Controller và cấp cho chúng chứng chỉ theo khuôn mẫu CongTy-LDAPS“.

Bước 4: Xác minh và kiểm tra kết nối LDAPS

Mọi thứ đã được thiết lập. Giờ là lúc kiểm tra thành quả.

Cách 1: Ép DC nhận chứng chỉ mới

Trên (các) máy chủ Domain Controller của bạn, mở Command Prompt với quyền Admin và gõ:

gpupdate /force

Lệnh này sẽ buộc DC liên lạc lại với AD và nhận chính sách mới, bao gồm cả chính sách “Autoenroll” chứng chỉ mà chúng ta vừa cấu hình. Quá trình này có thể mất vài phút.

Cách 2: Dùng LDP.exe (Công cụ kiểm tra tốt nhất)

LDP.exe là công cụ kiểm tra LDAP “cây nhà lá vườn” của Microsoft, có sẵn trên mọi Domain Controller.

1. Mở Start Menu, gõ ldp.exe và chạy nó.
2. Vào menu Connection -> chọn Connect….
3. Trong hộp thoại Connect:
   • Server: Gõ tên FQDN của Domain Controller. (Ví dụ: dc01.congty.local).
   • Port: Gõ 636.
   • Tick chọn ô “SSL”.

   

4. Nhấn OK.
5. Kết quả (Kết nối):
   • Thành công: Nếu cửa sổ bên phải hiển thị một loạt văn bản, bắt đầu bằng ld = ldap_sslinit... và liệt kê thông tin RootDSE (tất cả các thông số của AD), bạn đã kết nối LDAPS thành công!
   • Thất bại: Nếu báo lỗi “Cannot open connection” hoặc “Error 0x51 = Server Down”, có nghĩa là port 636 chưa được kích hoạt.
6. Kiểm tra Ràng buộc (Bind) – Nên làm:
   • Sau khi kết nối thành công (bước 5), hãy vào menu Connection -> chọn Bind….
   • Chọn “Bind with credentials”.
   • Nhập tên người dùng (ví dụ: administrator), mật khẩu, và domain (ví dụ: congty.local).
   • Nhấn OK.
   • Kết quả (Xác thực): Nếu cửa sổ bên phải hiển thị dòng Authenticated as: 'TENMIEN\Administrator', bạn đã xác nhận 100% rằng kênh mã hóa LDAPS không chỉ mở mà còn hoạt động xác thực thành công.

   

Cách 3: Dùng Netstat

Một cách kiểm tra nhanh khác là xem máy chủ có đang “lắng nghe” (LISTENING) trên port 636 không.

Mở Command Prompt (Admin) và gõ:

netstat -an | findstr "636"

Nếu bạn thấy một dòng có TCP 0.0.0.0:636 ... LISTENING, điều đó có nghĩa là dịch vụ LDAPS đã được kích hoạt trên máy chủ.

Xử lý sự cố (Troubleshooting) thường gặp

Nếu LDP.exe thất bại, đừng lo lắng. Dưới đây là các bước kiểm tra phổ biến. (bạn cũng có thể tham khảo bài Phân tích & sửa lỗi kết nối Proxy: Hướng dẫn debug “Connection Refused” & “Timeout” (HTTP/SOCKS5)).

Lỗi: LDP.exe báo “Error 0x51 = Server Down”

• Triệu chứng: Port 636 hoàn toàn không hoạt động, netstat không thấy gì.
• Nguyên nhân: DC không tìm thấy chứng chỉ hợp lệ.
• Giải pháp:
  1. Mở mmc.exe -> File -> Add/Remove Snap-in.
  2. Chọn Certificates -> Add -> Chọn “Computer account” -> Local computer -> Finish -> OK.
  3. Trong MMC, điều hướng đến Personal -> Certificates.
  4. Nhìn vào các chứng chỉ ở đây. Bạn phải thấy chứng chỉ do CongTy-CA cấp (template CongTy-LDAPS).
  5. Double-click vào nó, xem tab Details. Đảm bảo trường Enhanced Key Usage có “Server Authentication”.
  6. Nếu không thấy chứng chỉ, hãy chạy lại gpupdate /force hoặc khởi động lại DC.
  7. Pro-tip: Mở adsiedit.msc, kết nối vào “Default naming context”, tìm đến DC của bạn (ví dụ: CN=DC01,OU=Domain Controllers,DC=congty,DC=local), chuột phải -> Properties. Tìm thuộc tính renewServerCertificate và set giá trị là 1. Thao tác này sẽ buộc DC yêu cầu chứng chỉ mới ngay lập tức mà không cần khởi động lại.

Lỗi: Máy khách (Client) báo “Certificate Verify Failed”

• Triệu chứng: Bạn cấu hình LDAPS thành công. LDP.exe trên chính DC chạy tốt. Nhưng một ứng dụng, một máy chủ Linux, hoặc một máy tính Windows không trong domain khi kết nối LDAPS thì báo lỗi “Untrusted CA”, “Invalid Certificate” hoặc “Certificate Verify Failed”.
• Nguyên nhân: Đây là điều hoàn toàn bình thường. Máy khách không tự động tin tưởng “CA nội bộ” (CongTy-CA) mà bạn vừa tạo ra. Chỉ các máy tính đã join domain mới tự động tin tưởng nó.
• Giải pháp (Cách Admin xuất CA):
  1. Bạn cần xuất chứng chỉ CA gốc (chứng chỉ của CA, không phải chứng chỉ của DC) và đưa nó cho máy khách.
  2. Mở certsrv.msc (Certification Authority).
  3. Chuột phải vào tên CA của bạn (CongTy-CA) -> Properties.
  4. Tab General -> Nhấn nút “View Certificate”.
  5. Tab Details -> Nhấn nút “Copy to File…”.
  6. Trong wizard, chọn định dạng “Base-64 encoded X.509 (.CER)”.

     

  7. Lưu file với tên (ví dụ: CongTyCA.cer).
• Giải pháp (Cách Import vào máy khách):
  • Máy Windows (Thủ công): Gửi file CongTyCA.cer cho máy khách. Chuột phải vào file -> Install Certificate -> Chọn “Local Machine” -> Chọn “Place all certificates in the following store” -> Browse -> Chọn “Trusted Root Certification Authorities” -> OK và hoàn tất.
  • Máy Windows (Tự động): Dùng Group Policy (GPO) để đẩy file CongTyCA.cer này vào mục “Trusted Root Certification Authorities” của tất cả các máy tính.
  • Máy Linux/Ứng dụng: Đây chính là vấn đề gặp phải khi bạn Tích hợp Squid với Active Directory: Cấu hình xác thực LDAP và dùng cờ -Z (StartTLS). Bạn sẽ cần import file .cer này vào kho tin tưởng (trust store) của hệ điều hành (ví dụ: update-ca-certificates trên Ubuntu) hoặc của ứng dụng (vídụ: keytool cho Java).

Câu hỏi thường gặp (FAQ)

1. LDAP (port 389) và LDAPS (port 636) khác nhau như thế nào?

• LDAP (Port 389): Là giao thức truy vấn Active Directory ở dạng văn bản rõ (không mã hóa). Mọi thông tin, kể cả mật khẩu (nếu dùng simple bind), đều có thể bị đọc trộm (sniffing).
• LDAPS (Port 636): Là LDAP qua SSL/TLS. Toàn bộ phiên kết nối được mã hóa ngay từ đầu, tương tự như cách Port 443 (HTTPS) bảo vệ website.

2. Sự khác biệt giữa LDAPS (Port 636) và StartTLS (Port 389) là gì?

Cả hai đều mã hóa dữ liệu, nhưng cách thức khác nhau:

• LDAPS (Port 636): Kết nối được mã hóa SSL/TLS trước khi bất kỳ dữ liệu LDAP nào được gửi đi. Đây là một kênh an toàn chuyên dụng.
• StartTLS (Port 389): Kết nối bắt đầu ở dạng văn bản rõ (LDAP) trên port 389. Sau đó, máy khách gửi một lệnh “StartTLS” để yêu cầu nâng cấp kết nối lên mã hóa. Hướng dẫn này tập trung vào LDAPS (port 636) vì nó rõ ràng và được hỗ trợ rộng rãi hơn.

3. Cổng 3268 và 3269 là gì? Chúng có liên quan gì đến LDAPS không?

Có, chúng là phiên bản “Global Catalog” (GC) của LDAP/LDAPS. Global Catalog chứa thông tin (một phần) của mọi đối tượng trong toàn bộ rừng (forest) AD.

• Port 3268 (GC): Truy vấn Global Catalog không mã hóa.
• Port 3269 (GC-S): Truy vấn Global Catalog an toàn (đã mã hóa). Khi bạn cấu hình LDAPS (port 636) bằng AD CS theo hướng dẫn này, cổng 3269 cũng sẽ tự động được kích hoạt.

4. Tôi có cần cài đặt chứng chỉ thủ công trên mọi Domain Controller không?

Không. Miễn là bạn làm theo hướng dẫn này và chọn “Enterprise CA” (Bước 4) và cấu hình “Autoenroll” cho nhóm “Domain Controllers” (Bước 5), các DC sẽ tự động liên hệ với CA và đăng ký (enroll) chứng chỉ. Đây là ưu điểm lớn nhất của việc dùng AD CS.

5. Tôi có thể dùng chứng chỉ từ bên thứ ba (Let’s Encrypt, GoDaddy) không?

Có thể, nhưng không được khuyến nghị cho môi trường AD nội bộ. Việc sử dụng AD CS (Enterprise CA) như hướng dẫn là “best practice” vì nó tự động tin cậy trong toàn bộ domain và không tốn chi phí. Nếu dùng chứng chỉ bên thứ ba, bạn sẽ phải cài đặt, gán và gia hạn thủ công trên từng DC.

6. Cấu hình LDAPS có làm chậm máy chủ Domain Controller không?

Về mặt lý thuyết là có, nhưng thực tế là không đáng kể. Việc mã hóa và giải mã SSL/TLS tiêu tốn một chút CPU. Tuy nhiên, các CPU máy chủ hiện đại (vài năm trở lại đây) đều có các tập lệnh (như AES-NI) được thiết kế để xử lý mã hóa ở cấp độ phần cứng. Gánh nặng (overhead) này là cực kỳ nhỏ và bạn sẽ không nhận thấy bất kỳ sự suy giảm hiệu năng nào trong hoạt động bình thường.

7. Lỗi “Certificate Verify Failed” là gì khi máy khách Linux/Java kết nối?

Đây là lỗi phổ biến nhất và là một dấu hiệu tốt, có nghĩa là LDAPS đã hoạt động! Lỗi này xảy ra vì máy khách (máy chủ Linux, ứng dụng Java, v.v.) không tin tưởng CA nội bộ (CongTy-CA) của bạn. Bạn phải xuất chứng chỉ CA gốc (file .CER) từ máy chủ CA và nhập (import) nó vào “Trusted Store” (kho lưu trữ tin cậy) của máy khách. Chi tiết xem tại Mục 7.2 của bài viết.

8. Điều gì xảy ra nếu chứng chỉ LDAPS hết hạn?

Kết nối LDAPS sẽ thất bại. Khi chứng chỉ hết hạn, các máy khách (ứng dụng, máy chủ Linux, v.v.) sẽ từ chối kết nối đến port 636 vì chúng không thể xác minh được danh tính của DC nữa. Tuy nhiên, nếu bạn dùng “Enterprise CA” và cấu hình “Autoenroll” (như Bước 5), các DC sẽ tự động gia hạn (renew) chứng chỉ của chúng trước khi hết hạn, giúp bạn tránh được sự cố này.

Kết luận

Chúc mừng! Bạn không chỉ vừa bật một cái port, mà bạn vừa triển khai cả một hạ tầng Public Key Infrastructure (PKI) nội bộ. Việc cấu hình LDAPS là một bước bảo mật nền tảng và bắt buộc đối với bất kỳ quản trị viên Active Directory nào.

Bằng cách sử dụng AD CS để tạo một Enterprise Root CA, bạn đã tự động hóa toàn bộ quy trình cấp phát và gia hạn chứng chỉ cho các Domain Controller, đảm bảo kết nối LDAP luôn được mã hóa, an toàn và sẵn sàng cho mọi ứng dụng tích hợp.

Tài liệu tham khảo

• Tutorial – Configure LDAPS for Microsoft Entra Domain Services – Microsoft Entra ID | Microsoft Learn
• How To Enable LDAPS on an AD Domain Controller
• Export trusted client CA certificate chain for client authentication – Azure Application Gateway | Microsoft Learn
• How to use LDP.EXE to check connectivity and access to AD
• Verifying LDAPS in Active Directory