In the last post I gave a demo on using the new Azure AD connect tool to integrate your on premise domain with Azure Active Directory. The process is fairly simple but one question I received is: How do I integrate my office 365 subscription and users with my on premise domain? Well thanks to the tool, this process is fairly easy if you have taken the step of ensuring your Office 365 user accounts match closely to your existing domain accounts. If they don’t then you will probably need to do some manual cleanup before your integration. I’ll cover some of those steps manual steps later in the post.



When you create an Office 365 subscription Microsoft will actually provision an Azure Active Directory instance for you behind the scenes. If you have an Azure Subscription you can connect the two so that you can manage your O365 domain from the Azure Management Portal. So in essence the process is very close to the last process besides a few minor configuration changes. The first change is during the Identifying Users step. Here you will to select an Active Directory attribute that will match up on premise and online accounts. In my case is was very simple since the email addresses where the same so I chose the Mail attribute. SID’s may be your choice for Exchange scenarios.

Next, on the Optional Features step you can select the check box next to “Azure AD app and attribute filtering” to let the Connect tool know about other applications that should be synced.

One you check the Apps option, the tool will enable a new section where you can set more explicit options about application and attributes. The tool is smart enough to map additional AD attributes in order to correctly integrate the applications with your domain users.

I chose all the default applications just in case I want to add Microsoft Online tools in the future. You can be more granular about specific AD attributes as well but I left those as is. After you complete the wizard and first sync, your users should start showing up in O365.

That covers the easy part when your user’s and structure are fairly simple. However, production environments are often anything but simple. Here are a few things that you should be ware of:


  • Active Directory must have certain settings configured in order to work properly with single sign-on. In particular, the user principal name (UPN), or logon name, must be set up in a specific way for each user. Use the Microsoft Deployment Readiness Tool to inspect your Active Directory environment to generate a report that includes information about whether or not you are ready to set up single sign-on and what changes you need to make to prepare for single sign-on.
  • The domain you choose to federate must be registered as a public domain with a domain registrar or within your own public DNS servers.
  • If you have already set up Active Directory synchronization, the user’s UPN may not match the user’s on-premises UPN defined in Active Directory. To fix this, rename the user’s UPN using the Set-MsolUserPrincipalName cmdlet in the Microsoft Azure Active Directory Module for Windows PowerShell.