We've heard consistent feedback that integrating your on premises identities with Azure AD is harder than it should be. There are too many pages of documentation to read, too many different tools to download and configure, and far too much on premises hardware required. We agree!
We've heard your feedback and shared our plans to make Azure AD integration with local directories easier:
To achieve these goals, we've created Azure AD Connect. Now you can connect your on-premises Windows Server Active Directory to your tenant in Azure Active Directory with only 4 clicks.
Jen Field is a Senior Program Manager in my team and has written up a nice guest blog post with the details on AAD Connect below. I hope you'll find it interesting and helpful.
For those of you who just want to get started, you can download the preview from the Azure Active Directory Connect program on MS Connect, (be sure to sign in if you'd like to submit feedback), or you can always give us feedback via the Windows Azure AD Forum.
Alex Simons (Twitter: Alex_A_Simons)
Director of PM
Active Directory Team
I'm Jen Field, one of the Program Managers in the Active Directory team. Today I'm happy to be able to announce the availability of the first step along this path with our first Public Preview of Azure Active Directory Connect (AAD Connect).
AAD Connect is a single wizard that performs all of the steps you would otherwise have to do manually for connecting Active Directory and local directories to Azure Active Directory:
In the Beta release, the AAD Connect wizard provides a guided experience for integrating a single Active Directory forest with Windows Azure Active Directory. In upcoming versions, we plan support multi-forest scenarios.
The shortest path to getting your connection up and running, the Express Settings option configures
directory integration in just 3 clicks, configuring Dirsync with the password hash sync option for a single forest, and then kicking off sync right away. This allows sign on to cloud resources based on Active Directory passwords within 15 - 20 minutes:
We only ask for your on premises Enterprise Administrator credentials (in the future we plan to allow configuration without EA credentials):
We summarize what we are about to configure:
And then we perform the configuration steps, both on premises and in the cloud:
Finally, we let you know the results and what you should do next:
For those who would like the SSO with federation option, or who simply don't want to kick off sync right away, the wizard guides you through choosing and configuring the right solution:
You can deploy Dirsync with password sync or opt for AD FS for Single Sign on via federation:
AD FS has some additional requirements, which we let you know about:
You can deploy one or many AD FS and Web application proxy machines for a complete, highly available solution:
We'll help you to ensure your Azure domains are in the correct state before proceeding to setup federation:
We'll summarize what we're about to configure. Optionally you can choose to configure password sync in addition to AD FS for an easy "High Availability light" via fall back to cloud sign on:
Then we'll perform the installation and configuration steps, again both on premises and in the cloud:
Finally, we'll let you know what manual tasks you need to do, and help you to verify the installation works:
As you'll see in the wizard, we are planning support for multiple forests using AAD Sync soon....
Below are some additional capabilities you won't see in the wizard yet, but we are planning include soon:
We look forward to providing you these options in the near future. In the meantime, go ahead and download the beta, and feel free to provide your feedback and suggestions via MS Connect or on the Azure Active Directory Forum. We look forward to hearing from you!
And if you've read this far, thanks a ton for your time! We really appreciate your interest!
Bravo. If this works then it will be a huge step towards simplifying a rather cumbersome process.
After this integrate into the Powershell Deployment Toolkit and we are in Business :-D
But seriously.. like Alex mentioned: If it works as advertised its a very welcome Addition!
It looks very nice and hopefully it is easyer to set up a sync with Office 365 with this tool. At the moment it is very hard to make a good working sync.
Looks great! Will it also support /fullsql setup for DirSync/AADSync in 50k+ object scenarios? If not, consider it as a featreq from me to add that to the wizard :) That process could really use a wizard interface. Thanks
Any early birds yet? Whats the outcome, any issues?
@jesper: Yes those will be supported for sure.
awesome, thanks for sharing.
why not add this to next version of Active Directory ?
@francoismart: We're keeping it separate for now as we want to be able to update/improve it at a very rapid clip outside of the standard Windows Server ship cycle.
When will this be replacing the current DirSync tool offered in Office 365 Portal?
After setting up multiple domains with ADFS and DirSync, this is wonderful! I'm looking forward to testing this out when we rebuild our QA environment. Great work guys, so many exciting things happening in the cloud these days with Microsoft!
@Curt: We'll get the Office 365 portal linking to us in the near future, hopefully our next release.
Hi, I get stuck on the page where I have to enter my Windows Server AD enterprise administrator credentials. I'm a domain admin (domain admins are member of the enterprise admin group). I have tried to enter my credentials as domain\username, domain.tld\username
and firstname.lastname@example.org, but in all cases I get the same message: "Failed to locate the user principal with identity by type Name". What should I do to correct this?
In trying to setup a test environment, it would have been nice if this article had included all of the prerequisites to enable this. Does this only work with domains that have a public DNS presence? Do I have to have an onmicrosoft.com account to make
this work? Etc.
@Martijn: Thanks for this. We do have a known issue by which you must match the username portion of the SAM account name (such as DOMAIN\user1) to the prefix of the UPN (such as email@example.com). If your user's AD account has, for example, SAM account
name DOMAIN\user1 and UPN firstname.lastname@example.org, we fail with the message you report. This has been reported by a couple of other users, and we plan to fix this in our next release. Let me know if matching the usernames does not solve your problem. Thanks again!