With all the fancy features in Active Directory, I almost tend to forget it was originally an x.500 directory services, offering LDAP connectivity. Although today this is less evident, LDAP is intensively used under the hood for directory connectivity. Alongside the older RPC-based protocols it is used for over 90% of the communication to the Active Directory database. (Notable exceptions are password resets)
Below is an architectural view of Active Directory client/server communication, showing LDAP as the linking pin:
Microsoft has enhanced the LDAP implementation in Active Directory Domain Services for Windows Server 2012.
Enhanced LDAP Logging
Logging is useful for troubleshooting. Active Directory admins can enable logging on Active Directory in the registry through Active Directory Diagnostic Event Logging. This is strong stuff, but it is also exactly what you’re craving for in these kinds of situations.
As Microsoft KnowledgeBase article 314980 explains, you can turn on any of the Active Directory Diagnostic Logging categories, available in the registry in the following location:
Specifically, Microsoft has worked to enhance the LDAP logging of level 5 of the 16 LDAP Interface Events registry DWORD value.
Enabling LDAP logging
To enable LDAP logging, perform the following steps:
- Start the Registry Editor by running regedit.exe.
- Locate and click the following registry key:
- In the right pane of the Registry Editor, double-click the 16 LDAP Interface Events.
- Type 5 as the logging level in the Value data box, and then click OK.
- Close the Registry Editor
This will record all events, including debug strings and configuration changes to the Directory Services log of Event Viewer.
Many admins have given Microsoft precise feedback on scenarios where LDAP logging was getting them nowhere, since they were unable to isolate and/or diagnose root causes of many behaviors/failures with the existing logging capabilities.
In Windows Server 2012, Active Directory Diagnostic Event Logging has been enhanced with additional logging that logs entry and exit stats for a given API. The entries themselves now log the operation name, the SID of the caller’s context, the client IP, entry tick and client ID.
New LDAP Controls
The LDAP standard was designed with extensibility in mind. The standard allows the behavior of any operation to be modified through the use of controls. In addition to the repertoire of predefined operations, such as “search” and “modify,” the LDAP v3 defines an extended operation. The pair of extended operation request/response is called an extension.
Microsoft has introduced seven new controls in LDAP for Active Directory Domain Services in Windows Server 2012:
Batched extended-LDAP operations
This new LDAP Control modifies the default behavior to treat all operations within a given batch as a single transaction. When using this control, all operations in the batch will fail or all will succeed. This new control is particularly useful for programmatic schema extensions since the entire list of updates could be treated as a batch.
Require server-sorted search use index on sort attribute (1.2.840.113518.104.22.1687)
This LDAP control eliminates the need for tempTable when performing sorted search, thereby increasing scale possibilities. It is particularly good for large result sets because, in the past, sorted searches would have simply failed.
This LDAP control alters the traditional DirSync behavior and forces the return of specified unchanged attributes.
TreeDelete control with batch size (1.2.840.113522.214.171.1244)
In Windows Server 2008 R2 and earlier, the LDAP batch size is hard-coded with a limit of 16K. This new LDAP control, exposes a mechanism to lower this hard-coded default allowing the delete operation to declare its own batch size. This ensures deletions do not slow convergence beyond system tolerance.
Include ties in server-sorted search results (1.2.840.1135126.96.36.1990)
This LDAP Control, also referred to as the “soft size limit”, returns additional data on ties when performing sorted searches. Within the context of a sorted search, two objects are considered “tied” if their attribute values for the sorted attribute are the same, i.e. the objects are tied by virtue of the common value in the sort attribute (same place in the index).
Using this LDAP control admins can page between sorted search results with large results sets, with a soft size limit, to limit the page-size and ensuring requests are distributed across Domain Controllers, instead of being targeted at one single Domain Controller, because it is the only Domain Controller that knows where pages begin and end.
Return highest change stamp applied as part of an update (1.2.840.1135188.8.131.525)
This LDAP control is similar to searchStats control in that when checked in, it causes the result to contain additional data. This data is the invocationID and highest USN allocated during the transaction (in BER encoded format).
This LDAP control is useful for programmatically determining convergence between any two instances, immediately following an update.
Expected entry count (1.2.840.1135184.108.40.2061)
This LDAP control requires a minimum and maximum value. This control is useful for uniqueness, in-use and/or absence checking. Of course, this new LDAP Control is very powerful when combined with the new Batched extended-LDAP operations LDAP Control.
Microsoft has made several improvements in an essential protocol: LDAP.
When you’re having trouble and need adequate logging capabilities, Windows Server 2012 has got your back. Also, if you’re involved with Active Directory Domain Services from a software developer or ISV point of view, the new LDAP controls might make your work a lot easier. No doubt, Microsoft will try and use the new LDAP controls when they develop new Active Directory solutions and new ways to perform management tasks in the next version of Windows Server.
A list of LDAP Extended Controls