HOWTO: Detect Apps and Services using LDAP instead of LDAPS

LDAP integrated devices

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:

  1. Right-click Start
  2. Choose Windows PowerShell (Admin) from the Start Menu to open an elevated Windows PowerShell window.
  3. Issue the following line of PowerShell:

    Set-ItemProperty –Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\" -Name "16 LDAP Interface Events" -Value 2 -Type DWORD

  4. Type Y and confirm with Enter.
  5. 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:

  1. Right-click Start
  2. Choose Windows PowerShell (Admin) from the Start Menu to open an elevated Windows PowerShell window.
  3. Issue the following line of PowerShell:

    Set-ItemProperty –Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\" -Name "16 LDAP Interface Events" -Value 0 -Type DWORD

  4. Type Y and confirm with Enter.
  5. 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.

One Response to HOWTO: Detect Apps and Services using LDAP instead of LDAPS

  1.  

    In my experience the setting [16 LDAP Interface Events=2] generates much other events.
    I would also check Event ID 2887, by default every 24 hour this will log an event if a unsigned/insecure ldap bind was completed. The combo of 2887/2889 will help a lot in my opinion.

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.