Understanding the differences between Azure AD Roles and Azure RBAC Roles with respect to the levels tenant, root, management group and subscription

I find that getting to understand the differences between Azure AD Roles and Azure RBAC Roles with respect to the following levels are often overlooked or misunderstood:

• Tenant
• Root
• Management group
• Subscription

Those who have not yet had the opportunity to be exposed to larger organizations where multiple subscriptions and the use of management groups for organizing subscriptions may not realize the way in which all these components interact with each other so this blog post serves to provide an overview of them.

Let me begin by providing the official Microsoft documentation for each of the components and note that if you decide to reach all of them then you may not need to read this blog post.

Quickstart: Set up a tenant
https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant

What are Azure management groups?
https://docs.microsoft.com/en-us/azure/governance/management-groups/overview

Microsoft Azure glossary: A dictionary of cloud terminology on the Azure platform - Subscription
https://docs.microsoft.com/en-us/azure/azure-glossary-cloud-terminology#subscription

Associate or add an Azure subscription to your Azure Active Directory tenant
https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-how-subscriptions-associated-directory

Classic subscription administrator roles, Azure roles, and Azure AD roles (must read)
https://docs.microsoft.com/en-us/azure/role-based-access-control/rbac-and-directory-admin-roles

Note that there isn’t a Microsoft document that explains what the Root level is but the following diagram should explain what and where it sits among the other components:

Notice that I’ve included an on-premise Active Directory in the diagram to denote that domains within the traditional Active Directory Domain Services (AD DS) can be synchronized into Azure AD after they have been added as a custom domain. The user accounts, computer accounts and groups (also known as security principals) that are synchronized into AAD (Azure Active Directory) can be used to assign Azure permissions from various levels of the resources (e.g. Root, manage groups, subscriptions, and resources). As accounts are primarily synchronized from AD DS to AAD and not the other way around, you cannot grant permissions to your on-premise resources with AAD accounts. I’ve also included Office 365 in the diagram to depict how Azure AD roles for SaaS application management (O365, D365, PowerBi, Intune), which I will elaborate later in this blog post.

Azure account and Azure subscriptions

Before jumping into the roles used to manage Azure, it is important to understand that an Azure account represents a billing relationship. This essentially means that an Azure account is all of the following:

• A user identity
• One or more Azure subscriptions
• An associated set of Azure resources.

The administrator who creates the account is the Account Administrator for all subscriptions created in that account as well as the default Service Administrator for the subscription.

Azure subscriptions help administrators accomplish the following:

• Organize access to Azure resource
• Control how resource usage is reported, billed, and paid for (https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/view-all-accounts)

An example can be where there are multiple environments for a project and each environment’s budget should be billed separately for their own Azure consumption. Having multiple subscriptions under the same tenant would allow the access to resources and billing costs to be isolated.

Lastly, each subscription is associated with an Azure AD directory and cannot have more than one even though an Azure AD directly can be associated to more than one subscription. The following is a diagram that depicts the relationship between the Azure AD tenant owner, the subscription and the resources.

The Beginning of Azure – Classic Subscription Administrator Roles

When Azure was first released, access to resources was managed by only the following three administrator roles:

• Account Administrator
• Service Administrator
• Co-Administrator

Those who got into Azure later (after RBAC roles were introduced) will see references to these accounts in the Classic administrators tab:

Or alternatively some CSP subscriptions such as the one below provides the informational message indicating:

This type of subscription does not support classic administrators.

The Evolution of Azure Roles with RBAC

Having only the 3 type of roles to manage the full scope of Azure resources did not scale very well so Microsoft later added Azure role-based access control (Azure RBAC) to provide a more fine-grained access management to resources. Azure RBAC provided 70 built-in roles that could be assigned at different scopes (Management Group, Subscription and Resources), and allows the creation of custom roles. There are four fundamental Azure roles. The first three apply to all resource types:

Azure role	Permissions	Notes
Owner	Full access to all resources Delegate access to others	The Service Administrator and Co-Administrators are assigned the Owner role at the subscription scope Applies to all resource types.
Contributor	Create and manage all of types of Azure resources Create a new tenant in Azure Active Directory Cannot grant access to others	Applies to all resource types.
Reader	View Azure resources	Applies to all resource types.
User Access Administrator	Manage user access to Azure resources

The rest of the 66 roles can be found here: https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles Being familiar with these roles is useful for the AZ exams.

While most of the new environments should have move away from the Azure classic deployment model, it is important to note that only the Azure portal and the Azure Resource Manager APIs support Azure RBAC. Users, groups, and applications that are assigned Azure roles cannot use the Azure classic deployment model APIs. I would highly recommend the following document to understand the differences:

Azure Resource Manager vs. classic deployment: Understand deployment models and the state of your resources
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/deployment-models

Azure RBAC roles are available throughout the Azure portal via the Access control (IAM) blade for management groups:

… subscriptions:

… resource groups:

… other resources (a disk resource in the screenshot below):

In the Azure portal, role assignments using Azure RBAC appear on the Access control (IAM) blade. This blade can be found throughout the portal, such as management groups, subscriptions, resource groups, and various resources.

What is RBAC?

As a refresh, RBAC abbreviates for Role-Based Access Control, which is used to define what the security principal that is assigned the RBAC role, can perform. The nuts and bolts of how RBAC work in Azure is where a built in or custom role has a definition with a collection of permissions. The definition lists the operations that can be performed and these can include read, write, and delete. One of the ways to review the definition is to use the Get-AzRoleDefinition cmdlet with a specified role such as Contributor as shown below:

PS C:\> Get-AzRoleDefinition "Contributor" | ConvertTo-Json

{

"Name": "Contributor",

"Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",

"IsCustom": false,

"Description": "Lets you manage everything except access to resources.",

"Actions": [

"*"

],

"NotActions": [

"Microsoft.Authorization/*/Delete",

"Microsoft.Authorization/*/Write",

"Microsoft.Authorization/elevateAccess/Action",

"Microsoft.Blueprint/blueprintAssignments/write",

"Microsoft.Blueprint/blueprintAssignments/delete"

],

"DataActions": [],

"NotDataActions": [],

"AssignableScopes": [

"/"

]

}

List Azure role definitions

https://docs.microsoft.com/en-us/azure/role-based-access-control/role-definitions-list?tabs=roles

Note the Actions that are allowed (the * denotes all actions) and the NotActions that are not allowed (granting authorization, elevating access, and Blue Print write and delete).

What are Azure AD Roles? They should not be mistaken for Azure Roles (RBAC)

It is important to recognize that Azure AD roles and Azure roles (RBAC) are not the same. Azure roles are as described from the previous sections, while Azure AD roles are used to manage Azure AD resources in a directory such as create or edit users, assign administrative roles to others, reset user passwords, manage user licenses, and manage domains. Think of them as the traditional Active Directory but a modernized version used in the cloud with a drastically different architecture. The following table describes a few of the more important Azure AD roles.

Azure role	Permissions	Notes
Global Administrator	Manage access to all administrative features in Azure Active Directory, as well as services that federate to Azure Active Directory Assign administrator roles to others Reset the password for any user and all other administrators	The person who signs up for the Azure Active Directory tenant becomes a Global Administrator.
User Administrator	Create and manage all aspects of users and groups Manage support tickets Monitor service health Change passwords for users, Helpdesk administrators, and other User Administrators
Billing Administrator	Make purchases Manage subscriptions Manage support tickets Monitors service health

The Azure AD roles can be found in Roles and administrators blade:

The complete list of Azure AD roles can be found here: https://docs.microsoft.com/en-us/azure/active-directory/roles/permissions-reference

Differences between Azure roles and Azure AD roles

Microsoft’s official documentation states that at a high level, Azure roles control permissions to manage Azure resources, while Azure AD roles control permissions to manage Azure Active Directory resources with the following table highlighting some of the differences:

Azure roles	Azure AD roles
Manage access to Azure resources	Manage access to Azure Active Directory resources
Supports custom roles	Supports custom roles
Scope can be specified at multiple levels (management group, subscription, resource group, resource)	Scope can be specified at the tenant level (organization-wide), administrative unit, or on an individual object (for example, a specific application)
Role information can be accessed in Azure portal, Azure CLI, Azure PowerShell, Azure Resource Manager templates, REST API	Role information can be accessed in Azure admin portal, Microsoft 365 admin center, Microsoft Graph, AzureAD PowerShell

Are there any overlaps between Azure roles and Azure AD roles?

One of the common questions I get asked about Azure roles and Azure AD is whether they overlap and the short answer is no as shown in the diagram I presented earlier:

Azure AD role permissions can't be used in Azure custom roles and vice versa. The only situation where Azure AD spans into the resources that Azure RBAC roles manage is if a Global Admin elevates their access by activating the Global Admin can manage Azure Subscriptions and Management Groups switch in the Azure portal as shown in the following screenshot:

Access management for Azure resources

Terence Luk can manage access to all Azure subscriptions and management groups in this tenant.

https://docs.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin

Enabling this option will grant the user the Azure RBAC role named User Access Administrator role to all subscriptions for the tenant as shown in the screenshot below:

Notice that there is a Foreign Principal for ‘Tec… labeled above. The subscription in this example was provisioned by the CSP partner Tech Data and by accepting the invite, they were granted Owner permissions to the subscription. It is also important to note that the User Access Administrator role allows the user to grant other users access to Azure resources, which is only a permission an Owner has.

Azure AD and Office 365

Those who work heavily in the Office 365 space will recognize that some Azure AD administrator roles span into Microsoft Office 365. These roles include the Global Administrator role and the User Administrator role. The following is a screenshot of the Roles listed in the Microsoft 365 admin center Roles portal:

This list is can be expanded to show the rest of the non-administrative roles:

Notice how there is a Billing admin in the Microsoft 365 roles. This is the same role as the Billing Administrator in Azure AD and assigning this role in either Azure AD or Microsoft 365 will have the other reflect the same change:

 

This is also the same for the Global Administrator role in Azure AD and in Office 365:

CSP Permissions for Subscriptions

Having worked for CSP over the past few years, one of the most common questions I get asked by the client we as the CSP is trying to establish a relationship with is what type of permissions are granted when they accept us (the vendor) as the their CSP and the answer is that we are granted Global Administrator and Helpdesk admin roles as shown in the Microsoft 365 admin console screenshot below:

Which can be removed if required:

As well as a Owner as shown in the Azure portal below:

Here are some useful reference documents about this topic:

Azure subscriptions and resource management
https://docs.microsoft.com/en-us/partner-center/customers-revoke-admin-privileges#azure-subscriptions-and-resource-management

Delegated admin privileges in Azure AD
https://docs.microsoft.com/en-us/partner-center/customers-revoke-admin-privileges#delegated-admin-privileges-in-azure-ad

Invite a customer to establish a reseller relationship with you
https://docs.microsoft.com/en-us/partner-center/request-a-relationship-with-a-customer#invite-a-customer-to-establish-a-reseller-relationship-with-you

Transitioning to CSP for Seat-based services
https://docs.microsoft.com/en-us/partner-center/transition-seat-based-services

Multi-partner functions in CSP
https://docs.microsoft.com/en-us/partner-center/multipartner

I hope this blog post has been informative for anyone who may be looking for information about the differences between Azure AD roles and Azure RBAC roles.

Enabling user for Teams Enterprise Voice fails with: "Management object not found for identity"

Problem

You’ve signed into Office 365 with the appropriate PowerShell modules and cmdlets:

Import-Module SkypeOnlineConnector

$sfbSession = New-CsOnlineSession

Import-PSSession $sfbSession

… and proceed to use the Set-CsUser cmdlet to enable a user for Teams Enterprise Voice but it fails with the following error:

PS C:\> Set-CsUser -Identity mesheiah@contoso.com -EnterpriseVoiceEnabled $true -HostedVoiceMail $true -OnPremLineURI tel:+7324

Management object not found for identity "mesheiah@contoso.com".

+ CategoryInfo : NotSpecified: (:) [Set-CsUser], ManagementException

+ FullyQualifiedErrorId : Microsoft.Rtc.Management.AD.ManagementException,Microsoft.Rtc.Management.AD.Cmdlets.SetO

csUserCmdlet

+ PSComputerName : admin0b.online.lync.com

The user being enabled for Teams Enterprise Voice has been previously enabled for an on-premise Skype For Business Enterprise Voice so you use the following cmdlet to list the uri properties and notice that the LineURI is still configured with the on-premise deployment:

PS C:\> Get-CsOnlineUser -Identity mesheiah@contoso.com | FL *uri

OnPremLineURI :

LineServerURI :

LineURI : TEL:+14165555555;ext=1324

Including the OnPremHostingProvider to the cmdlet will display the following SRV: value for it:

Attempting to use the Set-CsUser cmdlet to configure the LineURI to null will fail:

PS C:\> Set-CsUser -Identity mesheiah@contoso.com -LineURI $null Unable to set "LineURI". This parameter is restricted within Remote Tenant PowerShell.

+ CategoryInfo : InvalidArgument: (:) [Set-CsUser], ManagementException

+ FullyQualifiedErrorId : LineURI,Microsoft.Rtc.Management.AD.Cmdlets.SetOcsUserCmdlet

+ PSComputerName : admin0b.online.lync.com

PS C:\>

You’ve confirmed that the user has been removed from the on-premise Skype for Business Server.

Solution

One of the possible reasons why this error would be thrown is if the user account still has the msRTCSIP-DeploymentLocator attribute populated with the SRV: value:

This attribute and its value is required for the on-premise Skype for Business configuration but would prevent the user account that is synced into Azure AD to be enabled for Teams Enterprise Voice. To correct the issue, simply open the properties and Clear the value:

Issue a synchronization between the on-premise AD and Azure AD:

Start-ADSyncSyncCycle -PolicyType Delta

Wait for a few minutes and the account should have the LineURI and OnPremHostingProvider attributes empty.

Proceeding to enable the account for Enterprise Voice will now complete.

PowerShell script to extract ObjectGUID, convert to Base64 encoded string, and assign immutableID for Azure AD account for hard matching with AD Connect

I recently had a client who used Office 365 for Exchange Online and Teams while also having an on-premise Active Directory but did not appear to have AD Connect deployed to synchronize their on-premise Active Directory accounts with their Office 365 Azure AD accounts. This became a problem when we started the WVD deployment so the client agreed to have us focus on synchronizing the two directories before commencing with other planned projects.

Azure AD Connect Soft Match vs Hard Match

As some may already know, there are two ways of matching accounts in on-premise Active Directory and Azure AD:

1. Soft Match
2. Hard Match

Soft Match uses the properties of userPrincipalName and ProxyAddresses to determine (evaluated by Azure AD) whether an account in the on-premise Active Directory can be merged with an Azure AD account. This essentially means that if an account is found to have the same userPrincipalName or the same primary SMTP address of ProxyAddresses, then AD Connect will merge the two accounts.

More information about ProxyAddresses matching with the primary SMTP address can be found here:

How to use SMTP matching to match on-premises user accounts to Office 365 user accounts for directory synchronization
https://support.microsoft.com/en-us/help/2641663/use-smtp-matching-to-match-on-premises-user-accounts-to-office-365

Hard Match uses the property sourceAnchor/immutableID to match the on-premise Active Directory account to the Office 365 account. The default sourceAnchor that Azure AD Connect uses for the on-premise Active Directory is the objectGUID property and the immutableID property is a value assigned to the Azure AD user account. To perform a Hard Match between two accounts, we would set the immutableID property of the existing user in Azure AD to the Base64 encoded string of the ObjectGUID of the user in the on-premise AD.

More information about soft and hard match can be found here:

Azure AD Connect: When you have an existing tenant
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-existing-tenant#sync-with-existing-users-in-azure-ad

The Problem

The plan for merging the accounts between on-premise and the cloud was to use the soft match method and the initial test with a newly created account worked without any issues. However, proceeding to accounts that have existed in the on-premise Active Directory would consistently throw a Duplicate Attributes and AttributeValueMustBeUnique error in the AD Connect export job. After reviewing the KB article below without finding a resolution, I decided to proceed with the hard match method.

Troubleshooting Errors during synchronization
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-sync-errors

The immediate issue I had with the hard match method was that it required a lot of manual labour to extract the ObjectGUID from the on-premise AD account, convert it to a Base64 encoded string, then import it into the Azure AD account’s immutableId attribute.

Extract Immutable ID

$UPN = "jsmith@contoso.com"

$user = Get-ADUser -Filter 'UserPrincipalName -eq $UPN'

$name = $user.name

$immutableid = [System.Convert]::ToBase64String($user.ObjectGUID.tobytearray())

Import Immutable ID

Set-MsolUser -UserPrincipalName jsmith@contoso.com -ImmutableId <convertedObjectGUID>

Having to perform the above for 50, 500 or 5000 and more accounts would not be efficient.

Solution

As with many laborious tasks in technology, the best way to minimize the amount of manual labour is to script the process and the following demonstrates this.

Step #1 – Extracting accounts in on-premise Active Directory

We will need to first obtain a list of users we’ll be hard matching with the accounts in Azure AD. If you are matching accounts that are nicely organized in OUs, you can use the following PowerShell cmdlet to export them into a CSV file:

Get-ADUser -Filter * -SearchBase "OU=Toronto,OU=Contoso-Users,DC=contoso,DC=com" -Properties * | Select-Object name,UserPrincipalName,emailaddress | export-csv -path c:\temp\Toronto.csv

The PowerShell cmdlet above will export all of the accounts in the specified OU with the fields:

1. Name
2. UserPrincipalName
3. emailAddress

Repeat the above for any other OUs that need to be matched.

Step #2 – Extracting accounts in Azure AD

The environment I worked in did not consistently have mirroring accounts in the on-premise Active Directory and Azure AD so I decided to export the list of accounts in Azure AD to compare in a spreadsheet:

Get-MsolUser | Select-Object DisplayName,UserPrincipalName,@{Name=’ProxyAddresses’;Expression={[string]::join(“;”, ($_.ProxyAddresses))}},ImmutableId | export-csv -path c:\temp\Toronto-MSOL.csv

Step #3 – Compare the accounts in on-premise AD and Azure AD

With the two CSV files extracted, I placed the UPNs into an Excel spreadsheet and used Home > Conditional Formatting > Highlight Cells Rules > Duplicate Values feature to identify which accounts have matching ones in the other directory.

Step #4 – Extract on-premise AD accounts’ ObjectGUID and Convert to ImmutableID

Now that we have a list of UPNs for users who we intend on matching from the on-premise Active Directory, proceed to create a txt file with just the UPNs separated by line breaks and use the following PowerShell script to extract the ObjectGUID then convert the value to Base 64 so it can be assigned as the immutableID:

foreach ($UPN in Get-Content C:\temp\TorontoAccounts.txt) {

$user = Get-ADUser -Filter 'UserPrincipalName -eq $UPN'

$name = $user.name

$immutableid = [System.Convert]::ToBase64String($user.ObjectGUID.tobytearray())

#$UPN,$name,$immutableid

#Store the information from this run into the array

[PSCustomObject]@{

UPN = $UPN

Name = $name

ImmutableID = $immutableId

} | Export-Csv C:\temp\UPNsWithImmutableID.csv -notype -Append

}

Step #5 – Import the UPNs with ImmutableIDs into Azure AD

The final step in this process is to use the CSV created in step #4 to assign the immutableIDs to the identified UPNs in Azure AD with the following script:

$onPremADUsers = Import-Csv c:\temp\UPNsWithImmutableID.csv

foreach ($row in $onPremADUsers)

{

#$row.UPN, $row.Name, $row.ImmutableID

Set-MsolUser -UserPrincipalName $row.UPN -ImmutableId $row.ImmutableID

}

The above will read the CSV file and assign the immutableID.

Step #6 – Confirm that the ImmutableIDs have been assigned

The last step, which is more of a verification step, is to review the UPNs that were assigned with the immutableIDs:

$onPremADUsers = Import-Csv c:\temp\UPNsWithImmutableID.csv

foreach ($row in $onPremADUsers)

{

Get-MsolUser -UserPrincipalName $row.UPN | Select-Object DisplayName,UserPrincipalName,ImmutableId

}

Hope this helps anyone who is looking for a quicker way of extracting and assigning sourceAnchor/immutableID so AD Connect can hard match accounts.

Attempting to set immutableId for user throws the error: "Set-MsolUser : Uniqueness violation. Property: SourceAnchor."

Problem

You’re attempting to use the Set-MsolUser cmdlet to configure the immutableId attribute for a user in Azure Active Directory but receive the following error:

PS C:\> Set-MsolUser -UserPrincipalName jsmith@contoso.com -ImmutableId "zxGeOiOTdkivMtgkOsuvKA=="

Set-MsolUser : Uniqueness violation. Property: SourceAnchor.

At line:1 char:1

+ Set-MsolUser -UserPrincipalName jsmith@contoso.com -ImmutableId ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : OperationStopped: (:) [Set-MsolUser], MicrosoftOnlineException

+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.UniquenessValidationException,Microsoft.Onlin

e.Administration.Automation.SetUser

PS C:\>

Reviewing the properties of the user account that you are trying to assign the immutableID value to confirms that it is null:

Get-MsolUser -UserPrincipalName jsmith@contoso.com | FL immutableId

Using Get-MsolUser to search for an account with the immutableID does not return any results:

Get-MsolUser | Where-Object {$_.ImmutableId -eq "zxGeOiOTdkivMtgkOsuvKA=="} | select UserPrincipalName

Solution

One of the most common reasons I’ve found for this error is if a deleted user object has the same immutableID assigned to it. A typical scenario would be:

1. An effort was made to merge on-premise Active Directory accounts with Azure AD but Azure AD Connect created a new account with a random number following the name rather than merge the two accounts
2. The administrator deletes the new account and attempts to assign the ObjectGUID (converted to base 64) of the on-premise Active Directory account to the Azure AD account

To confirm whether there is an account in the deleted users container, execute the following cmdlet:

Get-MsolUser -ReturnDeletedUsers

The following cmdlet can return the UPN along with the immutableID of the user accounts found in the deleted users container:

Get-MsolUser -ReturnDeletedUsers | FL UserPrincipalName,immutableID

Once the account with the conflicting immutableID is identified, the following cmdlet can be used to delete it:

Remove-MsolUser -UserPrincipalName jsmith@contoso.com -RemoveFromRecycleBin

With the account removed, you should now be able to assign the immutableID.

Azure AD Connect no longer synchronizes and displays the error AzureADConnect has stopped working

Problem

You’ve noticed that the Azure AD Connect server in the on-premise environment is no longer synchronizing with Azure AD and attempting to launch the synchronization engine displays the following error:

AzureADConnect has stopped working

Problem Event Name: CLR20r3

Problem Signature01: AzureADConnect.exe

Attempting to run an AD Sync via PowerShell will indicate that the Synchronization service isn’t running:

Windows PowerShell

Copyright (C) 2014 Microsoft Corporation. All rights reserved.

PS C:\Windows\system32> Start-ADSyncSyncCycle -PolicyType Delta

Start-ADSyncSyncCycle : Synchronization Service is not running.

At line:1 char:1

+ Start-ADSyncSyncCycle -PolicyType Delta

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : WriteError: (Microsoft.Ident...ADSyncSyncCycle:StartADSyncSyncCycle) [Start-ADSyncSyncCy

cle], InvalidOperationException

+ FullyQualifiedErrorId : Synchronization Service is not running.,Microsoft.IdentityManagement.PowerShell.Cmdlet.S

tartADSyncSyncCycle

PS C:\Windows\system32>

Solution

One of the reasons why the above errors would be thrown is if the AD Connect server has run out of drive space on the C drive. Increasing the C drive space or cleaning up unneeded files to create space will correct the issue:

Deploying Azure AD Connect for Office 365 with AD FS for authentication

One of the methods for providing authentication for Office 365 services is to redirect users back to an on-premise AD FS (Active Directory Federation Services) portal so that authentication can be handled by the local infrastructure with Domain Controllers. Some organizations prefer this route because they may already have AD FS setup for multiple services with a MFA solution configured and would like to unify authentication requests to their on-premise infrastructure because they have yet to migrate their infrastructure to the Azure cloud. In other instances, the organization may already have most of their infrastructure migrated to the Azure cloud but would like to leverage the additional capabilities of AD FS. I won’t go into the details of each option but refer to the following documentation for more information:

Azure AD Connect user sign-in options
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-user-signin#federation-that-uses-a-new-or-existing-farm-with-ad-fs-in-windows-server-2012-r2

I’ve come across many organizations who have their AD Connect installed on a domain controller but it is actually not recommended by Microsoft:

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-prerequisites

Installing Azure AD Connect on a Domain Controller is not recommended due to security practices and more restrictive settings that can prevent Azure AD Connect from installing correctly.

Other security concerns are as follows:

• Restarts of the server for troubleshooting AD Connect would affect domain controller services, DNS or other roles that may be on the server
• DR for domain controllers would not be as straightforward with the additional AD Connect service installed and the same will be for the AD Connect
• AD Connect installs a version of SQL Server 2012 Express Edition database which complicates the demotion of a domain controller if that is to be done in the future
• SQL Server 2012 is an additional component that can raise security concerns when on a domain controller
• Extra application or agent increases the attack surface (SQL Server are known for vulnerabilities)
• Azure AD Connect service accounts requiring administrative permissions are added locally to the server which means it would be placed into the Builtin\Administrators group thus resulting it having administrative privileges to the AD Domain
• Local install of SQL Server would consume additional memory thus resulting in extra memory consumption contending with the domain controller’s use of RAM to cache the ntds.dit database
• If the domain controller AD Connect is installed on is not a GC then that can cause issues

I would suggest reviewing the Microsoft provided documentation so that you can have the information required to make the best decision that meets the organization’s requirements.

With the above stated, the purpose of this post will be to demonstrate the process of installing and setting up Azure AD Connect to use AD FS as the user sign-in method for the organization on a Windows Server 2019 server with an already deployed AD FS on Windows Server 2019 farm.

For more information about deploying AD FS on Windows Server 2019, refer to my previous blog posts:

Deploying a redundant Active Directory Federation Services (ADFS) farm on Windows Server 2019
http://terenceluk.blogspot.com/2020/04/deploying-redundant-active-directory.html

Deploying a redundant Active Directory Federation Services (ADFS) Web Application Proxy servers on Windows Server 2019
http://terenceluk.blogspot.com/2020/04/deploying-redundant-active-directory_21.html

Custom Domain Prerequisite

Begin by ensure that the organization’s sign-in domain (typically the primary SMTP domain) has been added as a custom domain and verified with the required TXT record in your Azure tenant:

Proceed to download the latest Azure AD Connect from the Azure Active Directory portal:

In the event where the organization’s Active Directory domain is non-routable (e.g. contoso.local), you will need to prepare the domain for directory synchronization as outlined in the following documentation.

Prepare a non-routable domain for directory synchronization

https://docs.microsoft.com/en-us/office365/enterprise/prepare-a-non-routable-domain-for-directory-synchronization

Install Azure AD Connect

Launch the downloaded AzureADConnect.msi file to start the installer:

Proceed to install Azure AD Connect:

Configure Azure AD Connect

I usually recommend to never go with Express settings as this configures Azure AD Connect with default settings, which most administrations may not go back to review the documentation to understand what it does and may have unanticipated consequences in the future.

I would like to encourage everyone who needs to set up AD Connect to go through all the following documentation that will outline the configuration parameters for a custom installation:

Custom installation of Azure AD Connect
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-custom

Setting up AD FS for sign-in also is not available via the Express Settings so select the Customize button:

By leaving all of the optional settings unchecked, AD Connect will set up a SQL Server 2012 Express LocalDB instance, create the appropriate groups, and assign permissions without intervention. For more information about the optional settings, please refer to the following table:

Use an existing SQL Server	Allows you to specify the SQL Server name and the instance name. Choose this option if you already have a database server that you would like to use. Enter the instance name followed by a comma and port number in Instance Name if your SQL Server does not have browsing enabled. Then specify the name of the Azure AD Connect database. Your SQL privileges determine whether a new database will be created or your SQL administrator must create the database in advance. If you have SQL SA permissions see How to install using an existing database. If you have been delegated permissions (DBO) see Install Azure AD Connect with SQL delegated administrator permissions.
Use an existing service account	By default Azure AD Connect uses a virtual service account for the synchronization services to use. If you use a remote SQL server or use a proxy that requires authentication, you need to use a managed service account or use a service account in the domain and know the password. In those cases, enter the account to use. Make sure the user running the installation is an SA in SQL so a login for the service account can be created. See Azure AD Connect accounts and permissions. With the latest build, provisioning the database can now be performed out of band by the SQL administrator and then installed by the Azure AD Connect administrator with database owner rights. For more information see Install Azure AD Connect using SQL delegated administrator permissions.
Specify custom sync groups	By default Azure AD Connect creates four groups local to the server when the synchronization services are installed. These groups are: Administrators group, Operators group, Browse group, and the Password Reset Group. You can specify your own groups here. The groups must be local on the server and cannot be located in the domain.

We will be using a local SQL Express database (installed by AD Connect) to store the data for AD Connect so proceed by clicking on the Install button:

Once Azure AD Connect has been installed, you will be presented with the following User sign-in options:

Password Hash Synchronization is the default option as it is for the Express settings and given that we are configuring AD FS as the sign-in option, proceed by selecting Federation with AD FS:

Proceed by entering the credentials for an account that has global administrator permissions for the Azure tenant:

Select the domain in the forest that Azure AD Connect will be synchronization from the FOREST drop down menu:

**Note that the domain in this example has a non-routable internal domain (.local suffix) but a UPN suffix with the SMTP domain the organization will be used to sign into resources have already been added as a custom domain and verified.

Select Create new AD account if a service account has not already been created for the AD Connect Synchronization application:

AD Connect will validate the Enterprise admin credentials to ensure that it is able to connect to the selected domain:

Upon successful completion, the selected domain will be listed under the CONFIGURED DIRECTORIES heading with a green check mark beside it:

Clicking Next will allow AD Connect to retrieve the directory schema of the domain:

Since the Active Directory domain uses a non-routable suffix but an additional UPN has already been configured, the wizard will indicate that it is not added (it isn’t possible to do so) but the UPN suffix has been verified:

For referencing the following are attributes that are available:

Proceed with using having the userPrincipalname selected for the USER PRINCIPAL NAME drop box menu and select Continue without matching all UPN suffixes to verified domains (this needs to be selected as there is a non-routable domain listed):

The next Domain/OU Filtering page is where the configuration for whether AD Connect will synchronize the whole domain or only selected domains and OUs is configured. Be cognizant of whether the whole domain should be synchronized or not as this as it is best practice to only synchronize OUs that are required especially if the domain has a lot of unused objects. Selectively synchronizing only the objects that is needed will optimize the performance. With that said, if the OU structure isn’t organized well with objects scattered across everywhere then it may be best to synchronize the whole domain to avoid missing critical objects.

Uniquely identifying users isn’t as important for a single forest with single domain as users typically have only one identity but having multiple forests and domains usually means a single user could have multiple identities. If an organization with multiple forests and domains is being configured, decide multiple identities will be identified as described in the following table.

Setting	Description
Users are only represented once across all forests	All users are created as individual objects in Azure AD. The objects are not joined in the metaverse.
Mail attribute	This option joins users and contacts if the mail attribute has the same value in different forests. Use this option when your contacts have been created using GALSync. If this option is chosen, User objects whose Mail attribute aren't populated will not be synchronized to Azure AD.
ObjectSID and msExchangeMasterAccountSID/ msRTCSIP-OriginatorSid	This option joins an enabled user in an account forest with a disabled user in a resource forest. In Exchange, this configuration is known as a linked mailbox. This option can also be used if you only use Lync and Exchange is not present in the resource forest.
sAMAccountName and MailNickName	This option joins on attributes where it is expected the sign-in ID for the user can be found.
A specific attribute	This option allows you to select your own attribute. If this option is chosen, User objects whose (selected) attribute aren't populated will not be synchronized to Azure AD. Limitation: Make sure to pick an attribute that already can be found in the metaverse. If you pick a custom attribute (not in the metaverse), the wizard cannot complete.

For the purpose of this example, only one domain in a forest will be synchronized so the Users are represented only once across all directories will be selected:

For reference, a few of the options for attributes that can be used to identify users are as follows:

The Filter users and devices is great for AD Connect pilots where the OU structure does not permit the synchronization of objects that are selected for the pilot. With the filtering option, an administrator can create a group and add all the objects in so these objects are the only ones that get synchronized into Azure AD. Note that nested groups are not allowed so all the objects in the group must be direct members.

I won’t go write an explanation as to what each optional feature provides as the table from the documentation does a great job explaining it:

Optional Features	Description
Exchange Hybrid Deployment	The Exchange Hybrid Deployment feature allows for the co-existence of Exchange mailboxes both on-premises and in Office 365. Azure AD Connect is synchronizing a specific set of attributes from Azure AD back into your on-premises directory.
Exchange Mail Public Folders	The Exchange Mail Public Folders feature allows you to synchronize mail-enabled Public Folder objects from your on-premises Active Directory to Azure AD.
Azure AD app and attribute filtering	By enabling Azure AD app and attribute filtering, the set of synchronized attributes can be tailored. This option adds two more configuration pages to the wizard. For more information, see Azure AD app and attribute filtering.
Password hash synchronization	If you selected federation as the sign-in solution, then you can enable this option. Password hash synchronization can then be used as a backup option. For additional information, see Password hash synchronization. If you selected Pass-through Authentication this option can also be enabled to ensure support for legacy clients and as a backup option. For additional information, see Password hash synchronization.
Password writeback	By enabling password writeback, password changes that originate in Azure AD is written back to your on-premises directory. For more information, see Getting started with password management.
Group writeback	If you use the Office 365 Groups feature, then you can have these groups represented in your on-premises Active Directory. This option is only available if you have Exchange present in your on-premises Active Directory.
Device writeback	Allows you to writeback device objects in Azure AD to your on-premises Active Directory for Conditional Access scenarios. For more information, see Enabling device writeback in Azure AD Connect.
Directory extension attribute sync	By enabling directory extensions attribute sync, attributes specified are synced to Azure AD. For more information, see Directory extensions.

As AD FS is going to be configured, we will enabled Password has synchronization as a fallback if the federation service is not available:

Implement password hash synchronization with Azure AD Connect sync
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchronization

Password hash synchronization can also be enabled in addition to federation. It may be used as a fallback if your federation service experiences an outage.

Enter an account with domain administrator rights for the Azure AD Connect to perform the configuration changes:

Note that the account needs to be a local administrator on the AD FS servers that will be used. Domain Administrators group is usually a part of the administrator group on the servers but if they are not, ensure that you add this account onto the servers:

Configure AD FS Farm

The AD Connect wizard can actually create and configure an AD FS farm but this example already has an AD FS farm configured so the Use an existing AD FS farm will be selected:

Specify the FQDN of the primary server in the AD FS farm:

The wizard will attempt to validate the AD FS farm:

Upon successfully validating the farm, select the domain to federate with Azure AD:

Allow AD Connect to perform the configuration:

Once the configuration has completed, allow AD Connect to start the synchronization:

Verifying synchronization service connectivity to Azure Active Directory

Creating the Azure Active Directory Synchronization Account

Installing Azure AD Connect Health agent for sync

Azure AD Connection configuration has now completed:

Verify Internal and External AD FS Access

If an existing AD FS farm was used then the DNS records for intranet and internet access should have been configured so proceed to run both of the Verify federation connectivity tests:

Verify Azure AD Connect Configuration for Azure Active Directory

Switching back to the Azure portal’s Azure Active Directory will display the Status as Enabled for Azure AD Connect:

Verify Azure AD Connect Synchronization Service

Launching the Synchronization Service Manager on the AD Connect server will show that a Full Import, Full Synchronization and Export is ran:

Test Office 365 Sign-in AD FS Redirection

Attempting to sign in through https://login.microsoftonline.com should not bring you to the AD FS login page:

However, you will be redirected the AD FS sign page once the email address (UPN) is entered as the identity:

Verify Relying Party Trusts Configuration for O365 in AD FS

Logging onto the AD FS management console on the AD FS server will show that a Microsoft Office 365 Identity Platform Worldwide was configured in the Relying Party Trusts by the Azure AD Connect wizard:

Turn on MFA for O365 Sign-in

If a MFA solution such as Duo in this example is deployed, it can be turned on by right clicking on Microsoft Office 365 Identity Platform Worldwide and selecting Edit Access Control Policy…:

Click on Use access control policy link:

Select Permit everyone and require MFA:

MFA will now be required when users sign into Office 365 via the AD FS sign-in portal.