Active Directory Domain Services (AD DS) offers many ways to integrate applications and services.
Traditionally, the Lightweight Directory Access Protocol (LDAP) was used by software developers to integrate. While Kerberos-based Integrated Windows Authentication (IWA) can also be used, LDAP has kept a certain foothold for software solutions, as it is also available on non-Windows and non-IIS-based solutions and can be used to integrate with other directories, besides AD DS.
LDAP, however, was never envisioned from the start as a protocol for open networks. Eventually, LDAP over SSL (commonly abbreviated as LDAPS and described in RFC 2830) was introduced in 2000 to address the plain-text nature of the original LDAP (LDAPv3, described in RFC 2251).
Many of the software packages supporting LDAPS have no issues connecting using LDAP, thus removing the need to work with certificates. As appealing as this sounds to AD admins, it should be avoided as the service accounts used to poke around in AD DS through LDAP often have significant privileges. These privileges can be asserted after a malicious person has acquired them through a Meddle in the Middle (MitM) attack.
LDAP Channel Binding has been introduced to counteract MitM and replay attacks, but it only work when using LDAPS. LDAP should be a thing of the past. All LDAP communications to domain controllers should be LDAPS.
But how do you get insights in what accounts on what hosts communicate using plain LDAP and not LDAPS using built-in tools?
That’s the question that this blogpost tries to answer.
Note:
Using Microsoft Defender for Identity, detecting apps and services using LDAP instead of LDAPS is simple, as there is a built-in detection. However the license requirements for Microsoft Defender for Identity may be considered too steep to answer just this one question.
Before you begin
You’ll need to meet the following requirements to detect applications, services and systems using LDAP instead of LDAPS:
Account Requirements
Sign in with an account that is a member of the Domain Admins group, or an account that has delegated permissions to:
- Manage Group Policy objects, or has delegated permissions to Edit Settings or Edit settings, delete and modify security permissions on an existing Group Policy object
- Read the logs on all Domain Controllers within the Active Directory environment.
System requirements
Sign in to each domain controller.
Enabling LDAP diagnostics
Domain Controllers with default settings do not provide the information needed to detect non-S LDAP connections. The 16 LDAP Interface Events diagnostic logging needs to be enabled. This can be achieved using Group Policy or using Windows PowerShell.
Perform these steps to enable auditing Kerberos Service Ticket Operations using Group Policy:
- Right-click Start
- Choose Windows PowerShell (Admin) from the Start Menu to open an elevated Windows PowerShell window.
- Issue the following line of PowerShell:
Set-ItemProperty –Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\" -Name "16 LDAP Interface Events" -Value 2 -Type DWORD
- Type Y and confirm with Enter.
- Close the Windows PowerShell window.
Repeat the above steps for each domain controller in the environment.
Note:
Increasing the size of the Directory Service log can be useful in environments with large amounts of LDAP traffic.
Detecting applications, services and systems using LDAP instead of LDAPS
Now, you can use the following lines of Windows PowerShell to detect the use of LDAP by applications, services and systems towards the domain controllers. Its output displays the last 24 hours of successful connections:
$Hours = 24
$DCs = Get-ADDomainController -filter *
$InsecureLDAPBinds = @()
ForEach ($DC in $DCs) {
Get-WinEvent -ComputerName $DC.Hostname -FilterHashtable @{Logname='Directory Service';Id=2889; StartTime=(Get-Date).AddHours("-$Hours")} >> $null
ForEach ($Event in $Events) {
$eventXML = [xml]$Event.ToXml()
$Client = ($eventXML.event.EventData.Data[0])
$IPAddress = $Client.SubString(0,$Client.LastIndexOf(":"))
$User = $eventXML.event.EventData.Data[1]
Switch ($eventXML.event.EventData.Data[2])
{
0 {$BindType = "Unsigned"}
1 {$BindType = "Simple"}
}
$Row = "" | select IPAddress,User,BindType
$Row.IPAddress = $IPAddress
$Row.User = $User
$Row.BindType = $BindType
$InsecureLDAPBinds += $Row
}
}
$InsecureLDAPBinds | Out-Gridview
Disabling LDAP diagnostics
As the 16 LDAP Interface Events diagnostic logging require additional resources when the setting is enabled, so you might want to disable the setting when you’re done.
Perform these steps to disable auditing Kerberos Service Ticket Operations using Group Policy:
- Right-click Start
- Choose Windows PowerShell (Admin) from the Start Menu to open an elevated Windows PowerShell window.
- Issue the following line of PowerShell:
Set-ItemProperty –Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\" -Name "16 LDAP Interface Events" -Value 0 -Type DWORD
- Type Y and confirm with Enter.
- Close the Windows PowerShell window.
Repeat the above steps for each domain controller in the environment.
Concluding
When you know what applications, services and/or systems connect using LDAP to your domain controllers, you can reconfigure them to use LDAPS.
This is essential to implement LDAP Channel Binding and Signing changes.
Last week, I presented at Techorama Belgium 2022, the Las Vegas Edition. The event was held at Kinepolis Cinemas in Antwerp, Belgium.
After sharing steaks, I drove to the Van der Valk hotel in Antwerp where all Techorama Belgium 2022 speakers stayed.
During breakfast, I saw a lot of familiar faces. I had breakfast with Barbara Forbes and Evert Bleijendaal, both former colleagues at SCCT and now both working at OGD again. 
Login