What is Azure AD? Imagine a full Cloud Identity solution offered as a service in Microsoft Azure. It can work with your existing on-premises AD or as a stand-alone directory to offer identity services for applications, either on-premises or in the cloud.  You can read more about Azure AD in the team’s blog here:

In a series of blog posts we will demonstrate various “real world” usage scenarios where organizations can use Azure AD. In this post we will see how we can create a new Azure AD directory, assign a public DNS name to it and finally how we can integrate it with our on-premises AD infrastructure.

Create an Azure AD directory

First we need to create our Azure AD directory which can be done from the Azure Management Portal. You can also use your Microsoft Account to sign-up for a trial to test this scenario.

Notice that during the creation of a new Azure AD directory you need to provide a Domain Name which must be unique and in the form of: <name> You will be able to add your own public DNS name in that same directory later:


At this point you can enable the Azure AD Premium features from the Azure AD directory’s dashboard. Some of the features that we will discuss in upcoming blog posts will require enabling Azure AD Premium (like Group-based application access). You can find a detailed list of the features in Azure AD Basic vs. Azure AD Premium, here:

Associate your public DNS name

The next step is to associate your Azure AD Directory with your public DNS name. This is mandatory if you want to use for example: instead of the built-in as the user credential. To associate this public DNS name (in my case this is: you need to verify ownership by adding specific DNS records (similar to what you would do to verify ownership of your DNS name on Office 365):


Decide how you will integrate your on-premises AD

Before we add Users and Groups, we need to decide how we will integrate our on-premises AD with Azure AD. There are three options:

Option #1: Directory Sync

The first option is to simply synchronize local Users and Groups to Azure AD. In this scenario you install the Azure AD Sync tool to periodically sync your User and Group objects to Azure AD (the default is every 3 hours). The Azure AD Sync tool is based on Forefront Identity Manager (FIM) and as a result it allows you to do advanced filtering based on Organizational Units, Attributes, Group Membership, etc. and of course you can select which attributes you want to sync or even do transformations of those attributes based on Declarative Provisioning Expressions, for example to change the UPN. The latest version also supports multi-forest sync.

You can read more about Azure AD Sync here: and, about filtering here: and about Declarative Provisioning Expressions:

By choosing to do only basic Directory Sync your Users will have different passwords on your on-premises AD and on your Azure AD.


You can find more information on this option here:

The basic advantage of this option is simplicity:  you are creating User and Group objects in Azure AD with the same attributes (or modified according to your rules) and the passwords in Azure AD are completely separate. The main disadvantage is that users have to remember a different password on Azure AD (which might also mean that they have to abide to a different set of password policies as configured in Azure AD) and that SSO scenarios do not work.

Option #2: Directory Sync with Password Sync

This is basically the same scenario as Option #1 with the main difference being that Azure AD Sync will also synchronize the password of the user. Password Sync works by synchronizing the password hash of each user (not the actual plaintext password). This hash is read from the on-premises AD and then encrypted and synchronized to Azure AD. As a result the user’s password is neither exposed to the password sync tool nor to Azure AD or any of the associated services. It is worth noting that the user account which you configure in the Azure AD Sync Tool to read on-premises AD objects has the same read-only permissions in your on-premises AD as the one used in Option #1.

When the User changes his on-premises AD password then the Azure AD Sync service will sync the password, usually in a matter of minutes (during this time the user will not be signed off of any services which use his Azure AD logon).

You can read more about how Password Sync works here:


If you wish you can also optionally configure the “Password write-back” feature in the Azure AD Sync Tool. This allows the User to reset/change his on-premises AD password in Azure AD. This is a useful scenario in cases where the User does not have a way to change his password through your on-premises AD (i.e. external collaborators that do not work in your premises). To enable this feature you must configure your sync AD account to have the “Reset Password” and “Change Password” on your domain (read more here:

The big advantage of this option is that it is as simple to setup as Option #1 but also provides the same password for Users in both on-premises AD and Azure AD. This also means that you practically enforce the same password policy (the one you have on your on-premises AD). On the other hand (and similarly to Option #1) SSO does not work, as the Azure AD objects do not share the same token (they only have similar attributes and the same password hash).

You can read more about this option here:

Option #3: Directory Sync with Single Sign-On

In this scenario you are deploying a Security Token Service on-premises to enable SSO (also called, identity federation) in the Cloud. The Security Token Service can be Active Directory Federation Services (AD FS, a role in Windows Server), Shibboleth Identity Provider (an open-source alternative: or another third-party identity provider. After deploying the STS in your premises you create a Federation Trust with the Azure AD authentication system to provide SSO to your local AD users.


To better understand this scenario we will see in action the sign-on experience from the perspective of a User connecting from outside the organization’s network:

1. The User attempts to authenticate to Azure AD (for example on: and types his username: in the sign-in page provided:



2. Azure AD knows that all users are federated and redirects them from Microsoft Azure to authenticate to your local AD FS installation (for example on



The authentication webpage above is served through your on-premises AD FS implementation. This means that you need to publish AD FS securely through HTTPs. You can achieve this by deploying Web Application Proxy (another Windows Server 2012 R2 role) on your DMZ (or similar). So the user is redirected to your AD FS (securely published through Web Application Proxy).

3. User enters his credentials there. AD FS verifies their validity and redirects the user back to Azure AD where the user is authenticated with the claims provided to him by AD FS. This means the user credentials were provided only to AD FS (on-premises) and nowhere else.

In the case of a User sign-in from a work computer on the corporate network SSO works automatically and transparently to the user (i.e. no sign-in prompts like above).

The steps to plan and deploy an AD FS infrastructure for this scenario are described here: More details about this scenario are described here:

Deploy and Configure the Azure AD Sync Tool

Usually you will deploy the Azure AD Sync Tool on a Windows Server (2008 and above, 2012 R2 recommended) inside your corporate network. This can be a stand-alone server, a member server or even a domain controller, physical or virtual, and will (of course) require internet access to Microsoft Azure and connectivity to the AD Domains you want to synchronize (on the same AD Forest or not). You can find the detailed deployment steps here:

Deploy and Configure AD FS and WAP

The recommended architecture for a typical AD FS/WAP deployment to support AD requires an AD FS Farm deployed behind NLB, inside your corporate network:


And a WAP (Web Application Proxy) Farm deployed behind NLB, in your DMZ (or equivalent):


AD FS requires a database server to store its configuration. You can use the built-in Windows Internal Database mechanism if your User objects are less than 100,000 or a SQL Server cluster if you have more (or simply prefer to use SQL Server).

Note that AD FS on Windows Server 2012 R2 has a built-in mechanism against brute-force and denial-of-service attacks as well as malicious account lockout. This mechanism is called Extranet Lockout Protection and you can read more about this here:

All necessary steps to plan and deploy your AD FS infrastructure to support Azure AD can be found here:

Note: The Azure AD team has released a new convenient tool to make deploying Azure AD Sync, AD FS and all their dependencies much easier. It is called Azure AD Connect and you can find more info about this tool here: and here: Please note that as of the time of this writing this tool cannot be used on production environments, yet.

Verify the deployment

After a first successful synchronization cycle you will be able to see the synchronized users in the Azure AD management portal:


Notice that the synchronized users are marked as “Local Active Directory”. There is nothing stopping you from adding Microsoft Accounts ( in the example above), or pure Azure Active Directory accounts that exist solely in Azure AD.

You verify the deployment by signing-in to an Azure AD service such as

Next Steps

In a series of upcoming blog posts we will see some practical scenarios where we can utilize Azure AD as our Cloud Identity Provider.


  • Nithya

    Excellent post,thanks for making it easy.

  • Surya Chirravuri

    Superb post. Thanks a lot… I have few questions, appreciate if I could get some quick help as I have little time left…
    1) In option 1, is it possible to set a null password on Azure AD, i.e. keep it empty? What if I have a policy that doesn’t allow password hashes to be synced at all?
    2) How does the hash authentication occur on the cloud on option 2 (password sync) – is there an article on how this works behind the scenes?
    3) Is the inbuilt Azure AD STS/IDaaS capable in itself for users to achieve SSO to SaaS applications like Box, Service-Now, etc? i.e. is there a possibility I can authenticate users on the cloud (of course, provided the hash is synced), generate a SAML or WS-Fed and take the user to the SaaS applications? When will I need ADFS? Do I need ADFS for O365 or is there a way to make it work without ADFS?
    4) Is it right if I say I need ADFS in two use-cases – a) When I need to authenticate the user always on the internal network b) When I have a service/application that I have exposed from my network/DC to the outside world and I need a Service Provider functionality. Is this a correct way of thinking?
    5) Is it possible I configure Azure IDaaS to directly talk to internal AD? (may be open a direct connection securely, if possible)? Does this make sense at all (sorry if I am sounding dumb)
    6) If I already have a FIM internally, is it still required if I have a premium license for Azure (As MIM comes with it?)?
    7) If the target systems that FIM connects to move to Azure cloud, how does provisioning flow change? Can you please elaborate a bit on this?

    Thanks in anticipation.