- Interact with Azure Cosmos DB with PowerShell - Tue, Sep 14 2021
- Azure health services: Track Microsoft cloud outages and maintenance - Wed, Sep 8 2021
- Powerline: Customize your PowerShell console - Tue, Aug 31 2021
Here's the setup: you want to give your local Active Directory users single sign-on (SSO) access to cloud apps that use your Azure Active Directory (Azure AD) tenant for authentication.
The normal pattern is to deploy Azure AD Connect to one or more local infrastructure servers and configure the service to synchronize local AD identities to Azure AD. Depending on how you structure that account synchronization, your local users can use their "email address" (actually their user principal name) and their local password to sign into your organization's Azure-based cloud apps.
Azure AD Connect, as it existed historically, suffered from some significant problems, including but not limited to:
- All configuration needed to be done locally on your Azure AD Connect server(s).
- No in-box fault tolerance; instead, you configured additional Azure AD Connect servers to run in staging mode.
- The ADSync PowerShell module didn't work in PowerShell Core, and the commands were of no help.
I have some good news: Microsoft's Azure AD team has done some great work in the hybrid identity space and now offers a cloud provisioning model that addresses the aforementioned shortcomings. Let's dig in!
In the name of completeness, let's review some hybrid identity prerequisites you need to take care of before you can implement any sort of Azure AD account replication. First, you need to add your business's Domain Name System (DNS) domain name to your Azure AD tenant. Your goal is to have your users' Azure AD sign-in UPN match their business email address. This means you may need to add an alternate UPN suffix to your local AD users' account attributes to match the Azure AD domain.
Azure AD Connect uses TCP 443 (TLS encryption), so there is no requirement for a site-to-site VPN or ExpressRoute connection. That said, you should work with your network engineering team so that Azure AD Connect ports and protocols are allowed to escape your corporate perimeter.
Lastly, be sure to run Microsoft's idFix tool to sort out any potential local AD account attribute formatting issues prior to your initial synchronization.
Set up cloud sync ^
The instructions I'm giving you here work whether this is your first local Azure AD Connect agent or you're already using the existing Azure AD Connect client. The cloud provisioning package can be installed alongside an existing Azure AD Connect installation.
Sign into the Azure portal, browse to the Azure AD Connect blade in your Azure AD tenant, and click Manage cloud sync. In the Azure AD Provisioning view, click Download agent. The following screenshot shows the Azure portal user interface.
Next, run the Azure AD Connect provisioning agent package on your Windows Server member server or domain controller. As I said, your existing Azure AD Connect installation, if you have one, will be upgraded automatically.
The Provisioning Agent installation process comprises the following steps:
- Authenticate to your Azure AD tenant as a Global Administrator.
- Authenticate to the local AD as a domain admin and enable Azure AD Connect to create a group managed service account (gMSA).
- Connect your local AD directory to your Azure AD tenant.
The following screenshot shows me provisioning the required gMSA.
When installation is complete, the wizard will prompt you to define a provisioning configuration in the Azure portal. In the meantime, take note of the services associated with your brand-new Azure AD Connect application. These services all run in the security context provided by the previously mentioned gMSA.
Define a provisioning configuration ^
Back in the Azure portal, navigate to Azure AD, select Azure AD Connect from the settings, and then click New configuration.
The Edit provisioning configuration interface is shown in the screenshot below. To define a configuration:
- Choose a local AD scoping option. You can synchronize all domain users, selected security groups, or selected organizational units. Note that you have to type the distinguished names of your OUs.
- Manage the local AD user and group attributes that will replicate to Azure AD. Note you can enable password hash synchronization or not. If not, then the synchronization method uses passthrough authentication.
- Optionally verify that the synchronization engine works properly by testing with a local AD user account. Again, you need to type the AD distinguished name here.
- Provide a notification email address.
- Enable or disable the service.
If you've deployed the cloud provisioning agent on a server that already has Azure AD Connect running, Microsoft recommends you avoid attempting to synchronize the same objects in both environments. In other words, if my DEV OU is synchronizing with Azure AD Connect and my OPS OU is synchronizing with Azure AD Connect Cloud Provisioning, that's fine.
Back on the Azure AD Provisioning blade, you can review all agents and/or Azure Activity Log data, as shown below. Clicking the configuration takes you back to the configuration details, where you can make changes when needed.
Of course, you'll want to test that account synchronization is working. In the next composite screenshot, you can see my local AD test user Sarah's local AD account as well as her successful sign-in into my Azure AD tenant's MyApps portal.
With respect to high availability, all you need to do now is install the Provisioning Agent on additional local AD servers and create a configuration for them. In the screenshot below, you can see I added my company.pri domain controller (which has an alternate UPN suffix of timw.info) to my synchronization environment.
Lastly, Microsoft (finally!) rewrote their Azure AD Connect PowerShell cmdlets. You now need the AADCloudSyncTools PowerShell module, available (believe it or not!) in the PowerShell Gallery.
The new PowerShell module works on PowerShell Core and has quite a few dependencies, including the Microsoft Authentication Library (MSAL) bits and the AzureAD module.
Run the following command from an administrative PowerShell Core session on your Azure AD Connect server:
I show you the module's enclosed command in our final screenshot.
I'm grateful to report that Microsoft did indeed create help files for these commands as well.
Remember that as a Public Preview product, we're still in the early days with Azure AD Connect cloud provisioning. Yes, the interface is a bit spare at the moment, and having to type DNs is annoying. Also, the logs give too many GUIDs and object IDs and not enough human-readable metadata, in my humble opinion.
Subscribe to 4sysops newsletter!
That said, I give the Azure AD engineering team a virtual "high five" for finally addressing some of the previous Azure AD Connect version's biggest weaknesses. The bottom line is that this solution works, and you can extend your local AD domain's identities into Azure AD quickly, relatively easily, with high availability, and without the need of a VPN or ExpressRoute circuit.