Azure Active Directory

There are three Azure AD editions:

  • Azure AD Free
  • Azure AD Office365
  • Azure AD Premium (P1/P2)

The features vary per edition, but in all cases we can use Azure AD Connect. For the Premium edition you have licenses per user/month. You can check Licenses / License Features via the Azure Portal.

To populate Azure AD, there are two options. You can create a so-called native account in Azure Active Directory (completely separate identity from ADDS user) or you can start of from the free tool Azure AD Connect. Azure AD Connect replicates on-prem Active Directory users to Azure Active Directory users. It cannot be used the other way around, so always from ADDS to AAD. By default replication occurs every 30 minutes. Urgent changes like password changes are replicated every two minutes. 4You can indicate that you want to replicate a hash of the ADDS password hash from ADDS to AAD. Remember that you can never reverse the AAD hash to the ADDS password hash. It’s irreversible. More details: Note that you may not be able to revert a password hash. You can still enable option Password WriteBack to be able to change the password in AAD and write it back to ADDS.


  • So why do you want Azure AD Connect? It means you can authenticate against Azure Active Directory with your ADDS account.
  • How do you get Azure AD Connect? Go to the Azure Portal, select Azure AD Connect, use the download option to get the tool. Under services you will see aa service named Microsoft Azure AD Sync. In the Azure Portal you can then see if Azure AD Connect is still running successfully.


Let’s start our explanation of authentication in the cloud with a look at on-prem authentication. On-prem authentication uses Kerberos. Here we have tickets and the tickets are encrypted.

  • A client first accesses the IDP to get an user ticket that is encrypted using the user password, so that only the user can decrypt and read the ticket.
  • Next the user calls the IDP again with the user ticket to get access to a certain server, let’s a file server. The identity provider and the file server share a secret. That’s why the ticket can be encrypted using the shared secret and passed back to the client.
  • Next the client sends the server ticket to the file server. The file server knows the secret and can decrypt and read the ticket saying that the user can access the file server.

Why can’t we use Kerberos in the cloud? First and foremost, we don’t have a restricted domain where we can add servers and share secrets between identity providers, users and servers. In other words, tokens can’t be encrypted just like that. Secondly, in the cloud any user and service can be added. We will have to use open standards for tickets and we will have to use encrypted protocols (https), because the tickets are no longer encrypted.

First let’s look at some authentication scenarios in the cloud. Scenario 1 accesses a backend service using an access token. 

Scenario 2 accesses a second backend service using a session token.

Scenario 3 uses federation, that means: authentication is done by an identity provider trusted by Azure AD (think of Microsodt, Google, Facebook, Motion10, etc.).

The above scenarios implicitly use cloud-only authentication. This means Azure AD Connect is running with the password hash option enabled. Users can logon to Azure AD using the same username and password they have in ADDS. ADDS is not involved in the authenticaton process though.

An alternative to cloud-only authentication is hybrid authentication:

  • Pass-through Authentication (PTA). Username/Password is sent to Azure AD but validated against ADDS. In this case we have SSO. If a user is logged in via AAD, it’s effectively authenticated against ADDS.
  • Username/password sent to federated service which then performs authentication.

In the cloud we use tokens instead of tickets. Tokens or JSON Web Tokens or Bearer tokens contain claims. A claim provides assertions about an entity. This can be the end user, the client application or the server application. In OAuth2.0 we distinguish among an access token and a resfresh token. Both tokens are encoded, but not encrypted. That’s why we will have to send the tokens over an encrypted transport channel like https.

  • Access Token (AT). Short-Lived. Typically for one hour. Access Tokens can not be revoked once provided. That means that a compromised token can be used for one hour. It’s a limited risk. Nothing to be done about it. Each backend server needs it’s own access token. The access token passed to the second server is replaced by a Session Token (ST).
  • Refresh Token (RT). Long Lived. Standard 14 days, but can be stretched to 90 days. RT’s can be invalidated, in which case the user will have to re-authenticate. The same RT can be used to access different backend servers. RT tokens provide SSO.

To dive a bit deeper into this. It’s important to no the difference between an access token (OAuth2.0 authorization) and an ID Token (OpenID Connect authentication).

  • An Access Tokenis issued as part of an OAuth2.0 flow. It contains containing the permissions the client has been granted.
  • You can also have an ID token. This token is sent as part of an OpenID Connect flow. Used to sign in a user and get basic information about them.

Microsoft uses the Microsoft Identity Platform to implement authentication/authorization. See:

The Microsoft Identity Platform uses the following protocols:

  • The protocols for Azure AD authentication are OAUth2.0 and OpenId Connect. OpenId Connect is a true authentication protocol built on top of OAuth 2.0. OAuth 2.0 is actually aimed at authorization, but it’s a gray line.
  • Next we have two protocols that are used ever less frequent: SAML 2.0 and WS-Federation. SAML 2.0 like OpenId Connect is used for authentication and also enables SSO. SAML authentication is commonly used with ADFS. WS-Federation is used between identity provider and is more or less like SAML 2.0.

As a final example, we will show two Azure Active Directory scenarios. First all we show the authentication dialog when there are end users involved:

Next we show a scenario where authentication takes place at the application level.

And finally another way to look at it.