In March 2020, Microsoft will release its monthly updates. With those updates, Microsoft will disable insecure LDAP Bindings, which is going to break a lot of your systems (hopefully not). But this was already communicated, and you know all about it, right? If not, you should read those two articles that can help you with understanding what is happening and when.
What I wanted to provide in this blog post are four cmdlets that will make that task a bit less complicated. Instead of spending time on setting up monitoring, reading up on events, you can spend time on tracking down machines doing insecure LDAP communication, and preventing that before Microsoft does this for you.
For that purpose, I've updated three of my PowerShell modules to provide you automated tools to make your job easy.
Let's start with PSWinReportingV2, and it's “famous” Find-Events cmdlet. Two new reports added – LdapBindingsSummary and LdapBindingsDetails. The first report can tell you which, if any, Domain Controllers are getting queries done in an insecure way. You see, each day, DC log one event that provides that information. We're reading that and presenting it in easy to understand way. The second report is a bit more complicated because it requires you to enable diagnostic logging for LDAP queries. Since PSWinReportingV2 doesn't do that, it may happen you get some events in summary, but no events in detail view. Don't worry, I've got you covered with ADEssentials module and Set-WinADDiagnostics that I'll describe a bit later.
$Events = Find-Events -Report LdapBindingsDetails,LdapBindingsSummary -DatesRange Last7days -DetectDC $Events $EVents.LdapBindingsSummary | Out-htmlView -ScrollX $Events.LdapBindingsDetails | Out-HtmlView -ScrollX
Since we have requested more than one report, the output from Find-Events is a hashtable of reports. We can then use PSWriteHTML to get it pretty displayed in HTML, or you can use any other way to consume the output. Since I already had LDAP Diagnostics turned on, it shows me events for two of my reports. The first report covers LDAP Bindings Summary, which shows you how many simple binds or unsigned binds happened in one day per each Domain Controller that was getting them.
Since I have quite a few in my Domain, I decided to enable diagnostics on all Domain Controllers and verify which IP addresses with which accounts are doing those simple binds. In the second report, all that shows up. You may need to wait some time before gathering those events after enabling diagnostics.
As explained above, PSWinReportingV2 is just helping you out, providing Summary by default and Details only if you have diagnostics enabled. But how do I enable them? Well, you can do it manually via registry or use the ADEssentials module, and it's Set-WinADDiagnostics and Get-WinADDiagnostics (in the order you prefer).
With that cmdlet, you can easily enable diagnostics for any type, but in our case, we need to allow it to for LDAP Interface Events with Level Basic. This command contains the ability to exclude, include domains, domain controllers, so it's easy to enable it on one DC or just one domain within a forest.
Set-WinADDiagnostics -Diagnostics 'LDAP Interface Events' -Level Basic -SkipRoDC
We can also run verification of whether our change did happen.
Set-WinADDiagnostics -Diagnostics 'LDAP Interface Events' -Level Basic -SkipRoDC Get-WinADDiagnostics
Easy? Of course, you can always change it back to None when done diagnosing.
My final cmdlet (fourth as the blog title suggested) is Invoke-Testimo that comes in updated module Testimo. I've added simple detection based on Events. If you want to check for insecure bindings, choose the correct source as below.
invoke-testimo -Sources DCLDAPInsecureBindings -showreport
Of course, nothing is stopping you from executing it without picking up Sources. However, be prepared that for large forest/domain, it's going to take a while. Also, there is a known issue where the PSWriteHTML report that you see above, which has multiple tabs and numerous tables, is very, very slow when switching tabs. This is a known issue and something that I plan on fixing in PSWriteHTML. Sorry about that.
Whether the above modules/commands help you or not, please make sure to secure your Active Directory before Microsoft does this for you. And when they do with patch deployment, you may find yourself with not so fun situation of broken services. If you're into using commands above all you have to do is:
Install-Module PSWinReportingV2 -Force Install-Module Testimo -Force Install-Module ADEssentials -Force # actually Testimo will install ADEssentials so not really needed
After installing or updating those modules, you're good to go, and the above commands should be available. As always, before running anything on production, make sure to test in the test environment and review source codes that I provide on GitHub. I've tested this successfully on three different forests, and it seems to be working correctly. However, if you find a bug, please let me know.
