Checking the server for errors as is customary every morning, I open up server manager and see a few warnings and a few errors on the server roles.
Lets investigate the warning on Active Directory Domain Service (ADDS) first. A quick examination of the event log leads me to event 2886.
The security of this directory server can be significantly enhanced by configuring the server to reject SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP binds that do not request signing (integrity verification) and LDAP simple binds that are performed on a cleartext (non-SSL/TLS-encrypted) connection. Even if no clients are using such binds, configuring the server to reject them will improve the security of this server.
Some clients may currently be relying on unsigned SASL binds or LDAP simple binds over a non-SSL/TLS connection, and will stop working if this configuration change is made. To assist in identifying these clients, if such binds occur this directory server will log a summary event once every 24 hours indicating how many such binds occurred. You are encouraged to configure those clients to not use such binds. Once no such events are observed for an extended period, it is recommended that you configure the server to reject such binds.
They further go on to describe the problem in these words:
The security of a directory server can be significantly improved by configuring the server to reject Simple Authentication and Security Layer (SASL)LDAP binds that do not request signing (integrity verification) and LDAP simple binds that are performed on a clear text (non-SSL/TLS-encrypted) connection. SASLs may include protocols such as Negotiate, Kerberos, NTLM, or Digest.
Unsigned network traffic is susceptible to replay attacks in which an intruder intercepts the authentication attempt and the issuance of a ticket. The intruder can reuse the ticket to impersonate the legitimate user. Additionally, unsigned network traffic is susceptible to man-in-the-middle attacks in which an intruder captures packets between the client and the server, changes the packets, and then forwards them to the server. If this occurs on a LDAP server, an attacker can cause a server to make decisions that are based on forged requests from the LDAP client.
If you don’t understand these security features and what SASL bind or LDAP simple binds are- then imagine it simply as clients accessing and communicating with the AD using plain english, which anyone could eavesdrop on. You certainly don’t want anyone listening to your AD.
In order to see if your clients are using these communication methods, we need to turn up the logging level for LDAP Interface Events, and then wait to see if we get any error messages. I would suggest monitoring these events for a few days before making changes- blocking these binds will cause a client using them to disconnect, and better to work on that proactively.
Open Regedit (Start>Run>Regedit) and navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
You will see that this key has listed a bunch of diagnostic features, all set to zero. You can enable the logging for each of these events by changing the number to anything up to 5. A list of what each number does can be found here.
Change the value of 16 LDAP Interface Events to 2 by double clicking it and changing 0 to 2, and hitting enter.
Now keep your eye on the Event Log for event ID 2889, which will contain the IP Address of the client connecting with these binds.
Alternately, if you disable these binds, the server will post one log event every 24 hours with ID 2888.
After a few days, or hours, or no time depending upon how patient you are, you may check the Event Log and find these entries, or not. To make things easier you could create a custom log in event viewer, and filter in only event id’s 2886, 2888, and 2889.
LDAP Event Log
As you can see, my filter is only finding event id 2886, which is the security for the bind warning. I am not seeing any 2888 or 2889, which would mean that clients were connecting using these binds. So let’s go ahead and correct the security vulnerability less privilege is more.
To do this, we need to configure the server to REQUIRE LDAP signing. This is done by Group Policy. Microsoft recommends that you make this change in the Default Domain Policy– yet I do not touch that one. So I am going to make a new GPO and link it in the domain, then apply it to all computers. You can make the changes to the Default Domain Policy if you want.
Open up GPMC from Start>All Programs>Administrative Tools>Group Policy Management.
Right click your domain, and click Create a GPO and link it here…
Name it something appropriate, like LDAP Signing.
Then open the GPO by right clicking it and selecting Edit. Now drill down to:
Computer Configuration>Policies>Windows Settings>Security Settings>Local Policies>Security Options.
Right-click on Domain Controller: LDAP Server Signing Requirements and select properties.
Check off Define this Policy Setting.
Select Require Signing in the drop-down box.
Click ok and accept the warning. You can follow the link to Microsft’s KB article describing what is going on.
Basically, older clients might be configured to use these unsigned binds, pretty much pre XP Pro SP2. If all of your clients are updated or using newer Windows versions, you don’t have to worry about configuring them to start signing. If you have older clients, and don’t know how to change them- you might want to leave this setting alone.
This is a good setting to change to lock down your server, and close unneccessary vulnerabilities in the path between client and server. A hacker might be able to intercept a unsigned packet and change it, then forwarding it to your server. The server would read the packet and execute actions based on the hackers unsigned packet.
As always if you break your network, it’s not my fault 🙂