Hi all,

I promised to deliver some behind the scenes blogs on Azure Active Directory Connect. I will be delivering on that promise through a series of blog posts that will explore the functionality of the tool that isn’t well documented (if at all documented) by Microsoft. Our first stop in the journey will be exploring how the Azure Active Directory Sync tool handles synchronizations to and from Active Directory Domain Services (AD DS).

The Azure Active Directory Sync component of Azure Active Directory Connect is built from the same framework as Forefront Identity Manager (now called Microsoft Identity Manger (MIM)). This means the connector for AD DS is very similar (possibly a direct port) of the connector used in MIM. So that means all the documentation for this connector is heavily documented with the MIM documentation right? Oh no no no no. What little documentation that does exist for MIM is at the sub-100 level (really Microsoft?). This means we have to be a bit creative in figuring out exactly how the connector is pulling for changes.

I had heard on the grapevine that the AD DS connector uses the uSNChanged method of querying for directory changes as outlined in the following link. To verify this I setup a small lab with a domain controller and a server running Azure Active Directory Connect (AADC going forward). Like any good AD engineer, I cranked up Field Engineering logging on the domain controller per this link. To my surprise, I saw didn’t see any LDAP queries from my AADC server.

My next step was to do some network captures with Wireshark. During the capture I saw the LDAP traffic coming in encrypted via a TLS tunnel. Foiled yet again… or was I? Thankfully Azure Active Directory Sync has an option where encryption of LDAP traffic can be turned off. This is accomplished by opening the Synchronization Service application on the AADC server, navigating to the Connectors tab, right-clicking the Active Directory Domain Services connector, selecting Properties, select Configure Directory Partitions selection, and clicking the Options button. Uncheck both options as seen in the screenshot below. Once encryption is turned off, the LDAP queries can be read.

When we dig through the capture we see the following LDAP query coming from the AADC server:

baseObject: dc=journeyofthegeek,dc=local
Scope: substree
Filter: (&(|(objectClass=computer)(objectClass=contact)(objectClass=container)(objectClass=domainDNS)(objectClass=foreignSecurityPrincipal)(objectClass=group)(objectClass=inetOrgPerson)(objectClass=msDS-Device)(objectClass=organizationalUnit)(objectClass=user))(!(objectClass=groupPolicyContainer))(!(objectClass=msDS-GroupManagedServiceAccount))(!(objectClass=msDS-ManagedServiceAccount))(!(objectClass=msExchConfigurationContainer))(!(objectClass=msImaging-PSPs))(!(objectClass=msPKI-Key-Recovery-Agent))(!(objectClass=rpcContainer))
Attributes: Reference to this link.
Controls:

• • ControlType: 1.2.840.113556.1.4.417 (LDAP_SERVER_SHOW_DELETED_OID)
  • ControlType: 1.2.840.113556.1.4.529 (LDAP_SERVER_EXTENDED_DN_OID)
  • ControlType: 1.2.840.113556.1.4.2065 (LDAP_SERVER_SHOW_DEACTIVATED_LINK_OID)

<liControlType: 1.2.840.113556.1.4.841 (LDAP_SERVER_DIRSYNC_OID)

The query above is a fairly basic LDAP query. The controls are what we are interested in. Let’s walk through the first three controls quickly.

1. ControlType: 1.2.840.113556.1.4.417 (LDAP_SERVER_SHOW_DELETED_OID)Quick Explanation: This control tells the directory to return deleted objects that match the query filter.
   More Detail: Link
2. ControlType: 1.2.840.113556.1.4.529 (LDAP_SERVER_EXTENDED_DN_OID)
   Quick Explanation: This control tells the directory to return the DN preceded by the objectGUID and objectSID in string format.
   More Detail: Link

• ControlType: 1.2.840.113556.1.4.2065 (LDAP_SERVER_SHOW_DEACTIVATED_LINK_OID)
  Quick Explanation: When used in combination with LDAP_SERVER_SHOW_DELETED_OID, it also returns link (forward/backlink) attributes on deleted object.
  More Detail: Link

The fourth control is the most important piece of the query, so let’s spend some time on it. Active Directory Domain Services provides a few different methods for an application to stay updated on the changes within the directory backend. Three of those methods are change notifications, the DirSync control, and the USNChanged. We are going to focus on the DirSync control, but information on the two other methods can be found here.

The DirSync control allows an application to keep track of changes in the directory by utilizing a piece of data that contains information about the state of the directory as the application last knew it. AD DS puts this of data into a cookie which is updated by the directory each time the application requests a synchronization from the directory. During the initial request (the Full Import run profile in Azure AD Sync) the cookie contains a null value which instructs the directory to return all objects and attributes that match the filter. The directory places a value in the cookie during this initial request. For subsequent requests (the Delta Import run profile in Azure AD Sync) the value of the cookie is used to determine which objects and attributes have changed since the last sync and only that information is returned to the application. The cookie is updated during each subsequent request.

I noticed the connector using the DirSync control I was a bit confused, because much of the documentation out on the web states there are specific permissions and rights required by the identity used by the application in order for that identity to be authorized to leverage the control. After a lot of searching through the web and reading forums, I came across an archived version of an MSDN link that had this interesting piece of information:

LDAP_DIRSYNC_OBJECT_SECURITY (OS): Server 2003 operating system, Windows Server 2008 operating system, Windows Server 2008 R2 operating system, Windows Server 2012 operating system, Windows Server 2012 R2 operating system, and Windows Server 2016 Technical Preview operating system: If this flag is present, the client can only view objects and attributes that are otherwise accessible to the client. If this flag is not present, the server checks if the client has access rights to read the changes in the NC.

This means the identity requesting the use of the DirSync control does not require any permission or right if this flag is set. The caveat being that the application will only receive back the objects and attributes that is authorized to view in the directory.

In the MSDN article noted here, you will notice that the explanation of that flag looks to have been cut off or mistakenly forgotten. Looks like someone made a boo boo. Searching for the flag does yield this article which contains the proper explanation of the flag.

Another thing to note is that DirSync requests to a domain controller are not logged in any event log that I could find. Additionally, they are not logged as traditional LDAP queries are when Field Engineering is enabled. This makes a network capture your only way to identify an application using the DirSync control, unless the application is encrypting the tunnel with TLS. In that scenario you are out of luck. There are rumors that this information will be provided in 2016, but I have yet to test it.

Well there you go, the connector for AD DS uses the DirSync control executed via LDAP to perform its synchronizations against AD DS.

In the next post I will cover the SQL instance that is created during an express installation of Azure AD Connect.