Using Microsoft Flow
If there is anything consistent about Office 365,
Identity management is a huge part of any organization's migration into “the cloud.” Sure, you can move your email, your IM and presence, your document libraries, maybe even your voice and video services into Office 365. But unless your organization is very small, identity management will still take place in your own on-premises Active Directory.
Since the introduction of Office 365, and even before that with the ironically named “BPOS,” Microsoft has had several different solutions for cloud identity management. These solutions have ranged from bad to confusing. The solutions that have been easy to use have lacked good functionality, and the solutions with enterprise functionality have been difficult and costly to deploy.
Azure Active Directory Connect is not a new product. It’s been around for a year or so, but it is the product Microsoft is investing in as the go-to cloud identity management solution going forward. In this blog post, I’m going to look at some of the new and advanced features that make AAD Connect a good solution for the basis of your cloud identity management for Microsoft solutions.
Maybe the most notable accomplishment Microsoft has managed to pull off with AAD Connect is that this tool is very simple to deploy in its most basic configuration, but can be customized to meet many different organizations' needs. Maybe that should not be a notable feature, but in a world where IT solutions are either easy to deploy or highly functional, it’s nice to see a product that is both.
The default “click next seven times” configuration of AAD Connect is a fully functional solution that will work just fine for many small organizations. The advanced features, which we’ll talk about below, are not that hard to configure and add a lot of value.
The DirSync synchronization schedule has long been a pain point for administrations migrating into Office 365. I’ve had to explain hundreds of times that DirSync runs every three hours, so when creating a new user on-premises, it can take quite a while for that user to show up in the cloud. Of course, you could manually force a DirSync cycle to kick off, but the process to do that changed a bunch of times, and it was always pretty confusing. The old DirSync (and Azure AD Sync) product did have a configuration file that could be edited to change that sync schedule, but that was never a supported configuration.
Now with AAD Connect, the default sync schedule is 30 minutes, and there are simple PowerShell commands to modify that schedule in a supported way.
Get-ADSyncScheduler and Set-AdSyncScheduler are the commands you need to control your synchronization schedule.
This is one of those features I'm on the fence about. Or maybe it would be better to say this feature is great for some organizations, but something most organizations should be turning off.
In its default “click next seven times” configuration, AAD Connect will set itself to check in with Microsoft and automatically download and install upgrades. If your reading this article (and I’m going to guess you are), this is probably not the configuration for you. Even if you do the express install, AutoUpgrade is easily controlled via the Get-ADSyncAutoUpgrade and Set-ADSyncAutoUpgrade PowerShell cmdlets.
I recently had a question from a customer who had migrated into Office 365 some time ago. When they did their initial migration, it made sense for them to use cloud-only identities. But as they added more Microsoft cloud services, they needed to move to synchronized identities.
With DirSync, or AAD Sync, this would have been a rather painful process of matching the source anchors for on-premises accounts to Azure AD accounts. Now the process is very easy – just make sure the user’s on-premises and cloud UPNs match, and let AAD Connect take care of the rest. With very little work, we reset about 150 users from cloud-only identities to synchronized identities.
Anyone who has run DirSync, or AAD Sync, will tell you that the errors and reporting you get when there is an issue syncing an account are less than desirable. With Azure AD Connect, you will soon be able to go into your Azure AD portal (https://portal.azure.com) and find much better information about account sync errors.
In the screenshot below, you can see my tenant does not have the “Sync Error” reporting turned on yet, but that is where the improved error reporting will show up.
This is an awesome new feature that was announced at Ignite this year. It’s a feature that falls in between password sync and full AD FS. Pass-through authentication is not going to be available until sometime in 2017, but in the meantime, here is a quick rundown of how it will work.
In June 2013, Microsoft added password sync to DirSync so you could copy your on-premises passwords from Active Directory into Azure Active Directory and your users could have a “similar sign-on” experience. For many customers going to Office 365, that is a great solution. It does not require all the servers and load balancers that you need with AD FS, but there are still a few problems with that solution.
First, your password gets copied to Microsoft. Even small organizations with compliance requirements can be uncomfortable with that. Second, you don’t get single sign-on when you use password sync. Finally, password sync does not give you a single place where you can “turn off” or control a user’s account. Pass-through authentication can address all these issues. The bottom line is pass-through authentication gives you almost all the benefits of deploying AD FS without the high deployment costs.
Pass-through authentication will be available in 2017 (hopefully early in 2017, but it’ll be ready when it’s ready). We’ll have more details about how to deploy this feature as it gets closer to release.
There you have it. If your organization is not using AAD Connect to synchronize user accounts from your on-premises Active Directory into Azure Active Directory, you're missing out on some great features with more even better features coming soon. Personally, I don’t see a lot of reason to bother with those complex AD FS deployments unless your organization has some very strict user authentication controls that you must apply.
Nathan is a five time former Microsoft MVP and he specializes in Exchange, Microsoft 365, Active Directory, and cloud identity and security.