Hello once again and welcome back. This post will conclude my deep dive into Azure Active Directory Connect. Today we will cover how Azure Active Directory Sync (AADS) reaches out to Azure Active Directory (AAD), how the authentication occurs, and what the communication between the two looks like. For this exercise we’ll be using Fiddler to take a deeper look at the traffic.

To capture the traffic between AADS and AAD the machine.config in C:WindowsMicrosoft.NETFramework64v4.0.30319Config needs to be modified to according to this link. After the section below is added, open Fiddler and save the new config and execute a manual initial sync of AADS through PowerShell.

After the sync finishes, we see the sessions captures below.

Let’s break down the process.

1. The application performs an GET for login.windows.net/common/UserRealm/Sync_SERVER03_95b83ea05b5b@journeyofthegeek.onmicrosoft.com?api-version=1.0. Within the header we are requesting home realm discovery on the identity being used to connect to Azure Active Directory, Sync_SERVER03_95b83ea05b5b@journeyofthegeek.onmicrosoft.com. This identity is automatically provisioned in your Azure Active Directory instance during the configuration of Azure Active Directory Connect.The browser is returned a JWT that includes the following information:
   1. account_type=Managed – Indicates the account is an Azure AD Managed account
   2. cloud_instance_name=microsoftonline.com
   3. domain_name=journeyofthegeek.com
   4. ver=1.0
2. The application next performs a POST to login.windows.net/journeyofthegeek.onmicrosoft.com/oauth2/token which is the authorization server endpoint for my sample tenant. The following names and values are posted:
   1. Resource = https://graph.windows.net – Access to Azure Graph API is being requested.
   2. client_id Your instance of AADC’s client ID that was automatically created during installation
   3. grant_type = password – Indicates Resource Owner Credentials flow is being requested.
   4. username = Sync_SERVER03_95b83ea05b5b@journeyofthegeek.onmicrosoft.com – UPN of the AADC account
   5. password – This is a 16 character complex password that was automatically configuring during configuration of AADC. Recall that 16 characters is currently the maximum password length for an Azure AD Managed account.
   6. scope = openid – Here we are requesting OpenID Connect 1.0.

   After our account has been successfully authenticated, we are returned a JWT containing a bunch of information. Let’s take some time and break down the data returned.

   1. access_token – Here we receive back a signed bearer access token that has been issued by my tenant’s token endpoint that includes the claims of the IP address of my AADC server, an audience of the graph API, an authentication method reference indicated we authenticated with a password, the name of the account we authenticated with from Azure AD (actual name, not the UPN), the UPN, and a scope of user impersonation.
   2. expires_in = 3600 – This indicates the access token has a lifetime of 60 minutes.
   3. expires_on = some value – The time the token expires. This value is the number of seconds from epoch.
   4. ext_expires_in = 3600 – I’m not sure what this value is indicating the expiration time for.
   5. id_token – This is an id token that contains similar information about the identity as the access token. This is not signed.
   6. not_before = some value The time after which the bearer token can be used. This value is the number of seconds from epoch.
   7. refresh_token – Our apps refresh token.
   8. resource = https://graph.windows.net
   9. scope = user_impersonation – Indicates the scope of the access token we received is user impersonation.
   10. token_type = bearer – Indicates the access token we received is a bearer token.
3. The application next performs a POST to adminwebservice.microsoftonline.com/provisioningservice.svc and begins to communicate with SOAP provisioning API. That’s correct, I said SOAP. I’m unsure as why MS is using the SOAP instead of the REST-based Graph API. Maybe it’s a legacy thing they are still in the progress of migrating? I won’t spend much time digging into what the communication content looks like because I don’t think it lends a ton of value.

The authentication process outlined in steps 1 and 2 are repeated regardless of whether Azure AD Sync is performing an import or an export. There is some interesting differences in the SOAP calls that I want to call out. During the import/export we see the following calls being made to the API:

1. ReadBackAzureADSyncObject
2. GetCompanyConfiguration
3. UpdateDirSyncConfiguration
4. ProvisionAzureADSyncObjects
5. FinalizeExport

My guess is the first two calls are performed during and import run profile and the last three are performed during an export run profile.

Well folks that is it for today. I hope your inner geek has been satisfied by taking a look behind the “magic” Microsoft loves so much these days.

Thanks for reading!