How can I safely implement required ldap signing?

[ajm-b]

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network...

"If you configure the server to require LDAP signatures, you must also configure the client computers. If you do not configure the client devices, they cannot communicate with the server, which could cause many features to fail, including user authentication, Group Policy, and logon scripts."

Given this - how in the world can you safely implement this? It seems to me that unless everything processed right at the same time - you're guaranteed to have some clients that cannot communicate to even get group policy anymore?

[#2]

@ajm-b 

Set your clients to 'negotiate signing', check server event logs and when you don't see any reports of unsigned connections you are safe to enable server required signing.

Log - Applications and Services Logs\Directory Service

Source - ActiveDirectory_DomainService

Let me know if you need more help.

[#3]

thanks

[#4]

@Steve Norton"If you set the server to require LDAP signatures, you must also set the client devices to do so. Not setting the client devices will prevent client computers from communicating with the server. This can cause many features to fail, including user authentication, Group Policy, and logon scripts."

If clients are set to negotiate, and the server is set to require, clients will be rejected.

[#5]

I hope this helps someone. Here's some initial results from test environment.

[2012 r2 dc, forest/domain level @ 2008 R2, windows 10 1903, rolling with defaults for group policy except these 2 noted below]

1. shutdown client (set to negotiate for both settings)
2. change domain gpo to have "domain controller: ldap server signing requirements" and "network security: ldap client signing requirements" set to REQUIRE SIGNING
3. gpupdate domain controller, verify with mmc rsop that it has applied these settings
4. startup client: I'm able to logon w/o issue. nltest /sc_query:<testenv domain> verifies that the secure channel is established
5. mmc rsop verifies that the client has applied both settings set to REQUIRE SIGNING
6. gpupdate succeeds on client
7. able to browse \\<testenv domain>\sysvol
8. launch ADSIEdit on client: attempting to simplebind to <testenv>:389 while specifying credentials fails with error: "Operation failed. Error code: 0x2028 A more secure authentication method is required for this server. 00002028: LdapErr: DSID-0c090202, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v2580"
9. repeat same scenario except unchecking simplebind in ADSIEdit results in success
10. as expected for this testenv, trying to bind 636/TLS/SSL does not succeed, verifying we aren't falling back to SSL/TLS to avoid required signing without realizing it.
11. sidenote on ADSIEdit oddity: if I didn't check "specify credentials", I could still bind even if simple bind was checked...I'm assuming ADSIEdit was reaching over the already-established secure channel but if someone can confirm that behavior of ADSIEdit I'd appreciate it.

So to summarize: it does seem confirmed that unreachable/offline clients (set to negotiate) are able to come back later after the DC has already processed REQUIRED SIGNING and get the new settings- even though I'm not sure technically how that actually works. If someone can shed light on that I'd appreciate it...I'd assume the client coming back and trying to reach DC for group policy would be like:

1. (client comes back online with its last group policy set to negotiate)
2. client tries to negotiate ldap with DC that is set to REQUIRE ldap signing.
3. DC rejects client's bind attempt
4. client cannot update group policy or talk with DC anymore

...Now it certainly didn't work this way in my testing, but I have no idea why. Do you?

[#6]

@ajm-bIs it simply that the help documentation is misleading?

[#7]

I'm uncertain Mr @Steve Norton...and it's a scary thing to be uncertain about.

[#8 · Accepted solution]

@ajm-b 

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-...

Require signature. The LDAP data-signing option must be negotiated unless Transport Layer Security/Secure Sockets Layer (TLS/SSL) is in use.

So if the client is set to negotiate a connection is possible.

The problem that can be faced is if the client is set to 'required' and the server is set to 'none' then the client will report a bind failure to the calling code as it will not connect to a correctly hardened server.

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network...

Require signing. This level is the same as Negotiate signing. However, if the LDAP server's intermediate saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is returned a message that the LDAP BIND command request failed.