AD LDAP session security requirements
Microsoft's edit ·
Microsoft's commit message in MicrosoftDocs/SupportArticles-docs · commit 478ac15 · +89 −0 lines · also on GitHub
The file is new at this commit, or was moved here from another path: every line shows as added.
1
+---
2
+title: LDAP session security settings and requirements after ADV190023
3
+description: Discusses LDAP session security settings and requirements after security advisory ADV190023 is installed.
4
+ms.date: 07/07/2023
5
+author: Deland-Han
6
+ms.author: delhan
7
+manager: dcscontentpm
8
+audience: itpro
9
+ms.topic: troubleshooting
10
+localization_priority: medium
11
+ms.reviewer: herbertm, wincicadsec, kaushika
12
+ms.custom: sap:ldap-configuration-and-interoperability, csstroubleshoot
13
+---
14
+# LDAP session security settings and requirements after ADV190023 is installed
15
+
16
+This article discusses LDAP session security settings and requirements after security advisory ADV190023 is installed.
17
+
18
+_Applies to:_ Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
19
+_Original KB number:_ 4563239
20
+
21
+## Summary
22
+
23
+This article introduces the functional changes that are provided by security advisory [ADV190023](https://portal.msrc.microsoft.com/security-guidance/advisory/ADV190023). Additionally, this article describes the security settings for each kind of Lightweight Directory Access Protocol (LDAP) session, and what is required to operate the LDAP sessions in a secure way.
24
+
25
+ADV190023 discusses settings for both LDAP session signing and additional client security context verification (Channel Binding Token, CBT). In the implementation, there are two separate items:
26
+
27
+- **LDAPServerIntegrity** and events logged on Domain Controllers
28
+- **LdapEnforceChannelBinding** and events logged on Domain Controllers.
29
+
30
+When you determine the best path to improve security according to ADV190023, there may be actions needed by application owners in both areas. However, the settings and requirements to meet them are different. It's also quite possible that a solution for both topics consists in a single change. For example, by moving from simple bind to SASL using Kerberos or TLS with simple bind.
31
+
32
+The new Channel Binding Token (CBT) option is the LDAP TLS implementation of the [Extended Protection for Authentication](/dotnet/framework/wcf/feature-details/extended-protection-for-authentication-overview) (EPA) scheme that is described in RFC 5056.
33
+
34
+> [!NOTE]
35
+> "EPA" and "CBT" can be used interchangeably in this context.
36
+
37
+## More information
38
+
39
+The method by which LDAP session security is handled depends on which protocol and authentication options are chosen. There are several possible session options:
40
+
41
+- Sessions on ports 389 or 3268 or on custom LDS ports that don't use TLS/SSL for a simple bind: There's no security for these sessions. This is because credentials are transmitted in clear text. Therefore, there's no secure key material to provide protection. These sessions should be disabled by setting **LDAPServerIntegrity** to **Required**.
42
+- Sessions on ports 389 or 3268 or on custom LDS ports that don't use TLS/SSL for a Simple Authentication and Security Layer (SASL) bind.
43
+- Sessions that use TLS/SSL by using a predetermined port (636, 3269, or a custom LDS port), or standard ports (389, 3268, or a custom LDS port) that use the STARTTLS extended operation.
44
+
45
+### LDAP sessions not using TLS/SSL, binding by using SASL
46
+
47
+If LDAP sessions are signed or encrypted by using an SASL logon, the sessions are secure from Man-In-the-Middle (MITM) attacks. This is because you can obtain the signing keys only if you know the user password. You don't have to have Extended Protection for Authentication (EPA) information.
48
+
49
+The SASL method that is chosen may have its own attack vectors, such as NTLMv1. But the LDAP session itself is secure. If you're using Kerberos AES 256-bit encryption, that is as good as it gets in 2020.
50
+The following policy guidelines apply:
51
+
52
+- The **LDAPServerIntegrity=2** setting is important for this session option because it enforces the use of signing by the client. When you encrypt the sessions, this requirement is also met.
53
+- The **LdapEnforceChannelBinding** setting has no bearing on this session option.
54
+
55
+### LDAP sessions using TLS/SSL and simple bind for user authentication
56
+
57
+There's no CBT information added for these sessions. The quality of the TLS client implementation governs whether the client can detect an MITM attack (through server certificate name checking, verification of CRL, and so on).
58
+
59
+The following policy guidelines apply:
60
+
61
+- The requirement for **LDAPServerIntegrity** is met because the TLS channel provides signing. The level of security that the TLS channel provides depends on the TLS client implementation.
62
+- The **LdapEnforceChannelBinding** setting has no bearing on this session option.
63
+
64
+### LDAP sessions using TLS/SSL, binding by using certificate for user authentication
65
+
66
+Currently, there's no CBT information added for these sessions. The quality of the TLS client implementation governs whether the client can detect an MITM attack (through server certificate name checking, verification of CRL, and so on). Client certificate authentication is sufficient to block MITM attacks, but it doesn't prevent other categories of attacks that can be mitigated only by appropriate client-side validation of the TLS certificate that is presented by the server.
67
+
68
+The following policy guidelines apply:
69
+
70
+- The requirement for **LDAPServerIntegrity** is met because the TLS channel provides signing. The level of security that the TLS channel provides depends on the TLS client implementation.
71
+- The **LdapEnforceChannelBinding** setting has no bearing on this session option.
72
+
73
+### LDAP Sessions using TLS/SSL, binding with SASL for user authentication
74
+
75
+In this scenario, TLS provides the session security for encryption, and the encryption keys are based on the server certificate. Specifically for SASL authentication that uses NTLM, the NTLM authentication data may have been relayed from the session that was held by the MITM attacker. In the case of such an attack, there's no proof that the client has a valid password hash.
76
+The CBT information is protected against tampering through signing or encryption (depending on the authentication protocol) by using a session key that can be obtained only by knowing the user's or server's credentials. The MITM attacker wouldn't have this password hash if it intercepted an NTLM authentication.
77
+
78
+The following policy guidelines apply:
79
+
80
+- The **LdapEnforceChannelBinding** setting is used for this session option. When you set this value to **2**, the LDAP server requires CBT information (equivalent to EPA), and it's required to pass verification.
81
+- The requirement for **LDAPServerIntegrity** is met because the TLS channel provides signing. The level of security that it provides depends on the TLS client implementation and whether CBT is required.
82
+
83
+## References
84
+
85
+For more information, see the following articles:
86
+
87
+- [Extended Protection for Authentication](https://msrc.microsoft.com/blog/2009/12/extended-protection-for-authentication/)
88
+- [Control Extended Protection for Authentication using Security Policy](/archive/blogs/askds/control-extended-protection-for-authentication-using-security-policy)
89
+- [Supporting Extended Protection for Authentication (EPA) in a service](/windows/win32/secauthn/epa-support-in-service)
Microsoft's Markdown source from MicrosoftDocs/SupportArticles-docs, © Microsoft Corporation, under CC BY 4.0. Changed lines with up to 3 unchanged lines around each; ChangeIntel kept this copy 10 Oct 18:27 UTC. The commit date is when the source changed, which can be hours or days before Learn published it.