What is C-LDAP in Microsoft Active Directory services?
Active Directory (AD) is a directory service developed by Microsoft. Active Directory services include AD Certificate Services, AD Domain Services, AD Federation Services, AD Lightweight Directory Services, and AD Rights Management Services. A server running Active Directory Domain Services (AD DS) is called a domain controller.
Among other protocols, Active Directory uses LDAP (Lightweight Directory Access Protocol) on TCP port 389.
It also uses C-LDAP (Connection-less Lightweight Directory Access Protocol) on UDP port 389 for searches against the rootDSE entry.
What is AD rootDSE entry?
The rootDSE entry is created by default during Active Directory configuration, and can be queried by unauthenticated clients (also known as AD-Ping). This entry provides the configuration status of the server, and contains attributes that represent the features, capabilities, and extensions provided by the particular server.
If your Active Directory is exposed to the Internet, querying the rootDSE entry allows hackers to collect information about your server and AD configuration to perform information gathering and prepare an attack.
Also, since C-LDAP is based on UDP, the rootDSE query can be exploited to perform amplification attacks (the attacker can spoof his target IP address to saturate it with rootDSE replies):
How to verify if your server is vulnerable?
Use the following command from a remote machine, as root, to collect the rootDSE information of your Active Directory service:
# nmap -Pn -sSU -p 389,636 --script ldap-rootdse <Your-server-IP>
PORT STATE SERVICE
389/tcp open ldap
| LDAP Results
| currentTime: 20170000115711.0Z
| subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=ws2012,DC=ms
| dsServiceName: CN=NTDS Settings,CN=SERVERNAME,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=ws2012,DC=ms
| namingContexts: DC=ws2012,DC=ms
| namingContexts: CN=Configuration,DC=ws2012,DC=ms
| namingContexts: CN=Schema,CN=Configuration,DC=ws2012,DC=ms
| namingContexts: DC=DomainDnsZones,DC=ws2012,DC=ms
| namingContexts: DC=ForestDnsZones,DC=ws2012,DC=ms
| defaultNamingContext: DC=ws2012,DC=ms
| schemaNamingContext: CN=Schema,CN=Configuration,DC=ws2012,DC=ms
| configurationNamingContext: CN=Configuration,DC=ws2012,DC=ms
| rootDomainNamingContext: DC=ws2012,DC=ms
| supportedControl: supported.extension.OID.
| supportedLDAPVersion: 3
| supportedLDAPVersion: 2
| supportedLDAPPolicies: MaxPoolThreads
| supportedLDAPPolicies: MaxPercentDirSyncRequests
| supportedLDAPPolicies: MaxDatagramRecv
| supportedLDAPPolicies: MaxReceiveBuffer
| supportedLDAPPolicies: InitRecvTimeout
| supportedLDAPPolicies: MaxConnections
| supportedLDAPPolicies: MaxConnIdleTime
| supportedLDAPPolicies: MaxPageSize
| supportedLDAPPolicies: MaxBatchReturnMessages
| supportedLDAPPolicies: MaxQueryDuration
| supportedLDAPPolicies: MaxTempTableSize
| supportedLDAPPolicies: MaxResultSetSize
| supportedLDAPPolicies: MinResultSets
| supportedLDAPPolicies: MaxResultSetsPerConn
| supportedLDAPPolicies: MaxNotificationPerConn
| supportedLDAPPolicies: MaxValRange
| supportedLDAPPolicies: MaxValRangeTransitive
| supportedLDAPPolicies: ThreadMemoryLimit
| supportedLDAPPolicies: SystemMemoryLimitPercent
| highestCommittedUSN: 15800080
| supportedSASLMechanisms: GSSAPI
| supportedSASLMechanisms: GSS-SPNEGO
| supportedSASLMechanisms: EXTERNAL
| supportedSASLMechanisms: DIGEST-MD5
| dnsHostName: SERVER.FQDN
| ldapServiceName: SERVER.SPN
| serverName: CN=SERVERNAME,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=ws2012,DC=ms
| supportedCapabilities: supported.capabilities.OID.
| isSynchronized: TRUE
| isGlobalCatalogReady: TRUE
| domainFunctionality: 6
| forestFunctionality: 6
|_ domainControllerFunctionality: 6
If the command returns a time-out, the service might already be filtered.
Active Directory Domain Services (AD DS) are designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose these services directly to the Internet or, in general, to an environment where untrusted clients can directly access these services.
Different options are available to mitigate this issue and protect your server:
- Use your firewall to filter inbound connections to your server, and only allow the trusted network IPs/hosts that need to contact your AD DS to access it.
While restricting UDP/389 will prevent amplification attacks exploitation, restricting TCP/389 and TCP/636 will prevent information disclosure.
- Design your AD DS infrastructure with a secure architecture. Depending on your needs, you should review if your architecture requires DirectAccess connectivity (VPN-like feature), or requires AD Federation Services (Web single-sign-on feature):
Additional best practices for securing active directory:
Additional information for designing your AD DS infrastructure: