Original text by RUS
If I told you that there was a 90% plus chance that your Domain Controllers allowed receiving credentials in clear text over your network, you would probably wouldn’t believe me. If I went a step further and told you that nearly half of the customers I visit for AD security assessments not only allowed them, but had extremely privileged accounts such as Domain Admins credentials traversing the network in clear text, you would probably think «that wouldn’t happen on my network», well that’s what they all told me too 🙂
With a little bit of effort, you can reveal this common scenario very easily.
[Update] If you have 2008 R2, you need this hotfix to ensure the events have the flag which identifies Simple vs Unsigned binds.
A Simple Check
The first step to understanding if your affected is to look for Event ID 2886 and 2887 in your Directory Service log. If any of your Domain Controllers have the 2886 event present, it indicates that LDAP signing is not being enforced by your DC and it is possible to perform a simple (clear text) LDAP bind over a non-encrypted connection. This configuration is controlled by the security option «Domain controller: LDAP server signing requirements». I nearly always find this setting set to «None».
Our next port of call is the 2887 event. This event occurs every 24 hours and will report how many unsigned and clear text binds have occurred to this DC. If you have any numbers greater than zero, you have some homework to do. Luckily, the rest of this post will help you do just that.
The core of the issue is this, when an application performs a simple LDAP bind, the username and password is transmitted in clear text in the very first packet. The DC doesn’t even have a chance to prevent this exposure from occurring. If this connection is not encrypted at a lower layer such as TLS or IPSec, it may be intercepted and a bad day may soon follow.
OK, how badly am I affected?
Thankfully, we have the ability to increase our «LDAP Interface Events» diagnostic levels on a DC to report when these insecure binds occur. The commands for enabling and disabling are below. Warning: This setting has the ability to create a large number of events into the Directory Service event log. It will also log a number of other LDAP interface errors which may seem extremely alarming, these are normal and don’t freak out too much when you see them. I highly recommend enabling this diagnostic level for a very short period of time (like 1o minutes) during your initial discovery phase. Once you have identified (and remediated) the noisiest offenders, you can begin enabling it for longer periods each time.Копировать
# Enable Simple LDAP Bind Logging
Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2
Копировать
# Disable Simple LDAP Bind Logging.
Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 0
Note: You may need replace the double quotes after copy+paste.
Once we have the 2889 events logged, we can examine them and determine which IP addresses and user accounts are binding insecurely. Looking through them all one by one may take awhile, the following are some resources to help you along.
Custom Event View
Download here -> LDAP Signing Events Custom View.xml
This custom event view that can help you easily isolate «LDAP Signing Events» on your DC’s Once imported, it will create a nice filtered view of all of the relevant LDAP signing events (2886 through 2889). Follow these steps to import it.
- Open Event Viewer.
- Right-click «Custom Views» then select «Import Custom View».
- Provide a path to the downloaded .xml file. Feel free to rename it/change the description and location as you see fit.
- If you are doing this on a management server (and you should be) you will get an error about the service channel being missing. Once you bind to the appropriate Domain Controller, it will show the appropriate events.
If there are no events, awesome! But as per above, if we have 2886 and 2887 events, we need to investigate. With diagnostics enabled, the 2889 events will also show up (possibly in large quantities) in this view.
Insecure LDAP Binds Query Script
Download here -> Query-InsecureLDAPBinds.ps1
The second resource is a simple PowerShell script that will parse and extract the relevant data from the logged 2889 events on your DC into a nice .csv By default, it will only query for 2889 events that occurred in the past 24 hours. You can override this if you wish to go further (or shorter if there is lots of noise)Копировать
.\Query-InsecureLDAPBinds.ps1 -ComputerName dc1.contoso.com -Hours 24
The output .CSV will include IP Addresses, Ports, Username and the binding type. This can help quickly narrow down the affected user accounts and begin your remediation. It should look the following:Копировать
"IPAddress","Port","User","BindType"
"10.0.0.3","60901","CONTOSO\Administrator","Simple"
"[::1]","65445","CONTOSO\Administrator","Simple"
Fixing Your Applications
Sometimes fixing the offending applications is as simple as ticking a «Secure Connection» or «Secure Bind» checkbox inside the applications config. Sometimes this may require the use of certificates on your DC to allow TLS binds to them over TCP 636.
If the application has no way binding securely, throw it out. OK, sometimes thats not always possible, but if your application vendor won’t provide a secure way to do LDAP binds, you will need to get a little extreme and encrypt the whole TCP stream between the application and DC using IPSEC with ESP. Thankfully most modern applications have some kind of ability to perform secure LDAP connections and we don’t need to go this far.
Once you have cleaned up the main offenders (both by privilege and total count) you can repeat the diagnostics process for a little longer each time to track down the overnight scheduled tasks and processes and other connections that happen only periodically. It’s a slow process but required before you block these binds entirely.
Conclusion
Hopefully you stop reading reading this post because your DC’s «Require Signing» for their LDAP configuration. If not, you should now be well aware of the culprits in your environment and on your way to remediating them. In a future post I will explain the process of actually preventing these weak LDAP binds and also monitoring for applications still attempting them (and exposing their credentials in the process)