Hybrid Identity Documentation

Contents
Hybrid identity documentation

Overview
What is hybrid identity?
Tutorials
Integrate a single AD forest AD environment to the cloud with PHS
Integrate a single AD forest AD environment to the cloud with PTA
Federate a single AD forest environment to the cloud
Set up PHS as backup for AD FS in Azure AD Connect
Concepts
Hybrid Identity
Cloud Governed Management for On-Premises Workloads
Four steps to a strong identity foundation
Choose a hybrid identity authentication method
Azure AD Connect and Connect Health
What is Azure AD Connect and Connect Health?
Choose the right authentication
Identity synchronization and duplicate attribute resiliency
Password hash synchronization
What is password hash synchronization?
How password hash synchronization works
Pass-through authentication
What is pass-through authentication?
How pass-through authentication works
Pass-through authentication current limitations
Security deep dive on pass-through authentication
Pass-through authentication and user privacy
Federation
What is federation?
How federation works
Azure AD federation compatibility list
Single sign-on
What is Single Sign-On?
How Single Sign-On works
Single Sign-On and user privacy
Azure AD Connect Sync
What is Azure AD Connect Sync?
Azure ADSync service account
Azure AD Connect Sync features
What is the Azure AD Connect Sync service manager?
Azure AD Connect Sync technical concepts
Understanding Azure AD Connect Sync architecture
Understanding Declarative Provisioning
Understanding Declarative Provisioning Expressions
Understanding the default configuration
Understanding users and contacts
Understanding shadow attributes
How-to guides
Installation and upgrade
Installation Roadmap
Installation Prerequisites
Choose the installation type
Install Azure AD Connect with Express settings (Password Hash Synch)
Install Azure AD Connect Federation or other Custom settings
Import and export configuration settings
Install Azure AD Connect with Pass-through Authentication (PTA)
Install Azure AD Connect Health
Automatic upgrade
Running the installation wizard a second time
Upgrade to a new version of Azure AD Connect
Upgrade from DirSync or Azure AD Sync
Install using an existing ADSync database
Install using SQL delegated administrator permissions
Upgrade preview agents for PTA
Move Azure AD Connect database from SQL Express to SQL Server
When you already have Azure AD
Post installation tasks
Plan and design
Design concepts
Topologies for Azure AD Connect
Factors influencing the performance of Azure AD Connect
How will users sign-in
Azure AD UserPrincipalName population
Special considerations for instances
Migration
Migrate from federation to PHS
Migrate from federation to PTA
Move groups from one forest to another
Migrate to cloud authentication using staged rollout
Hybrid Identity Design Considerations
Hybrid Identity Design Considerations Overview
Determine identity requirements
Determine sync requirements
Determine multi-factor auth requirements
Determine lifecycle adoption strategy
Define a data protection strategy
Plan data protection requirements
Determine content management requirements
Determine access control requirements
Determine incident response requirements
Plan for hybrid identity lifecycle
Define an adoption strategy
Hybrid identity design considerations - Next Steps
Hybrid identity tools comparison
Manage Azure AD Connect
Enable device writeback
Enable group writeback
Device options
Additional features in Azure AD Connect
Prevent accidental deletes
Enable AD recycle bin
Configure the AD DS Connector account
Change the Azure ADSync service account password
Change the Azure AD Connector account password
Change the AD DS Connector account password
Manage Pass-through authentication
Get started with pass-through authentication
Pass-through authentication FAQ
Disable PTA with Azure AD Connect "Do not configure"
Manage Federation Services
Managing federation with Azure AD Connect
Multiple domain support for federating
Federate multiple instances of Azure AD with single instance of AD FS
Renew federation certificates for O365 and Azure AD
Update the SSL certificate for AD FS
Manage the AD FS trust with Azure AD
Configure group claims for applications
Change hash algorithm for O365 RP
Use a SAML 2.0 server as your Idp
Post configuration tasks for Hybrid Azure AD join
Manage single sign-on
Get started with Single Sign-On
Single Sign-On FAQ
Manage Azure AD Connect Health
Azure AD Connect Health Operations
Use Azure AD Connect Health with AD FS
Risky IP report for Azure AD Connect Health with AD FS
Use Azure AD Connect Health for sync
Use Azure AD Connect Health with AD DS
Health service data out-of-date
Diagnose duplicate attribute sync errors
Azure AD Connect Health alert catalog
Azure AD Connect Health data retrieval
Manage Azure AD Connect Sync
Staging server and disaster recovery
Best practices for changing the default configuration
Change the default configuration
Fix modified default rules
Configure directory extensions
Configure preferred data location
Configure filtering
Manage the scheduler
Create and customize a synchronization rule
Azure AD Connect sync V2 endpoint API
Azure AD Connect Sync service manager
Manage the service manager operations tab
Use connectors with the service manager
Metaverse designer
Metaverse search
Troubleshoot
What is the Azure AD Connect Admin Agent?
What is the ADConnectivityTools PowerShell module?
Connectivity
Errors during synchronization
Object is not synchronized
Source anchor during installation
Object sync using the troubleshooting task
Single sign-on
LargeObject error caused by userCertificate
How to recover from LocalDB 10-GB limit
SQL connectivity
Attribute synchronization
Installation issues
UPN changes
Reference
Hybrid Identity Required Ports and Protocols
Azure AD Connect version history
Azure AD Connect Health version history
Azure AD Pass-through Authentication agent version history
Connector version history
Accounts and permissions
Azure AD Connect FAQ
Azure AD Connect Health FAQ
Hybrid identity considerations for Azure Government
Azure AD Connect user privacy
Azure AD Connect Health user privacy
Azure AD Connect in Germany
DirSync Deprecation
Attributes synchronized
Functions Reference
TLS 1.2 enforcement
ADSyncConfig Reference
ADSyncTools Reference
ADConnectivityTools Reference
msExchUserHoldPolicies and cloudMSExchUserHoldPolicies
Understanding Azure AD Connect 1.4.xx.x device disappearance
Azure AD Connect version history archive
What is hybrid identity with Azure Active
Directory?
9/7/2020 • 2 minutes to read • Edit Online
Today, businesses, and corporations are becoming more and more a mixture of on-premises and cloud
applications. Users require access to those applications both on-premises and in the cloud. Managing
users both on-premises and in the cloud poses challenging scenarios.
Microsoft’s identity solutions span on-premises and cloud-based capabilities. These solutions create a
common user identity for authentication and authorization to all resources, regardless of location. We
call this hybrid identity .
With hybrid identity to Azure AD and hybrid identity management these scenarios become possible.
To achieve hybrid identity with Azure AD, one of three authentication methods can be used, depending
on your scenarios. The three methods are:
Password hash synchronization (PHS)
Pass-through authentication (PTA)
Federation (AD FS)
These authentication methods also provide single-sign on capabilities. Single-sign on automatically
signs your users in when they are on their corporate devices, connected to your corporate network.
For additional information, see Choose the right authentication method for your Azure Active Directory
hybrid identity solution.
Common scenarios and recommendations

Here are some common hybrid identity and access management scenarios with recommendations as
to which hybrid identity option (or options) might be appropriate for each.
I N EED TO : P H S A N D SSO 1 P TA A N D SSO 2 A D F S3
Sync new user, contact,

and group accounts
created in my on-
premises Active Directory
to the cloud
automatically.
Set up my tenant for

Office 365 hybrid
scenarios.
Enable my users to sign

in and access cloud
services using their on-
premises password.
I N EED TO : P H S A N D SSO P TA A N D SSO AD FS
Implement single sign-on

using corporate
credentials.
Ensure no password
hashes are stored in the
cloud.
Enable cloud-based
multi-factor
authentication solutions.
Enable on-premises
multi-factor
authentication solutions.
Support smartcard
authentication for my
users.4
Display password expiry

notifications in the Office
Portal and on the
Windows 10 desktop.
1 Password hash synchronization with single sign-on.
2 Pass-through authentication and single sign-on.
3 Federated single sign-on with AD FS.
4 AD FS can be integrated with your enterprise PKI to allow sign-in using certificates. These
certificates can be soft-certificates deployed via trusted provisioning channels such as MDM or
GPO or smartcard certificates (including PIV/CAC cards) or Hello for Business (cert-trust). For more
information about smartcard authentication support, see this blog.
License requirements for using Azure AD Connect

Using this feature is free and included in your Azure subscription.
Next Steps
What is password hash synchronization (PHS)?
What is pass-through authentication (PTA)?
What is federation?
What is single-sign on?
Tutorial: Integrate a single AD forest using password
hash sync (PHS)
The following tutorial will walk you through creating a hybrid identity environment using password hash sync. This
environment can then be used for testing or for getting more familiar with how a hybrid identity works.
Prerequisites
The following are prerequisites required for completing this tutorial
A computer with Hyper-V installed. It is suggested to do this on either a Windows 10 or a Windows Server 2016
computer.
An external network adapter to allow the virtual machine to communicate with the internet.
An Azure subscription
A copy of Windows Server 2016
NOTE
This tutorial uses PowerShell scripts so that you can create the tutorial environment in the quickest amount of time. Each of
the scripts uses variables that are declared at the beginning of the scripts. You can and should change the variables to reflect
your environment.
The scripts used create a general Active Directory environment prior to installing Azure AD Connect. They are relevant for all
of the tutorials.
Copies of the PowerShell scripts that are used in this tutorial are available on GitHub here.
Create a virtual machine

The first thing that we need to do, in order to get our hybrid identity environment up and running is to create a
virtual machine that will be used as our on-premises Active Directory server. Do the following:
1. Open up the PowerShell ISE as Administrator.
2. Run the following script.
#Declare variables
$VMName = 'DC1'
$Switch = 'External'
$InstallMedia = 'D:\ISO\en_windows_server_2016_updated_feb_2018_x64_dvd_11636692.iso'
$Path = 'D:\VM'
$VHDPath = 'D:\VM\DC1\DC1.vhdx'
$VHDSize = '64424509440'
#Create New Virtual Machine

New-VM -Name $VMName -MemoryStartupBytes 16GB -BootDevice VHD -Path $Path -NewVHDPath $VHDPath -NewVHDSizeBytes
$VHDSize -Generation 2 -Switch $Switch
#Set the memory to be non-dynamic

Set-VMMemory $VMName -DynamicMemoryEnabled $false
#Add DVD Drive to Virtual Machine

Add-VMDvdDrive -VMName $VMName -ControllerNumber 0 -ControllerLocation 1 -Path $InstallMedia
#Mount Installation Media

$DVDDrive = Get-VMDvdDrive -VMName $VMName
#Configure Virtual Machine to Boot from DVD

Set-VMFirmware -VMName $VMName -FirstBootDevice $DVDDrive
Complete the operating system deployment

In order to finish building the virtual machine, you need to finish the operating system installation.
1. Hyper-V Manager, double-click on the virtual machine
2. Click on the Start button.
3. You will be prompted to ‘Press any key to boot from CD or DVD’. Go ahead and do so.
4. On the Windows Server start up screen select your language and click Next .
5. Click Install Now .
6. Enter your license key and click Next .
7. Check **I accept the license terms and click Next .
8. Select Custom: Install Windows Only (Advanced)
9. Click Next
10. Once the installation has completed, restart the virtual machine, sign-in and run Windows updates to ensure the
VM is the most up-to-date. Install the latest updates.
Install Active Directory prerequisites

Now that we have a virtual machine up, we need to do a few things prior to installing Active Directory. That is, we
need to rename the virtual machine, set a static IP address and DNS information, and install the Remote Server
Administration tools. Do the following:
#Declare variables
$ipaddress = "10.0.1.117"
$ipprefix = "24"
$ipgw = "10.0.1.1"
$ipdns = "10.0.1.117"
$ipdns2 = "8.8.8.8"
$ipif = (Get-NetAdapter).ifIndex
$featureLogPath = "c:\poshlog\featurelog.txt"
$newname = "DC1"
$addsTools = "RSAT-AD-Tools"
#Set static IP address

New-NetIPAddress -IPAddress $ipaddress -PrefixLength $ipprefix -InterfaceIndex $ipif -DefaultGateway $ipgw
# Set the DNS servers

Set-DnsClientServerAddress -InterfaceIndex $ipif -ServerAddresses ($ipdns, $ipdns2)
#Rename the computer

Rename-Computer -NewName $newname -force
#Install features
New-Item $featureLogPath -ItemType file -Force
Add-WindowsFeature $addsTools
Get-WindowsFeature | Where installed >>$featureLogPath
#Restart the computer

Restart-Computer
Create a Windows Server AD environment

Now that we have the VM created and it has been renamed and has a static IP address, we can go ahead and install
and configure Active Directory Domain Services. Do the following:
#Declare variables
$DatabasePath = "c:\windows\NTDS"
$DomainMode = "WinThreshold"
$DomainName = "contoso.com"
$DomaninNetBIOSName = "CONTOSO"
$ForestMode = "WinThreshold"
$LogPath = "c:\windows\NTDS"
$SysVolPath = "c:\windows\SYSVOL"
$Password = "Pass1w0rd"
$SecureString = ConvertTo-SecureString $Password -AsPlainText -Force
#Install AD DS, DNS and GPMC

start-job -Name addFeature -ScriptBlock {
Add-WindowsFeature -Name "ad-domain-services" -IncludeAllSubFeature -IncludeManagementTools
Add-WindowsFeature -Name "dns" -IncludeAllSubFeature -IncludeManagementTools
Add-WindowsFeature -Name "gpmc" -IncludeAllSubFeature -IncludeManagementTools }
Wait-Job -Name addFeature
#Create New AD Forest

Install-ADDSForest -CreateDnsDelegation:$false -DatabasePath $DatabasePath -DomainMode $DomainMode -DomainName
$DomainName -SafeModeAdministratorPassword $SecureString -DomainNetbiosName $DomainNetBIOSName -ForestMode
$ForestMode -InstallDns:$true -LogPath $LogPath -NoRebootOnCompletion:$false -SysvolPath $SysVolPath -
Force:$true
Create a Windows Server AD user
Now that we have our Active Directory environment, we need to a test account. This account will be created in our
on-premises AD environment and then synchronized to Azure AD. Do the following:
#Declare variables
$Givenname = "Allie"
$Surname = "McCray"
$Displayname = "Allie McCray"
$Name = "amccray"
$Identity = "CN=ammccray,CN=Users,DC=contoso,DC=com"
#Create the user

New-ADUser -Name $Name -GivenName $Givenname -Surname $Surname -DisplayName $Displayname -AccountPassword
$SecureString
#Set the password to never expire

Set-ADUser -Identity $Identity -PasswordNeverExpires $true -ChangePasswordAtLogon $false -Enabled $true
Create an Azure AD tenant

Now we need to create an Azure AD tenant so that we can synchronize our users to the cloud. To create a new
Azure AD tenant, do the following.
1. Browse to the Azure portal and sign in with an account that has an Azure subscription.
2. Select the plus icon (+) and search for Azure Active Director y .
3. Select Azure Active Director y in the search results.
4. Select Create .
5. Provide a name for the organization along with the initial domain name . Then select Create . This will
create your directory.
6. Once this has completed, click the here link, to manage the directory.
Create a global administrator in Azure AD

Now that we have an Azure AD tenant, we will create a global administrator account. This account is used to create
the Azure AD Connector account during Azure AD Connect installation. The Azure AD Connector account is used to
write information to Azure AD. To create the global administrator account do the following.
1. Under Manage , select Users .
2. Select All users and then select + New user .
3. Provide a name and username for this user. This will be your Global Admin for the tenant. You will also want to
change the Director y role to Global administrator. You can also show the temporary password. When you
are done, select Create .
4. Once this has completed, open a new web browser and sign-in to myapps.microsoft.com using the new global
administrator account and the temporary password.
5. Change the password for the global administrator to something that you will remember.
Download and install Azure AD Connect

Now it is time to download and install Azure AD Connect. Once it has been installed we will run through the
express installation. Do the following:
1. Download Azure AD Connect
2. Navigate to and double-click AzureADConnect.msi .
3. On the Welcome screen, select the box agreeing to the licensing terms and click Continue .
4. On the Express settings screen, click Use express settings .
5. On the Connect to Azure AD screen, enter the username and password the global administrator for Azure AD.
Click Next .
6. On the Connect to AD DS screen, enter the username and password for an enterprise admin account. Click Next .
7. On the Ready to configure screen, click Install .
8. When the installation completes, click Exit .
9. After the installation has completed, sign out and sign in again before you use the Synchronization Service
Manager or Synchronization Rule Editor.
Verify users are created and synchronization is occurring

We will now verify that the users that we had in our on-premises directory have been synchronized and now exist
in out Azure AD tenant. Be aware that this may take a few hours to complete. To verify users are synchronized do
the following.
2. On the left, select Azure Active Director y
4. Verify that you see the new users in our tenant
Test signing in with one of our users

1. Browse to https://myapps.microsoft.com
2. Sign-in with a user account that was created in our new tenant. You will need to sign-in using the following
format: (user@domain.onmicrosoft.com). Use the same password that the user uses to sign-in on-premises.
You have now successfully setup a hybrid identity environment that you can use to test and familiarize yourself
with what Azure has to offer.
Next Steps
Hardware and prerequisites
Express settings
Password hash synchronization|
Tutorial: Integrate a single AD forest using pass-
through authentication (PTA)
The following tutorial will walk you through creating a hybrid identity environment using pass-through
authentication. This environment can then be used for testing or for getting more familiar with how a hybrid
identity works.
Prerequisites
computer.
A custom domain that can be verified
NOTE
your environment.
of the tutorials.

virtual machine that will be used as our on-premises Active Directory server.
NOTE
If you have never run a script in PowerShell on your host machine you will need to run Set-ExecutionPolicy remotesigned
and say yes in PowerShell, prior to running scripts.
Do the following:
#Declare variables
$VMName = 'DC1'
$Path = 'D:\VM'
$VHDSize = '64424509440'






9. Click Next
Install Active Directory prerequisites

2. Run Set-ExecutionPolicy remotesigned and say yes to all [A]. Press Enter.
#Declare variables
$ipaddress = "10.0.1.117"
$ipprefix = "24"
$ipgw = "10.0.1.1"
$ipdns = "10.0.1.117"
$ipdns2 = "8.8.8.8"
$newname = "DC1"



#Install features

Restart-Computer

#Declare variables
$DomaninNetBIOSName = "CONTOSO"


$DomainName -SafeModeAdministratorPassword $SecureString -DomainNetbiosName $DomainNetBIOSName -ForestMode
Force:$true

#Declare variables
$Surname = "McCray"
$Name = "amccray"
#Create the user

$SecureString


4. Select Create .

Add the custom domain name to your directory

Now that we have a tenant and a global administrator, we need to add our custom domain so that Azure can verify
it. Do the following:
1. Back in the Azure portal be sure to close the All Users blade.
2. On the left, select Custom domain names .
3. Select Add custom domain .
4. On Custom domain names , enter the name of your custom domain in the box, and click Add Domain .
5. On the custom domain name screen you will be supplied with either TXT or MX information. This information
must be added to the DNS information of the domain registrar under your domain. So you need to go to your
domain registrar, enter either the TXT or MX information in the DNS settings for your domain. This will allow
Azure to verify your domain. This may take up to 24 hours for Azure to verify it. For more information, see the
add a custom domain documentation.
6. To ensure that it is verified, click the Verify button.

4. On the Express settings screen, click Customize .
5. On the Install required components screen. Click Install .
6. On the User Sign-in screen, select Pass-through authentication and Enable single sign-on and click Next .
7. On the Connect to Azure AD screen, enter the username and password of the global admin we created above
and click Next .
8. On the Connect your directories screen, click Add Director y . Then select Create new AD account and enter
the contoso\Administrator username and password and click OK .
9. Click Next .
10. On the Azure AD sign-in configuration screen, select Continue without matching all UPN suffixes to
verified domains and click Next.
11. On the Domain and OU filtering screen, click Next .
12. On the Uniquely identifying your users screen, click Next .
13. On the Filter users and devices screen, click Next .
14. On the Optional features screen, click Next .
15. On the Enable single sign-n credentials page, enter the contoso\Administrator username and password and click
Next.

the following.

Next Steps
Customized settings
Tutorial: Federate a single AD forest environment to
the cloud
The following tutorial will walk you through creating a hybrid identity environment using federation. This
environment can then be used for testing or for getting more familiar with how a hybrid identity works.
Prerequisites
computer.
A custom domain that can be verified
NOTE
your environment.
of the tutorials.

virtual machine that will be used as our on-premises Active Directory server.
NOTE
If you have never run a script in PowerShell on your host machine you will need to run
Set-ExecutionPolicy remotesigned and say yes in PowerShell, prior to running scripts.
Do the following:
#Declare variables
$VMName = 'DC1'
$Path = 'D:\VM'
$VHDSize = '64424509440'






9. Click Next
Install Active Directory pre-requisites

2. Run Set-ExecutionPolicy remotesigned and say yes to all [A]. Press Enter.
#Declare variables
$ipaddress = "10.0.1.117"
$ipprefix = "24"
$ipgw = "10.0.1.1"
$ipdns = "10.0.1.117"
$ipdns2 = "8.8.8.8"
$newname = "DC1"



#Install features

Restart-Computer

#Declare variables
$DomainNetBIOSName = "CONTOSO"
$Password = ConvertTo-SecureString "Passw0rd" -AsPlainText -Force


$DomainName -SafeModeAdministratorPassword $Password -DomainNetbiosName $DomainNetBIOSName -ForestMode
Force:$true

#Declare variables
$Surname = "McCray"
$Name = "amccray"
#Create the user

$SecureString

Create a certificate for AD FS

Now we will create a TLS/SSL certificate that will be used by AD FS. This is will be a self-signed certificate and is
only for testing purposes. Microsoft does not recommend using a self-signed certificate in a production
environment. Do the following:
#Declare variables
$DNSname = "adfs.contoso.com"
$Location = "cert:\LocalMachine\My"
#Create certificate
New-SelfSignedCertificate -DnsName $DNSname -CertStoreLocation $Location

4. Select Create .


Add the custom domain name to your directory

Now that we have a tenant and a global administrator, we need to add our custom domain so that Azure can verify
it. Do the following:
1. Back in the Azure portal be sure to close the All Users blade.
2. On the left, select Custom domain names .
3. Select Add custom domain .
4. On Custom domain names , enter the name of your custom domain in the box, and click Add Domain .
5. On the custom domain name screen you will be supplied with either TXT or MX information. This information
must be added to the DNS information of the domain registrar under your domain. So you need to go to your
domain registrar, enter either the TXT or MX information in the DNS settings for your domain. This will allow
Azure to verify your domain. This may take up to 24 hours for Azure to verify it. For more information, see the
add a custom domain documentation.
6. To ensure that it is verified, click the Verify button.

4. On the Express settings screen, click Customize .
5. On the Install required components screen. Click Install .
6. On the User Sign-in screen, select Federation with AD FS and click Next .
7. On the Connect to Azure AD screen, enter the username and password of the global admin we created
above and click Next .
8. On the Connect your directories screen, click Add Director y . Then select Create new AD account and
enter the contoso\Administrator username and password and click OK .
9. Click Next .
10. On the Azure AD sign-in configuration screen, select Continue without matching all UPN suffixes to
verified domains and click Next.
12. On the Uniquely identifying your users screen, click Next .
13. On the Filter users and devices screen, click Next .
14. On the Optional features screen, click Next .
15. On the Domain Administrator credentials page, enter the contoso\Administrator username and password
and click Next.
16. On the AD FS farm screen, make sure Configure a new AD FS farm is selected.
17. Select Use a cer tificate installed on the federation ser vers and click Browse .
18. Enter DC1 in the search box and select it when it is found. Click Ok .
19. From the Cer tificate File drop-down, select adfs.contoso.com the certificate we created above. Click
Next .
20. On the AD FS server screen, click Browse and enter DC1 in the search box and select it when it is found.
Click Ok . Click Next .
21. On the Web application Proxy servers screen, click Next .

22. On the AD FS service account screen, enter the contoso\Administrator username and password and click
Next.
23. On the Azure AD Domain screen, select your verified custom domain from the drop-down and click Next .

the following.

Next Steps
Customized settings
Azure AD Connect and federation
Tutorial: Setting up PHS as backup for AD FS in Azure
AD Connect
The following tutorial will walk you through setting up password hash sync as a backup and fail-over for AD FS.
This document will also demonstrate how to enable password hash sync as the primary authentication method, if
AD FS has failed or become unavailable.
NOTE
Although these steps are usually performed during emergency or outage situations, it is recommended that you test these
steps and verify your procedures before an outage occurs.
NOTE
In the event that you do not have access to Azure AD Connect server or the server does not have access to the internet, you
can contact Microsoft Support to assist with the changes to the Azure AD side.
Prerequisites
This tutorial builds upon the Tutorial: Federate a single AD forest environment to the cloud and is a per-requisite
before attempting this tutorial. If you have not completed this tutorial, do so before attempting the steps in this
document.
IMPORTANT
Prior to switching to PHS you should create a backup of your AD FS environment. This can be done using the AD FS Rapid
Restore Tool.
Enable PHS in Azure AD Connect

The first step, now that we have an Azure AD Connect environment that is using federation, is to turn on password
hash sync and allow Azure AD Connect to synchronize the hashes.
Do the following:
1. Double-click the Azure AD Connect icon that was created on the desktop
2. Click Configure .
3. On the Additional tasks page, select Customize synchronization options and click Next .
4. Enter the username and password for your global administrator. This account was created here in the previous
tutorial.
5. On the Connect your directories screen, click Next .
7. On the Optional features screen, check Password hash synchronization and click Next .
8. On the Ready to configure screen click Configure .
9. Once the configuration completes, click Exit .
10. That's it! You are done. Password hash synchronization will now occur and can be used as a backup if AD FS
becomes unavailable.
Switch to password hash synchronization

Now, we will show you how to switch over to password hash synchronization. Before you start, consider under
which conditions should you make the switch. Don't make the switch for temporary reasons, like a network outage,
a minor AD FS problem, or a problem that affects a subset of your users. If you decide to make the switch because
fixing the problem will take too long, do the following:
IMPORTANT
Be aware that it will take some time for the password hashes to synchronize to Azure AD. This means that it may take up 3
hours for the synchronizations to complete and before you can start authenticating using the password hashes.
3. Select Change user sign-in and click Next .
4. Enter the username and password for your global administrator. This account was created here in the previous
tutorial.
5. On the User sign-in screen, select Password Hash Synchronization and place a check in the Do not
conver t user accounts box.
6. Leave the default Enable single sign-on selected and click Next .
7. On the Enable single sign-on screen click Next .
8. On the Ready to configure screen, click Configure .
9. Once configuration is complete, click Exit .
10. Users can now use their passwords to sign in to Azure and Azure services.

2. Sign in with a user account that was created in our new tenant. You will need to sign in using the following
format: (user@domain.onmicrosoft.com). Use the same password that the user uses to sign in on-premises.
Switch back to federation

Now, we will show you how to switch back to federation. To do this, do the following:
3. Select Change user sign-in and click Next .
4. Enter the username and password for your global administrator. This is the account that was created here in the
previous tutorial.
5. On the User sign-in screen, select Federation with AD FS and click Next .
6. On the Domain Administrator credentials page, enter the contoso\Administrator username and password and
click Next.
7. On the AD FS farm screen, click Next .
8. On the Azure AD domain screen, select the domain from the drop-down and click Next .
9. On the Ready to configure screen, click Configure .
10. Once configuration is complete, click Next .
11. On the Verify federation connectivity screen, click Verify . You may need to configure DNS records (add A
and AAAA records) for this to complete successfully.
12. Click Exit .
Reset the AD FS and Azure trust

Now we need to reset the trust between AD FS and Azure.
3. Select Manage Federation and click Next .
4. Select Reset Azure AD trust and click Next .
5. On the Connect to Azure AD screen enter the username and password for your global administrator.
6. On the Connect to AD FS screen, enter the contoso\Administrator username and password and click Next.
7. On the Cer tificates screen, click Next .

Next steps
Express settings
How Azure AD Delivers Cloud Governed
Management for On-Premises Workloads
Azure Active Directory (Azure AD) is a comprehensive identity as a service (IDaaS) solution used by millions of
organizations that span all aspects of identity, access management, and security. Azure AD holds more than a billion
user identities and helps users sign in and securely access both:
External resources, such as Microsoft Office 365, the Azure portal, and thousands of other Software-as-a-Service
(SaaS) applications.
Internal resources, such as applications on an organization's corporate network and intranet, along with any
cloud applications developed by that organization.
Organizations can use Azure AD if they are 'pure cloud,' or as a 'hybrid' deployment if they have on-premises
workloads. A hybrid deployment of Azure AD can be part of a strategy for an organization to migrate its IT assets to
the cloud, or to continue to integrate existing on-premises infrastructure alongside new cloud services.
Historically, 'hybrid' organizations have seen Azure AD as an extension of their existing on-premises infrastructure.
In these deployments, the on-premises identity governance administration, Windows Server Active Directory or
other in-house directory systems, are the control points, and users and groups are synced from those systems to a
cloud directory such as Azure AD. Once those identities are in the cloud, they can be made available to Office 365,
Azure, and other applications.
As organizations move more of their IT infrastructure along with their applications to the cloud, many are looking
for the improved security and simplified management capabilities of identity management as a service. The cloud-
delivered IDaaS features in Azure AD accelerate the transition to cloud governed management by providing the
solutions and capabilities that allow organizations to quickly adopt and move more of their identity management
from traditional on-premises systems to Azure AD, while continuing to support existing as well as new applications.
This paper outlines Microsoft's strategy for hybrid IDaaS and describes how organizations can use Azure AD for
their existing applications.
The Azure AD approach to cloud governed identity management

As organizations transition to the cloud, they need assurances that they have controls over their complete
environment - more security and more visibility into activities, supported by automation, and proactive insights.
"Cloud governed management " describes how organizations manage and govern their users, applications,
groups, and devices from the cloud.
In this modern world, organizations need to be able to manage effectively at scale, because of the proliferation of
SaaS applications and the increasing role of collaboration and external identities. The new risk landscape of the
cloud means an organization must be more responsive - a malicious actor who compromises a cloud user could
affect cloud and on-premises applications.
In particular, hybrid organizations need to be able to delegate and automate tasks, which historically IT did
manually. To automate tasks, they need APIs and processes that orchestrate the lifecycle of the different identity-
related resources (users, groups, applications, devices), so they can delegate the day-to-day management of those
resources to more individuals outside of core IT staff. Azure AD addresses these requirements through user account
management and native authentication for users without requiring on-premises identity infrastructure. Not
building out on-premises infrastructure can benefit organizations that have new communities of users, such as
business partners, which didn't originate in their on-premises directory, but whose access management is critical to
achieving business outcomes.
In addition, management isn't complete without governance --- and governance in this new world is an integrated
part of the identity system rather than an add-on. Identity governance gives organizations the ability to manage the
identity and access lifecycle across employees, business partners and vendors, and services and applications.
Incorporating identity governance makes it easier to enable the organization to transition to cloud governed
management, allows IT to scale, addresses new challenges with guests and provides deeper insights and
automation than what customers had with on-premises infrastructure. Governance in this new world means the
ability for an organization to have transparency, visibility, and proper controls on the access to resources within the
organization. With Azure AD, security operations and audit teams have visibility into who has --- and who should
have - access to what resources in the organization (on what devices), what those users are doing with that access,
and whether the organization has and uses appropriate controls to remove or restrict access in accordance with
company or regulatory policies.
The new management model benefits organizations with both SaaS and line-of-business (LOB) applications, as they
are more easily able to manage and secure access to those applications. By integrating applications with Azure AD,
organizations will be able to use and manage access across both cloud and on-premises originated identities
consistently. Application lifecycle management becomes more automated, and Azure AD provides rich insights into
application usage that wasn't easily achievable in on-premises identity management. Through the Azure AD, Office
365 groups and Teams self-service features, organizations can easily create groups for access management and
collaboration and add or remove users in the cloud to enable collaboration and access management requirements.
Selecting the right Azure AD capabilities for cloud governed management depends upon the applications to be
used, and how those applications will be integrated with Azure AD. The following sections outline the approaches to
take for AD-integrated applications, and applications that use federation protocols (for example, SAML, OAuth, or
OpenID Connect).
Cloud governed management for AD-integrated applications

Azure AD improves the management for an organization's on-premises Active Directory-integrated applications
through secure remote access and Conditional Access to those applications. In addition, Azure AD also provides
account lifecycle management and credential management for the user's existing AD accounts, including:
Secure remote access and Conditional Access for on-premises applications
For many organizations, the first step in managing access from the cloud for on-premises AD-integrated web and
remote desktop-based applications is to deploy the application proxy in front of those applications to provide
secure remote access.
After a single sign-on to Azure AD, users can access both cloud and on-premises applications through an external
URL or an internal application portal. For example, Application Proxy provides remote access and single sign-on to
Remote Desktop, SharePoint, as well as apps such as Tableau and Qlik, and line of business (LOB) applications.
Furthermore, Conditional Access policies can include displaying the terms of use and ensuring the user has agreed
to them before being able to access an application.
Automatic lifecycle management for Active Director y accounts

Identity governance helps organizations achieve a balance between productivity --- how quickly can a person have
access to the resources they need, such as when they join the organization? --- and security --- how should their
access change over time, such as when that person's employment status changes? Identity lifecycle management is
the foundation for identity governance, and effective governance at scale requires modernizing the identity lifecycle
management infrastructure for applications.
For many organizations, identity lifecycle for employees is tied to the representation of that user in a human capital
management (HCM) system. For organizations using Workday as their HCM system, Azure AD can ensure user
accounts in AD are automatically provisioned and deprovisioned for workers in Workday. Doing so leads to
improved user productivity through automation of birthright accounts and manages risk by ensuring application
access is automatically updated when a user changes roles or leaves the organization. The Workday-driven user
provisioning deployment plan is a step-by-step guide that walks organizations through the best practices
implementation of Workday to Active Directory User Provisioning solution in a five-step process.
Azure AD Premium also includes Microsoft Identity Manager, which can import records from other on-premises
HCM systems, including SAP, Oracle eBusiness, and Oracle PeopleSoft.
Business-to-business collaboration increasingly requires granting access to people outside your organization.
Azure AD B2B collaboration enables organizations to securely share their applications and services with guest users
and external partners while maintaining control over their own corporate data.
Azure AD can automatically create accounts in AD for guest users as needed, enabling business guests to access
on-premises AD-integrated applications without needing another password. Organizations can set up multi-factor
authentication (MFA) policies for guest users so MFA checks are done during application proxy authentication. Also,
any access reviews that are done on cloud B2B users apply to on-premises users. For example, if the cloud user is
deleted through lifecycle management policies, the on-premises user is also deleted.
Credential management for Active Director y accounts Azure AD's self-service password reset allows users
who have forgotten their passwords to be reauthenticated and reset their passwords, with the changed passwords
written to on-premises Active Directory. The password reset process can also use the on-premises Active Directory
password policies: When a user resets their password, it's checked to ensure it meets the on-premises Active
Directory policy before committing it to that directory. The self-service password reset deployment plan outlines
best practices to roll out self-service password reset to users via web and Windows-integrated experiences.
Finally, for organizations that permit users to change their passwords in AD, AD can be configured to use the same
password policy as the organization is using in Azure AD through the Azure AD password protection feature,
currently in public preview.
When an organization is ready to move an AD-integrated application to the cloud by moving the operating system
hosting the application to Azure, Azure AD Domain Services provides AD-compatible domain services (such as
domain join, group policy, LDAP, and Kerberos/NTLM authentication). Azure AD Domain Services integrates with
the organization's existing Azure AD tenant, making it possible for users to sign in using their corporate credentials.
Additionally, existing groups and user accounts can be used to secure access to resources, ensuring a smoother 'lift-
and-shift' of on-premises resources to Azure infrastructure services.
Cloud governed management for on-premises federation-based

applications
For an organization that already uses an on-premises identity provider, moving applications to Azure AD enables
more secure access and an easier administrative experience for federation management. Azure AD enables
configuring granular per-application access controls, including Azure Multi-Factor Authentication, by using Azure
AD Conditional Access. Azure AD supports more capabilities, including application-specific token signing
certificates and configurable certificate expiration dates. These capabilities, tools, and guidance enable
organizations to retire their on-premises identity providers. Microsoft's own IT, for one example, has moved 17,987
applications from Microsoft's internal Active Directory Federation Services (AD FS) to Azure AD.
To begin migrating federated applications to Azure AD as the identity provider, refer to https://aka.ms/migrateapps
that includes links to:
The white paper Migrating Your Applications to Azure Active Directory, which presents the benefits of
migration and describes how to plan for migration in four clearly-outlined phases: discovery, classification,
migration, and ongoing management. You'll be guided through how to think about the process and break
down your project into easy-to-consume pieces. Throughout the document are links to important resources
that will help you along the way.
The solution guide Migrating Application Authentication from Active Directory Federation Services to Azure
Active Directory explores in more detail the same four phases of planning and executing an application
migration project. In this guide, you'll learn how to apply those phases to the specific goal of moving an
application from Active Directory Federation Services (AD FS) to Azure AD.
The Active Directory Federation Services Migration Readiness Script can be run on existing on-premises
Active Directory Federation Services (AD FS) servers to determine the readiness of applications for
migration to Azure AD.
Ongoing access management across cloud and on-premises

applications
Organizations need a process to manage access that is scalable. Users continue to accumulate access rights and
end up with beyond what was initially provisioned for them. Furthermore, enterprise organizations need to be able
to scale efficiently to develop and enforce access policy and controls on an ongoing basis.
Typically, IT delegates access approval decisions to business decision makers. Furthermore, IT can involve the users
themselves. For example, users that access confidential customer data in a company's marketing application in
Europe need to know the company's policies. Guest users also may be unaware of the handling requirements for
data in an organization to which they've been invited.
Organizations can automate the access lifecycle process through technologies such as dynamic groups, coupled
with user provisioning to SaaS applications, or applications integrated using the System for Cross-Domain Identity
Management (SCIM) standard. Organizations also can control which guest users have access to on-premises
applications. These access rights can then be regularly reviewed using recurring Azure AD access reviews.
Future directions
In hybrid environments, Microsoft's strategy is to enable deployments where the cloud is the control plane for
identity , and on-premises directories and other identity systems, such as Active Directory and other on-premises
applications, are the target for provisioning users with access. This strategy will continue to ensure the rights,
identities, and access in those applications and workloads that rely upon them. At this end state, organizations will
be able to drive end-user productivity entirely from the cloud.
Next steps
For more information on how to get started on this journey, see the Azure AD deployment plans, located at
https://aka.ms/deploymentplans . They provide end-to-end guidance about how to deploy Azure Active Directory
(Azure AD) capabilities. Each plan explains the business value, planning considerations, design, and operational
procedures needed to successfully roll out common Azure AD capabilities. Microsoft continually updates the
deployment plans with best practices learned from customer deployments and other feedback when we add new
capabilities to managing from the cloud with Azure AD.
Four steps to a strong identity foundation with Azure
Active Directory
Managing access to apps and data can no longer rely on the traditional network security boundary strategies such
as perimeter networks and firewalls because of the rapid movement of apps to the cloud. Now organizations must
trust their identity solution to control who and what has access to the organization's apps and data. More
organizations are allowing employees to bring their own devices to work and use their devices from anywhere they
can connect to the Internet. Ensuring those devices are compliant and secure has become an important
consideration in the identity solution an organization chooses to implement. In today's digital workplace, identity is
the primary control plane of any organization moving to the cloud.
In adopting an Azure Active Directory (Azure AD) hybrid identity solution, organizations gain access to premium
features that unlock productivity through automation, delegation, self-service, and single sign-on capabilities. It
allows your workers to access company resources from wherever they need to do their work while allowing your IT
team to govern that access by ensuring that the right people have the right access to the right resources to
establish secure productivity.
Based on our learnings, this checklist of best practices will help you quickly deploy recommended actions to build a
strong identity foundation in your organization:
Connect to apps easily
Establish one identity for every user automatically
Empower your users securely
Operationalize your insights
Step 1 - Connect to apps easily

By connecting your apps with Azure AD, you can improve end-user productivity and security by enabling single
sign-on (SSO) and do user provisioning. By managing your apps in a single place, Azure AD, you can minimize
administrative overhead and achieve a single point of control for your security and compliance policies.
This section covers your options for managing user access to apps, enabling secure remote access to internal apps,
and the benefits of migrating your apps to Azure AD.
Make apps available to your users seamlessly
Azure AD enables administrators to add applications to the Enterprise applications gallery in the Azure portal.
Adding applications to the Enterprise applications gallery makes it easier for you to configure applications to use
Azure AD as your identity provider. It also lets you manage user access to the application with Conditional Access
policies and configure single sign-on (SSO) to applications so that users don't have to enter their passwords
repeatedly and are automatically signed into both on-premises and cloud-based applications.
Once applications are added to the Azure AD gallery, users can see apps that are assigned to them and search and
request other apps as needed. Azure AD provides several methods for users to access their apps:
Access panel/My Apps
Office 365 app launcher
Direct sign-on to federated apps
Direct sign-on links
To learn more about user access to apps, see Step 3 -- Empower Your Users in this article.
Migrate apps from Active Directory Federation Services to Azure AD
Migrating single sign-on configuration from Active Directory Federation Services (ADFS) to Azure AD enables
additional capabilities on security, a more consistent manageability, and collaboration. For optimal results, we
recommend that you migrate your apps from AD FS to Azure AD. Bringing your application authentication and
authorization to Azure AD provides you with the following benefits:
Managing cost
Managing risk
Increasing productivity
Addressing compliance and governance
To learn more, see the Migrating Your Applications to Azure Active Directory whitepaper.
Enable secure remote access to apps
Azure AD Application Proxy provides a simple solution for organizations to publish on-premises apps to the cloud
for remote users who need access to internal apps in a secure manner. After a single sign-on to Azure AD, users can
access both cloud and on-premises applications through external URLs or an internal application portal.
Azure AD Application Proxy offers the following benefits:
Extending Azure AD to on-premises resources
Cloud-scale security and protection
Features like Conditional Access and Multi-Factor Authentication that are easy to enable
No components in the perimeter network such as VPN and traditional reverse proxy solutions
No inbound connections required
Single sign-on (SSO) across devices, resources, and apps in the cloud and on-premises
Empowers end users to be productive anytime and anywhere
Discover Shadow IT with Microsoft Cloud App Security
In modern enterprises, IT departments are often not aware of all the cloud applications that are used by the users to
do their work. When IT admins are asked how many cloud apps they think their employees use, on average they
say 30 or 40. In reality, the average is over 1,000 separate apps being used by employees in your organization. 80%
of employees use non-sanctioned apps that no one has reviewed and may not be compliant with your security and
compliance policies.
Microsoft Cloud App Security (MCAS) can help you identify useful apps that are popular with users that IT may
sanction and add to the Enterprise applications gallery so that users benefit from capabilities such as SSO and
Conditional Access.
"Cloud App Security helps us ensure that our people are properly using our cloud and SaaS applications, in ways
that support the foundational security policies that help protect Accenture." --- John Blasi, Managing Director,
Information Security, Accenture
In addition to detecting shadow IT, MCAS can also determine the risk level of apps, prevent unauthorized access to
corporate data, possible data leakage, and other security risks inherent in the applications.
Step 2 - Establish one identity for every user automatically

Bringing on-premises and cloud-based directories together in an Azure AD hybrid identity solution will allow you
to reuse your existing on-premises Active Directory investment by provisioning your existing identities in the cloud.
The solution synchronizes on-premises identities with Azure AD, while IT keeps the on-premises Active Directory
running with any existing governance solutions as the primary source of truth for identities. Microsoft's Azure AD
hybrid identity solution spans on-premises and cloud-based capabilities, creating a common user identity for
authentication and authorization to all resources regardless of their location.
Integrating your on-premises directories with Azure AD makes your users more productive and prevents users
from using multiple accounts across apps and services by providing a common identity for accessing both cloud
and on-premises resources. Using multiple accounts is a pain point for end users and IT alike. From an end-user
perspective, having multiple accounts means having to remember multiple passwords. To avoid this, many users
reuse the same password for each account, which is bad from a security perspective. From an IT perspective, reuse
often leads to more password resets and helpdesk costs along with the end-user complaints.
Azure AD Connect is the tool that is used for to sync your on-premises identities to Azure AD, which can then be
used to access cloud applications. Once the identities are in Azure AD, they can provision to SaaS applications like
Salesforce or Concur.
In this section, we list recommendations for providing high availability, modern authentication for the cloud, and
reducing your on-premises footprint.
NOTE
If you want to learn more about Azure AD Connect, see What is Azure AD Connect Sync?
Set up a staging server for Azure AD Connect and keep it up-to -date
Azure AD Connect plays a key role in the provisioning process. If the Sync Server goes offline for any reason,
changes to on-premises won't be updated in the cloud and cause access issues to users. It's important to define a
failover strategy that allows administrators to quickly resume synchronization after the sync server goes offline.
To provide high availability in the event your primary Azure AD Connect server goes offline, it's recommended that
you deploy a separate staging server for Azure AD Connect. Deploying a server allows the administrator to
"promote" the staging server to production by a simple configuration switch. Having a standby server configured in
staging mode also allows you to test and deploy new configuration changes and introduce a new server if
decommissioning the old one.
TIP
Azure AD Connect is updated on a regular basis. Therefore, it's strongly recommended that you keep the staging server
current in order to take advantage of the performance improvements, bug fixes, and new capabilities that each new version
provides.
Enable cloud authentication

Organizations with on-premises Active Directory should extend their directory to Azure AD using Azure AD
Connect and configure the appropriate authentication method. Choosing the correct authentication method for
your organization is the first step in your journey of moving apps to the cloud. It's a critical component since it
controls access to all cloud data and resources.
The simplest and recommended method for enabling cloud authentication for on-premises directory objects in
Azure AD is to enable Password Hash Synchronization (PHS). Alternatively, some organizations may consider
enabling Pass-through Authentication (PTA).
Whether you choose PHS or PTA, don't forget to enable Seamless Single Sign-on to allow users to access cloud
apps without constantly entering their username and password in the app when using Windows 7 and 8 devices on
your corporate network. Without single sign-on, users must remember application-specific passwords and sign
into each application. Likewise, IT staff needs to create and update user accounts for each application such as Office
365, Box, and Salesforce. Users need to remember their passwords, plus spend the time to sign into each
application. Providing a standardized single sign-on mechanism to the entire enterprise is crucial for best user
experience, reduction of risk, ability to report, and governance.
For organizations already using AD FS or another on-premises authentication provider, moving to Azure AD as
your identity provider can reduce complexity and improve availability. Unless you have specific use cases for using
federation, we recommend migrating from federated authentication to either PHS and Seamless SSO or PTA and
Seamless SSO to enjoy the benefits of a reduced on-premises footprint and the flexibility the cloud offers with
improved user experiences. For more information, see Migrate from federation to password hash synchronization
for Azure Active Directory.
Enable automatic deprovisioning of accounts
Enabling automated provisioning and deprovisioning to your applications is the best strategy for governing the
lifecycle of identities across multiple systems. Azure AD supports automated, policy-based provisioning and
deprovisioning of user accounts to a variety of popular SaaS applications such as ServiceNow and Salesforce, and
others that implement the SCIM 2.0 protocol. Unlike traditional provisioning solutions, which require custom code
or manual uploading of CSV files, the provisioning service is hosted in the cloud, and features pre-integrated
connectors that can be set up and managed using the Azure portal. A key benefit of automatic deprovisioning is
that it helps secure your organization by instantly removing users' identities from key SaaS apps when they leave
the organization.
To learn more about automatic user account provisioning and how it works, see Automate User Provisioning and
Deprovisioning to SaaS Applications with Azure Active Directory.
Step 3 - Empower your users securely

In today's digital workplace, it's important to balance security with productivity. However, end users often push back
on security measures that slow their productivity and access to cloud apps. To help address this, Azure AD provides
self-service capabilities that enable users to remain productive while minimizing administrative overhead.
This section lists recommendations for removing friction from your organization by empowering your users while
remaining vigilant.
Enable Self-Service Password Reset for all users
Azure's self-service password reset (SSPR) offers a simple means for IT administrators to allow users to reset and
unlock their passwords or accounts without administrator intervention. The system includes detailed reporting that
tracks when users access the system, along with notifications to alert you to misuse or abuse.
By default, Azure AD unlocks accounts when it performs a password reset. However, when you enable Azure AD
Connect integration on-premises, you also have the option to separate those two operations, which enable users to
unlock their account without having to reset the password.
Ensure all users are registered for MFA and SSPR
Azure provides reports that can be used by you and your organization to ensure users are registered for MFA and
SSPR. Users who haven't registered may need to be educated on the process.
The MFA sign-ins report includes information about MFA usage and gives you insights into how MFA is working in
your organization. Having access to sign-in activity (and audits and risk detections) for Azure AD is crucial for
troubleshooting, usage analytics, and forensics investigations.
Likewise, the Self-service Password Management report can be used to determine who has (or hasn't) registered
for SSPR.
Self-service app management
Before your users can self-discover applications from their access panel, you need to enable self-service application
access to any applications that you wish to allow users to self-discover and request access to. Self-service
application access is a great way to allow users to self-discover applications and optionally allow the business
group to approve access to those applications. You can allow the business group to manage the credentials
assigned to those users for Password Single-Sign On Applications right from their access panels.
Self-service group management
Assigning users to applications is best mapped when using groups, because they allow great flexibility and ability
to manage at scale:
Attribute-based using dynamic group membership
Delegation to app owners
Azure AD provides the ability to manage access to resources using security groups and Office 365 groups. These
groups can be managed by a group owner who can approve or deny membership requests and delegate control of
group membership. Known as self-service group management, this feature saves time by allowing group owners
who aren't assigned an administrative role to create and manage groups without having to rely on administrators
to handle their requests.
Step 4 - Operationalize your insights

Auditing and logging of security-related events and related alerts are essential components of an efficient strategy
to ensure that users remain productive and your organization is secure. Security logs and reports can help answer
question such as:
Are you using what you're paying for?
Is there anything suspicious or malicious happening in my tenant?
Who was impacted during a security incident?
Security logs and reports provide you with an electronic record of suspicious activities and help you detect patterns
that may indicate attempted or successful external penetration of the network, and internal attacks. You can use
auditing to monitor user activity, document regulatory compliance, do forensic analysis, and more. Alerts provide
notifications of security events.
Assign least privileged admin roles for operations
As you think about your approach to operations, there are a couple levels of administration to consider. The first
level places the burden of administration on your global administrator(s). Always using the global administrator
role, might be appropriate for smaller companies. But for larger organizations with help desk personnel and
administrators responsible for specific tasks, assigning the role of global administrator can be a security risk since it
provides those individuals with the ability to manage tasks that are above and beyond what they should be capable
of doing.
In this case, you should consider the next level of administration. Using Azure AD, you can designate end users as
"limited administrators" who can manage tasks in less-privileged roles. For example, you might assign your help
desk personnel the security reader role to provide them with the ability to manage security-related features with
read-only access. Or perhaps it makes sense to assign the authentication administrator role to individuals to give
them the ability to reset non-password credentials or read and configure Azure Service Health.
To learn more, see Administrator role permissions in Azure Active Directory.
Monitor hybrid components (Azure AD Connect sync, AD FS ) using Azure AD Connect Health
Azure AD Connect and AD FS are critical components that can potentially break lifecycle management and
authentication and ultimately lead to outages. Therefore, you should deploy Azure AD Connect Health for
monitoring and reporting of these components.
To learn more, go read Monitor AD FS using Azure AD Connect Health.
Use Azure Monitor to collect data logs for analytics
Azure Monitor is a unified monitoring portal for all Azure AD logs, which provides deep insights, advanced
analytics, and smart machine learning. With Azure Monitor, you can consume metrics and logs within the portal
and via APIs to gain more visibility into the state and performance of your resources. It enables a single pane of
glass experience within the portal while enabling a wide range of product integrations via APIs and data export
options that support traditional third-party SIEM systems. Azure Monitor also gives you the ability to configure
alert rules to get notified or to take automated actions on issues impacting your resources.
Create custom dashboards for your leadership and your day to day
Organizations that don't have a SIEM solution can download the Power BI Content Pack for Azure AD. The Power BI
content pack contains pre-built reports to help you understand how your users adopt and use Azure AD features,
which allows you to gain insights into all the activities within your directory. You can also create your own custom
dashboard and share with your leadership team to report on day-to-day activities. Dashboards are a great way to
monitor your business and see all of your most important metrics at a glance. The visualizations on a dashboard
may come from one underlying dataset or many, and from one underlying report or many. A dashboard combines
on-premises and cloud data, providing a consolidated view regardless of where the data lives.
Understand your support call drivers

When you implement a hybrid identity solution as outlined in this article, you should ultimately notice a reduction
in your support calls. Common issues such as forgotten passwords and account lockouts are mitigated by
implementing Azure's self-service password reset, while enabling self-service application access allows users to
self-discover and request access to applications without relying on your IT staff.
If you don't observe a reduction in support calls, we recommend that you analyze your support call drivers in an
attempt to confirm if SSPR or self-service application access has been configured correctly or if there are any other
new issues that can be systematically addressed.
"In our digital transformation journey, we needed a reliable identity and access management provider to facilitate
seamless yet secure integration between us, partners and cloud service providers, for an effective ecosystem; Azure
AD was the best option offering us the needed capabilities and visibility that enabled us to detect and respond to
risks." --- Yazan Almasri, Global Information Security Director, Aramex
Monitor your usage of apps to drive insights
In addition to discovering Shadow IT, monitoring app usage across your organization using Microsoft Cloud App
Security can help your organization as you move to take full advantage of the promise of cloud applications. It can
help keep you in control of your assets through improved visibility into activity and increase the protection of
critical data across cloud applications. Monitoring app usage in your organization using MCAS can help you answer
the following questions:
What unsanctioned apps are employees using to store data in?
Where and when is sensitive data being stored in the cloud?
Who is accessing sensitive data in the cloud?
"With Cloud App Security, we can quickly spot anomalies and take action." --- Eric LePenske, Senior Manager,
Information Security, Accenture
Summary
There are many aspects to implementing a hybrid Identity solution, but this four-step checklist will help you quickly
accomplish an identity infrastructure that will enable users to be more productive and secure.
Connect to apps easily
Establish one identity for every user automatically
Empower your users securely
Operationalize your insights
We hope this document is a useful roadmap to establishing a strong identity foundation for your organization.
Identity checklist
We recommend that you print the following checklist for reference as you begin your journey to a more solid
identity foundation in your organization.
Today
DO N E? IT EM
Pilot Self- Service Password Reset (SSPR) for a group
Monitor hybrid components using Azure AD Connect Health
Assign least privileged admin roles for operation
Discover Shadow IT with Microsoft Cloud App Security
Use Azure Monitor to collect data logs for analysis

Next two weeks
DO N E? IT EM
Make an app available for your users
Pilot Azure AD provisioning for a SaaS app of choice
Setup a staging server for Azure AD Connect and keep it up-

to-date
Start migrating apps from ADFS to Azure AD
Create custom dashboards for your leadership and your day

to day
Next month
DO N E? IT EM
Pilot secure remote access to apps
Ensure all users are registered for MFA and SSPR
Enable cloud authentication
Next three months

DO N E? IT EM
Enable self-service app management
Enable self-service group management
Understand your support call drivers
Next steps
Learn how you can increase your secure posture using the capabilities of Azure Active Directory and this five-step
checklist - Five steps to securing your identity infrastructure.
Learn how the identity features in Azure AD can help you accelerate your transition to cloud governed
management by providing the solutions and capabilities that allow organizations to quickly adopt and move more
of their identity management from traditional on-premises systems to Azure AD - How Azure AD Delivers Cloud
Governed Management for On-Premises Workloads.
Choose the right authentication method for your
Azure Active Directory hybrid identity solution
Choosing the correct authentication method is the first concern for organizations wanting to move their apps to the
cloud. Don't take this decision lightly, for the following reasons:
1. It's the first decision for an organization that wants to move to the cloud.
2. The authentication method is a critical component of an organization’s presence in the cloud. It controls
access to all cloud data and resources.
3. It's the foundation of all the other advanced security and user experience features in Azure AD.
Identity is the new control plane of IT security, so authentication is an organization’s access guard to the new cloud
world. Organizations need an identity control plane that strengthens their security and keeps their cloud apps safe
from intruders.
NOTE
Changing your authentication method requires planning, testing, and potentially downtime. Staged rollout is a great way to
test users migration from federation to cloud authentication.
Out of scope
Organizations that don't have an existing on-premises directory footprint aren't the focus of this article. Typically,
those businesses create identities only in the cloud, which doesn’t require a hybrid identity solution. Cloud-only
identities exist solely in the cloud and aren't associated with corresponding on-premises identities.
Authentication methods
When the Azure AD hybrid identity solution is your new control plane, authentication is the foundation of cloud
access. Choosing the correct authentication method is a crucial first decision in setting up an Azure AD hybrid
identity solution. Implement the authentication method that is configured by using Azure AD Connect, which also
provisions users in the cloud.
To choose an authentication method, you need to consider the time, existing infrastructure, complexity, and cost of
implementing your choice. These factors are different for every organization and might change over time.
Azure AD supports the following authentication methods for hybrid identity solutions.
Cloud authentication
When you choose this authentication method, Azure AD handles users' sign-in process. Coupled with seamless
single sign-on (SSO), users can sign in to cloud apps without having to reenter their credentials. With cloud
authentication, you can choose from two options:
Azure AD password hash synchronization . The simplest way to enable authentication for on-premises
directory objects in Azure AD. Users can use the same username and password that they use on-premises without
having to deploy any additional infrastructure. Some premium features of Azure AD, like Identity Protection and
Azure AD Domain Services, require password hash synchronization, no matter which authentication method you
choose.
NOTE
Passwords are never stored in clear text or encrypted with a reversible algorithm in Azure AD. For more information on the
actual process of password hash synchronization, see Implement password hash synchronization with Azure AD Connect
sync.
Azure AD Pass-through Authentication . Provides a simple password validation for Azure AD authentication
services by using a software agent that runs on one or more on-premises servers. The servers validate the users
directly with your on-premises Active Directory, which ensures that the password validation doesn't happen in the
cloud.
Companies with a security requirement to immediately enforce on-premises user account states, password policies,
and sign-in hours might use this authentication method. For more information on the actual pass-through
authentication process, see User sign-in with Azure AD pass-through authentication.
Federated authentication
When you choose this authentication method, Azure AD hands off the authentication process to a separate trusted
authentication system, such as on-premises Active Directory Federation Services (AD FS), to validate the user’s
password.
The authentication system can provide additional advanced authentication requirements. Examples are smartcard-
based authentication or third-party multifactor authentication. For more information, see Deploying Active
Directory Federation Services.
The following section helps you decide which authentication method is right for you by using a decision tree. It
helps you determine whether to deploy cloud or federated authentication for your Azure AD hybrid identity
solution.
Decision tree
Details on decision questions:
1. Azure AD can handle sign-in for users without relying on on-premises components to verify passwords.
2. Azure AD can hand off user sign-in to a trusted authentication provider such as Microsoft’s AD FS.
3. If you need to apply, user-level Active Directory security policies such as account expired, disabled account,
password expired, account locked out, and sign-in hours on each user sign-in, Azure AD requires some on-
premises components.
4. Sign-in features not natively supported by Azure AD:
Sign-in using smartcards or certificates.
Sign-in using on-premises MFA Server.
Sign-in using third-party authentication solution.
Multi-site on-premises authentication solution.
5. Azure AD Identity Protection requires Password Hash Sync regardless of which sign-in method you choose, to
provide the Users with leaked credentials report. Organizations can fail over to Password Hash Sync if their
primary sign-in method fails and it was configured before the failure event.
NOTE
Azure AD Identity Protection require Azure AD Premium P2 licenses.
Detailed considerations
Cloud authentication: Password hash synchronization
Effor t . Password hash synchronization requires the least effort regarding deployment, maintenance, and
infrastructure. This level of effort typically applies to organizations that only need their users to sign in to
Office 365, SaaS apps, and other Azure AD-based resources. When turned on, password hash
synchronization is part of the Azure AD Connect sync process and runs every two minutes.
User experience . To improve users' sign-in experience, deploy seamless SSO with password hash
synchronization. Seamless SSO eliminates unnecessary prompts when users are signed in.
Advanced scenarios . If organizations choose to, it's possible to use insights from identities with Azure AD
Identity Protection reports with Azure AD Premium P2. An example is the leaked credentials report. Windows
Hello for Business has specific requirements when you use password hash synchronization. Azure AD
Domain Services requires password hash synchronization to provision users with their corporate credentials
in the managed domain.
Organizations that require multifactor authentication with password hash synchronization must use Azure
Multi-Factor Authentication or Conditional Access custom controls. Those organizations can't use third-party
or on-premises multifactor authentication methods that rely on federation.
NOTE
Azure AD Conditional Access require Azure AD Premium P1 licenses.
Business continuity . Using password hash synchronization with cloud authentication is highly available as
a cloud service that scales to all Microsoft datacenters. To make sure password hash synchronization does
not go down for extended periods, deploy a second Azure AD Connect server in staging mode in a standby
configuration.
Considerations . Currently, password hash synchronization doesn't immediately enforce changes in on-
premises account states. In this situation, a user has access to cloud apps until the user account state is
synchronized to Azure AD. Organizations might want to overcome this limitation by running a new
synchronization cycle after administrators do bulk updates to on-premises user account states. An example is
disabling accounts.
NOTE
The password expired and account locked-out states aren't currently synced to Azure AD with Azure AD Connect. When you
change a user's password and set the user must change password at next logon flag, the password hash will not be synced to
Azure AD with Azure AD Connect until the user changes their password.
Refer to implementing password hash synchronization for deployment steps.

Cloud authentication: Pass-through Authentication
Effor t . For pass-through authentication, you need one or more (we recommend three) lightweight agents
installed on existing servers. These agents must have access to your on-premises Active Directory Domain
Services, including your on-premises AD domain controllers. They need outbound access to the Internet and
access to your domain controllers. For this reason, it's not supported to deploy the agents in a perimeter
network.
Pass-through Authentication requires unconstrained network access to domain controllers. All network
traffic is encrypted and limited to authentication requests. For more information on this process, see the
security deep dive on pass-through authentication.
User experience . To improve users' sign-in experience, deploy seamless SSO with Pass-through
Authentication. Seamless SSO eliminates unnecessary prompts after users sign in.
Advanced scenarios . Pass-through Authentication enforces the on-premises account policy at the time of
sign-in. For example, access is denied when an on-premises user’s account state is disabled, locked out, or
their password expires or the logon attempt falls outside the hours when the user is allowed to sign in.
Organizations that require multifactor authentication with pass-through authentication must use Azure
Multi-Factor Authentication (MFA) or Conditional Access custom controls. Those organizations can't use a
third-party or on-premises multifactor authentication method that relies on federation. Advanced features
require that password hash synchronization is deployed whether or not you choose pass-through
authentication. An example is the leaked credentials report of Identity Protection.
Business continuity . We recommend that you deploy two extra pass-through authentication agents. These
extras are in addition to the first agent on the Azure AD Connect server. This additional deployment ensures
high availability of authentication requests. When you have three agents deployed, one agent can still fail
when another agent is down for maintenance.
There's another benefit to deploying password hash synchronization in addition to pass-through
authentication. It acts as a backup authentication method when the primary authentication method is no
longer available.
Considerations . You can use password hash synchronization as a backup authentication method for pass-
through authentication, when the agents can't validate a user's credentials due to a significant on-premises
failure. Fail over to password hash synchronization doesn't happen automatically and you must use Azure AD
Connect to switch the sign-on method manually.
For other considerations on Pass-through Authentication, including Alternate ID support, see frequently
asked questions.
Refer to implementing pass-through authentication for deployment steps.
Effor t . A federated authentication system relies on an external trusted system to authenticate users. Some
companies want to reuse their existing federated system investment with their Azure AD hybrid identity
solution. The maintenance and management of the federated system falls outside the control of Azure AD. It's
up to the organization by using the federated system to make sure it's deployed securely and can handle the
authentication load.
User experience . The user experience of federated authentication depends on the implementation of the
features, topology, and configuration of the federation farm. Some organizations need this flexibility to adapt
and configure the access to the federation farm to suit their security requirements. For example, it's possible
to configure internally connected users and devices to sign in users automatically, without prompting them
for credentials. This configuration works because they already signed in to their devices. If necessary, some
advanced security features make users' sign-in process more difficult.
Advanced scenarios . A federated authentication solution is required when customers have an
authentication requirement that Azure AD doesn't support natively. See detailed information to help you
choose the right sign-in option. Consider the following common requirements:
Authentication that requires smartcards or certificates.
On-premises MFA servers or third-party multifactor providers requiring a federated identity provider.
Authentication by using third-party authentication solutions. See the Azure AD federation compatibility
list.
Sign in that requires a sAMAccountName, for example DOMAIN\username, instead of a User Principal
Name (UPN), for example, user@domain.com.
Business continuity . Federated systems typically require a load-balanced array of servers, known as a
farm. This farm is configured in an internal network and perimeter network topology to ensure high
availability for authentication requests.
Deploy password hash synchronization along with federated authentication as a backup authentication
method when the primary authentication method is no longer available. An example is when the on-
premises servers aren't available. Some large enterprise organizations require a federation solution to
support multiple Internet ingress points configured with geo-DNS for low-latency authentication requests.
Considerations . Federated systems typically require a more significant investment in on-premises
infrastructure. Most organizations choose this option if they already have an on-premises federation
investment. And if it's a strong business requirement to use a single-identity provider. Federation is more
complex to operate and troubleshoot compared to cloud authentication solutions.
For a non-routable domain that can't be verified in Azure AD, you need extra configuration to implement user ID
sign in. This requirement is known as Alternate login ID support. See Configuring Alternate Login ID for limitations
and requirements. If you choose to use a third-party multi-factor authentication provider with federation, ensure
the provider supports WS-Trust to allow devices to join Azure AD.
Refer to Deploying Federation Servers for deployment steps.
NOTE
When you deploy your Azure AD hybrid identity solution, you must implement one of the supported topologies of Azure AD
Connect. Learn more about supported and unsupported configurations at Topologies for Azure AD Connect.
Architecture diagrams
The following diagrams outline the high-level architecture components required for each authentication method
you can use with your Azure AD hybrid identity solution. They provide an overview to help you compare the
differences between the solutions.
Simplicity of a password hash synchronization solution:
Agent requirements of pass-through authentication, using two agents for redundancy:
Components required for federation in your perimeter and internal network of your organization:
Comparing methods
PA SSW O RD H A SH PA SS- T H RO UGH
SY N C H RO N IZ AT IO N + A UT H EN T IC AT IO N +
C O N SIDERAT IO N SEA M L ESS SSO SEA M L ESS SSO F EDERAT IO N W IT H A D F S
Where does authentication In the cloud In the cloud after a secure On-premises
happen? password verification
exchange with the on-
premises authentication
agent
What are the on-premises None One server for each Two or more AD FS servers
server requirements beyond additional authentication
the provisioning system: agent Two or more WAP servers in
Azure AD Connect? the perimeter/DMZ network
What are the requirements None Outbound Internet access Inbound Internet access to
for on-premises Internet and from the servers running WAP servers in the
networking beyond the authentication agents perimeter
provisioning system?
Inbound network access to
AD FS servers from WAP
servers in the perimeter
Network load balancing
Is there a TLS/SSL certificate No No Yes

requirement?
Is there a health monitoring Not required Agent status provided by Azure AD Connect Health
solution? Azure Active Directory
admin center
Do users get single sign-on Yes with Seamless SSO Yes with Seamless SSO Yes
to cloud resources from
domain-joined devices within
the company network?
What sign-in types are UserPrincipalName + UserPrincipalName + UserPrincipalName +

supported? password password password
Windows-Integrated Windows-Integrated sAMAccountName +

Authentication by using Authentication by using password
Seamless SSO Seamless SSO
Windows-Integrated
Alternate login ID Alternate login ID Authentication
Certificate and smart card

authentication
Alternate login ID
Is Windows Hello for Key trust model Key trust model Key trust model
Business supported? Requires Windows Server
2016 Domain functional Certificate trust model
level
What are the multifactor Azure MFA Azure MFA Azure MFA
authentication options?
Custom Controls with Custom Controls with Azure MFA server
Conditional Access* Conditional Access*
Third-party MFA
Custom Controls with

Conditional Access*
What user account states are Disabled accounts Disabled accounts Disabled accounts
supported? (up to 30-minute delay)
Account locked out Account locked out
Account expired Account expired
Password expired Password expired
Sign-in hours Sign-in hours
What are the Conditional Azure AD Conditional Azure AD Conditional Azure AD Conditional
Access options? Access, with Azure AD Access, with Azure AD Access, with Azure AD
Premium Premium Premium
AD FS claim rules
Is blocking legacy protocols Yes Yes Yes

supported?
Can you customize the logo, Yes, with Azure AD Premium Yes, with Azure AD Premium Yes
image, and description on
the sign-in pages?
What advanced scenarios are Smart password lockout Smart password lockout Multisite low-latency
supported? authentication system
Leaked credentials reports,
with Azure AD Premium P2 AD FS extranet lockout
Integration with third-party

identity systems
NOTE
Custom controls in Azure AD Conditional Access do not currently support device registration.
Recommendations
Your identity system ensures your users' access to cloud apps and the line-of-business apps that you migrate and
make available in the cloud. To keep authorized users productive and bad actors out of your organization’s sensitive
data, authentication controls access to apps.
Use or enable password hash synchronization for whichever authentication method you choose, for the following
reasons:
1. High availability and disaster recover y . Pass-through Authentication and federation rely on on-
premises infrastructure. For pass-through authentication, the on-premises footprint includes the server
hardware and networking the Pass-through Authentication agents require. For federation, the on-premises
footprint is even larger. It requires servers in your perimeter network to proxy authentication requests and
the internal federation servers.
To avoid single points of failure, deploy redundant servers. Then authentication requests will always be
serviced if any component fails. Both pass-through authentication and federation also rely on domain
controllers to respond to authentication requests, which can also fail. Many of these components need
maintenance to stay healthy. Outages are more likely when maintenance isn't planned and implemented
correctly. Avoid outages by using password hash synchronization because the Microsoft Azure AD cloud
authentication service scales globally and is always available.
2. On-premises outage sur vival . The consequences of an on-premises outage due to a cyber-attack or
disaster can be substantial, ranging from reputational brand damage to a paralyzed organization unable to
deal with the attack. Recently, many organizations were victims of malware attacks, including targeted
ransomware, which caused their on-premises servers to go down. When Microsoft helps customers deal
with these kinds of attacks, it sees two categories of organizations:
Organizations that previously also turned on password hash synchronization on top of federated or
pass-through authentication changed their primary authentication method to then use password hash
synchronization. They were back online in a matter of hours. By using access to email via Office 365,
they worked to resolve issues and access other cloud-based workloads.
Organizations that didn’t previously enable password hash synchronization had to resort to untrusted
external consumer email systems for communications to resolve issues. In those cases, it took them
weeks to restore their on-premises identity infrastructure, before users were able to sign in to cloud-
based apps again.
3. Identity protection . One of the best ways to protect users in the cloud is Azure AD Identity Protection with
Azure AD Premium P2. Microsoft continually scans the Internet for user and password lists that bad actors
sell and make available on the dark web. Azure AD can use this information to verify if any of the usernames
and passwords in your organization are compromised. Therefore, it's critical to enable password hash
synchronization no matter which authentication method you use, whether it's federated or pass-through
authentication. Leaked credentials are presented as a report. Use this information to block or force users to
change their passwords when they try to sign in with leaked passwords.
Conclusion
This article outlines various authentication options that organizations can configure and deploy to support access to
cloud apps. To meet various business, security, and technical requirements, organizations can choose between
password hash synchronization, Pass-through Authentication, and federation.
Consider each authentication method. Does the effort to deploy the solution, and the user's experience of the sign-
in process address your business requirements? Evaluate whether your organization needs the advanced scenarios
and business continuity features of each authentication method. Finally, evaluate the considerations of each
authentication method. Do any of them prevent you from implementing your choice?
Next steps
In today’s world, threats are present 24 hours a day and come from everywhere. Implement the correct
authentication method, and it will mitigate your security risks and protect your identities.
Get started with Azure AD and deploy the right authentication solution for your organization.
If you're thinking about migrating from federated to cloud authentication, learn more about changing the sign-in
method. To help you plan and implement the migration, use these project deployment plans or consider using the
new Staged Rollout feature to migrate federated users to using cloud authentication in a staged approach.
What is Azure AD Connect?
Azure AD Connect is the Microsoft tool designed to meet and accomplish your hybrid identity goals. It provides
the following features:
Password hash synchronization - A sign-in method that synchronizes a hash of a users on-premises AD
password with Azure AD.
Pass-through authentication - A sign-in method that allows users to use the same password on-premises and
in the cloud, but doesn't require the additional infrastructure of a federated environment.
Federation integration - Federation is an optional part of Azure AD Connect and can be used to configure a
hybrid environment using an on-premises AD FS infrastructure. It also provides AD FS management
capabilities such as certificate renewal and additional AD FS server deployments.
Synchronization - Responsible for creating users, groups, and other objects. As well as, making sure identity
information for your on-premises users and groups is matching the cloud. This synchronization also includes
password hashes.
- Azure AD Connect Health can provide robust monitoring and provide a central location in the Azure portal
Healt h Monit oring
to view this activity.
What is Azure AD Connect Health?

Azure Active Directory (Azure AD) Connect Health provides robust monitoring of your on-premises identity
infrastructure. It enables you to maintain a reliable connection to Office 365 and Microsoft Online Services. This
reliability is achieved by providing monitoring capabilities for your key identity components. Also, it makes the
key data points about these components easily accessible.
The information is presented in the Azure AD Connect Health portal. Use the Azure AD Connect Health portal to
view alerts, performance monitoring, usage analytics, and other information. Azure AD Connect Health enables
the single lens of health for your key identity components in one place.
Why use Azure AD Connect?
Integrating your on-premises directories with Azure AD makes your users more productive by providing a
common identity for accessing both cloud and on-premises resources. Users and organizations can take
advantage of:
Users can use a single identity to access on-premises applications and cloud services such as Office 365.
Single tool to provide an easy deployment experience for synchronization and sign-in.
Provides the newest capabilities for your scenarios. Azure AD Connect replaces older versions of identity
integration tools such as DirSync and Azure AD Sync. For more information, see Hybrid Identity directory
integration tools comparison.
Why use Azure AD Connect Health?

When with Azure AD, your users are more productive because there's a common identity to access both cloud
and on-premises resources. Ensuring the environment is reliable, so that users can access these resources,
becomes a challenge. Azure AD Connect Health helps monitor and gain insights into your on-premises identity
infrastructure thus ensuring the reliability of this environment. It is as simple as installing an agent on each of
your on-premises identity servers.
Azure AD Connect Health for AD FS supports AD FS 2.0 on Windows Server 2008 R2, Windows Server 2012,
Windows Server 2012 R2 and Windows Server 2016. It also supports monitoring the AD FS proxy or web
application proxy servers that provide authentication support for extranet access. With an easy and quick
installation of the Health Agent, Azure AD Connect Health for AD FS provides you a set of key capabilities.
Key benefits and best practices:
K EY B EN EF IT S B EST P RA C T IC ES
Enhanced security Extranet lockout trends

Failed sign-ins report
In privacy compliant
Get alerted on all critical ADFS system issues Server configuration and availability
Performance and connectivity
Regular maintenance
Easy to deploy and manage Quick agent installation

Agent auto upgrade to the latest
Data available in portal within minutes
Rich usage metrics Top applications usage

Network locations and TCP connection
Token requests per server
Great user experience Dashboard fashion from Azure portal

Alerts through emails
License requirements for using Azure AD Connect

Using this feature is free and included in your Azure subscription.
License requirements for using Azure AD Connect Health

Using this feature requires an Azure AD Premium P1 license. To find the right license for your requirements,
see Comparing generally available features of the Free, Basic, and Premium editions.
Next steps
Express settings
Customized settings
Install Azure AD Connect Health agents
Choose the right authentication method for your
Azure Active Directory hybrid identity solution
Choosing the correct authentication method is the first concern for organizations wanting to move their apps to
the cloud. Don't take this decision lightly, for the following reasons:
1. It's the first decision for an organization that wants to move to the cloud.
2. The authentication method is a critical component of an organization’s presence in the cloud. It controls
access to all cloud data and resources.
3. It's the foundation of all the other advanced security and user experience features in Azure AD.
Identity is the new control plane of IT security, so authentication is an organization’s access guard to the new cloud
world. Organizations need an identity control plane that strengthens their security and keeps their cloud apps safe
from intruders.
NOTE
Changing your authentication method requires planning, testing, and potentially downtime. Staged rollout is a great way to
test users migration from federation to cloud authentication.
Out of scope
Organizations that don't have an existing on-premises directory footprint aren't the focus of this article. Typically,
those businesses create identities only in the cloud, which doesn’t require a hybrid identity solution. Cloud-only
identities exist solely in the cloud and aren't associated with corresponding on-premises identities.
Authentication methods
When the Azure AD hybrid identity solution is your new control plane, authentication is the foundation of cloud
access. Choosing the correct authentication method is a crucial first decision in setting up an Azure AD hybrid
identity solution. Implement the authentication method that is configured by using Azure AD Connect, which also
provisions users in the cloud.
To choose an authentication method, you need to consider the time, existing infrastructure, complexity, and cost of
implementing your choice. These factors are different for every organization and might change over time.
Azure AD supports the following authentication methods for hybrid identity solutions.
Cloud authentication
When you choose this authentication method, Azure AD handles users' sign-in process. Coupled with seamless
single sign-on (SSO), users can sign in to cloud apps without having to reenter their credentials. With cloud
authentication, you can choose from two options:
Azure AD password hash synchronization . The simplest way to enable authentication for on-premises
directory objects in Azure AD. Users can use the same username and password that they use on-premises without
having to deploy any additional infrastructure. Some premium features of Azure AD, like Identity Protection and
Azure AD Domain Services, require password hash synchronization, no matter which authentication method you
choose.
NOTE
Passwords are never stored in clear text or encrypted with a reversible algorithm in Azure AD. For more information on the
actual process of password hash synchronization, see Implement password hash synchronization with Azure AD Connect
sync.
Azure AD Pass-through Authentication . Provides a simple password validation for Azure AD authentication
services by using a software agent that runs on one or more on-premises servers. The servers validate the users
directly with your on-premises Active Directory, which ensures that the password validation doesn't happen in the
cloud.
Companies with a security requirement to immediately enforce on-premises user account states, password
policies, and sign-in hours might use this authentication method. For more information on the actual pass-
through authentication process, see User sign-in with Azure AD pass-through authentication.
When you choose this authentication method, Azure AD hands off the authentication process to a separate trusted
authentication system, such as on-premises Active Directory Federation Services (AD FS), to validate the user’s
password.
The authentication system can provide additional advanced authentication requirements. Examples are
smartcard-based authentication or third-party multifactor authentication. For more information, see Deploying
Active Directory Federation Services.
The following section helps you decide which authentication method is right for you by using a decision tree. It
helps you determine whether to deploy cloud or federated authentication for your Azure AD hybrid identity
solution.
Decision tree
Details on decision questions:
1. Azure AD can handle sign-in for users without relying on on-premises components to verify passwords.
2. Azure AD can hand off user sign-in to a trusted authentication provider such as Microsoft’s AD FS.
3. If you need to apply, user-level Active Directory security policies such as account expired, disabled account,
password expired, account locked out, and sign-in hours on each user sign-in, Azure AD requires some on-
premises components.
4. Sign-in features not natively supported by Azure AD:
Sign-in using smartcards or certificates.
Sign-in using on-premises MFA Server.
Sign-in using third-party authentication solution.
Multi-site on-premises authentication solution.
5. Azure AD Identity Protection requires Password Hash Sync regardless of which sign-in method you choose, to
provide the Users with leaked credentials report. Organizations can fail over to Password Hash Sync if their
primary sign-in method fails and it was configured before the failure event.
NOTE
Azure AD Identity Protection require Azure AD Premium P2 licenses.
Detailed considerations
Cloud authentication: Password hash synchronization
Effor t . Password hash synchronization requires the least effort regarding deployment, maintenance, and
infrastructure. This level of effort typically applies to organizations that only need their users to sign in to
Office 365, SaaS apps, and other Azure AD-based resources. When turned on, password hash
synchronization is part of the Azure AD Connect sync process and runs every two minutes.
User experience . To improve users' sign-in experience, deploy seamless SSO with password hash
synchronization. Seamless SSO eliminates unnecessary prompts when users are signed in.
Advanced scenarios . If organizations choose to, it's possible to use insights from identities with Azure AD
Identity Protection reports with Azure AD Premium P2. An example is the leaked credentials report.
Windows Hello for Business has specific requirements when you use password hash synchronization.
Azure AD Domain Services requires password hash synchronization to provision users with their corporate
credentials in the managed domain.
Organizations that require multifactor authentication with password hash synchronization must use Azure
Multi-Factor Authentication or Conditional Access custom controls. Those organizations can't use third-
party or on-premises multifactor authentication methods that rely on federation.
NOTE
Azure AD Conditional Access require Azure AD Premium P1 licenses.
Business continuity . Using password hash synchronization with cloud authentication is highly available
as a cloud service that scales to all Microsoft datacenters. To make sure password hash synchronization
does not go down for extended periods, deploy a second Azure AD Connect server in staging mode in a
standby configuration.
Considerations . Currently, password hash synchronization doesn't immediately enforce changes in on-
premises account states. In this situation, a user has access to cloud apps until the user account state is
synchronized to Azure AD. Organizations might want to overcome this limitation by running a new
synchronization cycle after administrators do bulk updates to on-premises user account states. An example
is disabling accounts.
NOTE
The password expired and account locked-out states aren't currently synced to Azure AD with Azure AD Connect. When
you change a user's password and set the user must change password at next logon flag, the password hash will not be
synced to Azure AD with Azure AD Connect until the user changes their password.
Refer to implementing password hash synchronization for deployment steps.

Cloud authentication: Pass-through Authentication
Effor t . For pass-through authentication, you need one or more (we recommend three) lightweight agents
installed on existing servers. These agents must have access to your on-premises Active Directory Domain
Services, including your on-premises AD domain controllers. They need outbound access to the Internet
and access to your domain controllers. For this reason, it's not supported to deploy the agents in a
perimeter network.
Pass-through Authentication requires unconstrained network access to domain controllers. All network
traffic is encrypted and limited to authentication requests. For more information on this process, see the
security deep dive on pass-through authentication.
User experience . To improve users' sign-in experience, deploy seamless SSO with Pass-through
Authentication. Seamless SSO eliminates unnecessary prompts after users sign in.
Advanced scenarios . Pass-through Authentication enforces the on-premises account policy at the time of
sign-in. For example, access is denied when an on-premises user’s account state is disabled, locked out, or
their password expires or the logon attempt falls outside the hours when the user is allowed to sign in.
Organizations that require multifactor authentication with pass-through authentication must use Azure
Multi-Factor Authentication (MFA) or Conditional Access custom controls. Those organizations can't use a
third-party or on-premises multifactor authentication method that relies on federation. Advanced features
require that password hash synchronization is deployed whether or not you choose pass-through
authentication. An example is the leaked credentials report of Identity Protection.
Business continuity . We recommend that you deploy two extra pass-through authentication agents.
These extras are in addition to the first agent on the Azure AD Connect server. This additional deployment
ensures high availability of authentication requests. When you have three agents deployed, one agent can
still fail when another agent is down for maintenance.
There's another benefit to deploying password hash synchronization in addition to pass-through
authentication. It acts as a backup authentication method when the primary authentication method is no
longer available.
Considerations . You can use password hash synchronization as a backup authentication method for pass-
through authentication, when the agents can't validate a user's credentials due to a significant on-premises
failure. Fail over to password hash synchronization doesn't happen automatically and you must use Azure
AD Connect to switch the sign-on method manually.
For other considerations on Pass-through Authentication, including Alternate ID support, see frequently
asked questions.
Refer to implementing pass-through authentication for deployment steps.
Effor t . A federated authentication system relies on an external trusted system to authenticate users. Some
companies want to reuse their existing federated system investment with their Azure AD hybrid identity
solution. The maintenance and management of the federated system falls outside the control of Azure AD.
It's up to the organization by using the federated system to make sure it's deployed securely and can
handle the authentication load.
User experience . The user experience of federated authentication depends on the implementation of the
features, topology, and configuration of the federation farm. Some organizations need this flexibility to
adapt and configure the access to the federation farm to suit their security requirements. For example, it's
possible to configure internally connected users and devices to sign in users automatically, without
prompting them for credentials. This configuration works because they already signed in to their devices. If
necessary, some advanced security features make users' sign-in process more difficult.
Advanced scenarios . A federated authentication solution is required when customers have an
authentication requirement that Azure AD doesn't support natively. See detailed information to help you
choose the right sign-in option. Consider the following common requirements:
Authentication that requires smartcards or certificates.
On-premises MFA servers or third-party multifactor providers requiring a federated identity provider.
Authentication by using third-party authentication solutions. See the Azure AD federation compatibility
list.
Sign in that requires a sAMAccountName, for example DOMAIN\username, instead of a User Principal
Name (UPN), for example, user@domain.com.
Business continuity . Federated systems typically require a load-balanced array of servers, known as a
farm. This farm is configured in an internal network and perimeter network topology to ensure high
availability for authentication requests.
Deploy password hash synchronization along with federated authentication as a backup authentication
method when the primary authentication method is no longer available. An example is when the on-
premises servers aren't available. Some large enterprise organizations require a federation solution to
support multiple Internet ingress points configured with geo-DNS for low-latency authentication requests.
Considerations . Federated systems typically require a more significant investment in on-premises
infrastructure. Most organizations choose this option if they already have an on-premises federation
investment. And if it's a strong business requirement to use a single-identity provider. Federation is more
complex to operate and troubleshoot compared to cloud authentication solutions.
For a non-routable domain that can't be verified in Azure AD, you need extra configuration to implement user ID
sign in. This requirement is known as Alternate login ID support. See Configuring Alternate Login ID for
limitations and requirements. If you choose to use a third-party multi-factor authentication provider with
federation, ensure the provider supports WS-Trust to allow devices to join Azure AD.
Refer to Deploying Federation Servers for deployment steps.
NOTE
When you deploy your Azure AD hybrid identity solution, you must implement one of the supported topologies of Azure
AD Connect. Learn more about supported and unsupported configurations at Topologies for Azure AD Connect.
Architecture diagrams
The following diagrams outline the high-level architecture components required for each authentication method
you can use with your Azure AD hybrid identity solution. They provide an overview to help you compare the
differences between the solutions.
Simplicity of a password hash synchronization solution:
Agent requirements of pass-through authentication, using two agents for redundancy:
Components required for federation in your perimeter and internal network of your organization:
Comparing methods
Where does authentication In the cloud In the cloud after a secure On-premises
happen? password verification
exchange with the on-
premises authentication
agent
What are the on-premises None One server for each Two or more AD FS servers
server requirements beyond additional authentication
the provisioning system: agent Two or more WAP servers in
Azure AD Connect? the perimeter/DMZ network
What are the requirements None Outbound Internet access Inbound Internet access to
for on-premises Internet from the servers running WAP servers in the
and networking beyond the authentication agents perimeter
provisioning system?
Inbound network access to
AD FS servers from WAP
servers in the perimeter
Network load balancing
Is there a TLS/SSL certificate No No Yes

requirement?
Is there a health monitoring Not required Agent status provided by Azure AD Connect Health
solution? Azure Active Directory
admin center
Do users get single sign-on Yes with Seamless SSO Yes with Seamless SSO Yes
to cloud resources from
domain-joined devices
within the company
network?
What sign-in types are UserPrincipalName + UserPrincipalName + UserPrincipalName +

supported? password password password
Windows-Integrated Windows-Integrated sAMAccountName +

Authentication by using Authentication by using password
Seamless SSO Seamless SSO
Windows-Integrated
Alternate login ID Alternate login ID Authentication
Certificate and smart card

authentication
Alternate login ID
Is Windows Hello for Key trust model Key trust model Key trust model
Business supported? Requires Windows Server
2016 Domain functional Certificate trust model
level
What are the multifactor Azure MFA Azure MFA Azure MFA
authentication options?
Custom Controls with Custom Controls with Azure MFA server
Conditional Access* Conditional Access*
Third-party MFA
Custom Controls with

Conditional Access*
What user account states Disabled accounts Disabled accounts Disabled accounts
are supported? (up to 30-minute delay)
Account locked out Account locked out
Account expired Account expired
Password expired Password expired
Sign-in hours Sign-in hours
What are the Conditional Azure AD Conditional Azure AD Conditional Azure AD Conditional
Access options? Access, with Azure AD Access, with Azure AD Access, with Azure AD
Premium Premium Premium
AD FS claim rules
Is blocking legacy protocols Yes Yes Yes

supported?
Can you customize the logo, Yes, with Azure AD Premium Yes, with Azure AD Premium Yes
image, and description on
the sign-in pages?
What advanced scenarios Smart password lockout Smart password lockout Multisite low-latency
are supported? authentication system
Leaked credentials reports,
with Azure AD Premium P2 AD FS extranet lockout
Integration with third-party

identity systems
NOTE
Custom controls in Azure AD Conditional Access do not currently support device registration.
Recommendations
Your identity system ensures your users' access to cloud apps and the line-of-business apps that you migrate and
make available in the cloud. To keep authorized users productive and bad actors out of your organization’s
sensitive data, authentication controls access to apps.
Use or enable password hash synchronization for whichever authentication method you choose, for the following
reasons:
1. High availability and disaster recover y . Pass-through Authentication and federation rely on on-
premises infrastructure. For pass-through authentication, the on-premises footprint includes the server
hardware and networking the Pass-through Authentication agents require. For federation, the on-premises
footprint is even larger. It requires servers in your perimeter network to proxy authentication requests and
the internal federation servers.
To avoid single points of failure, deploy redundant servers. Then authentication requests will always be
serviced if any component fails. Both pass-through authentication and federation also rely on domain
controllers to respond to authentication requests, which can also fail. Many of these components need
maintenance to stay healthy. Outages are more likely when maintenance isn't planned and implemented
correctly. Avoid outages by using password hash synchronization because the Microsoft Azure AD cloud
authentication service scales globally and is always available.
2. On-premises outage sur vival . The consequences of an on-premises outage due to a cyber-attack or
disaster can be substantial, ranging from reputational brand damage to a paralyzed organization unable to
deal with the attack. Recently, many organizations were victims of malware attacks, including targeted
ransomware, which caused their on-premises servers to go down. When Microsoft helps customers deal
with these kinds of attacks, it sees two categories of organizations:
Organizations that previously also turned on password hash synchronization on top of federated or
pass-through authentication changed their primary authentication method to then use password
hash synchronization. They were back online in a matter of hours. By using access to email via Office
365, they worked to resolve issues and access other cloud-based workloads.
Organizations that didn’t previously enable password hash synchronization had to resort to
untrusted external consumer email systems for communications to resolve issues. In those cases, it
took them weeks to restore their on-premises identity infrastructure, before users were able to sign
in to cloud-based apps again.
3. Identity protection . One of the best ways to protect users in the cloud is Azure AD Identity Protection
with Azure AD Premium P2. Microsoft continually scans the Internet for user and password lists that bad
actors sell and make available on the dark web. Azure AD can use this information to verify if any of the
usernames and passwords in your organization are compromised. Therefore, it's critical to enable
password hash synchronization no matter which authentication method you use, whether it's federated or
pass-through authentication. Leaked credentials are presented as a report. Use this information to block or
force users to change their passwords when they try to sign in with leaked passwords.
Conclusion
This article outlines various authentication options that organizations can configure and deploy to support access
to cloud apps. To meet various business, security, and technical requirements, organizations can choose between
password hash synchronization, Pass-through Authentication, and federation.
Consider each authentication method. Does the effort to deploy the solution, and the user's experience of the
sign-in process address your business requirements? Evaluate whether your organization needs the advanced
scenarios and business continuity features of each authentication method. Finally, evaluate the considerations of
each authentication method. Do any of them prevent you from implementing your choice?
Next steps
In today’s world, threats are present 24 hours a day and come from everywhere. Implement the correct
authentication method, and it will mitigate your security risks and protect your identities.
Get started with Azure AD and deploy the right authentication solution for your organization.
If you're thinking about migrating from federated to cloud authentication, learn more about changing the sign-in
method. To help you plan and implement the migration, use these project deployment plans or consider using the
new Staged Rollout feature to migrate federated users to using cloud authentication in a staged approach.
Identity synchronization and duplicate attribute
resiliency
Duplicate Attribute Resiliency is a feature in Azure Active Directory that will eliminate friction caused by
UserPrincipalName and SMTP ProxyAddress conflicts when running one of Microsoft’s synchronization tools.
These two attributes are generally required to be unique across all User , Group , or Contact objects in a given
Azure Active Directory tenant.
NOTE
Only Users can have UPNs.
The new behavior that this feature enables is in the cloud portion of the sync pipeline, therefore it is client agnostic
and relevant for any Microsoft synchronization product including Azure AD Connect, DirSync and MIM +
Connector. The generic term “sync client” is used in this document to represent any one of these products.
Current behavior
If there is an attempt to provision a new object with a UPN or ProxyAddress value that violates this uniqueness
constraint, Azure Active Directory blocks that object from being created. Similarly, if an object is updated with a
non-unique UPN or ProxyAddress, the update fails. The provisioning attempt or update is retried by the sync client
upon each export cycle, and continues to fail until the conflict is resolved. An error report email is generated upon
each attempt and an error is logged by the sync client.
Behavior with Duplicate Attribute Resiliency

Instead of completely failing to provision or update an object with a duplicate attribute, Azure Active Directory
“quarantines” the duplicate attribute which would violate the uniqueness constraint. If this attribute is required for
provisioning, like UserPrincipalName, the service assigns a placeholder value. The format of these temporary
values is
<OriginalPrefix>+<4DigitNumber>@<InitialTenantDomain>.onmicrosoft.com .
The attribute resiliency process handles only UPN and SMTP ProxyAddress values.
If the attribute is not required, like a ProxyAddress , Azure Active Directory simply quarantines the conflict
attribute and proceeds with the object creation or update.
Upon quarantining the attribute, information about the conflict is sent in the same error report email used in the
old behavior. However, this info only appears in the error report one time, when the quarantine happens, it does
not continue to be logged in future emails. Also, since the export for this object has succeeded, the sync client does
not log an error and does not retry the create / update operation upon subsequent sync cycles.
To support this behavior a new attribute has been added to the User, Group, and Contact object classes:
DirSyncProvisioningErrors
This is a multi-valued attribute that is used to store the conflicting attributes that would violate the uniqueness
constraint should they be added normally. A background timer task has been enabled in Azure Active Directory
that runs every hour to look for duplicate attribute conflicts that have been resolved, and automatically removes
the attributes in question from quarantine.
Enabling Duplicate Attribute Resiliency
Duplicate Attribute Resiliency will be the new default behavior across all Azure Active Directory tenants. It will be
on by default for all tenants that enabled synchronization for the first time on August 22nd, 2016 or later. Tenants
that enabled sync prior to this date will have the feature enabled in batches. This rollout will begin in September
2016, and an email notification will be sent to each tenant's technical notification contact with the specific date
when the feature will be enabled.
NOTE
Once Duplicate Attribute Resiliency has been turned on it cannot be disabled.
To check if the feature is enabled for your tenant, you can do so by downloading the latest version of the Azure
Active Directory PowerShell module and running:
Get-MsolDirSyncFeatures -Feature DuplicateUPNResiliency
Get-MsolDirSyncFeatures -Feature DuplicateProxyAddressResiliency
NOTE
You can no longer use Set-MsolDirSyncFeature cmdlet to proactively enable the Duplicate Attribute Resiliency feature before
it is turned on for your tenant. To be able to test the feature, you will need to create a new Azure Active Directory tenant.
Identifying Objects with DirSyncProvisioningErrors

There are currently two methods to identify objects that have these errors due to duplicate property conflicts,
Azure Active Directory PowerShell and the Microsoft 365 admin center. There are plans to extend to additional
portal based reporting in the future.
Azure Active Directory PowerShell
For the PowerShell cmdlets in this topic, the following is true:
All of the following cmdlets are case sensitive.
The –ErrorCategor y Proper tyConflict must always be included. There are currently no other types of
ErrorCategor y , but this may be extended in the future.
First, get started by running Connect-MsolSer vice and entering credentials for a tenant administrator.
Then, use the following cmdlets and operators to view errors in different ways:
1. See All
2. By Property Type
3. By Conflicting Value
4. Using a String Search
5. Sorted
6. In a Limited Quantity or All
See all
Once connected, to see a general list of attribute provisioning errors in the tenant run:
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict
This produces a result like the following:

By property type
To see errors by property type, add the -Proper tyName flag with the UserPrincipalName or ProxyAddresses
argument:
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyName UserPrincipalName
Or
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyName ProxyAddresses
By conflicting value
To see errors relating to a specific property add the -Proper tyValue flag (-Proper tyName must be used as well
when adding this flag):
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyValue User@domain.com -PropertyName
UserPrincipalName
Using a string search

To do a broad string search use the -SearchString flag. This can be used independently from all of the above
flags, with the exception of -ErrorCategor y Proper tyConflict , which is always required:
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -SearchString User
In a limited quantity or all

1. MaxResults <Int> can be used to limit the query to a specific number of values.
2. All can be used to ensure all results are retrieved in the case that a large number of errors exists.
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -MaxResults 5
Microsoft 365 admin center

You can view directory synchronization errors in the Microsoft 365 admin center. The report in the Microsoft 365
admin center only displays User objects that have these errors. It does not show info about conflicts between
Groups and Contacts .
For instructions on how to view directory synchronization errors in the Microsoft 365 admin center, see Identify
directory synchronization errors in Office 365.
Identity synchronization error report
When an object with a duplicate attribute conflict is handled with this new behavior a notification is included in the
standard Identity Synchronization Error Report email that is sent to the Technical Notification contact for the
tenant. However, there is an important change in this behavior. In the past, information about a duplicate attribute
conflict would be included in every subsequent error report until the conflict was resolved. With this new behavior,
the error notification for a given conflict does only appear once- at the time the conflicting attribute is quarantined.
Here is an example of what the email notification looks like for a ProxyAddress conflict:
Resolving conflicts
Troubleshooting strategy and resolution tactics for these errors should not differ from the way duplicate attribute
errors were handled in the past. The only difference is that the timer task sweeps through the tenant on the
service-side to automatically add the attribute in question to the proper object once the conflict is resolved.
The following article outlines various troubleshooting and resolution strategies: Duplicate or invalid attributes
prevent directory synchronization in Office 365.
Known issues
None of these known issues causes data loss or service degradation. Several of them are aesthetic, others cause
standard “pre-resiliency” duplicate attribute errors to be thrown instead of quarantining the conflict attribute, and
another causes certain errors to require extra manual fix-up.
Core behavior :
1. Objects with specific attribute configurations continue to receive export errors as opposed to the duplicate
attribute(s) being quarantined.
For example:
a. New user is created in AD with a UPN of Joe@contoso.com and ProxyAddress
smtp:Joe@contoso.com
b. The properties of this object conflict with an existing Group, where ProxyAddress is
SMTP:Joe@contoso.com .
c. Upon export, a ProxyAddress conflict error is thrown instead of having the conflict attributes
quarantined. The operation is retried upon each subsequent sync cycle, as it would have been before the
resiliency feature was enabled.
2. If two Groups are created on-premises with the same SMTP address, one fails to provision on the first
attempt with a standard duplicate ProxyAddress error. However, the duplicate value is properly
quarantined upon the next sync cycle.
Office Por tal Repor t :
1. The detailed error message for two objects in a UPN conflict set is the same. This indicates that they have
both had their UPN changed / quarantined, when in fact only a one of them had any data changed.
2. The detailed error message for a UPN conflict shows the wrong displayName for a user who has had their
UPN changed/quarantined. For example:
a. User A syncs up first with UPN = User@contoso.com .
b. User B is attempted to be synced up next with UPN = User@contoso.com .
c. User B’s UPN is changed to User1234@contoso.onmicrosoft.com and User@contoso.com is
added to DirSyncProvisioningErrors .
d. The error message for User B should indicate that User A already has User@contoso.com as a UPN,
but it shows User B’s own displayName.
Identity synchronization error repor t :
The link for steps on how to resolve this issue is incorrect:
It should point to https://aka.ms/duplicateattributeresiliency.
See also
Azure AD Connect sync
Integrating your on-premises identities with Azure Active Directory
Identify directory synchronization errors in Office 365
What is password hash synchronization with Azure
AD?
Password hash synchronization is one of the sign-in methods used to accomplish hybrid identity. Azure AD
Connect synchronizes a hash, of the hash, of a user's password from an on-premises Active Directory instance to a
cloud-based Azure AD instance.
Password hash synchronization is an extension to the directory synchronization feature implemented by Azure AD
Connect sync. You can use this feature to sign in to Azure AD services like Office 365. You sign in to the service by
using the same password you use to sign in to your on-premises Active Directory instance.
Password hash synchronization helps by reducing the number of passwords, your users need to maintain to just
one. Password hash synchronization can:
Improve the productivity of your users.
Reduce your helpdesk costs.
Password Hash Sync also enables leaked credential detection for your hybrid accounts. Microsoft works alongside
dark web researchers and law enforcement agencies to find publicly available username/password pairs. If any of
these pairs match those of our users, the associated account is moved to high risk.
NOTE
Only new leaked credentials found after you enable PHS will be processed against your tenant. Verifying against previously
found credential pairs is not performed.
Optionally, you can set up password hash synchronization as a backup if you decide to use Federation with Active
Directory Federation Services (AD FS) as your sign-in method.
To use password hash synchronization in your environment, you need to:
Install Azure AD Connect.
Configure directory synchronization between your on-premises Active Directory instance and your Azure
Active Directory instance.
Enable password hash synchronization.
For more information, see What is hybrid identity?.
Next Steps
What is pass-through authentication (PTA)?
What is federation?
How Password hash synchronization works
Implement password hash synchronization with
This article provides information that you need to synchronize your user passwords from an on-premises
Active Directory instance to a cloud-based Azure Active Directory (Azure AD) instance.
How password hash synchronization works

The Active Directory domain service stores passwords in the form of a hash value representation, of the actual
user password. A hash value is a result of a one-way mathematical function (the hashing algorithm). There is
no method to revert the result of a one-way function to the plain text version of a password.
To synchronize your password, Azure AD Connect sync extracts your password hash from the on-premises
Active Directory instance. Extra security processing is applied to the password hash before it is synchronized to
the Azure Active Directory authentication service. Passwords are synchronized on a per-user basis and in
chronological order.
The actual data flow of the password hash synchronization process is similar to the synchronization of user
data. However, passwords are synchronized more frequently than the standard directory synchronization
window for other attributes. The password hash synchronization process runs every 2 minutes. You cannot
modify the frequency of this process. When you synchronize a password, it overwrites the existing cloud
password.
The first time you enable the password hash synchronization feature, it performs an initial synchronization of
the passwords of all in-scope users. You cannot explicitly define a subset of user passwords that you want to
synchronize. However, if there are multiple connectors, it is possible to disable password hash sync for some
connectors but not others using the Set-ADSyncAADPasswordSyncConfiguration cmdlet.
When you change an on-premises password, the updated password is synchronized, most often in a matter of
minutes. The password hash synchronization feature automatically retries failed synchronization attempts. If an
error occurs during an attempt to synchronize a password, an error is logged in your event viewer.
The synchronization of a password has no impact on the user who is currently signed in. Your current cloud
service session is not immediately affected by a synchronized password change that occurs, while you are
signed in, to a cloud service. However, when the cloud service requires you to authenticate again, you need to
provide your new password.
A user must enter their corporate credentials a second time to authenticate to Azure AD, regardless of whether
they're signed in to their corporate network. This pattern can be minimized, however, if the user selects the
Keep me signed in (KMSI) check box at sign-in. This selection sets a session cookie that bypasses authentication
for 180 days. KMSI behavior can be enabled or disabled by the Azure AD administrator. In addition, you can
reduce password prompts by turning on Seamless SSO, which automatically signs users in when they are on
their corporate devices connected to your corporate network.
NOTE
Password sync is only supported for the object type user in Active Directory. It is not supported for the iNetOrgPerson
object type.
Detailed description of how password hash synchronization works
The following section describes, in-depth, how password hash synchronization works between Active Directory
and Azure AD.
1. Every two minutes, the password hash synchronization agent on the AD Connect server requests stored
password hashes (the unicodePwd attribute) from a DC. This request is via the standard MS-DRSR
replication protocol used to synchronize data between DCs. The service account must have Replicate
Directory Changes and Replicate Directory Changes All AD permissions (granted by default on installation)
to obtain the password hashes.
2. Before sending, the DC encrypts the MD4 password hash by using a key that is a MD5 hash of the RPC
session key and a salt. It then sends the result to the password hash synchronization agent over RPC. The
DC also passes the salt to the synchronization agent by using the DC replication protocol, so the agent will
be able to decrypt the envelope.
3. After the password hash synchronization agent has the encrypted envelope, it uses
MD5CryptoServiceProvider and the salt to generate a key to decrypt the received data back to its original
MD4 format. The password hash synchronization agent never has access to the clear text password. The
password hash synchronization agent’s use of MD5 is strictly for replication protocol compatibility with the
DC, and it is only used on premises between the DC and the password hash synchronization agent.
4. The password hash synchronization agent expands the 16-byte binary password hash to 64 bytes by first
converting the hash to a 32-byte hexadecimal string, then converting this string back into binary with UTF-
16 encoding.
5. The password hash synchronization agent adds a per user salt, consisting of a 10-byte length salt, to the 64-
byte binary to further protect the original hash.
6. The password hash synchronization agent then combines the MD4 hash plus the per user salt, and inputs it
into the PBKDF2 function. 1000 iterations of the HMAC-SHA256 keyed hashing algorithm are used.
7. The password hash synchronization agent takes the resulting 32-byte hash, concatenates both the per user
salt and the number of SHA256 iterations to it (for use by Azure AD), then transmits the string from Azure
AD Connect to Azure AD over TLS.
8. When a user attempts to sign in to Azure AD and enters their password, the password is run through the
same MD4+salt+PBKDF2+HMAC-SHA256 process. If the resulting hash matches the hash stored in Azure
AD, the user has entered the correct password and is authenticated.
NOTE
The original MD4 hash is not transmitted to Azure AD. Instead, the SHA256 hash of the original MD4 hash is
transmitted. As a result, if the hash stored in Azure AD is obtained, it cannot be used in an on-premises pass-the-hash
attack.
Security considerations
When synchronizing passwords, the plain-text version of your password is not exposed to the password hash
synchronization feature, to Azure AD, or any of the associated services.
User authentication takes place against Azure AD rather than against the organization's own Active Directory
instance. The SHA256 password data stored in Azure AD--a hash of the original MD4 hash--is more secure
than what is stored in Active Directory. Further, because this SHA256 hash cannot be decrypted, it cannot be
brought back to the organization's Active Directory environment and presented as a valid user password in a
pass-the-hash attack.
Password policy considerations
There are two types of password policies that are affected by enabling password hash synchronization:
Password complexity policy
Password expiration policy
Password complexity policy
When password hash synchronization is enabled, the password complexity policies in your on-premises Active
Directory instance override complexity policies in the cloud for synchronized users. You can use all of the valid
passwords from your on-premises Active Directory instance to access Azure AD services.
NOTE
Passwords for users that are created directly in the cloud are still subject to password policies as defined in the cloud.
Password expiration policy

If a user is in the scope of password hash synchronization, by default the cloud account password is set to
Never Expire.
You can continue to sign in to your cloud services by using a synchronized password that is expired in your on-
premises environment. Your cloud password is updated the next time you change the password in the on-
premises environment.
En fo r c e C l o u d P a ssw o r d P o l i c y F o r P a ssw o r d Sy n c e d U se r s
If there are synchronized users that only interact with Azure AD integrated services and must also comply with
a password expiration policy, you can force them to comply with your Azure AD password expiration policy by
enabling the EnforceCloudPasswordPolicyForPasswordSyncedUsers feature.
When EnforceCloudPasswordPolicyForPasswordSyncedUsers is disabled (which is the default setting), Azure
AD Connect sets thePasswordPoliciesattribute of synchronized users to "DisablePasswordExpiration". This is
done every time a user's password is synchronized and instructs Azure AD to ignore the cloud password
expiration policy for that user. You can check the value of the attribute using theAzure ADPowerShell module
with the following command:
(Get-AzureADUser -objectID <User Object ID>).passwordpolicies
To enable the EnforceCloudPasswordPolicyForPasswordSyncedUsers feature, run the following command

using the MSOnline PowerShell module as shown below. You would have to type yes for the Enable parameter
as shown below :
Set-MsolDirSyncFeature -Feature EnforceCloudPasswordPolicyForPasswordSyncedUsers
cmdlet Set-MsolDirSyncFeature at command pipeline position 1
Supply values for the following parameters:
Enable: yes
Confirm
Continue with this operation?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y
Once enabled, Azure AD does not go to each synchronized user to remove the DisablePasswordExpiration
value from thePasswordPoliciesattribute. Instead, the value is set to None during thenext password syncfor
each user when they next change their password in on-premises AD.
It is recommended to enable EnforceCloudPasswordPolicyForPasswordSyncedUsers, prior to enabling
password hash sync, so that the initial sync of password hashes does not add the DisablePasswordExpiration
value to the PasswordPolicies attribute for the users.
The default Azure AD password policy requires users to change their passwords every 90 days. Ifyour policy in
AD is also 90 days, the two policies should match. However, if the AD policy is not 90 days, you can update the
Azure AD password policy to match by using the Set-MsolPasswordPolicyPowerShell command.
Azure AD supports a separate password expiration policy per registered domain.
Caveat: If there are synchronized accounts that need to have non-expiring passwords in Azure AD, you must
explicitly add the DisablePasswordExpiration value to the PasswordPolicies attribute of the user object in Azure
AD. You can do this by running the following command.
Set-AzureADUser -ObjectID <User Object ID> -PasswordPolicies "DisablePasswordExpiration"
NOTE
The Set-MsolPasswordPolicy PowerShell command will not work on federated domains.
Synchronizing temporary passwords and "Force Password Change on Next Logon"

It is typical to force a user to change their password during their first logon, especially after an admin password
reset occurs. It is commonly known as setting a "temporary" password and is completed by checking the "User
must change password at next logon" flag on a user object in Active Directory (AD).
The temporary password functionality helps to ensure that the transfer of ownership of the credential is
completed on first use, to minimize the duration of time in which more than one individual has knowledge of
that credential.
To support temporary passwords in Azure AD for synchronized users, you can enable the
ForcePasswordChangeOnLogOn feature, by running the following command on your Azure AD Connect
server:
Set-ADSyncAADCompanyFeature -ForcePasswordChangeOnLogOn$true
NOTE
Forcing a user to change their password on next logon requires a password change at the same time. Azure AD Connect
will not pick up the force password change flag by itself; it is supplemental to the detected password change that occurs
during password hash sync.
Cau t i on
You should only use this feature when SSPR and Password Writeback are enabled on the tenant. This is so that
if a user changes their password via SSPR, it will be synchronized to Active Directory.
Account expiration
If your organization uses the accountExpires attribute as part of user account management, this attribute is not
synchronized to Azure AD. As a result, an expired Active Directory account in an environment configured for
password hash synchronization will still be active in Azure AD. We recommend that if the account is expired, a
workflow action should trigger a PowerShell script that disables the user's Azure AD account (use the Set-
AzureADUser cmdlet). Conversely, when the account is turned on, the Azure AD instance should be turned on.
Overwrite synchronized passwords
An administrator can manually reset your password by using Windows PowerShell.
In this case, the new password overrides your synchronized password, and all password policies defined in the
cloud are applied to the new password.
If you change your on-premises password again, the new password is synchronized to the cloud, and it
overrides the manually updated password.
The synchronization of a password has no impact on the Azure user who is signed in. Your current cloud
service session is not immediately affected by a synchronized password change that occurs while you're signed
in to a cloud service. KMSI extends the duration of this difference. When the cloud service requires you to
authenticate again, you need to provide your new password.
Additional advantages
Generally, password hash synchronization is simpler to implement than a federation service. It doesn't
require any additional servers, and eliminates dependence on a highly available federation service to
authenticate users.
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.
Password hash sync process for Azure AD Domain Services

If you use Azure AD Domain Services to provide legacy authentication for applications and services that need
to use Kerberos, LDAP, or NTLM, some additional processes are part of the password hash synchronization
flow. Azure AD Connect uses the additional following process to synchronize password hashes to Azure AD for
use in Azure AD Domain Services:
IMPORTANT
Azure AD Connect should only be installed and configured for synchronization with on-premises AD DS environments.
It's not supported to install Azure AD Connect in an Azure AD DS managed domain to synchronize objects back to
Azure AD.
Azure AD Connect only synchronizes legacy password hashes when you enable Azure AD DS for your Azure AD tenant.
The following steps aren't used if you only use Azure AD Connect to synchronize an on-premises AD DS environment
with Azure AD.
If your legacy applications don't use NTLM authentication or LDAP simple binds, we recommend that you disable NTLM
password hash synchronization for Azure AD DS. For more information, see Disable weak cipher suites and NTLM
credential hash synchronization.
1. Azure AD Connect retrieves the public key for the tenant's instance of Azure AD Domain Services.
2. When a user changes their password, the on-premises domain controller stores the result of the password
change (hashes) in two attributes:
unicodePwd for the NTLM password hash.
supplementalCredentials for the Kerberos password hash.
3. Azure AD Connect detects password changes through the directory replication channel (attribute changes
needing to replicate to other domain controllers).
4. For each user whose password has changed, Azure AD Connect performs the following steps:
Generates a random AES 256-bit symmetric key.
Generates a random initialization vector needed for the first round of encryption.
Extracts Kerberos password hashes from the supplementalCredentials attributes.
Checks the Azure AD Domain Services security configuration SyncNtlmPasswords setting.
If this setting is disabled, generates a random, high-entropy NTLM hash (different from the
user's password). This hash is then combined with the exacted Kerberos password hashes
from the supplementalCrendetials attribute into one data structure.
If enabled, combines the value of the unicodePwd attribute with the extracted Kerberos
password hashes from the supplementalCredentials attribute into one data structure.
Encrypts the single data structure using the AES symmetric key.
Encrypts the AES symmetric key using the tenant's Azure AD Domain Services public key.
5. Azure AD Connect transmits the encrypted AES symmetric key, the encrypted data structure containing the
password hashes, and the initialization vector to Azure AD.
6. Azure AD stores the encrypted AES symmetric key, the encrypted data structure, and the initialization vector
for the user.
7. Azure AD pushes the encrypted AES symmetric key, the encrypted data structure, and the initialization
vector using an internal synchronization mechanism over an encrypted HTTP session to Azure AD Domain
Services.
8. Azure AD Domain Services retrieves the private key for the tenant's instance from Azure Key vault.
9. For each encrypted set of data (representing a single user's password change), Azure AD Domain Services
then performs the following steps:
Uses its private key to decrypt the AES symmetric key.
Uses the AES symmetric key with the initialization vector to decrypt the encrypted data structure that
contains the password hashes.
Writes the Kerberos password hashes it receives to the Azure AD Domain Services domain controller.
The hashes are saved into the user object's supplementalCredentials attribute that is encrypted to the
Azure AD Domain Services domain controller's public key.
Azure AD Domain Services writes the NTLM password hash it received to the Azure AD Domain
Services domain controller. The hash is saved into the user object's unicodePwd attribute that is
encrypted to the Azure AD Domain Services domain controller's public key.
Enable password hash synchronization

IMPORTANT
If you are migrating from AD FS (or other federation technologies) to Password Hash Synchronization, we highly
recommend that you follow our detailed deployment guide published here.
When you install Azure AD Connect by using the Express Settings option, password hash synchronization is
automatically enabled. For more information, see Getting started with Azure AD Connect using express
settings.
If you use custom settings when you install Azure AD Connect, password hash synchronization is available on
the user sign-in page. For more information, see Custom installation of Azure AD Connect.
Password hash synchronization and FIPS
If your server has been locked down according to Federal Information Processing Standard (FIPS), then MD5 is
disabled.
To enable MD5 for password hash synchronization, perform the following steps:
1. Go to %programfiles%\Azure AD Sync\Bin.
2. Open miiserver.exe.config.
3. Go to the configuration/runtime node at the end of the file.
4. Add the following node: <enforceFIPSPolicy enabled="false"/>
5. Save your changes.
For reference, this snippet is what it should look like:
<configuration>
<runtime>
<enforceFIPSPolicy enabled="false"/>
</runtime>
</configuration>
For information about security and FIPS, see Azure AD password hash sync, encryption, and FIPS compliance.
Troubleshoot password hash synchronization

If you have problems with password hash synchronization, see Troubleshoot password hash synchronization.
Next steps
Azure AD Connect sync: Customizing synchronization options
Get a step-by-step deployment plan for migrating from ADFS to Password Hash Synchronization
User sign-in with Azure Active Directory Pass-
through Authentication
What is Azure Active Directory Pass-through Authentication?

Azure Active Directory (Azure AD) Pass-through Authentication allows your users to sign in to both on-
premises and cloud-based applications using the same passwords. This feature provides your users a better
experience - one less password to remember, and reduces IT helpdesk costs because your users are less likely
to forget how to sign in. When users sign in using Azure AD, this feature validates users' passwords directly
against your on-premises Active Directory.
This feature is an alternative to Azure AD Password Hash Synchronization, which provides the same benefit of
cloud authentication to organizations. However, certain organizations wanting to enforce their on-premises
Active Directory security and password policies, can choose to use Pass-through Authentication instead. Review
this guide for a comparison of the various Azure AD sign-in methods and how to choose the right sign-in
method for your organization.
You can combine Pass-through Authentication with the Seamless Single Sign-On feature. This way, when your
users are accessing applications on their corporate machines inside your corporate network, they don't need to
type in their passwords to sign in.
Key benefits of using Azure AD Pass-through Authentication

Great user experience
Users use the same passwords to sign into both on-premises and cloud-based applications.
Users spend less time talking to the IT helpdesk resolving password-related issues.
Users can complete self-service password management tasks in the cloud.
Easy to deploy & administer
No need for complex on-premises deployments or network configuration.
Needs just a lightweight agent to be installed on-premises.
No management overhead. The agent automatically receives improvements and bug fixes.
Secure
On-premises passwords are never stored in the cloud in any form.
Protects your user accounts by working seamlessly with Azure AD Conditional Access policies,
including Multi-Factor Authentication (MFA), blocking legacy authentication and by filtering out brute
force password attacks.
The agent only makes outbound connections from within your network. Therefore, there is no
requirement to install the agent in a perimeter network, also known as a DMZ.
The communication between an agent and Azure AD is secured using certificate-based
authentication. These certificates are automatically renewed every few months by Azure AD.
Highly available
Additional agents can be installed on multiple on-premises servers to provide high availability of
sign-in requests.
Feature highlights
Supports user sign-in into all web browser-based applications and into Microsoft Office client applications
that use modern authentication.
Sign-in usernames can be either the on-premises default username ( userPrincipalName ) or another
attribute configured in Azure AD Connect (known as Alternate ID ).
The feature works seamlessly with Conditional Access features such as Multi-Factor Authentication (MFA) to
help secure your users.
Integrated with cloud-based self-service password management, including password writeback to on-
premises Active Directory and password protection by banning commonly used passwords.
Multi-forest environments are supported if there are forest trusts between your AD forests and if name
suffix routing is correctly configured.
It is a free feature, and you don't need any paid editions of Azure AD to use it.
It can be enabled via Azure AD Connect.
It uses a lightweight on-premises agent that listens for and responds to password validation requests.
Installing multiple agents provides high availability of sign-in requests.
It protects your on-premises accounts against brute force password attacks in the cloud.
Next steps
Quickstart - Get up and running Azure AD Pass-through Authentication.
Migrate from AD FS to Pass-through Authentication - A detailed guide to migrate from AD FS (or other
federation technologies) to Pass-through Authentication.
Smart Lockout - Configure Smart Lockout capability on your tenant to protect user accounts.
Current limitations - Learn which scenarios are supported and which ones are not.
Technical Deep Dive - Understand how this feature works.
Frequently Asked Questions - Answers to frequently asked questions.
Troubleshoot - Learn how to resolve common issues with the feature.
Security Deep Dive - Additional deep technical information on the feature.
Azure AD Seamless SSO - Learn more about this complementary feature.
UserVoice - For filing new feature requests.
Azure Active Directory Pass-through Authentication:
Technical deep dive
This article is an overview of how Azure Active directory (Azure AD) Pass-through Authentication works. For deep
technical and security information, see the Security deep dive article.
How does Azure Active Directory Pass-through Authentication work?

NOTE
As a pre-requisite for Pass-through Authentication to work, users need to be provisioned into Azure AD from on-premises
Active Directory using Azure AD Connect. Pass-through Authentication does not apply to cloud-only users.
When a user tries to sign in to an application secured by Azure AD, and if Pass-through Authentication is enabled
on the tenant, the following steps occur:
1. The user tries to access an application, for example, Outlook Web App.
2. If the user is not already signed in, the user is redirected to the Azure AD User Sign-in page.
3. The user enters their username into the Azure AD sign in page, and then selects the Next button.
4. The user enters their password into the Azure AD sign in page, and then selects the Sign in button.
5. Azure AD, on receiving the request to sign in, places the username and password (encrypted by using the
public key of the Authentication Agents) in a queue.
6. An on-premises Authentication Agent retrieves the username and encrypted password from the queue. Note
that the Agent doesn't frequently poll for requests from the queue, but retrieves requests over a pre-
established persistent connection.
7. The agent decrypts the password by using its private key.
8. The agent validates the username and password against Active Directory by using standard Windows APIs,
which is a similar mechanism to what Active Directory Federation Services (AD FS) uses. The username can be
either the on-premises default username, usually userPrincipalName , or another attribute configured in Azure
AD Connect (known as Alternate ID ).
9. The on-premises Active Directory domain controller (DC) evaluates the request and returns the appropriate
response (success, failure, password expired, or user locked out) to the agent.
10. The Authentication Agent, in turn, returns this response back to Azure AD.
11. Azure AD evaluates the response and responds to the user as appropriate. For example, Azure AD either signs
the user in immediately or requests for Azure Multi-Factor Authentication.
12. If the user sign-in is successful, the user can access the application.
The following diagram illustrates all the components and the steps involved:
Next steps
Current limitations: Learn which scenarios are supported and which ones are not.
Quick Start: Get up and running on Azure AD Pass-through Authentication.
Smart Lockout: Configure the Smart Lockout capability on your tenant to protect user accounts.
Frequently Asked Questions: Find answers to frequently asked questions.
Troubleshoot: Learn how to resolve common problems with the Pass-through Authentication feature.
Security Deep Dive: Get deep technical information on the Pass-through Authentication feature.
Azure AD Seamless SSO: Learn more about this complementary feature.
UserVoice: Use the Azure Active Directory Forum to file new feature requests.
Current limitations
IMPORTANT
Azure Active Directory (Azure AD) Pass-through Authentication is a free feature, and you don't need any paid editions of
Azure AD to use it. Pass-through Authentication is only available in the world-wide instance of Azure AD, and not on the
Microsoft Azure Germany cloud or the Microsoft Azure Government cloud.
Supported scenarios
The following scenarios are supported:
User sign-ins to web browser-based applications.
User sign-ins to Outlook clients using legacy protocols such as Exchange ActiveSync, EAS, SMTP, POP and IMAP.
User sign-ins to legacy Office client applications and Office applications that support modern authentication:
Office 2013 and 2016 versions.
User sign-ins to legacy protocol applications such as PowerShell version 1.0 and others.
Azure AD joins for Windows 10 devices.
App passwords for Multi-Factor Authentication.
Unsupported scenarios
The following scenarios are not supported:
Detection of users with leaked credentials.
Azure AD Domain Services needs Password Hash Synchronization to be enabled on the tenant. Therefore
tenants that use Pass-through Authentication only don't work for scenarios that need Azure AD Domain
Services.
Pass-through Authentication is not integrated with Azure AD Connect Health.
IMPORTANT
As a workaround for unsupported scenarios only (except Azure AD Connect Health integration), enable Password Hash
Synchronization on the Optional features page in the Azure AD Connect wizard.
NOTE
Enabling Password Hash Synchronization gives you the option to failover authentication if your on-premises infrastructure is
disrupted. This failover from Pass-through Authentication to Password Hash Synchronization is not automatic. You'll need to
switch the sign-in method manually using Azure AD Connect. If the server running Azure AD Connect goes down, you'll
require help from Microsoft Support to turn off Pass-through Authentication.
Next steps
Quick start: Get up and running with Azure AD Pass-through Authentication.
Smart Lockout: Learn how to configure the Smart Lockout capability on your tenant to protect user accounts.
Technical deep dive: Understand how the Pass-through Authentication feature works.
Frequently asked questions: Find answers to frequently asked questions about the Pass-through Authentication
feature.
Security deep dive: Get deep technical information on the Pass-through Authentication feature.
Azure Active Directory Pass-through Authentication
security deep dive
This article provides a more detailed description of how Azure Active Directory (Azure AD) Pass-through
Authentication works. It focuses on the security aspects of the feature. This article is for security and IT
administrators, chief compliance and security officers, and other IT professionals who are responsible for IT
security and compliance at small-to-medium sized organizations or large enterprises.
The topics addressed include:
Detailed technical information about how to install and register the Authentication Agents.
Detailed technical information about the encryption of passwords during user sign-in.
The security of the channels between on-premises Authentication Agents and Azure AD.
Detailed technical information about how to keep the Authentication Agents operationally secure.
Other security-related topics.
Key security capabilities

These are the key security aspects of this feature:
It's built on a secure multi-tenanted architecture that provides isolation of sign-in requests between tenants.
On-premises passwords are never stored in the cloud in any form.
On-premises Authentication Agents that listen for, and respond to, password validation requests only make
outbound connections from within your network. There is no requirement to install these Authentication
Agents in a perimeter network (DMZ). As best practice, treat all servers running Authentication Agents as Tier
0 systems (see reference).
Only standard ports (80 and 443) are used for outbound communication from the Authentication Agents to
Azure AD. You don't need to open inbound ports on your firewall.
Port 443 is used for all authenticated outbound communication.
Port 80 is used only for downloading the Certificate Revocation Lists (CRLs) to ensure that none of the
certificates used by this feature have been revoked.
For the complete list of the network requirements, see Azure Active Directory Pass-through
Authentication: Quickstart.
Passwords that users provide during sign-in are encrypted in the cloud before the on-premises Authentication
Agents accept them for validation against Active Directory.
The HTTPS channel between Azure AD and the on-premises Authentication Agent is secured by using mutual
authentication.
Protects your user accounts by working seamlessly with Azure AD Conditional Access policies, including
Multi-Factor Authentication (MFA), blocking legacy authentication and by filtering out brute force password
attacks.
Components involved
For general details about Azure AD operational, service, and data security, see the Trust Center. The following
components are involved when you use Pass-through Authentication for user sign-in:
Azure AD STS : A stateless security token service (STS) that processes sign-in requests and issues security
tokens to users' browsers, clients, or services as required.
Azure Ser vice Bus : Provides cloud-enabled communication with enterprise messaging and relays
communication that helps you connect on-premises solutions with the cloud.
Azure AD Connect Authentication Agent : An on-premises component that listens for and responds to
password validation requests.
Azure SQL Database : Holds information about your tenant's Authentication Agents, including their
metadata and encryption keys.
Active Director y : On-premises Active Directory, where your user accounts and their passwords are stored.
Installation and registration of the Authentication Agents

Authentication Agents are installed and registered with Azure AD when you either:
Enable Pass-through Authentication through Azure AD Connect
Add more Authentication Agents to ensure the high availability of sign-in requests
Getting an Authentication Agent working involves three main phases:
1. Authentication Agent installation
2. Authentication Agent registration
3. Authentication Agent initialization
The following sections discuss these phases in detail.
Authentication Agent installation
Only global administrators can install an Authentication Agent (by using Azure AD Connect or standalone) on an
on-premises server. Installation adds two new entries to the Control Panel > Programs > Programs and
Features list:
The Authentication Agent application itself. This application runs with NetworkService privileges.
The Updater application that's used to auto-update the Authentication Agent. This application runs with
LocalSystem privileges.
IMPORTANT
From a security standpoint, administrators should treat the server running the PTA agent as if it were a domain controller.
The PTA agent servers should be hardened along the same lines as outlined in Securing Domain Controllers Against Attack
Authentication Agent registration

After you install the Authentication Agent, it needs to register itself with Azure AD. Azure AD assigns each
Authentication Agent a unique, digital-identity certificate that it can use for secure communication with Azure AD.
The registration procedure also binds the Authentication Agent with your tenant. This ensures that Azure AD
knows that this specific Authentication Agent is the only one authorized to handle password validation requests
for your tenant. This procedure is repeated for each new Authentication Agent that you register.
The Authentication Agents use the following steps to register themselves with Azure AD:
1. Azure AD first requests that a global administrator sign in to Azure AD with their credentials. During sign-in,
the Authentication Agent acquires an access token that it can use on behalf of the global administrator.
2. The Authentication Agent then generates a key pair: a public key and a private key.
The key pair is generated through standard RSA 2048-bit encryption.
The private key stays on the on-premises server where the Authentication Agent resides.
3. The Authentication Agent makes a “registration” request to Azure AD over HTTPS, with the following
components included in the request:
The access token acquired in step 1.
The public key generated in step 2.
A Certificate Signing Request (CSR or Certificate Request). This request applies for a digital identity
certificate, with Azure AD as its certificate authority (CA).
4. Azure AD validates the access token in the registration request and verifies that the request came from a
global administrator.
5. Azure AD then signs and sends a digital identity certificate back to the Authentication Agent.
The root CA in Azure AD is used to sign the certificate.
NOTE
This CA is not in the Windows Trusted Root Certificate Authorities store.
The CA is used only by the Pass-through Authentication feature. The CA is used only to sign CSRs
during the Authentication Agent registration.
None of the other Azure AD services use this CA.
The certificate’s subject (Distinguished Name or DN) is set to your tenant ID. This DN is a GUID that
uniquely identifies your tenant. This DN scopes the certificate for use only with your tenant.
6. Azure AD stores the public key of the Authentication Agent in a database in Azure SQL Database, which only
Azure AD has access to.
7. The certificate (issued in step 5) is stored on the on-premises server in the Windows certificate store
(specifically in the CERT_SYSTEM_STORE_LOCAL_MACHINE location). It is used by both the Authentication
Agent and the Updater applications.
Authentication Agent initialization
When the Authentication Agent starts, either for the first time after registration or after a server restart, it needs a
way to communicate securely with the Azure AD service and start accepting password validation requests.
Here is how Authentication Agents are initialized:

1. The Authentication Agent makes an outbound bootstrap request to Azure AD.
This request is made over port 443 and is over a mutually authenticated HTTPS channel. The request
uses the same certificate that was issued during the Authentication Agent registration.
2. Azure AD responds to the request by providing an access key to an Azure Service Bus queue that's unique to
your tenant and that's identified by your tenant ID.
3. The Authentication Agent makes a persistent outbound HTTPS connection (over port 443) to the queue.
The Authentication Agent is now ready to retrieve and handle password-validation requests.
If you have multiple Authentication Agents registered on your tenant, then the initialization procedure ensures
that each one connects to the same Service Bus queue.
Process sign-in requests

The following diagram shows how Pass-through Authentication processes user sign-in requests.
Pass-through Authentication handles a user sign-in request as follows:

1. A user tries to access an application, for example, Outlook Web App.
2. If the user is not already signed in, the application redirects the browser to the Azure AD sign-in page.
3. The Azure AD STS service responds back with the User sign-in page.
4. The user enters their username into the User sign-in page, and then selects the Next button.
5. The user enters their password into the User sign-in page, and then selects the Sign-in button.
6. The username and password are submitted to Azure AD STS in an HTTPS POST request.
7. Azure AD STS retrieves public keys for all the Authentication Agents registered on your tenant from Azure
SQL Database and encrypts the password by using them.
It produces "N" encrypted password values for "N" Authentication Agents registered on your tenant.
8. Azure AD STS places the password validation request, which consists of the username and the encrypted
password values, onto the Service Bus queue specific to your tenant.
9. Because the initialized Authentication Agents are persistently connected to the Service Bus queue, one of the
available Authentication Agents retrieves the password validation request.
10. The Authentication Agent locates the encrypted password value that's specific to its public key, by using an
identifier, and decrypts it by using its private key.
11. The Authentication Agent attempts to validate the username and the password against on-premises Active
Directory by using the Win32 LogonUser API with the dwLogonType parameter set to
LOGON32_LOGON_NETWORK .
This API is the same API that is used by Active Directory Federation Services (AD FS) to sign in users in
a federated sign-in scenario.
This API relies on the standard resolution process in Windows Server to locate the domain controller.
12. The Authentication Agent receives the result from Active Directory, such as success, username or password
incorrect, or password expired.
NOTE
If the Authentication Agent fails during the sign-in process, the whole sign-in request is dropped. There is no hand-off of
sign-in requests from one Authentication Agent to another Authentication Agent on-premises. These agents only
communicate with the cloud, and not with each other.
13. The Authentication Agent forwards the result back to Azure AD STS over an outbound mutually authenticated
HTTPS channel over port 443. Mutual authentication uses the certificate previously issued to the
Authentication Agent during registration.
14. Azure AD STS verifies that this result correlates with the specific sign-in request on your tenant.
15. Azure AD STS continues with the sign-in procedure as configured. For example, if the password validation was
successful, the user might be challenged for Multi-Factor Authentication or redirected back to the application.
Operational security of the Authentication Agents

To ensure that Pass-through Authentication remains operationally secure, Azure AD periodically renews
Authentication Agents' certificates. Azure AD triggers the renewals. The renewals are not governed by the
Authentication Agents themselves.
To renew an Authentication Agent's trust with Azure AD:
1. The Authentication Agent periodically pings Azure AD every few hours to check if it's time to renew its
certificate. The certificate is renewed 30 days prior to its expiration.
This check is done over a mutually authenticated HTTPS channel and uses the same certificate that was
issued during registration.
2. If the service indicates that it's time to renew, the Authentication Agent generates a new key pair: a public
key and a private key.
These keys are generated through standard RSA 2048-bit encryption.
The private key never leaves the on-premises server.
3. The Authentication Agent then makes a “certificate renewal” request to Azure AD over HTTPS, with the
following components included in the request:
The existing certificate that's retrieved from the CERT_SYSTEM_STORE_LOCAL_MACHINE location on
the Windows certificate store. There is no global administrator involved in this procedure, so there is no
access token needed on behalf of the global administrator.
The public key generated in step 2.
A Certificate Signing Request (CSR or Certificate Request). This request applies for a new digital identity
certificate, with Azure AD as its certificate authority.
4. Azure AD validates the existing certificate in the certificate renewal request. Then it verifies that the request
came from an Authentication Agent registered on your tenant.
5. If the existing certificate is still valid, Azure AD then signs a new digital identity certificate, and issues the
new certificate back to the Authentication Agent.
6. If the existing certificate has expired, Azure AD deletes the Authentication Agent from your tenant’s list of
registered Authentication Agents. Then a global administrator needs to manually install and register a new
Authentication Agent.
Use the Azure AD root CA to sign the certificate.
Set the certificate’s subject (Distinguished Name or DN) to your tenant ID, a GUID that uniquely
identifies your tenant. The DN scopes the certificate to your tenant only.
7. Azure AD stores the new public key of the Authentication Agent in a database in Azure SQL Database that
only it has access to. It also invalidates the old public key associated with the Authentication Agent.
8. The new certificate (issued in step 5) is then stored on the server in the Windows certificate store
(specifically in the CERT_SYSTEM_STORE_CURRENT_USER location).
Because the trust renewal procedure happens non-interactively (without the presence of the global
administrator), the Authentication Agent no longer has access to update the existing certificate in the
CERT_SYSTEM_STORE_LOCAL_MACHINE location.
NOTE
This procedure does not remove the certificate itself from the CERT_SYSTEM_STORE_LOCAL_MACHINE location.
9. The new certificate is used for authentication from this point on. Every subsequent renewal of the
certificate replaces the certificate in the CERT_SYSTEM_STORE_LOCAL_MACHINE location.
Auto-update of the Authentication Agents

The Updater application automatically updates the Authentication Agent when a new version (with bug fixes or
performance enhancements) is released. The Updater application does not handle any password validation
requests for your tenant.
Azure AD hosts the new version of the software as a signed Windows Installer package (MSI) . The MSI is
signed by using Microsoft Authenticode with SHA256 as the digest algorithm.
To auto-update an Authentication Agent:

1. The Updater application pings Azure AD every hour to check if there is a new version of the Authentication
Agent available.
This check is done over a mutually authenticated HTTPS channel by using the same certificate that was
issued during registration. The Authentication Agent and the Updater share the certificate stored on the
server.
2. If a new version is available, Azure AD returns the signed MSI back to the Updater.
3. The Updater verifies that the MSI is signed by Microsoft.
4. The Updater runs the MSI. This action involves the following steps:
NOTE
The Updater runs with Local System privileges.
Stops the Authentication Agent service
Installs the new version of the Authentication Agent on the server
Restarts the Authentication Agent service
NOTE
If you have multiple Authentication Agents registered on your tenant, Azure AD does not renew their certificates or update
them at the same time. Instead, Azure AD does so one at a time to ensure the high availability of sign-in requests.
Next steps
Quickstart: Get up and running on Azure AD Pass-through Authentication.
Smart Lockout: Configure the Smart Lockout capability on your tenant to protect user accounts.
How it works: Learn the basics of how Azure AD Pass-through Authentication works.
Frequently asked questions: Find answers to frequently asked questions.
User Privacy and Azure Active Directory Pass-
through Authentication
NOTE
This article provides steps for how to delete personal data from the device or service and can be used to support your
obligations under the GDPR. If you’re looking for general info about GDPR, see the GDPR section of the Service Trust portal.
Overview
Azure AD Pass-through Authentication creates the following log type, which can contain Personal Data:
Azure AD Connect trace log files.
Authentication Agent trace log files.
Windows Event log files.
Improve user privacy for Pass-through Authentication in two ways:
1. Upon request, extract data for a person and remove data from that person from the installations.
2. Ensure no data is retained beyond 48 hours.
We strongly recommend the second option as it is easier to implement and maintain. Following are the instructions
for each log type:
Delete Azure AD Connect trace log files
Check the contents of %ProgramData%\AADConnect folder and delete the trace log contents (trace-*.log files)
of this folder within 48 hours of installing or upgrading Azure AD Connect or modifying Pass-through
Authentication configuration, as this action may create data covered by GDPR.
IMPORTANT
Don’t delete the PersistedState.xml file in this folder, as this file is used to maintain the state of the previous installation of
Azure AD Connect and is used when an upgrade installation is done. This file will never contain any data about a person and
should never be deleted.
You can either review and delete these trace log files using Windows Explorer or you can use the following
PowerShell script to perform the necessary actions:
$Files = ((Get-Item -Path "$env:programdata\aadconnect\trace-*.log").VersionInfo).FileName
Foreach ($file in $Files) {

{Remove-Item -Path $File -Force}
}
Save the script in a file with the ".PS1" extension. Run this script as needed.
To learn more about related Azure AD Connect GDPR requirements, see this article.
Delete Authentication Agent event logs
This product may also create Windows Event Logs . To learn more, please read this article.
To view logs related to the Pass-through Authentication Agent, open the Event Viewer application on the server
and check under Application and Ser vice Logs\Microsoft\AzureAdConnect\AuthenticationAgent\Admin .
Delete Authentication Agent trace log files
You should regularly check the contents of %ProgramData%\Microsoft\Azure AD Connect Authentication
Agent\Trace and delete the contents of this folder every 48 hours.
IMPORTANT
If the Authentication Agent service is running, you'll not be able to delete the current log file in the folder. Stop the service
before trying again. To avoid user sign-in failures, you should have already configured Pass-through Authentication for high
availability.
You can either review and delete these files using Windows Explorer or you can use the following script to perform
the necessary actions:
$Files = ((Get-childitem -Path "$env:programdata\microsoft\azure ad connect authentication agent\trace" -

Recurse).VersionInfo).FileName
Foreach ($file in $files) {

}
To schedule this script to run every 48 hours follow these steps:

1. Save the script in a file with the ".PS1" extension.
2. Open Control Panel and click on System and Security .
3. Under the Administrative Tools heading, click on “Schedule Tasks ”.
4. In Task Scheduler , right-click on “Task Schedule Librar y ” and click on “Create Basic task … ”.
5. Enter the name for the new task and click Next .
6. Select “Daily ” for the Task Trigger and click Next .
7. Set the recurrence to two days and click Next .
8. Select “Star t a program ” as the action and click Next .
9. Type “PowerShell ” in the box for the Program/script, and in box labeled “Add arguments (optional) ”, enter
the full path to the script that you created earlier, then click Next .
10. The next screen shows a summary of the task you are about to create. Verify the values and click Finish to
create the task:
Note about Domain controller logs
If audit logging is enabled, this product may generate security logs for your Domain Controllers. To learn more
about configuring audit policies, read this article.
Next steps
Review the Microsoft Privacy policy on Trust Center
What is federation with Azure AD?
Federation is a collection of domains that have established trust. The level of trust may vary, but typically includes
authentication and almost always includes authorization. A typical federation might include a number of
organizations that have established trust for shared access to a set of resources.
You can federate your on-premises environment with Azure AD and use this federation for authentication and
authorization. This sign-in method ensures that all user authentication occurs on-premises. This method allows
administrators to implement more rigorous levels of access control. Federation with AD FS and PingFederate is
available.
TIP
If you decide to use Federation with Active Directory Federation Services (AD FS), you can optionally set up password hash
synchronization as a backup in case your AD FS infrastructure fails.
Next Steps
What is password hash synchronization?
What is federation?
How federation works
Federation with PingFederate
Azure Active Directory (Azure AD) Connect lets you configure federation with on-premises Active Directory
Federation Services (AD FS) and Azure AD. With federation sign-in, you can enable users to sign in to Azure AD-
based services with their on-premises passwords--and, while on the corporate network, without having to enter
their passwords again. By using the federation option with AD FS, you can deploy a new installation of AD FS, or
you can specify an existing installation in a Windows Server 2012 R2 farm.
This topic is the home for information on federation-related functionalities for Azure AD Connect. It lists links to
all related topics. For links to Azure AD Connect, see Integrating your on-premises identities with Azure Active
Directory.
Azure AD Connect: federation topics

TO P IC W H AT IT C O VERS A N D W H EN TO REA D IT
Azure AD Connect user sign-in options
Understand user sign-in options Learn about various user sign-in options and how they affect
the Azure sign-in user experience.
Install AD FS by using Azure AD Connect
Prerequisites See the prerequisites for a successful AD FS installation via

Azure AD Connect.
Configure an AD FS farm Install a new AD FS farm by using Azure AD Connect.
Federate with Azure AD using alternate login ID Configure federation using alternate login ID
Modify the AD FS configuration
Repair the trust Repair the current trust between on-premises AD FS and
Office 365/Azure.
Add a new AD FS server Expand an AD FS farm with an additional AD FS server after

initial installation.
Add a new AD FS WAP server Expand an AD FS farm with an additional Web Application
Proxy (WAP) server after initial installation.
Add a new federated domain Add another domain to be federated with Azure AD.
Update the TLS/SSL certificate Update the TLS/SSL certificate for an AD FS farm.
Renew federation certificates for Office 365 and Azure AD Renew your O365 certificate with Azure AD.
Other federation configuration

TO P IC W H AT IT C O VERS A N D W H EN TO REA D IT
Federate multiple instances of Azure AD with single instance Federate multiple Azure AD with single AD FS farm
of AD FS
Add a custom company logo/illustration Modify the sign-in experience by specifying the custom logo
that is shown on the AD FS sign-in page.
Add a sign-in description Change the sign-in description on the AD FS sign-in page.
Modify AD FS claim rules Modify or add claim rules in AD FS that correspond to Azure
AD Connect sync configuration.
Additional resources
Federating two Azure AD with single AD FS
AD FS deployment in Azure
High-availability cross-geographic AD FS deployment in Azure with Azure Traffic Manager
Azure Active Directory provides single-sign on and enhanced application access security for Office 365 and other
Microsoft Online services for hybrid and cloud-only implementations without requiring any third party solution.
Office 365, like most of Microsoft’s Online services, is integrated with Azure Active Directory for directory services,
authentication, and authorization. Azure Active Directory also provides single sign-on to thousands of SaaS
applications and on-premises web applications. See the Azure Active Directory application gallery for supported
SaaS applications.
IDP Validation
If your organization uses a third-party federation solution, you can configure single sign-on for your on-premises
Active Directory users with Microsoft Online services, such as Office 365, provided the third-party federation
solution is compatible with Azure Active Directory. For questions regarding compatibility, please contact your
identity provider. If you would like to see a list of identity providers who have previously been tested for
compatibility with Azure AD, by Microsoft, click here.
NOTE
Microsoft no longer provides validation testing to independent identity providers for compatibility with Azure Active
Directory. If you would like to test your product for interoperability please refer to these guidelines.
Next Steps
Integrate your on-premises directories with Azure Active Directory
Azure Active Directory Seamless Single Sign-On
What is Azure Active Directory Seamless Single Sign-On?

Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) automatically signs users in
when they are on their corporate devices connected to your corporate network. When enabled, users don't
need to type in their passwords to sign in to Azure AD, and usually, even type in their usernames. This
feature provides your users easy access to your cloud-based applications without needing any additional
on-premises components.
Seamless SSO can be combined with either the Password Hash Synchronization or Pass-through
Authentication sign-in methods. Seamless SSO is not applicable to Active Directory Federation Services
(ADFS).
IMPORTANT
Seamless SSO needs the user's device to be domain-joined only, but it is not used on Azure AD Joined or Hybrid
Azure AD joined devices. SSO on Azure AD joined, Hybrid Azure AD joined, and Azure AD registered devices works
based on the primary refresh token.
Key benefits
Great user experience
Users are automatically signed into both on-premises and cloud-based applications.
Users don't have to enter their passwords repeatedly.
Easy to deploy & administer
No additional components needed on-premises to make this work.
Works with any method of cloud authentication - Password Hash Synchronization or Pass-through
Authentication.
Can be rolled out to some or all your users using Group Policy.
Register non-Windows 10 devices with Azure AD without the need for any AD FS infrastructure.
This capability needs you to use version 2.1 or later of the workplace-join client.
Feature highlights
Sign-in username can be either the on-premises default username ( userPrincipalName ) or another
attribute configured in Azure AD Connect ( Alternate ID ). Both use cases work because Seamless SSO
uses the securityIdentifier claim in the Kerberos ticket to look up the corresponding user object in
Azure AD.
Seamless SSO is an opportunistic feature. If it fails for any reason, the user sign-in experience goes back
to its regular behavior - i.e, the user needs to enter their password on the sign-in page.
If an application (for example, https://myapps.microsoft.com/contoso.com ) forwards a domain_hint
(OpenID Connect) or whr (SAML) parameter - identifying your tenant, or login_hint parameter -
identifying the user, in its Azure AD sign-in request, users are automatically signed in without them
entering usernames or passwords.
Users also get a silent sign-on experience if an application (for example, https://contoso.sharepoint.com )
sends sign-in requests to Azure AD's endpoints set up as tenants - that is,
https://login.microsoftonline.com/contoso.com/<..> or
https://login.microsoftonline.com/<tenant_ID>/<..> - instead of Azure AD's common endpoint - that is,
https://login.microsoftonline.com/common/<...> .
Sign out is supported. This allows users to choose another Azure AD account to sign in with, instead of
being automatically signed in using Seamless SSO automatically.
Office 365 Win32 clients (Outlook, Word, Excel, and others) with versions 16.0.8730.xxxx and above are
supported using a non-interactive flow. For OneDrive, you will have to activate the OneDrive silent config
feature for a silent sign-on experience.
It can be enabled via Azure AD Connect.
It is a free feature, and you don't need any paid editions of Azure AD to use it.
It is supported on web browser-based clients and Office clients that support modern authentication on
platforms and browsers capable of Kerberos authentication:
IN T ERN ET M IC RO SO F T GO O GL E M O Z IL L A
O S\ B RO W SER EXP LO RER EDGE C H RO M E F IREF O X SA FA RI
Windows 10 Yes* Yes Yes Yes*** N/A
Windows 8.1 Yes* N/A Yes Yes*** N/A
Windows 8 Yes* N/A Yes Yes*** N/A
Windows 7 Yes* N/A Yes Yes*** N/A
Windows Server Yes** N/A Yes Yes*** N/A

2012 R2 or
above
Mac OS X N/A N/A Yes*** Yes*** Yes***
*Requires Internet Explorer versions 10 or above

**Requires Internet Explorer versions 10 or above. Disable Enhanced Protected Mode
***Requires additional configuration
NOTE
For Windows 10, the recommendation is to use Azure AD Join for the optimal single sign-on experience with Azure
AD.
Next steps
Quick Star t - Get up and running Azure AD Seamless SSO.
Deployment Plan - Step-by-step deployment plan.
Azure Active Directory Seamless Single Sign-On:
Technical deep dive
This article gives you technical details into how the Azure Active Directory Seamless Single Sign-On (Seamless
SSO) feature works.
How does Seamless SSO work?

This section has three parts to it:
1. The setup of the Seamless SSO feature.
2. How a single user sign-in transaction on a web browser works with Seamless SSO.
3. How a single user sign-in transaction on a native client works with Seamless SSO.
How does set up work?
Seamless SSO is enabled using Azure AD Connect as shown here. While enabling the feature, the following steps
occur:
A computer account ( AZUREADSSOACC ) is created in your on-premises Active Directory (AD) in each AD forest
that you synchronize to Azure AD (using Azure AD Connect).
In addition, a number of Kerberos service principal names (SPNs) are created to be used during the Azure AD
sign-in process.
The computer account's Kerberos decryption key is shared securely with Azure AD. If there are multiple AD
forests, each computer account will have its own unique Kerberos decryption key.
IMPORTANT
The AZUREADSSOACC computer account needs to be strongly protected for security reasons. Only Domain Admins should be
able to manage the computer account. Ensure that Kerberos delegation on the computer account is disabled, and that no
other account in Active Directory has delegation permissions on the AZUREADSSOACC computer account.. Store the
computer account in an Organization Unit (OU) where they are safe from accidental deletions and where only Domain
Admins have access. The Kerberos decryption key on the computer account should also be treated as sensitive. We highly
recommend that you roll over the Kerberos decryption key of the AZUREADSSOACC computer account at least every 30
days.
IMPORTANT
Seamless SSO supports the AES256_HMAC_SHA1, AES128_HMAC_SHA1 and RC4_HMAC_MD5 encryption types for
Kerberos. It is recommended that the encryption type for the AzureADSSOAcc$ account is set to AES256_HMAC_SHA1, or
one of the AES types vs. RC4 for added security. The encryption type is stored on the msDS-SupportedEncryptionTypes
attribute of the account in your Active Directory. If the AzureADSSOAcc$ account encryption type is set to
RC4_HMAC_MD5, and you want to change it to one of the AES encryption types, please make sure that you first roll over
the Kerberos decryption key of the AzureADSSOAcc$ account as explained in the FAQ document under the relevant
question, otherwise Seamless SSO will not happen.
Once the set-up is complete, Seamless SSO works the same way as any other sign-in that uses Integrated
Windows Authentication (IWA).
How does sign-in on a web browser with Seamless SSO work?
The sign-in flow on a web browser is as follows:
1. The user tries to access a web application (for example, the Outlook Web App -
https://outlook.office365.com/owa/) from a domain-joined corporate device inside your corporate network.
2. If the user is not already signed in, the user is redirected to the Azure AD sign-in page.
3. The user types in their user name into the Azure AD sign-in page.
NOTE
For certain applications, steps 2 & 3 are skipped.
4. Using JavaScript in the background, Azure AD challenges the browser, via a 401 Unauthorized response, to
provide a Kerberos ticket.
5. The browser, in turn, requests a ticket from Active Directory for the AZUREADSSOACC computer account (which
represents Azure AD).
6. Active Directory locates the computer account and returns a Kerberos ticket to the browser encrypted with
the computer account's secret.
7. The browser forwards the Kerberos ticket it acquired from Active Directory to Azure AD.
8. Azure AD decrypts the Kerberos ticket, which includes the identity of the user signed into the corporate
device, using the previously shared key.
9. After evaluation, Azure AD either returns a token back to the application or asks the user to perform
additional proofs, such as Multi-Factor Authentication.
10. If the user sign-in is successful, the user is able to access the application.
The following diagram illustrates all the components and the steps involved.
Seamless SSO is opportunistic, which means if it fails, the sign-in experience falls back to its regular behavior - i.e,
the user needs to enter their password to sign in.
How does sign-in on a native client with Seamless SSO work?
The sign-in flow on a native client is as follows:
1. The user tries to access a native application (for example, the Outlook client) from a domain-joined corporate
device inside your corporate network.
2. If the user is not already signed in, the native application retrieves the username of the user from the device's
Windows session.
3. The app sends the username to Azure AD, and retrieves your tenant's WS-Trust MEX endpoint. This WS-Trust
endpoint is used exclusively by the Seamless SSO feature, and is not a general implementation of the WS-Trust
protocol on Azure AD.
4. The app then queries the WS-Trust MEX endpoint to see if integrated authentication endpoint is available. The
integrated authentication endpoint is used exclusively by the Seamless SSO feature.
5. If step 4 succeeds, a Kerberos challenge is issued.
6. If the app is able to retrieve the Kerberos ticket, it forwards it up to Azure AD's integrated authentication
endpoint.
7. Azure AD decrypts the Kerberos ticket and validates it.
8. Azure AD signs the user in, and issues a SAML token to the app.
9. The app then submits the SAML token to Azure AD's OAuth2 token endpoint.
10. Azure AD validates the SAML token, and issues to the app an access token and a refresh token for the specified
resource, and an id token.
11. The user gets access to the app's resource.
The following diagram illustrates all the components and the steps involved.
Next steps
Quick Star t - Get up and running Azure AD Seamless SSO.
User Privacy and Azure AD Seamless Single Sign-On
NOTE
Overview
Azure AD Seamless SSO creates the following log type, which can contain Personal Data:
Azure AD Connect trace log files.
Improve user privacy for Seamless SSO in two ways:
1. Upon request, extract data for a person and remove data from that person from the installations.
We strongly recommend the second option as it is easier to implement and maintain. See following instructions for
each log type:
Delete Azure AD Connect trace log files
Check the contents of %ProgramData%\AADConnect folder and delete the trace log contents (trace-*.log files)
of this folder within 48 hours of installing or upgrading Azure AD Connect or modifying Seamless SSO
configuration, as this action may create data covered by GDPR.
IMPORTANT
Don’t delete the PersistedState.xml file in this folder, as this file is used to maintain the state of the previous installation of
Azure AD Connect and is used when an upgrade installation is done. This file will never contain any data about a person and
should never be deleted.
You can either review and delete these trace log files using Windows Explorer or you can use the following
PowerShell script to perform the necessary actions:
$Files = ((Get-Item -Path "$env:programdata\aadconnect\trace-*.log").VersionInfo).FileName
Foreach ($file in $Files) {

}
Save the script in a file with the ".PS1" extension. Run this script as needed.
To learn more about related Azure AD Connect GDPR requirements, see this article.
Note about Domain controller logs
If audit logging is enabled, this product may generate security logs for your Domain Controllers. To learn more
about configuring audit policies, read this article.
Next steps
Azure AD Connect sync: Understand and
customize synchronization
The Azure Active Directory Connect synchronization services (Azure AD Connect sync) is a main component
of Azure AD Connect. It takes care of all the operations that are related to synchronize identity data between
your on-premises environment and Azure AD. Azure AD Connect sync is the successor of DirSync, Azure AD
Sync, and Forefront Identity Manager with the Azure Active Directory Connector configured.
This topic is the home for Azure AD Connect sync (also called sync engine ) and lists links to all other
topics related to it. For links to Azure AD Connect, see Integrating your on-premises identities with Azure
Active Directory.
The sync service consists of two components, the on-premises Azure AD Connect sync component and
the service side in Azure AD called Azure AD Connect sync ser vice .
Azure AD Connect sync topics

TO P IC W H AT IT C O VERS A N D W H EN TO REA D
Azure AD Connect sync fundamentals
Understanding the architecture For those of you who are new to the sync engine and want
to learn about the architecture and the terms used.
Technical concepts A short version of the architecture topic and briefly

explains the terms used.
Topologies for Azure AD Connect Describes the different topologies and scenarios the sync
engine supports.
Custom configuration
Running the installation wizard again Explains what options you have available when you run the
Azure AD Connect installation wizard again.
Understanding Declarative Provisioning Describes the configuration model called declarative

provisioning.
Understanding Declarative Provisioning Expressions Describes the syntax for the expression language used in
declarative provisioning.
Understanding the default configuration Describes the out-of-box rules and the default
configuration. Also describes how the rules work together
for the out-of-box scenarios to work.
Understanding Users and Contacts Continues on the previous topic and describes how the
configuration for users and contacts works together, in
particular in a multi-forest environment.
How to make a change to the default configuration Walks you through how to make a common configuration
change to attribute flows.
Best practices for changing the default configuration Support limitations and for making changes to the out-of-
box configuration.
Configure Filtering Describes the different options for how to limit which
objects are being synchronized to Azure AD and step-by-
step how to configure these options.
Features and scenarios
Prevent accidental deletes Describes the prevent accidental deletes feature and how
to configure it.
Scheduler Describes the built-in scheduler, which is importing,

synchronizing, and exporting data.
Implement password hash synchronization Describes how password synchronization works, how to
implement, and how to operate and troubleshoot.
Device writeback Describes how device writeback works in Azure AD

Connect.
Directory extensions Describes how to extend the Azure AD schema with your
own custom attributes.
Office 365 PreferredDataLocation Describes how to put the user's Office 365 resources in the
same region as the user.
Sync Ser vice
Azure AD Connect sync service features Describes the sync service side and how to change sync
settings in Azure AD.
Duplicate attribute resiliency Describes how to enable and use userPrincipalName and
proxyAddresses duplicate attribute values resiliency.
Operations and UI
Synchronization Service Manager Describes the Synchronization Service Manager UI,

including Operations, Connectors, Metaverse Designer,
and Metaverse Search tabs.
Operational tasks and considerations Describes operational concerns, such as disaster recovery.
How To...
Reset the Azure AD account How to reset the credentials of the service account used to
connect from Azure AD Connect sync to Azure AD.
More information and references

Ports Lists which ports you need to open between the sync
engine and your on-premises directories and Azure AD.
Attributes synchronized to Azure Active Directory Lists all attributes being synchronized between on-
premises AD and Azure AD.
Functions Reference Lists all functions available in declarative provisioning.
Additional Resources
ADSync service account
Azure AD Connect installs an on-premises service which orchestrates synchronization between Active Directory
and Azure Active Directory. The Microsoft Azure AD Sync synchronization service (ADSync) runs on a server in your
on-premises environment. The credentials for the service are set by default in the Express installations but may be
customized to meet your organizational security requirements. These credentials are not used to connect to your
on-premises forests or Azure Active Directory.
Choosing the ADSync service account is an important planning decision to make prior to installing Azure AD
Connect. Any attempt to change the credentials after installation will result in the service failing to start, losing
access to the synchronization database, and failing to authenticate with your connected directories (Azure and AD
DS). No synchronization will occur until the original credentials are restored.
The default ADSync service account

When run on a member server, the AdSync service runs in the context of a Virtual Service Account (VSA). Due to a
product limitation, a custom service account is created when installed on a domain controller. If the Express settings
service account does not meet your organizational security requirements, deploy Azure AD Connect by choosing
the Customize option. Then choose the service account option which meets your organization’s requirements.
NOTE
The default service account when installed on a domain controller is of the form Domain\AAD_InstallationIdentifier. The
password for this account is randomly generated and presents significant challenges for recovery and password rotation.
Microsoft recommends customizing the service account during initial installation on a domain controller to use either a
standalone or group Managed Service Account (sMSA / gMSA)
A Z URE A D C O N N EC T LO C AT IO N SERVIC E A C C O UN T C REAT ED
Member Server NT SERVICE\ADSync
Domain Controller Domain\AAD_74dc30c01e80 (see note)
Custom ADSync service accounts

Microsoft recommends running the ADSync service in the context of either a Virtual Service Account or a
standalone or group Managed Service Account. Your domain administrator may also choose to create a service
account provisioned to meet your specific organizational security requirements. To customize the service account
used during installation, choose the Customize option on the Express Settings page below. The following options
are available:
default account – Azure AD Connect will provision the service account as described above
managed service account – use a standalone or group MSA provisioned by your administrator
domain account – use a domain service account provisioned by your administrator
Diagnosing ADSync service account changes
Changing the credentials for the ADSync service after installation will result in the service failing to start, losing
access to the synchronization database, and failing to authenticate with your connected directories (Azure and AD
DS). Granting database access to the new ADSync service account is insufficient to recover from this issue. No
synchronization will occur until the original credentials are restored.
The ADSync service will issue an error level message to the event log when it is unable to start. The content of the
message will vary depending on whether the built-in database (localdb) or full SQL is in use. The following are
examples of the event log entries that may be present.
Example 1
The AdSync service encryption keys could not be found and have been recreated. Synchronization will not occur
until this issue is corrected.
Troubleshooting this Issue The Microsoft Azure AD Sync encryption keys will become inaccessible if the AdSync
service Log On credentials are changed. If the credentials have been changed, use the Services application to
change the Log On account back to its originally configured value (ex. NT SERVICE\AdSync) and restart the service.
This will immediately restore correct operation of the AdSync service.
Please see the following article for further information.
Example 2
The service was unable to start because a connection to the local database (localdb) could not be established.
Troubleshooting this Issue The Microsoft Azure AD Sync service will lose permission to access the local database
provider if the AdSync service Log On credentials are changed. If the credentials have been changed use the
Services application to change the Log On account back to its originally configured value (ex. NT SERVICE\AdSync)
and restart the service. This will immediately restore correct operation of the AdSync service.
Please see the following article for further information.
Additional Details The following error information was returned by the provider:
OriginalError=0x80004005 OLEDB Provider error(s):

Description = 'Login timeout expired'
Failure Code = 0x80004005
Minor Number = 0
Description = 'A network-related or instance-specific error has occurred while establishing a connection to
SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is
configured to allow remote connections. For more information see SQL Server Books Online.'
Next steps
Learn more about Integrating your on-premises identities with Azure Active Directory.
Azure AD Connect sync service features
The synchronization feature of Azure AD Connect has two components:

The on-premises component named Azure AD Connect sync , also called sync engine .
The service residing in Azure AD also known as Azure AD Connect sync ser vice
This topic explains how the following features of the Azure AD Connect sync ser vice work and how you can
configure them using Windows PowerShell.
These settings are configured by the Azure Active Directory Module for Windows PowerShell. Download and
install it separately from Azure AD Connect. The cmdlets documented in this topic were introduced in the 2016
March release (build 9031.1). If you do not have the cmdlets documented in this topic or they do not produce the
same result, then make sure you run the latest version.
To see the configuration in your Azure AD directory, run Get-MsolDirSyncFeatures .
Many of these settings can only be changed by Azure AD Connect.

The following settings can be configured by Set-MsolDirSyncFeature :
DIRSY N C F EAT URE C O M M EN T
EnableSoftMatchOnUpn Allows objects to join on userPrincipalName in addition to

primary SMTP address.
SynchronizeUpnForManagedUsers Allows the sync engine to update the userPrincipalName

attribute for managed/licensed (non-federated) users.
After you have enabled a feature, it cannot be disabled again.
NOTE
From August 24, 2016 the feature Duplicate attribute resiliency is enabled by default for new Azure AD directories. This
feature will also be rolled out and enabled on directories created before this date. You will receive an email notification when
your directory is about to get this feature enabled.
The following settings are configured by Azure AD Connect and cannot be modified by Set-MsolDirSyncFeature :
DeviceWriteback Azure AD Connect: Enabling device writeback

DirectoryExtensions Azure AD Connect sync: Directory extensions
DuplicateProxyAddressResiliency Allows an attribute to be quarantined when it is a duplicate of

DuplicateUPNResiliency another object rather than failing the entire object during
export.
Password Hash Sync Implementing password hash synchronization with Azure AD

Connect sync
Pass-through Authentication User sign-in with Azure Active Directory Pass-through

Authentication
UnifiedGroupWriteback Group writeback
UserWriteback Not currently supported.
Duplicate attribute resiliency

Instead of failing to provision objects with duplicate UPNs / proxyAddresses, the duplicated attribute is
“quarantined” and a temporary value is assigned. When the conflict is resolved, the temporary UPN is changed to
the proper value automatically. For more details, see Identity synchronization and duplicate attribute resiliency.
UserPrincipalName soft match

When this feature is enabled, soft-match is enabled for UPN in addition to the primary SMTP address, which is
always enabled. Soft-match is used to match existing cloud users in Azure AD with on-premises users.
If you need to match on-premises AD accounts with existing accounts created in the cloud and you are not using
Exchange Online, then this feature is useful. In this scenario, you generally don’t have a reason to set the SMTP
attribute in the cloud.
This feature is on by default for newly created Azure AD directories. You can see if this feature is enabled for you
by running:
Get-MsolDirSyncFeatures -Feature EnableSoftMatchOnUpn
If this feature is not enabled for your Azure AD directory, then you can enable it by running:
Set-MsolDirSyncFeature -Feature EnableSoftMatchOnUpn -Enable $true
Synchronize userPrincipalName updates

Historically, updates to the UserPrincipalName attribute using the sync service from on-premises has been
blocked, unless both of these conditions were true:
The user is managed (non-federated).
The user has not been assigned a license.
NOTE
From March 2019, synchronizing UPN changes for federated user accounts is allowed.
Enabling this feature allows the sync engine to update the userPrincipalName when it is changed on-premises and
you use password hash sync or pass-through authentication.
This feature is on by default for newly created Azure AD directories. You can see if this feature is enabled for you
by running:
Get-MsolDirSyncFeatures -Feature SynchronizeUpnForManagedUsers
If this feature is not enabled for your Azure AD directory, then you can enable it by running:
Set-MsolDirSyncFeature -Feature SynchronizeUpnForManagedUsers -Enable $true
After enabling this feature, existing userPrincipalName values will remain as-is. On next change of the
userPrincipalName attribute on-premises, the normal delta sync on users will update the UPN.
See also
Integrating your on-premises identities with Azure Active Directory.
Introduction to the Azure AD Connect
Synchronization Service Manager UI
The Synchronization Ser vice Manager UI is used to configure more advanced aspects of the sync engine and
to see the operational aspects of the service.
You start the Synchronization Ser vice Manager UI from the start menu. It is named Synchronization
Ser vice and can be found in the Azure AD Connect group.
Next steps
Learn more about the Synchronization Service Manager UI, including Operations, Connectors, Metaverse
Designer, and Metaverse Search tabs.
Learn more about the Azure AD Connect sync configuration.
Azure AD Connect sync: Technical Concepts
This article is a summary of the topic Understanding architecture.

Azure AD Connect sync builds upon a solid metadirectory synchronization platform. The following sections
introduce the concepts for metadirectory synchronization. Building upon MIIS (Microsoft Identity Integration
Server), ILM (Identity Lifecycle Manager), and FIM (Forefront Identity Manager), the Azure Active Directory Sync
Services provides the next platform for connecting to data sources, synchronizing data between data sources, as
well as the provisioning and deprovisioning of identities.
The following sections provide more details about the following aspects of the FIM Synchronization Service:
Connector
Attribute flow
Connector space
Metaverse
Provisioning
Connector
The code modules that are used to communicate with a connected directory are called connectors (formerly
known as management agents (MAs)).
These are installed on the computer running Azure AD Connect sync. The connectors provide the agentless ability
to converse by using remote system protocols instead of relying on the deployment of specialized agents. This
means decreased risk and deployment times, especially when dealing with critical applications and systems.
In the picture above, the connector is synonymous with the connector space but encompasses all communication
with the external system.
The connector is responsible for all import and export functionality to the system and frees developers from
needing to understand how to connect to each system natively when using declarative provisioning to customize
data transformations.
Imports and exports only occur when scheduled, allowing for further insulation from changes occurring within the
system, since changes do not automatically propagate to the connected data source. In addition, developers may
also create their own connectors for connecting to virtually any data source.
Attribute flow
The metaverse is the consolidated view of all joined identities from neighboring connector spaces. In the figure
above, attribute flow is depicted by lines with arrowheads for both inbound and outbound flow. Attribute flow is
the process of copying or transforming data from one system to another and all attribute flows (inbound or
outbound).
Attribute flow occurs between the connector space and the metaverse bi-directionally when synchronization (full
or delta) operations are scheduled to run.
Attribute flow only occurs when these synchronizations are run. Attribute flows are defined in Synchronization
Rules. These can be inbound (ISR in the picture above) or outbound (OSR in the picture above).
Connected system
Connected system (aka connected directory) is referring to the remote system Azure AD Connect sync has
connected to and reading and writing identity data to and from.
Connector space
Each connected data source is represented as a filtered subset of the objects and attributes in the connector space.
This allows the sync service to operate locally without the need to contact the remote system when synchronizing
the objects and restricts interaction to imports and exports only.
When the data source and the connector have the ability to provide a list of changes (a delta import), then the
operational efficiency increases dramatically as only changes since the last polling cycle are exchanged. The
connector space insulates the connected data source from changes propagating automatically by requiring that
the connector schedule imports and exports. This added insurance grants you peace of mind while testing,
previewing, or confirming the next update.
Metaverse
The metaverse is the consolidated view of all joined identities from neighboring connector spaces.
As identities are linked together and authority is assigned for various attributes through import flow mappings,
the central metaverse object begins to aggregate information from multiple systems. From this object attribute
flow, mappings carry information to outbound systems.
Objects are created when an authoritative system projects them into the metaverse. As soon as all connections are
removed, the metaverse object is deleted.
Objects in the metaverse cannot be edited directly. All data in the object must be contributed through attribute
flow. The metaverse maintains persistent connectors with each connector space. These connectors do not require
reevaluation for each synchronization run. This means that Azure AD Connect sync does not have to locate the
matching remote object each time. This avoids the need for costly agents to prevent changes to attributes that
would normally be responsible for correlating the objects.
When discovering new data sources that may have preexisting objects that need to be managed, Azure AD
Connect sync uses a process called a join rule to evaluate potential candidates with which to establish a link. Once
the link is established, this evaluation does not reoccur and normal attribute flow can occur between the remote
connected data source and the metaverse.
Provisioning
When an authoritative source projects a new object into the metaverse a new connector space object can be
created in another Connector representing a downstream connected data source.
This inherently establishes a link, and attribute flow can proceed bi-directionally.
Whenever a rule determines that a new connector space object needs to be created, it is called provisioning.
However, because this operation only takes place within the connector space, it does not carry over into the
connected data source until an export is performed.
Azure AD Connect Sync: Customizing Synchronization options
Azure AD Connect sync: Understanding the
architecture
This topic covers the basic architecture for Azure AD Connect sync. In many aspects, it is similar to its predecessors
MIIS 2003, ILM 2007, and FIM 2010. Azure AD Connect sync is the evolution of these technologies. If you are
familiar with any of these earlier technologies, the content of this topic will be familiar to you as well. If you are
new to synchronization, then this topic is for you. It is however not a requirement to know the details of this topic
to be successful in making customizations to Azure AD Connect sync (called sync engine in this topic).
Architecture
The sync engine creates an integrated view of objects that are stored in multiple connected data sources and
manages identity information in those data sources. This integrated view is determined by the identity information
retrieved from connected data sources and a set of rules that determine how to process this information.
Connected Data Sources and Connectors
The sync engine processes identity information from different data repositories, such as Active Directory or a SQL
Server database. Every data repository that organizes its data in a database-like format and that provides standard
data-access methods is a potential data source candidate for the sync engine. The data repositories that are
synchronized by sync engine are called connected data sources or connected directories (CD).
The sync engine encapsulates interaction with a connected data source within a module called a Connector . Each
type of connected data source has a specific Connector. The Connector translates a required operation into the
format that the connected data source understands.
Connectors make API calls to exchange identity information (both read and write) with a connected data source. It
is also possible to add a custom Connector using the extensible connectivity framework. The following illustration
shows how a Connector connects a connected data source to the sync engine.
Data can flow in either direction, but it cannot flow in both directions simultaneously. In other words, a Connector
can be configured to allow data to flow from the connected data source to sync engine or from sync engine to the
connected data source, but only one of those operations can occur at any one time for one object and attribute.
The direction can be different for different objects and for different attributes.
To configure a Connector, you specify the object types that you want to synchronize. Specifying the object types
defines the scope of objects that are included in the synchronization process. The next step is to select the
attributes to synchronize, which is known as an attribute inclusion list. These settings can be changed any time in
response to changes to your business rules. When you use the Azure AD Connect installation wizard, these settings
are configured for you.
To export objects to a connected data source, the attribute inclusion list must include at least the minimum
attributes required to create a specific object type in a connected data source. For example, the
sAMAccountName attribute must be included in the attribute inclusion list to export a user object to Active
Directory because all user objects in Active Directory must have a sAMAccountName attribute defined. Again,
the installation wizard does this configuration for you.
If the connected data source uses structural components, such as partitions or containers to organize objects, you
can limit the areas in the connected data source that are used for a given solution.
Internal structure of the sync engine namespace
The entire sync engine namespace consists of two namespaces that store the identity information. The two
namespaces are:
The connector space (CS)
The metaverse (MV)
The connector space is a staging area that contains representations of the designated objects from a connected
data source and the attributes specified in the attribute inclusion list. The sync engine uses the connector space to
determine what has changed in the connected data source and to stage incoming changes. The sync engine also
uses the connector space to stage outgoing changes for export to the connected data source. The sync engine
maintains a distinct connector space as a staging area for each Connector.
By using a staging area, the sync engine remains independent of the connected data sources and is not affected by
their availability and accessibility. As a result, you can process identity information at any time by using the data in
the staging area. The sync engine can request only the changes made inside the connected data source since the
last communication session terminated or push out only the changes to identity information that the connected
data source has not yet received, which reduces the network traffic between the sync engine and the connected
data source.
In addition, sync engine stores status information about all objects that it stages in the connector space. When new
data is received, sync engine always evaluates whether the data has already been synchronized.
The metaverse is a storage area that contains the aggregated identity information from multiple connected data
sources, providing a single global, integrated view of all combined objects. Metaverse objects are created based on
the identity information that is retrieved from the connected data sources and a set of rules that allow you to
customize the synchronization process.
The following illustration shows the connector space namespace and the metaverse namespace within the sync
engine.
Sync engine identity objects

The objects in the sync engine are representations of either objects in the connected data source or the integrated
view that sync engine has of those objects. Every sync engine object must have a globally unique identifier (GUID).
GUIDs provide data integrity and express relationships between objects.
Connector space objects
When sync engine communicates with a connected data source, it reads the identity information in the connected
data source and uses that information to create a representation of the identity object in the connector space. You
cannot create or delete these objects individually. However, you can manually delete all objects in a connector
space.
All objects in the connector space have two attributes:
A globally unique identifier (GUID)
A distinguished name (also known as DN)
If the connected data source assigns a unique attribute to the object, then objects in the connector space can also
have an anchor attribute. The anchor attribute uniquely identifies an object in the connected data source. The sync
engine uses the anchor to locate the corresponding representation of this object in the connected data source.
Sync engine assumes that the anchor of an object never changes over the lifetime of the object.
Many of the Connectors use a known unique identifier to generate an anchor automatically for each object when it
is imported. For example, the Active Directory Connector uses the objectGUID attribute for an anchor. For
connected data sources that do not provide a clearly defined unique identifier, you can specify anchor generation
as part of the Connector configuration.
In that case, the anchor is built from one or more unique attributes of an object type, neither of which changes, and
that uniquely identifies the object in the connector space (for example, an employee number or a user ID).
A connector space object can be one of the following:
A staging object
A placeholder
Staging Objects
A staging object represents an instance of the designated object types from the connected data source. In addition
to the GUID and the distinguished name, a staging object always has a value that indicates the object type.
Staging objects that have been imported always have a value for the anchor attribute. Staging objects that have
been newly provisioned by sync engine and are in the process of being created in the connected data source do
not have a value for the anchor attribute.
Staging objects also carry current values of business attributes, and operational information needed by sync
engine to perform the synchronization process. Operational information includes flags that indicate the type of
updates that are staged on the staging object. If a staging object has received new identity information from the
connected data source that has not yet been processed, the object is flagged as pending impor t . If a staging
object has new identity information that has not yet been exported to the connected data source, it is flagged as
pending expor t .
A staging object can be an import object or an export object. The sync engine creates an import object by using
object information received from the connected data source. When sync engine receives information about the
existence of a new object that matches one of the object types selected in the Connector, it creates an import object
in the connector space as a representation of the object in the connected data source.
The following illustration shows an import object that represents an object in the connected data source.
The sync engine creates an export object by using object information in the metaverse. Export objects are exported
to the connected data source during the next communication session. From the perspective of the sync engine,
export objects do not exist in the connected data source yet. Therefore, the anchor attribute for an export object is
not available. After it receives the object from sync engine, the connected data source creates a unique value for
the anchor attribute of the object.
The following illustration shows how an export object is created by using identity information in the metaverse.
The sync engine confirms the export of the object by reimporting the object from the connected data source.
Export objects become import objects when sync engine receives them during the next import from that
connected data source.
Placeholders
The sync engine uses a flat namespace to store objects. However, some connected data sources such as Active
Directory use a hierarchical namespace. To transform information from a hierarchical namespace into a flat
namespace, sync engine uses placeholders to preserve the hierarchy.
Each placeholder represents a component (for example, an organizational unit) of an object's hierarchical name
that has not been imported into sync engine but is required to construct the hierarchical name. They fill gaps
created by references in the connected data source to objects that are not staging objects in the connector space.
The sync engine also uses placeholders to store referenced objects that have not yet been imported. For example,
if sync is configured to include the manager attribute for the Abbie Spencer object and the received value is an
object that has not been imported yet, such as CN=Lee Sperry,CN=Users,DC=fabrikam,DC=com, the manager
information is stored as placeholders in the connector space. If the manager object is later imported, the
placeholder object is overwritten by the staging object that represents the manager.
Metaverse objects
A metaverse object contains the aggregated view that sync engine has of the staging objects in the connector
space. Sync engine creates metaverse objects by using the information in import objects. Several connector space
objects can be linked to a single metaverse object, but a connector space object cannot be linked to more than one
metaverse object.
Metaverse objects cannot be manually created or deleted. The sync engine automatically deletes metaverse objects
that do not have a link to any connector space object in the connector space.
To map objects within a connected data source to a corresponding object type within the metaverse, sync engine
provides an extensible schema with a predefined set of object types and associated attributes. You can create new
object types and attributes for metaverse objects. Attributes can be single-valued or multivalued, and the attribute
types can be strings, references, numbers, and Boolean values.
Relationships between staging objects and metaverse objects
Within the sync engine namespace, the data flow is enabled by the link relationship between staging objects and
metaverse objects. A staging object that is linked to a metaverse object is called a joined object (or connector
object ). A staging object that is not linked to a metaverse object is called a disjoined object (or disconnector
object ). The terms joined and disjoined are preferred to not confuse with the Connectors responsible for
importing and exporting data from a connected directory.
Placeholders are never linked to a metaverse object
A joined object comprises a staging object and its linked relationship to a single metaverse object. Joined objects
are used to synchronize attribute values between a connector space object and a metaverse object.
When a staging object becomes a joined object during synchronization, attributes can flow between the staging
object and the metaverse object. Attribute flow is bidirectional and is configured by using import attribute rules
and export attribute rules.
A single connector space object can be linked to only one metaverse object. However, each metaverse object can
be linked to multiple connector space objects in the same or in different connector spaces, as shown in the
following illustration.
The linked relationship between the staging object and a metaverse object is persistent and can be removed only
by rules that you specify.
A disjoined object is a staging object that is not linked to any metaverse object. The attribute values of a disjoined
object are not processed any further within the metaverse. The attribute values of the corresponding object in the
connected data source are not updated by sync engine.
By using disjoined objects, you can store identity information in sync engine and process it later. Keeping a staging
object as a disjoined object in the connector space has many advantages. Because the system has already staged
the required information about this object, it is not necessary to create a representation of this object again during
the next import from the connected data source. This way, sync engine always has a complete snapshot of the
connected data source, even if there is no current connection to the connected data source. Disjoined objects can
be converted into joined objects, and vice versa, depending on the rules that you specify.
An import object is created as a disjoined object. An export object must be a joined object. The system logic
enforces this rule and deletes every export object that is not a joined object.
Sync engine identity management process

The identity management process controls how identity information is updated between different connected data
sources. Identity management occurs in three processes:
Import
Synchronization
Export
During the import process, sync engine evaluates the incoming identity information from a connected data source.
When changes are detected, it either creates new staging objects or updates existing staging objects in the
connector space for synchronization.
During the synchronization process, sync engine updates the metaverse to reflect changes that have occurred in
the connector space and updates the connector space to reflect changes that have occurred in the metaverse.
During the export process, sync engine pushes out changes that are staged on staging objects and that are flagged
as pending export.
The following illustration shows where each of the processes occurs as identity information flows from one
connected data source to another.
Import process
During the import process, sync engine evaluates updates to identity information. Sync engine compares the
identity information received from the connected data source with the identity information about a staging object
and determines whether the staging object requires updates. If it is necessary to update the staging object with
new data, the staging object is flagged as pending import.
By staging objects in the connector space before synchronization, sync engine can process only the identity
information that has changed. This process provides the following benefits:
Efficient synchronization . The amount of data processed during synchronization is minimized.
Efficient resynchronization . You can change how sync engine processes identity information without
reconnecting the sync engine to the data source.
Oppor tunity to preview synchronization . You can preview synchronization to verify that your assumptions
about the identity management process are correct.
For each object specified in the Connector, the sync engine first tries to locate a representation of the object in the
connector space of the Connector. Sync engine examines all staging objects in the connector space and tries to find
a corresponding staging object that has a matching anchor attribute. If no existing staging object has a matching
anchor attribute, sync engine tries to find a corresponding staging object with the same distinguished name.
When sync engine finds a staging object that matches by distinguished name but not by anchor, the following
special behavior occurs:
If the object located in the connector space has no anchor, then sync engine removes this object from the
connector space and marks the metaverse object it is linked to as retr y provisioning on next
synchronization run . Then it creates the new import object.
If the object located in the connector space has an anchor, then sync engine assumes that this object has either
been renamed or deleted in the connected directory. It assigns a temporary, new distinguished name for the
connector space object so that it can stage the incoming object. The old object then becomes transient , waiting
for the Connector to import the rename or deletion to resolve the situation.
If sync engine locates a staging object that corresponds to the object specified in the Connector, it determines what
kind of changes to apply. For example, sync engine might rename or delete the object in the connected data
source, or it might only update the object’s attribute values.
Staging objects with updated data are marked as pending import. Different types of pending imports are available.
Depending on the result of the import process, a staging object in the connector space has one of the following
pending import types:
None . No changes to any of the attributes of the staging object are available. Sync engine does not flag this
type as pending import.
Add . The staging object is a new import object in the connector space. Sync engine flags this type as pending
import for additional processing in the metaverse.
Update . Sync engine finds a corresponding staging object in the connector space and flags this type as
pending import so that updates to the attributes can be processed in the metaverse. Updates include object
renaming.
Delete . Sync engine finds a corresponding staging object in the connector space and flags this type as pending
import so that the joined object can be deleted.
Delete/Add . Sync engine finds a corresponding staging object in the connector space, but the object types do
not match. In this case, a delete-add modification is staged. A delete-add modification indicates to the sync
engine that a complete resynchronization of this object must occur because different sets of rules apply to this
object when the object type changes.
By setting the pending import status of a staging object, it is possible to reduce significantly the amount of data
processed during synchronization because doing so allows the system to process only those objects that have
updated data.
Synchronization process
Synchronization consists of two related processes:
Inbound synchronization, when the content of the metaverse is updated by using the data in the connector
space.
Outbound synchronization, when the content of the connector space is updated by using data in the metaverse.
By using the information staged in the connector space, the inbound synchronization process creates in the
metaverse the integrated view of the data that is stored in the connected data sources. Either all staging objects or
only those with a pending import information are aggregated, depending on how the rules are configured.
The outbound synchronization process updates export objects when metaverse objects change.
Inbound synchronization creates the integrated view in the metaverse of the identity information that is received
from the connected data sources. Sync engine can process identity information at any time by using the latest
identity information that it has from the connected data source.
Inbound synchronization
Inbound synchronization includes the following processes:
Provision (also called Projection if it is important to distinguish this process from outbound synchronization
provisioning). The Sync engine creates a new metaverse object based on a staging object and links them.
Provision is an object-level operation.
Join . The Sync engine links a staging object to an existing metaverse object. A join is an object-level operation.
Impor t attribute flow . Sync engine updates the attribute values, called attribute flow, of the object in the
metaverse. Import attribute flow is an attribute-level operation that requires a link between a staging object
and a metaverse object.
Provision is the only process that creates objects in the metaverse. Provision affects only import objects that are
disjoined objects. During provision, sync engine creates a metaverse object that corresponds to the object type of
the import object and establishes a link between both objects, thus creating a joined object.
The join process also establishes a link between import objects and a metaverse object. The difference between
join and provision is that the join process requires that the import object are linked to an existing metaverse
object, where the provision process creates a new metaverse object.
Sync engine tries to join an import object to a metaverse object by using criteria that is specified in the
Synchronization Rule configuration.
During the provision and join processes, sync engine links a disjoined object to a metaverse object, making them
joined. After these object-level operations are completed, sync engine can update the attribute values of the
associated metaverse object. This process is called import attribute flow.
Import attribute flow occurs on all import objects that carry new data and are linked to a metaverse object.
Outbound synchronization
Outbound synchronization updates export objects when a metaverse object change but is not deleted. The
objective of outbound synchronization is to evaluate whether changes to metaverse objects require updates to
staging objects in the connector spaces. In some cases, the changes can require that staging objects in all
connector spaces be updated. Staging objects that are changed are flagged as pending export, making them export
objects. These export objects are later pushed out to the connected data source during the export process.
Outbound synchronization has three processes:
Provisioning
Deprovisioning
Expor t attribute flow
Provisioning and deprovisioning are both object-level operations. Deprovisioning depends on provisioning
because only provisioning can initiate it. Deprovisioning is triggered when provisioning removes the link between
a metaverse object and an export object.
Provisioning is always triggered when changes are applied to objects in the metaverse. When changes are made to
metaverse objects, sync engine can perform any of the following tasks as part of the provisioning process:
Create joined objects, where a metaverse object is linked to a newly created export object.
Rename a joined object.
Disjoin links between a metaverse object and staging objects, creating a disjoined object.
If provisioning requires sync engine to create a new connector object, the staging object to which the metaverse
object is linked is always an export object, because the object does not yet exist in the connected data source.
If provisioning requires sync engine to disjoin a joined object, creating a disjoined object, deprovisioning is
triggered. The deprovisioning process deletes the object.
During deprovisioning, deleting an export object does not physically delete the object. The object is flagged as
deleted , which means that the delete operation is staged on the object.
Export attribute flow also occurs during the outbound synchronization process, similar to the way that import
attribute flow occurs during inbound synchronization. Export attribute flow occurs only between metaverse and
export objects that are joined.
Export process
During the export process, sync engine examines all export objects that are flagged as pending export in the
connector space, and then sends updates to the connected data source.
The sync engine can determine the success of an export but it cannot sufficiently determine that the identity
management process is complete. Objects in the connected data source can always be changed by other
processes. Because sync engine does not have a persistent connection to the connected data source, it is not
sufficient to make assumptions about the properties of an object in the connected data source based only on a
successful export notification.
For example, a process in the connected data source could change the object’s attributes back to their original
values (that is, the connected data source could overwrite the values immediately after the data is pushed out by
sync engine and successfully applied in the connected data source).
The sync engine stores export and import status information about each staging object. If values of the attributes
that are specified in the attribute inclusion list have changed since the last export, the storage of import and export
status enables sync engine to react appropriately. Sync engine uses the import process to confirm attribute values
that have been exported to the connected data source. A comparison between the imported and exported
information, as shown in the following illustration, enables sync engine to determine whether the export was
successful or if it needs to be repeated.
For example, if sync engine exports attribute C, which has a value of 5, to a connected data source, it stores C=5 in
its export status memory. Each additional export on this object results in an attempt to export C=5 to the
connected data source again because sync engine assumes that this value has not been persistently applied to the
object (that is, unless a different value was imported recently from the connected data source). The export memory
is cleared when C=5 is received during an import operation on the object.
Next steps
Azure AD Connect sync: Understanding Declarative
Provisioning
This topic explains the configuration model in Azure AD Connect. The model is called Declarative Provisioning and
it allows you to make a configuration change with ease. Many things described in this topic are advanced and not
required for most customer scenarios.
Overview
Declarative provisioning is processing objects coming in from a source connected directory and determines how
the object and attributes should be transformed from a source to a target. An object is processed in a sync
pipeline and the pipeline is the same for inbound and outbound rules. An inbound rule is from a connector space
to the metaverse and an outbound rule is from the metaverse to a connector space.
The pipeline has several different modules. Each one is responsible for one concept in object synchronization.
Source, The source object

Scope, Finds all sync rules that are in scope
Join, Determines relationship between connector space and metaverse
Transform, Calculates how attributes should be transformed and flow
Precedence, Resolves conflicting attribute contributions
Target, The target object
Scope
The scope module is evaluating an object and determines the rules that are in scope and should be included in the
processing. Depending on the attributes values on the object, different sync rules are evaluated to be in scope. For
example, a disabled user with no Exchange mailbox does have different rules than an enabled user with a mailbox.
The scope is defined as groups and clauses. The clauses are inside a group. A logical AND is used between all
clauses in a group. For example, (department =IT AND country = Denmark). A logical OR is used between groups.
The scope in this picture should be read as (department = IT AND country = Denmark) OR (country=Sweden). If
either group 1 or group 2 is evaluated to true, then the rule is in scope.
The scope module supports the following operations.
O P ERAT IO N DESC RIP T IO N
EQUAL, NOTEQUAL A string compare that evaluates if value is equal to the value
in the attribute. For multi-valued attributes, see ISIN and
ISNOTIN.
LESSTHAN, LESSTHAN_OR_EQUAL A string compare that evaluates if value is less than of the
value in the attribute.
CONTAINS, NOTCONTAINS A string compare that evaluates if value can be found

somewhere inside value in the attribute.
STARTSWITH, NOTSTARTSWITH A string compare that evaluates if value is in the beginning of

the value in the attribute.
ENDSWITH, NOTENDSWITH A string compare that evaluates if value is in the end of the
GREATERTHAN, GREATERTHAN_OR_EQUAL A string compare that evaluates if value is greater than of the
ISNULL, ISNOTNULL Evaluates if the attribute is absent from the object. If the
attribute is not present and therefore null, then the rule is in
scope.
ISIN, ISNOTIN Evaluates if the value is present in the defined attribute. This
operation is the multi-valued variation of EQUAL and
NOTEQUAL. The attribute is supposed to be a multi-valued
attribute and if the value can be found in any of the attribute
values, then the rule is in scope.
ISBITSET, ISNOTBITSET Evaluates if a particular bit is set. For example, can be used to
evaluate the bits in userAccountControl to see if a user is
enabled or disabled.
ISMEMBEROF, ISNOTMEMBEROF The value should contain a DN to a group in the connector

space. If the object is a member of the group specified, the
rule is in scope.
Join
The join module in the sync pipeline is responsible for finding the relationship between the object in the source
and an object in the target. On an inbound rule, this relationship would be an object in a connector space finding a
relationship to an object in the metaverse.
The goal is to see if there is an object already in the metaverse, created by another Connector, it should be
associated with. For example, in an account-resource forest the user from the account forest should be joined with
the user from the resource forest.
Joins are used mostly on inbound rules to join connector space objects together to the same metaverse object.
The joins are defined as one or more groups. Inside a group, you have clauses. A logical AND is used between all
clauses in a group. A logical OR is used between groups. The groups are processed in order from top to bottom.
When one group has found exactly one match with an object in the target, then no other join rules are evaluated.
If zero or more than one object is found, processing continues to the next group of rules. For this reason, the rules
should be created in the order of most explicit first and more fuzzy at the end.
The joins in this picture are processed from top to bottom. First the sync pipeline sees if there is a match on
employeeID. If not, the second rule sees if the account name can be used to join the objects together. If that is not a
match either, the third and final rule is a more fuzzy match by using the name of user.
If all join rules have been evaluated and there is not exactly one match, the Link Type on the Description page is
used. If this option is set to Provision , then a new object in the target is created.
An object should only have one single sync rule with join rules in scope. If there are multiple sync rules where join
is defined, an error occurs. Precedence is not used to resolve join conflicts. An object must have a join rule in
scope for attributes to flow with the same inbound/outbound direction. If you need to flow attributes both
inbound and outbound to the same object, you must have both an inbound and an outbound sync rule with join.
Outbound join has a special behavior when it tries to provision an object to a target connector space. The DN
attribute is used to first try a reverse-join. If there is already an object in the target connector space with the same
DN, the objects are joined.
The join module is only evaluated once when a new sync rule comes into scope. When an object has joined, it is
not disjoining even if the join criteria is no longer satisfied. If you want to disjoin an object, the sync rule that
joined the objects must go out of scope.
Metaverse delete
A metaverse object remains as long as there is one sync rule in scope with Link Type set to Provision or
StickyJoin . A StickyJoin is used when a Connector is not allowed to provision a new object to the metaverse, but
when it has joined, it must be deleted in the source before the metaverse object is deleted.
When a metaverse object is deleted, all objects associated with an outbound sync rule marked for provision are
marked for a delete.
Transformations
The transformations are used to define how attributes should flow from the source to the target. The flows can
have one of the following flow types : Direct, Constant, or Expression. A direct flow, flows an attribute value as-is
with no additional transformations. A constant value sets the specified value. An expression uses the declarative
provisioning expression language to express how the transformation should be. The details for the expression
language can be found in the understanding declarative provisioning expression language topic.
The Apply once checkbox defines that the attribute should only be set when the object is initially created. For
example, this configuration can be used to set an initial password for a new user object.
Merging attribute values
In the attribute flows there is a setting to determine if multi-valued attributes should be merged from several
different Connectors. The default value is Update , which indicates that the sync rule with highest precedence
should win.
There is also Merge and MergeCaseInsensitive . These options allow you to merge values from different
sources. For example, it can be used to merge the member or proxyAddresses attribute from several different
forests. When you use this option, all sync rules in scope for an object must use the same merge type. You cannot
define Update from one Connector and Merge from another. If you try, you receive an error.
The difference between Merge and MergeCaseInsensitive is how to process duplicate attribute values. The
sync engine makes sure duplicate values are not inserted into the target attribute. With MergeCaseInsensitive ,
duplicate values with only a difference in case are not going to be present. For example, you should not see both
"SMTP:bob@contoso.com" and "smtp:bob@contoso.com" in the target attribute. Merge is only looking at the
exact values and multiple values where there only is a difference in case might be present.
The option Replace is the same as Update , but it is not used.
Control the attribute flow process
When multiple inbound sync rules are configured to contribute to the same metaverse attribute, then precedence
is used to determine the winner. The sync rule with highest precedence (lowest numeric value) is going to
contribute the value. The same happens for outbound rules. The sync rule with highest precedence wins and
contribute the value to the connected directory.
In some cases, rather than contribute a value, the sync rule should determine how other rules should behave.
There are some special literals used for this case.
For inbound Synchronization Rules, the literal NULL can be used to indicate that the flow has no value to
contribute. Another rule with lower precedence can contribute a value. If no rule contributed a value, then the
metaverse attribute is removed. For an outbound rule, if NULL is the final value after all sync rules have been
processed, then the value is removed in the connected directory.
The literal AuthoritativeNull is similar to NULL but with the difference that no lower precedence rules can
contribute a value.
An attribute flow can also use IgnoreThisFlow . It is similar to NULL in the sense that it indicates there is nothing
to contribute. The difference is that it does not remove an already existing value in the target. It is like the attribute
flow has never been there.
Here is an example:
In Out to AD - User Exchange hybrid the following flow can be found:
IIF([cloudSOAExchMailbox] = True,[cloudMSExchSafeSendersHash],IgnoreThisFlow)
This expression should be read as: if the user mailbox is located in Azure AD, then flow the attribute from Azure
AD to AD. If not, do not flow anything back to Active Directory. In this case, it would keep the existing value in AD.
ImportedValue
The function ImportedValue is different than all other functions since the attribute name must be enclosed in
quotes rather than square brackets:
ImportedValue("proxyAddresses") .
Usually during synchronization an attribute uses the expected value, even if it hasn’t been exported yet or an error
was received during export (“top of the tower”). An inbound synchronization assumes that an attribute that hasn’t
yet reached a connected directory eventually reaches it. In some cases, it is important to only synchronize a value
that has been confirmed by the connected directory (“hologram and delta import tower”).
An example of this function can be found in the out-of-box Synchronization Rule In from AD – User Common
from Exchange. In Hybrid Exchange, the value added by Exchange online should only be synchronized when it has
been confirmed that the value was exported successfully:
proxyAddresses <- RemoveDuplicates(Trim(ImportedValue("proxyAddresses")))
Precedence
When several sync rules try to contribute the same attribute value to the target, the precedence value is used to
determine the winner. The rule with highest precedence, lowest numeric value, is going to contribute the attribute
in a conflict.
This ordering can be used to define more precise attribute flows for a small subset of objects. For example, the
out-of-box-rules make sure that attributes from an enabled account (User AccountEnabled ) have precedence
from other accounts.
Precedence can be defined between Connectors. That allows Connectors with better data to contribute values first.
Multiple objects from the same connector space
If you have several objects in the same connector space joined to the same metaverse object, precedence must be
adjusted. If several objects are in scope of the same sync rule, then the sync engine is not able to determine
precedence. It is ambiguous which source object should contribute the value to the metaverse. This configuration
is reported as ambiguous even if the attributes in the source have the same value.
For this scenario, you need to change the scope of the sync rules so the source objects have different sync rules in
scope. That allows you to define different precedence.
Next steps
Read more about the expression language in Understanding Declarative Provisioning Expressions.
See how declarative provisioning is used out-of-box in Understanding the default configuration.
See how to make a practical change using declarative provisioning in How to make a change to the default
configuration.
Continue to read how users and contacts work together in Understanding Users and Contacts.
Over view topics
Azure AD Connect sync: Understand and customize synchronization
Reference topics
Azure AD Connect sync: Functions Reference
Azure AD Connect sync: Understanding Declarative
Provisioning Expressions
Azure AD Connect sync builds on declarative provisioning first introduced in Forefront Identity Manager 2010. It
allows you to implement your complete identity integration business logic without the need to write compiled
code.
An essential part of declarative provisioning is the expression language used in attribute flows. The language
used is a subset of Microsoft® Visual Basic® for Applications (VBA). This language is used in Microsoft Office
and users with experience of VBScript will also recognize it. The Declarative Provisioning Expression Language is
only using functions and is not a structured language. There are no methods or statements. Functions are instead
nested to express program flow.
For more details, see Welcome to the Visual Basic for Applications language reference for Office 2013.
The attributes are strongly typed. A function only accepts attributes of the correct type. It is also case-sensitive.
Both function names and attribute names must have proper casing or an error is thrown.
Language definitions and Identifiers

Functions have a name followed by arguments in brackets: FunctionName(argument 1, argument N).
Attributes are identified by square brackets: [attributeName]
Parameters are identified by percent signs: %ParameterName%
String constants are surrounded by quotes: For example, "Contoso" (Note: must use straight quotes "" and not
smart quotes “”)
Numeric values are expressed without quotes and expected to be decimal. Hexadecimal values are prefixed
with &H. For example, 98052, &HFF
Boolean values are expressed with constants: True, False.
Built-in constants and literals are expressed with only their name: NULL, CRLF, IgnoreThisFlow
Functions
Declarative provisioning uses many functions to enable the possibility to transform attribute values. These
functions can be nested so the result from one function is passed in to another function.
Function1(Function2(Function3()))
The complete list of functions can be found in the function reference.

Parameters
A parameter is defined either by a Connector or by an administrator using PowerShell. Parameters usually
contain values that are different from system to system, for example the name of the domain the user is located
in. These parameters can be used in attribute flows.
The Active Directory Connector provided the following parameters for inbound Synchronization Rules:
PA RA M ET ER N A M E C O M M EN T
Domain.Netbios Netbios format of the domain currently being imported, for

example FABRIKAMSALES
PA RA M ET ER N A M E C O M M EN T
Domain.FQDN FQDN format of the domain currently being imported, for

example sales.fabrikam.com
Domain.LDAP LDAP format of the domain currently being imported, for

example DC=sales,DC=fabrikam,DC=com
Forest.Netbios Netbios format of the forest name currently being imported,

for example FABRIKAMCORP
Forest.FQDN FQDN format of the forest name currently being imported,

for example fabrikam.com
Forest.LDAP LDAP format of the forest name currently being imported,

for example DC=fabrikam,DC=com
The system provides the following parameter, which is used to get the identifier of the Connector currently
running:
Connector.ID
Here is an example that populates the metaverse attribute domain with the netbios name of the domain where
the user is located:
domain <- %Domain.Netbios%
Operators
The following operators can be used:
Comparison : <, <=, <>, =, >, >=
Mathematics : +, -, *, -
String : & (concatenate)
Logical : && (and), || (or)
Evaluation order : ( )
Operators are evaluated left to right and have the same evaluation priority. That is, the * (multiplier) is not
evaluated before - (subtraction). 2*(5+3) is not the same as 2*5+3. The brackets ( ) are used to change the
evaluation order when left to right evaluation order isn't appropriate.
Multi-valued attributes
The functions can operate on both single-valued and multi-valued attributes. For multi-valued attributes, the
function operates over every value and applies the same function to every value.
For example:
Trim([proxyAddresses]) Do a Trim of every value in the proxyAddress attribute.
Word([proxyAddresses],1,"@") & "@contoso.com" For every value with an @-sign, replace the domain with
@contoso.com.
IIF(InStr([proxyAddresses],"SIP:")=1,NULL,[proxyAddresses]) Look for the SIP-address and remove it from the
values.
Next steps
Read more about the configuration model in Understanding Declarative Provisioning.
See how declarative provisioning is used out-of-box in Understanding the default configuration.
configuration.
Over view topics
Reference topics
Azure AD Connect sync: Understanding the default
configuration
This article explains the out-of-box configuration rules. It documents the rules and how these rules impact the
configuration. It also walks you through the default configuration of Azure AD Connect sync. The goal is that the
reader understands how the configuration model, named declarative provisioning, is working in a real-world
example. This article assumes that you have already installed and configure Azure AD Connect sync using the
installation wizard.
To understand the details of the configuration model, read Understanding Declarative Provisioning.
Out-of-box rules from on-premises to Azure AD

The following expressions can be found in the out-of-box configuration.
User out-of-box rules
These rules also apply to the iNetOrgPerson object type.
A user object must satisfy the following to be synchronized:
Must have a sourceAnchor.
After the object has been created in Azure AD, then sourceAnchor cannot change. If the value is changed on-
premises, the object stops synchronizing until the sourceAnchor is changed back to its previous value.
Must have the accountEnabled (userAccountControl) attribute populated. With an on-premises Active
Directory, this attribute is always present and populated.
The following user objects are not synchronized to Azure AD:
IsPresent([isCriticalSystemObject]) . Ensure many out-of-box objects in Active Directory, such as the built-in
administrator account, are not synchronized.
IsPresent([sAMAccountName]) = False . Ensure user objects with no sAMAccountName attribute are not
synchronized. This case would only practically happen in a domain upgraded from NT4.
Left([sAMAccountName], 4) = "AAD_" , Left([sAMAccountName], 5) = "MSOL_" . Do not synchronize the service
account used by Azure AD Connect sync and its earlier versions.
Do not synchronize Exchange accounts that would not work in Exchange Online.
[sAMAccountName] = "SUPPORT_388945a0"
Left([mailNickname], 14) = "SystemMailbox{"
(Left([mailNickname], 4) = "CAS_" && (InStr([mailNickname], "}") > 0))
(Left([sAMAccountName], 4) = "CAS_" && (InStr([sAMAccountName], "}")> 0))
Do not synchronize objects that would not work in Exchange Online.
CBool(IIF(IsPresent([msExchRecipientTypeDetails]),BitAnd([msExchRecipientTypeDetails],&H21C07000) >
0,NULL))
This bitmask (&H21C07000) would filter out the following objects:
Mail-enabled Public Folder (In Preview as of version 1.1.524.0)
System Attendant Mailbox
Mailbox Database Mailbox (System Mailbox)
Universal Security Group (wouldn't apply for a user, but is present for legacy reasons)
Non-Universal Group (wouldn't apply for a user, but is present for legacy reasons)
Mailbox Plan
Discovery Mailbox
CBool(InStr(DNComponent(CRef([dn]),1),"\\0ACNF:")>0) . Do not synchronize any replication victim objects.
The following attribute rules apply:
sourceAnchor <- IIF([msExchRecipientTypeDetails]=2,NULL,..) . The sourceAnchor attribute is not contributed
from a linked mailbox. It is assumed that if a linked mailbox has been found, the actual account is joined later.
Exchange related attributes are only synchronized if the attribute mailNickName has a value.
When there are multiple forests, then attributes are consumed in the following order:
1. Attributes related to sign-in (for example userPrincipalName) are contributed from the forest with an
enabled account.
2. Attributes that can be found in an Exchange GAL (Global Address List) are contributed from the forest
with an Exchange Mailbox.
3. If no mailbox can be found, then these attributes can come from any forest.
4. Exchange related attributes (technical attributes not visible in the GAL) are contributed from the forest
where mailNickname ISNOTNULL .
5. If there are multiple forests that would satisfy one of these rules, then the creation order (date/time) of
the Connectors (forests) is used to determine which forest contributes the attributes. The first forest
connected will be the first forest to sync.
Contact out-of-box rules
A contact object must satisfy the following to be synchronized:
The contact must be mail-enabled. It is verified with the following rules:
IsPresent([proxyAddresses]) = True) . The proxyAddresses attribute must be populated.
A primary email address can be found in either the proxyAddresses attribute or the mail attribute. The
presence of an @ is used to verify that the content is an email address. One of these two rules must be
evaluated to True.
(Contains([proxyAddresses], "SMTP:") > 0) && (InStr(Item([proxyAddresses],
Contains([proxyAddresses], "SMTP:")), "@") > 0))
. Is there an entry with "SMTP:" and if there is, can an @ be found in the string?
(IsPresent([mail]) = True && (InStr([mail], "@") > 0) . Is the mail attribute populated and if it
is, can an @ be found in the string?
The following contact objects are not synchronized to Azure AD:
IsPresent([isCriticalSystemObject]) . Ensure no contact objects marked as critical are synchronized. Shouldn't
be any with a default configuration.
((InStr([displayName], "(MSOL)") > 0) && (CBool([msExchHideFromAddressLists]))) .
(Left([mailNickname], 4) = "CAS_" && (InStr([mailNickname], "}") > 0)) . These objects wouldn't work in
Exchange Online.
Group out-of-box rules
A group object must satisfy the following to be synchronized:
Must have less than 50,000 members. This count is the number of members in the on-premises group.
If it has more members before synchronization starts the first time, the group is not synchronized.
If the number of members grow from when it was initially created, then when it reaches 50,000
members it stops synchronizing until the membership count is lower than 50,000 again.
Note: The 50,000 membership count is also enforced by Azure AD. You are not able to synchronize
groups with more members even if you modify or remove this rule.
If the group is a Distribution Group , then it must also be mail enabled. See Contact out-of-box rules for this
rule is enforced.
The following group objects are not synchronized to Azure AD:
IsPresent([isCriticalSystemObject]) . Ensure many out-of-box objects in Active Directory, such as the built-in
administrators group, are not synchronized.
[sAMAccountName] = "MSOL_AD_Sync_RichCoexistence" . Legacy group used by DirSync.
BitAnd([msExchRecipientTypeDetails],&H40000000) . Role Group.
ForeignSecurityPrincipal out-of-box rules

FSPs are joined to "any" (*) object in the metaverse. In reality, this join only happens for users and security groups.
This configuration ensures that cross-forest memberships are resolved and represented correctly in Azure AD.
Computer out-of-box rules
A computer object must satisfy the following to be synchronized:
userCertificate ISNOTNULL . Only Windows 10 computers populate this attribute. All computer objects with a
value in this attribute are synchronized.
Understanding the out-of-box rules scenario

In this example, we are using a deployment with one account forest (A), one resource forest (R), and one Azure AD
directory.
In this configuration, it is assumed there is an enabled account in the account forest and a disabled account in the
resource forest with a linked mailbox.
Our goal with the default configuration is:
Attributes related to sign-in are synchronized from the forest with the enabled account.
Attributes that can be found in the GAL (Global Address List) are synchronized from the forest with the
mailbox. If no mailbox can be found, any other forest is used.
If a linked mailbox is found, the linked enabled account must be found for the object to be exported to Azure
AD.
Synchronization Rule Editor
The configuration can be viewed and changed with the tool Synchronization Rules Editor (SRE) and a shortcut to
it can be found in the start menu.
The SRE is a resource kit tool and it is installed with Azure AD Connect sync. To be able to start it, you must be a
member of the ADSyncAdmins group. When it starts, you see something like this:
In this pane, you see all Synchronization Rules created for your configuration. Each line in the table is one
Synchronization Rule. To the left under Rule Types, the two different types are listed: Inbound and Outbound.
Inbound and Outbound is from the view of the metaverse. You are mainly going to focus on the inbound rules in
this overview. The actual list of Synchronization Rules depends on the detected schema in AD. In the picture
above, the account forest (fabrikamonline.com) does not have any services, such as Exchange and Lync, and no
Synchronization Rules have been created for these services. However, in the resource forest
(res.fabrikamonline.com) you find Synchronization Rules for these services. The content of the rules is different
depending on the version detected. For example, in a deployment with Exchange 2013 there are more attribute
flows configured than in Exchange 2010/2007.
Synchronization Rule
A Synchronization Rule is a configuration object with a set of attributes flowing when a condition is satisfied. It is
also used to describe how an object in a connector space is related to an object in the metaverse, known as join
or match . The Synchronization Rules have a precedence value indicating how they relate to each other. A
Synchronization Rule with a lower numeric value has a higher precedence and in an attribute flow conflict, higher
precedence wins the conflict resolution.
As an example, look at the Synchronization Rule In from AD – User AccountEnabled . Mark this line in the SRE
and select Edit .
Since this rule is an out-of-box rule, you receive a warning when you open the rule. You should not make any
changes to out-of-box rules, so you are asked what your intentions are. In this case, you only want to view the
rule. Select No .
A Synchronization Rule has four configuration sections: Description, Scoping filter, Join rules, and
Transformations.
Description
The first section provides basic information such as a name and description.
You also find information about which connected system this rule is related to, which object type in the connected
system it applies to, and the metaverse object type. The metaverse object type is always person regardless when
the source object type is a user, iNetOrgPerson, or contact. The metaverse object type should never change so it is
created as a generic type. The Link Type can be set to Join, StickyJoin, or Provision. This setting works together
with the Join Rules section and is covered later.
You can also see that this sync rule is used for password sync. If a user is in scope for this sync rule, the password
is synchronized from on-premises to cloud (assuming you have enabled the password sync feature).
Scoping filter
The Scoping Filter section is used to configure when a Synchronization Rule should apply. Since the name of the
Synchronization Rule you are looking at indicates it should only be applied for enabled users, the scope is
configured so the AD attribute userAccountControl must not have the bit 2 set. When the sync engine finds a
user in AD, it applies this sync rule when userAccountControl is set to the decimal value 512 (enabled normal
user). It does not apply the rule when the user has userAccountControl set to 514 (disabled normal user).
The scoping filter has Groups and Clauses that can be nested. All clauses inside a group must be satisfied for a
Synchronization Rule to apply. When multiple groups are defined, then at least one group must be satisfied for
the rule to apply. That is, a logical OR is evaluated between groups and a logical AND is evaluated inside a group.
An example of this configuration can be found in the outbound Synchronization Rule Out to AAD – Group Join .
There are several synchronization filter groups, for example one for security groups ( securityEnabled EQUAL True )
and one for distribution groups ( securityEnabled EQUAL False ).
This rule is used to define which Groups should be provisioned to Azure AD. Distribution Groups must be mail
enabled to be synchronized with Azure AD, but for security groups an email is not required.
Join rules
The third section is used to configure how objects in the connector space relate to objects in the metaverse. The
rule you have looked at earlier does not have any configuration for Join Rules, so instead you are going to look at
In from AD – User Join .
The content of the join rule depends on the matching option selected in the installation wizard. For an inbound
rule, the evaluation starts with an object in the source connector space and each group in the join rules is
evaluated in sequence. If a source object is evaluated to match exactly one object in the metaverse using one of
the join rules, the objects are joined. If all rules have been evaluated and there is no match, then the Link Type on
the description page is used. If this configuration is set to Provision , then a new object is created in the target, the
metaverse, if at least one attribute in the join criteria is present (has a value). To provision a new object to the
metaverse is also known as to project an object to the metaverse.
The join rules are only evaluated once. When a connector space object and a metaverse object are joined, they
remain joined as long as the scope of the Synchronization Rule is still satisfied.
When evaluating Synchronization Rules, only one Synchronization Rule with join rules defined must be in scope.
If multiple Synchronization Rules with join rules are found for one object, an error is thrown. For this reason, the
best practice is to have only one Synchronization Rule with join defined when multiple Synchronization Rules are
in scope for an object. In the out-of-box configuration for Azure AD Connect sync, these rules can be found by
looking at the name and find those with the word Join at the end of the name. A Synchronization Rule without
any join rules defined applies the attribute flows when another Synchronization Rule joined the objects together
or provisioned a new object in the target.
If you look at the picture above, you can see that the rule is trying to join objectSID with
msExchMasterAccountSid (Exchange) and msRTCSIP-OriginatorSid (Lync), which is what we expect in an
account-resource forest topology. You find the same rule on all forests. The assumption is that every forest could
be either an account or resource forest. This configuration also works if you have accounts that live in a single
forest and do not have to be joined.
Transformations
The transformation section defines all attribute flows that apply to the target object when the objects are joined
and the scope filter is satisfied. Going back to the In from AD – User AccountEnabled Synchronization Rule,
you find the following transformations:
To put this configuration in context, in an Account-Resource forest deployment, it is expected to find an enabled
account in the account forest and a disabled account in the resource forest with Exchange and Lync settings. The
Synchronization Rule you are looking at contains the attributes required for sign-in and these attributes should
flow from the forest where there is an enabled account. All these attribute flows are put together in one
Synchronization Rule.
A transformation can have different types: Constant, Direct, and Expression.
A constant flow always flows a hardcoded value. In the case above, it always sets the value True in the
metaverse attribute named accountEnabled .
A direct flow always flows the value of the attribute in the source to the target attribute as-is.
The third flow type is Expression and it allows for more advanced configurations.
The expression language is VBA (Visual Basic for Applications), so people with experience of Microsoft Office or
VBScript will recognize the format. Attributes are enclosed in square brackets, [attributeName]. Attribute names
and function names are case-sensitive, but the Synchronization Rules Editor evaluates the expressions and
provide a warning if the expression is not valid. All expressions are expressed on a single line with nested
functions. To show the power of the configuration language, here is the flow for pwdLastSet, but with additional
comments inserted:
// If-then-else
IIF(
// (The evaluation for IIF) Is the attribute pwdLastSet present in AD?
IsPresent([pwdLastSet]),
// (The True part of IIF) If it is, then from right to left, convert the AD time format to a .NET datetime,
change it to the time format used by Azure AD, and finally convert it to a string.
CStr(FormatDateTime(DateFromNum([pwdLastSet]),"yyyyMMddHHmmss.0Z")),
// (The False part of IIF) Nothing to contribute
NULL
)
See Understanding Declarative Provisioning Expressions for more information on the expression language for
attribute flows.
Precedence
You have now looked at some individual Synchronization Rules, but the rules work together in the configuration.
In some cases, an attribute value is contributed from multiple synchronization rules to the same target attribute.
In this case, attribute precedence is used to determine which attribute wins. As an example, look at the attribute
sourceAnchor. This attribute is an important attribute to be able to sign in to Azure AD. You can find an attribute
flow for this attribute in two different Synchronization Rules, In from AD – User AccountEnabled and In from
AD – User Common . Due to Synchronization Rule precedence, the sourceAnchor attribute is contributed from
the forest with an enabled account first when there are several objects joined to the metaverse object. If there are
no enabled accounts, then the sync engine uses the catch-all Synchronization Rule In from AD – User
Common . This configuration ensures that even for accounts that are disabled, there is still a sourceAnchor.
The precedence for Synchronization Rules is set in groups by the installation wizard. All rules in a group have the
same name, but they are connected to different connected directories. The installation wizard gives the rule In
from AD – User Join highest precedence and it iterates over all connected AD directories. It then continues with
the next groups of rules in a predefined order. Inside a group, the rules are added in the order the Connectors
were added in the wizard. If another Connector is added through the wizard, the Synchronization Rules are
reordered and the new Connector’s rules are inserted last in each group.
Putting it all together
We now know enough about Synchronization Rules to be able to understand how the configuration works with
the different Synchronization Rules. If you look at a user and the attributes that are contributed to the metaverse,
the rules are applied in the following order:
NAME C O M M EN T
In from AD – User Join Rule for joining connector space objects with metaverse.
In from AD – UserAccount Enabled Attributes required for sign-in to Azure AD and Office 365.
We want these attributes from the enabled account.
NAME C O M M EN T
In from AD – User Common from Exchange Attributes found in the Global Address List. We assume the
data quality is best in the forest where we have found the
user’s mailbox.
In from AD – User Common Attributes found in the Global Address List. In case we didn’t
find a mailbox, any other joined object can contribute the
attribute value.
In from AD – User Exchange Only exists if Exchange has been detected. It flows all
infrastructure Exchange attributes.
In from AD – User Lync Only exists if Lync has been detected. It flows all infrastructure
Lync attributes.
Next steps
Continue reading how the out-of-box configuration works in Understanding Users and Contacts
configuration.
Over view topics
Azure AD Connect sync: Understanding Users,
Groups, and Contacts
There are several different reasons why you would have multiple Active Directory forests and there are several
different deployment topologies. Common models include an account-resource deployment and GAL sync’ed
forests after a merger & acquisition. But even if there are pure models, hybrid models are common as well. The
default configuration in Azure AD Connect sync does not assume any particular model but depending on how
user matching was selected in the installation guide, different behaviors can be observed.
In this topic, we will go through how the default configuration behaves in certain topologies. We will go through
the configuration and the Synchronization Rules Editor can be used to look at the configuration.
There are a few general rules the configuration assumes:
Regardless of which order we import from the source Active Directories, the end result should always be the
same.
An active account will always contribute sign-in information, including userPrincipalName and
sourceAnchor .
A disabled account will contribute userPrincipalName and sourceAnchor, unless it is a linked mailbox, if there is
no active account to be found.
An account with a linked mailbox will never be used for userPrincipalName and sourceAnchor. It is assumed
that an active account will be found later.
A contact object might be provisioned to Azure AD as a contact or as a user. You don’t really know until all
source Active Directory forests have been processed.
Groups
Important points to be aware of when synchronizing groups from Active Directory to Azure AD:
Azure AD Connect excludes built-in security groups from directory synchronization.
Azure AD Connect does not support synchronizing Primary Group memberships to Azure AD.
Azure AD Connect does not support synchronizing Dynamic Distribution Group memberships to Azure AD.
To synchronize an Active Directory group to Azure AD as a mail-enabled group:
If the group's proxyAddress attribute is empty, its mail attribute must have a value
If the group's proxyAddress attribute is non-empty, it must contain at least one SMTP proxy address
value. Here are some examples:
An Active Directory group whose proxyAddress attribute has value
{"X500:/0=contoso.com/ou=users/cn=testgroup"} will not be mail-enabled in Azure AD. It
does not have an SMTP address.
An Active Directory group whose proxyAddress attribute has values
{"X500:/0=contoso.com/ou=users/cn=testgroup","SMTP:johndoe@contoso.com"} will be
mail-enabled in Azure AD.
An Active Directory group whose proxyAddress attribute has values
{"X500:/0=contoso.com/ou=users/cn=testgroup", "smtp:johndoe@contoso.com"} will also be
mail-enabled in Azure AD.
Contacts
Having contacts representing a user in a different forest is common after a merger & acquisition where a
GALSync solution is bridging two or more Exchange forests. The contact object is always joining from the
connector space to the metaverse using the mail attribute. If there is already a contact object or user object with
the same mail address, the objects are joined together. This is configured in the rule In from AD – Contact Join .
There is also a rule named In from AD – Contact Common with an attribute flow to the metaverse attribute
sourceObjectType with the constant Contact . This rule has very low precedence so if any user object is joined
to the same metaverse object, then the rule In from AD – User Common will contribute the value User to this
attribute. With this rule, this attribute will have the value Contact if no user has been joined and the value User if at
least one user has been found.
For provisioning an object to Azure AD, the outbound rule Out to AAD – Contact Join will create a contact
object if the metaverse attribute sourceObjectType is set to Contact . If this attribute is set to User , then the rule
Out to AAD – User Join will create a user object instead. It is possible that an object is promoted from Contact
to User when more source Active Directories are imported and synchronized.
For example, in a GALSync topology we will find contact objects for everyone in the second forest when we
import the first forest. This will stage new contact objects in the AAD Connector. When we later import and
synchronize the second forest, we will find the real users and join them to the existing metaverse objects. We will
then delete the contact object in AAD and create a new user object instead.
If you have a topology where users are represented as contacts, make sure you select to match users on the mail
attribute in the installation guide. If you select another option, then you will have an order-dependent
configuration. Contact objects will always join on the mail attribute, but user objects will only join on the mail
attribute if this option was selected in the installation guide. You could then end up with two different objects in
the metaverse with the same mail attribute if the contact object was imported before the user object. During
export to Azure AD, an error will be thrown. This behavior is by design and would indicate bad data or that the
topology was not correctly identified during the installation.
Disabled accounts
Disabled accounts are synchronized as well to Azure AD. Disabled accounts are common to represent resources in
Exchange, for example conference rooms. The exception is users with a linked mailbox; as previously mentioned,
these will never provision an account to Azure AD.
The assumption is that if a disabled user account is found, then we will not find another active account later and
the object is provisioned to Azure AD with the userPrincipalName and sourceAnchor found. In case another active
account will join to the same metaverse object, then its userPrincipalName and sourceAnchor will be used.
Changing sourceAnchor
When an object has been exported to Azure AD then it is not allowed to change the sourceAnchor anymore. When
the object has been exported the metaverse attribute cloudSourceAnchor is set with the sourceAnchor value
accepted by Azure AD. If sourceAnchor is changed and not match cloudSourceAnchor , the rule Out to AAD –
User Join will throw the error sourceAnchor attribute has changed . In this case, the configuration or data
must be corrected so the same sourceAnchor is present in the metaverse again before the object can be
synchronized again.
Azure AD Connect sync service shadow attributes
Most attributes are represented the same way in Azure AD as they are in your on-premises Active Directory. But
some attributes have some special handling and the attribute value in Azure AD might be different than what Azure
AD Connect synchronizes.
Introducing shadow attributes

Some attributes have two representations in Azure AD. Both the on-premises value and a calculated value are
stored. These extra attributes are called shadow attributes. The two most common attributes where you see this
behavior are userPrincipalName and proxyAddress . The change in attribute values happens when there are
values in these attributes representing non-verified domains. But the sync engine in Connect reads the value in the
shadow attribute so from its perspective, the attribute has been confirmed by Azure AD.
You cannot see the shadow attributes using the Azure portal or with PowerShell. But understanding the concept
helps you to troubleshoot certain scenarios where the attribute has different values on-premises and in the cloud.
To better understand the behavior, look at this example from Fabrikam:
They have multiple UPN suffixes in their on-premises Active Directory, but they have only verified one.
userPrincipalName
A user has the following attribute values in a non-verified domain:
AT T RIB UT E VA L UE
on-premises userPrincipalName lee.sperry@fabrikam.com
Azure AD shadowUserPrincipalName lee.sperry@fabrikam.com
Azure AD userPrincipalName lee.sperry@fabrikam.onmicrosoft.com
The userPrincipalName attribute is the value you see when using PowerShell.
Since the real on-premises attribute value is stored in Azure AD, when you verify the fabrikam.com domain, Azure
AD updates the userPrincipalName attribute with the value from the shadowUserPrincipalName. You do not have
to synchronize any changes from Azure AD Connect for these values to be updated.
proxyAddresses
The same process for only including verified domains also occurs for proxyAddresses, but with some additional
logic. The check for verified domains only happens for mailbox users. A mail-enabled user or contact represent a
user in another Exchange organization and you can add any values in proxyAddresses to these objects.
For a mailbox user, either on-premises or in Exchange Online, only values for verified domains appear. It could look
like this:
on-premises proxyAddresses SMTP:abbie.spencer@fabrikamonline.com

smtp:abbie.spencer@fabrikam.com
smtp:abbie@fabrikamonline.com
Exchange Online proxyAddresses SMTP:abbie.spencer@fabrikamonline.com

smtp:abbie@fabrikamonline.com
SIP:abbie.spencer@fabrikamonline.com
In this case smtp:abbie.spencer@fabrikam.com was removed since that domain has not been verified. But
Exchange also added SIP:abbie.spencer@fabrikamonline.com . Fabrikam has not used Lync/Skype on-
premises, but Azure AD and Exchange Online prepare for it.
This logic for proxyAddresses is referred to as ProxyCalc . ProxyCalc is invoked with every change on a user when:
The user has been assigned a service plan that includes Exchange Online even if the user was not licensed for
Exchange. For example, if the user is assigned the Office E3 SKU, but only was assigned SharePoint Online. This
is true even if your mailbox is still on-premises.
The attribute msExchRecipientTypeDetails has a value.
You make a change to proxyAddresses or userPrincipalName.
ProxyCalc might take some time to process a change on a user and is not synchronous with the Azure AD Connect
export process.
NOTE
The ProxyCalc logic has some additional behaviors for advanced scenarios not documented in this topic. This topic is
provided for you to understand the behavior and not document all internal logic.
Quarantined attribute values

Shadow attributes are also used when there are duplicate attribute values. For more information, see duplicate
attribute resiliency.
See also
Integrating your on-premises identities with Azure Active Directory.
Azure AD Connect and Azure AD Connect Health
installation roadmap
Install Azure AD Connect

IMPORTANT
Microsoft doesn't support modifying or operating Azure AD Connect sync outside of the actions that are formally
documented. Any of these actions might result in an inconsistent or unsupported state of Azure AD Connect sync. As a
result, Microsoft can't provide technical support for such deployments.
You can find the download for Azure AD Connect on Microsoft Download Center.
SO L UT IO N SC EN A RIO
Before you start - Hardware and prerequisites Steps to complete before you start to install Azure AD
Connect.
Express settings If you have a single forest AD then this is the recommended
option to use.
User sign in with the same password using password
synchronization.
Customized settings Used when you have multiple forests. Supports many on-
premises topologies.
Customize your sign-in option, such as pass-through
authentication, ADFS for federation or use a 3rd party identity
provider.
Customize synchronization features, such as filtering and
writeback.
Upgrade from DirSync Used when you have an existing DirSync server already
running.
Upgrade from Azure AD Sync or Azure AD Connect There are several different methods depending on your
preference.
After installation you should verify it is working as expected and assign licenses to the users.
Next steps to Install Azure AD Connect
TO P IC L IN K
Download Azure AD Connect Download Azure AD Connect
Install using Express settings Express installation of Azure AD Connect
Install using Customized settings Custom installation of Azure AD Connect
Upgrade from DirSync Upgrade from Azure AD sync tool (DirSync)

TO P IC L IN K
After installation Verify the installation and assign licenses
Learn more about Install Azure AD Connect

You also want to prepare for operational concerns. You might want to have a stand-by server so you easily can fail
over if there is a disaster. If you plan to make frequent configuration changes, you should plan for a staging mode
server.
TO P IC L IN K
Supported topologies Topologies for Azure AD Connect
Design concepts Azure AD Connect design concepts
Accounts used for installation More about Azure AD Connect credentials and permissions
Operational planning Azure AD Connect sync: Operational tasks and considerations
User sign-in options Azure AD Connect User sign-in options
Configure sync features

Azure AD Connect comes with several features you can optionally turn on or are enabled by default. Some features
might sometimes require more configuration in certain scenarios and topologies.
Filtering is used when you want to limit which objects are synchronized to Azure AD. By default all users, contacts,
groups, and Windows 10 computers are synchronized. You can change the filtering based on domains, OUs, or
attributes.
Password hash synchronization synchronizes the password hash in Active Directory to Azure AD. The end-user can
use the same password on-premises and in the cloud but only manage it in one location. Since it uses your on-
premises Active Directory as the authority, you can also use your own password policy.
Password writeback will allow your users to change and reset their passwords in the cloud and have your on-
premises password policy applied.
Device writeback will allow a device registered in Azure AD to be written back to on-premises Active Directory so it
can be used for Conditional Access.
The prevent accidental deletes feature is turned on by default and protects your cloud directory from numerous
deletes at the same time. By default it allows 500 deletes per run. You can change this setting depending on your
organization size.
Automatic upgrade is enabled by default for express settings installations and ensures your Azure AD Connect is
always up to date with the latest release.
Next steps to configure sync features
TO P IC L IN K
Configure filtering Azure AD Connect sync: Configure filtering

TO P IC L IN K
Password hash synchronization Password hash synchronization
Pass-through Authentication Pass-through authentication
Password writeback Getting started with password management
Device writeback Enabling device writeback in Azure AD Connect
Prevent accidental deletes Azure AD Connect sync: Prevent accidental deletes
Automatic upgrade Azure AD Connect: Automatic upgrade
Customize Azure AD Connect sync

Azure AD Connect sync comes with a default configuration that is intended to work for most customers and
topologies. But there are always situations where the default configuration does not work and must be adjusted. It
is supported to make changes as documented in this section and linked topics.
If you have not worked with a synchronization topology before you want to start to understand the basics and the
terms used as described in the technical concepts. Azure AD Connect is the evolution of MIIS2003, ILM2007, and
FIM2010. Even if some things are identical, a lot has changed as well.
The default configuration assumes there might be more than one forest in the configuration. In those topologies a
user object might be represented as a contact in another forest. The user might also have a linked mailbox in
another resource forest. The behavior of the default configuration is described in users and contacts.
The configuration model in sync is called declarative provisioning. The advanced attribute flows are using functions
to express attribute transformations. You can see and examine the entire configuration using tools which comes
with Azure AD Connect. If you need to make configuration changes, make sure you follow the best practices so it is
easier to adopt new releases.
Next steps to customize Azure AD Connect sync
TO P IC L IN K
All Azure AD Connect sync articles Azure AD Connect sync
Technical concepts Azure AD Connect sync: Technical Concepts
Understanding the default configuration Azure AD Connect sync: Understanding the default
configuration
Understanding users and contacts Azure AD Connect sync: Understanding Users and Contacts
Declarative provisioning Azure AD Connect Sync: Understanding Declarative

Provisioning Expressions
Change the default configuration Best practices for changing the default configuration
Configure federation features

Azure AD Connect provides several features that simplify federating with Azure AD using AD FS and managing
your federation trust. Azure AD Connect supports AD FS on Windows Server 2012R2 or later.
Update TLS/SSL certificate of AD FS farm even if you are not using Azure AD Connect to manage your federation
trust.
Add an AD FS server to your farm to expand the farm as required.
Repair the trust with Azure AD in a few simple clicks.
ADFS can be configured to support multiple domains. For example you might have multiple top domains you need
to use for federation.
If your ADFS server has not been configured to automatically update certificates from Azure AD or if you use a
non-ADFS solution, then you will be notified when you have to update certificates.
Next steps to configure federation features
TO P IC L IN K
All AD FS articles Azure AD Connect and federation
Configure ADFS with subdomains Multiple Domain Support for Federating with Azure AD
Manage AD FS farm AD FS management and customization with Azure AD

Connect
Manually updating federation certificates Renewing Federation Certificates for Office 365 and Azure AD
Get started with Azure AD Connect Health

To get started with Azure AD Connect Health, use the following steps:
1. Get Azure AD Premium or start a trial.
2. Download and install Azure AD Connect Health Agents on your identity servers.
3. View the Azure AD Connect Health dashboard at https://aka.ms/aadconnecthealth.
NOTE
Remember that before you see data in your Azure AD Connect Health dashboard, you need to install the Azure AD Connect
Health Agents on your targeted servers.
Download and install Azure AD Connect Health Agent

Make sure that you satisfy the requirements for Azure AD Connect Health.
Get started using Azure AD Connect Health for AD FS
Download Azure AD Connect Health Agent for AD FS.
See the installation instructions.
Get started using Azure AD Connect Health for sync
Download and install the latest version of Azure AD Connect. The Health Agent for sync will be installed
as part of the Azure AD Connect installation (version 1.0.9125.0 or higher).
Get started using Azure AD Connect Health for AD DS
Download Azure AD Connect Health Agent for AD DS.
Azure AD Connect Health portal
The Azure AD Connect Health portal shows views of alerts, performance monitoring, and usage analytics. The
https://aka.ms/aadconnecthealth URL takes you to the main blade of Azure AD Connect Health. You can think of a
blade as a window. On The main blade, you see Quick Star t , services within Azure AD Connect Health, and
additional configuration options. See the following screenshot and brief explanations that follow the screenshot.
After you deploy the agents, the health service automatically identifies the services that Azure AD Connect Health is
monitoring.
NOTE
For licensing information, see the Azure AD Connect Health FAQ or the Azure AD Pricing page.
Quick Star t : When you select this option, the Quick Star t blade opens. You can download the Azure AD
Connect Health Agent by selecting Get Tools . You can also access documentation and provide feedback.
Azure Active Director y Connect (sync) : This option shows your Azure AD Connect servers that Azure
AD Connect Health is currently monitoring. Sync errors entry will show basic sync errors of your first
onboarded sync service by categories. When you select the Sync ser vices entry, the blade that opens
shows information about your Azure AD Connect servers. Read more about the capabilities at Using Azure
AD Connect Health for sync.
Active Director y Federation Ser vices : This option shows all the AD FS services that Azure AD Connect
Health is currently monitoring. When you select an instance, the blade that opens shows information about
that service instance. This information includes an overview, properties, alerts, monitoring, and usage
analytics. Read more about the capabilities at Using Azure AD Connect Health with AD FS.
Active Director y Domain Ser vices : This option shows all the AD DS forests that Azure AD Connect
Health is currently monitoring. When you select a forest, the blade that opens shows information about that
forest. This information includes an overview of essential information, the Domain Controllers dashboard,
the Replication Status dashboard, alerts, and monitoring. Read more about the capabilities at Using Azure
AD Connect Health with AD DS.
Configure : This section includes options to turn the following on or off:
The automatic update of the Azure AD Connect Health agent to the latest version: the Azure AD
Connect Health agent is automatically updated whenever new versions are available. This option is
enabled by default.
Access to data from the Azure AD directory integrity by Microsoft only for troubleshooting purposes: if
this option is enabled, Microsoft can access the same data viewed by the user. This information can be
useful for troubleshooting and to provide the necessary assistance. This option is disabled by default
Role based access control (IAM) is the section to manage the access to Connect Health data in role base.
Next Steps
Express settings
Customized settings
Password hash synchronization|
Prerequisites for Azure AD Connect
This article describes the prerequisites and the hardware requirements for Azure Active Directory (Azure AD)
Connect.
Before you install Azure AD Connect

Before you install Azure AD Connect, there are a few things that you need.
Azure AD
You need an Azure AD tenant. You get one with an Azure free trial. You can use one of the following portals to
manage Azure AD Connect:
The Azure portal.
The Office portal.
Add and verify the domain you plan to use in Azure AD. For example, if you plan to use contoso.com for your
users, make sure this domain has been verified and you're not using only the contoso.onmicrosoft.com
default domain.
An Azure AD tenant allows, by default, 50,000 objects. When you verify your domain, the limit increases to
300,000 objects. If you need even more objects in Azure AD, open a support case to have the limit increased
even further. If you need more than 500,000 objects, you need a license, such as Office 365, Azure AD
Premium, or Enterprise Mobility + Security.
Prepare your on-premises data
Use IdFix to identify errors such as duplicates and formatting problems in your directory before you
synchronize to Azure AD and Office 365.
Review optional sync features you can enable in Azure AD, and evaluate which features you should enable.
On-premises Active Directory
The Active Directory schema version and forest functional level must be Windows Server 2003 or later. The
domain controllers can run any version as long as the schema version and forest-level requirements are met.
If you plan to use the feature password writeback, the domain controllers must be on Windows Server 2008
R2 or later.
The domain controller used by Azure AD must be writable. Using a read-only domain controller (RODC) isn't
supported, and Azure AD Connect doesn't follow any write redirects.
Using on-premises forests or domains by using "dotted" (name contains a period ".") NetBIOS names isn't
supported.
We recommend that you enable the Active Directory recycle bin.
Azure AD Connect server
The Azure AD Connect server contains critical identity data. It's important that administrative access to this
server is properly secured. Follow the guidelines in Securing privileged access.
The Azure AD Connect server must be treated as a Tier 0 component as documented in the Active Directory
administrative tier model
To read more about securing your Active Directory environment, see Best practices for securing Active Directory.
Installation prerequisites
Azure AD Connect must be installed on a domain-joined Windows Server 2012 or later.
Azure AD Connect can't be installed on Small Business Server or Windows Server Essentials before 2019
(Windows Server Essentials 2019 is supported). The server must be using Windows Server standard or
better.
The Azure AD Connect server must have a full GUI installed. Installing Azure AD Connect on Windows Server
Core isn't supported.
The Azure AD Connect server must not have PowerShell Transcription Group Policy enabled if you use the
Azure AD Connect wizard to manage Active Directory Federation Services (AD FS) configuration. You can
enable PowerShell transcription if you use the Azure AD Connect wizard to manage sync configuration.
If AD FS is being deployed:
The servers where AD FS or Web Application Proxy are installed must be Windows Server 2012 R2 or
later. Windows remote management must be enabled on these servers for remote installation.
You must configure TLS/SSL certificates. For more information, see Managing SSL/TLS protocols and
cipher suites for AD FS and Managing SSL certificates in AD FS.
You must configure name resolution.
If your global administrators have MFA enabled, the URL https://secure.aadcdn.microsoftonline-p.com must
be in the trusted sites list. You're prompted to add this site to the trusted sites list when you're prompted for
an MFA challenge and it hasn't been added before. You can use Internet Explorer to add it to your trusted
sites.
Harden your Azure AD Connect server
We recommend that you harden your Azure AD Connect server to decrease the security attack surface for this
critical component of your IT environment. Following these recommendations will help to mitigate some
security risks to your organization.
Treat Azure AD Connect the same as a domain controller and other Tier 0 resources. For more information,
see Active Directory administrative tier model.
Restrict administrative access to the Azure AD Connect server to only domain administrators or other tightly
controlled security groups.
Create a dedicated account for all personnel with privileged access. Administrators shouldn't be browsing the
web, checking their email, and doing day-to-day productivity tasks with highly privileged accounts.
Follow the guidance provided in Securing privileged access.
Deny use of NTLM authentication with the AADConnect server. Here are some ways to do this: Restricting
NTLM on the AADConnect Server and Restricting NTLM on a domain
Ensure every machine has a unique local administrator password. For more information, see Local
Administrator Password Solution (LAPS) can configure unique random passwords on each workstation and
server store them in Active Directory protected by an ACL. Only eligible authorized users can read or request
the reset of these local administrator account passwords. You can obtain the LAPS for use on workstations
and servers fromthe Microsoft Download Center. Additional guidance for operating an environment with
LAPS and privileged access workstations (PAWs) can be found in Operational standards based on clean
source principle.
Implement dedicated privileged access workstations for all personnel with privileged access to your
organization's information systems.
Follow these additional guidelines to reduce the attack surface of your Active Directory environment.
SQL Server used by Azure AD Connect
Azure AD Connect requires a SQL Server database to store identity data. By default, a SQL Server 2012
Express LocalDB (a light version of SQL Server Express) is installed. SQL Server Express has a 10-GB size limit
that enables you to manage approximately 100,000 objects. If you need to manage a higher volume of
directory objects, point the installation wizard to a different installation of SQL Server. The type of SQL
Server installation can impact the performance of Azure AD Connect.
If you use a different installation of SQL Server, these requirements apply:
Azure AD Connect supports all versions of SQL Server from 2012 (with the latest service pack) to SQL
Server 2019. Azure SQL Database isn't supported as a database.
You must use a case-insensitive SQL collation. These collations are identified with a _CI_ in their name.
Using a case-sensitive collation identified by _CS_ in their name isn't supported.
You can have only one sync engine per SQL instance. Sharing a SQL instance with FIM/MIM Sync,
DirSync, or Azure AD Sync isn't supported.
Accounts
You must have an Azure AD Global Administrator account for the Azure AD tenant you want to integrate
with. This account must be a school or organization account and can't be a Microsoft account.
If you use express settings or upgrade from DirSync, you must have an Enterprise Administrator account for
your on-premises Active Directory.
If you use the custom settings installation path, you have more options. For more information, see Custom
installation settings.
Connectivity
The Azure AD Connect server needs DNS resolution for both intranet and internet. The DNS server must
be able to resolve names both to your on-premises Active Directory and the Azure AD endpoints.
If you have firewalls on your intranet and you need to open ports between the Azure AD Connect servers
and your domain controllers, see Azure AD Connect ports for more information.
If your proxy or firewall limit which URLs can be accessed, the URLs documented in Office 365 URLs and
IP address ranges must be opened.
If you're using the Microsoft cloud in Germany or the Microsoft Azure Government cloud, see Azure
AD Connect sync service instances considerations for URLs.
Azure AD Connect (version 1.1.614.0 and after) by default uses TLS 1.2 for encrypting communication
between the sync engine and Azure AD. If TLS 1.2 isn't available on the underlying operating system,
Azure AD Connect incrementally falls back to older protocols (TLS 1.1 and TLS 1.0).
Prior to version 1.1.614.0, Azure AD Connect by default uses TLS 1.0 for encrypting communication
between the sync engine and Azure AD. To change to TLS 1.2, follow the steps in Enable TLS 1.2 for Azure
AD Connect.
If you're using an outbound proxy for connecting to the internet, the following setting in the
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config file must be
added for the installation wizard and Azure AD Connect sync to be able to connect to the internet and
Azure AD. This text must be entered at the bottom of the file. In this code, <PROXYADDRESS> represents
the actual proxy IP address or host name.
<system.net>
<defaultProxy>
<proxy
usesystemdefault="true"
proxyaddress="http://<PROXYADDRESS>:<PROXYPORT>"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>
If your proxy server requires authentication, the service account must be located in the domain. Use the
customized settings installation path to specify a custom service account. You also need a different
change to machine.config. With this change in machine.config, the installation wizard and sync engine
respond to authentication requests from the proxy server. In all installation wizard pages, excluding the
Configure page, the signed-in user's credentials are used. On the Configure page at the end of the
installation wizard, the context is switched to the service account that you created. The machine.config
section should look like this:
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy
proxyaddress="http://<PROXYADDRESS>:<PROXYPORT>"
/>
</defaultProxy>
</system.net>
If the proxy configuration is being done in an existing setup, the Microsoft Azure AD Sync ser vice
needs to be restarted once for the Azure AD Connect to read the proxy configuration and update the
behviour.
When Azure AD Connect sends a web request to Azure AD as part of directory synchronization, Azure AD
can take up to 5 minutes to respond. It's common for proxy servers to have connection idle timeout
configuration. Ensure the configuration is set to at least 6 minutes or more.
For more information, see MSDN about the default proxy element. For more information when you have
problems with connectivity, see Troubleshoot connectivity problems.
Other
Optional: Use a test user account to verify synchronization.
Component prerequisites
PowerShell and .NET Framework
Azure AD Connect depends on Microsoft PowerShell and .NET Framework 4.5.1. You need this version or a later
version installed on your server. Depending on your Windows Server version, take the following actions:
Windows Server 2012 R2
Microsoft PowerShell is installed by default. No action is required.
.NET Framework 4.5.1 and later releases are offered through Windows Update. Make sure you've
installed the latest updates to Windows Server in Control Panel.
Windows Server 2012
The latest version of Microsoft PowerShell is available in Windows Management Framework 4.0,
available on the Microsoft Download Center.
.NET Framework 4.5.1 and later releases are available on the Microsoft Download Center.
Enable TLS 1.2 for Azure AD Connect
Prior to version 1.1.614.0, Azure AD Connect by default uses TLS 1.0 for encrypting the communication between
the sync engine server and Azure AD. You can configure .NET applications to use TLS 1.2 by default on the
server. For more information about TLS 1.2, see Microsoft Security Advisory 2960358.
1. Make sure you have the .NET 4.5.1 hotfix installed for your operating system. For more information, see
Microsoft Security Advisory 2960358. You might have this hotfix or a later release installed on your
server already.
2. For all operating systems, set this registry key and restart the server.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
"SchUseStrongCrypto"=dword:00000001
3. If you also want to enable TLS 1.2 between the sync engine server and a remote SQL Server, make sure
you have the required versions installed for TLS 1.2 support for Microsoft SQL Server.
Prerequisites for federation installation and configuration

Windows Remote Management
When you use Azure AD Connect to deploy AD FS or the Web Application Proxy (WAP), check these
requirements:
If the target server is domain joined, ensure that Windows Remote Managed is enabled.
In an elevated PowerShell command window, use the command Enable-PSRemoting –force .
If the target server is a non-domain-joined WAP machine, there are a couple of additional requirements:
On the target machine (WAP machine):
Ensure the Windows Remote Management/WS-Management (WinRM) service is running via
the Services snap-in.
In an elevated PowerShell command window, use the command Enable-PSRemoting –force .
On the machine on which the wizard is running (if the target machine is non-domain joined or is an
untrusted domain):
In an elevated PowerShell command window, use the command
Set-Item.WSMan:\localhost\Client\TrustedHosts –Value <DMZServerFQDN> -Force –Concatenate .
In the server manager:
Add a DMZ WAP host to a machine pool. In the server manager, select Manage > Add
Ser vers , and then use the DNS tab.
On the Ser ver Manager All Ser vers tab, right-click the WAP server, and select
Manage As . Enter local (not domain) credentials for the WAP machine.
To validate remote PowerShell connectivity, on the Ser ver Manager All Ser vers tab,
right-click the WAP server and select Windows PowerShell . A remote PowerShell
session should open to ensure remote PowerShell sessions can be established.
TLS/SSL certificate requirements
We recommend that you use the same TLS/SSL certificate across all nodes of your AD FS farm and all Web
Application Proxy servers.
The certificate must be an X509 certificate.
You can use a self-signed certificate on federation servers in a test lab environment. For a production
environment, we recommend that you obtain the certificate from a public certificate authority.
If you're using a certificate that isn't publicly trusted, ensure that the certificate installed on each Web
Application Proxy server is trusted on both the local server and on all federation servers.
The identity of the certificate must match the federation service name (for example, sts.contoso.com).
The identity is either a subject alternative name (SAN) extension of type dNSName or, if there are no
SAN entries, the subject name is specified as a common name.
Multiple SAN entries can be present in the certificate provided one of them matches the federation
service name.
If you're planning to use Workplace Join, an additional SAN is required with the value
enterpriseregistration. followed by the user principal name (UPN) suffix of your organization, for
example, enterpriseregistration.contoso.com.
Certificates based on CryptoAPI next-generation (CNG) keys and key storage providers (KSPs) aren't
supported. As a result, you must use a certificate based on a cryptographic service provider (CSP) and not a
KSP.
Wild-card certificates are supported.
Name resolution for federation servers
Set up DNS records for the AD FS name (for example, sts.contoso.com) for both the intranet (your internal
DNS server) and the extranet (public DNS through your domain registrar). For the intranet DNS record,
ensure that you use A records and not CNAME records. Using A records is required for Windows
authentication to work correctly from your domain-joined machine.
If you're deploying more than one AD FS server or Web Application Proxy server, ensure that you've
configured your load balancer and that the DNS records for the AD FS name (for example, sts.contoso.com)
point to the load balancer.
For Windows integrated authentication to work for browser applications using Internet Explorer in your
intranet, ensure that the AD FS name (for example, sts.contoso.com) is added to the intranet zone in Internet
Explorer. This requirement can be controlled via Group Policy and deployed to all your domain-joined
computers.
Azure AD Connect supporting components

Azure AD Connect installs the following components on the server where Azure AD Connect is installed. This list
is for a basic Express installation. If you choose to use a different SQL Server on the Install synchronization
ser vices page, SQL Express LocalDB isn't installed locally.
Azure AD Connect Health
Microsoft SQL Server 2012 Command Line Utilities
Microsoft SQL Server 2012 Express LocalDB
Microsoft SQL Server 2012 Native Client
Microsoft Visual C++ 2013 Redistribution Package
Hardware requirements for Azure AD Connect

The following table shows the minimum requirements for the Azure AD Connect sync computer.
N UM B ER O F O B JEC T S IN
A C T IVE DIREC TO RY CPU M EM O RY H A RD DRIVE SIZ E
Fewer than 10,000 1.6 GHz 4 GB 70 GB
10,000–50,000 1.6 GHz 4 GB 70 GB
50,000–100,000 1.6 GHz 16 GB 100 GB
For 100,000 or more

objects, the full version of
SQL Server is required
100,000–300,000 1.6 GHz 32 GB 300 GB
300,000–600,000 1.6 GHz 32 GB 450 GB
More than 600,000 1.6 GHz 32 GB 500 GB
The minimum requirements for computers running AD FS or Web Application Proxy servers are:
CPU: Dual core 1.6 GHz or higher
Memory: 2 GB or higher
Azure VM: A2 configuration or higher
Next steps
Select which installation type to use for Azure AD
Connect
Azure AD Connect has two installation types for new installation: Express and customized. This topic helps you to
decide which option to use during installation.
Express
Express is the most common option and is used by about 90% of all new installations. It was designed to provide a
configuration that works for the most common customer scenarios.
It assumes:
You have a single Active Directory forest on-premises.
You have an enterprise administrator account you can use for the installation.
You have less than 100,000 objects in your on-premises Active Directory.
You get:
Password hash synchronization from on-premises to Azure AD for single sign-on.
A configuration that synchronizes users, groups, contacts, and Windows 10 computers.
Synchronization of all eligible objects in all domains and all OUs.
Automatic upgrade is enabled to make sure you always use the latest available version.
Options where you can still use Express:
If you do not want to synchronize all OUs, you can still use Express and on the last page, unselect Star t the
synchronization process...*. Then run the installation wizard again and change the OUs in configuration
options and enable scheduled sync.
You want to enable one of the features in Azure AD Premium, such as Password writeback. First go through
express to get the initial installation completed. Then run the installation wizard again and change the
configuration options.
Custom
The customized path allows many more options than express. It should be used in all cases where the configuration
described in previous section for express is not representative for your organization.
Use when:
You do not have access to an enterprise admin account in Active Directory.
You have more than one forest or you plan to synchronize more than one forest in the future.
You have domains in your forest not reachable from the Connect server.
You plan to use federation or pass-through authentication for user sign-in.
You have more than 100,000 objects and need to use a full SQL Server.
You plan to use group-based filtering and not only domain or OU-based filtering.
Upgrade from DirSync

If you are currently using DirSync, then follow the steps in Upgrade from DirSync to upgrade your existing
configuration. There are two different upgrade options:
In-place upgrade to install Connect on the same server.
Parallel deployment to install Connect on a new server while the existing DirSync server is still operational.
Upgrade from Azure AD Sync

If you are currently using Azure AD Sync, then you can follow the same steps as when you upgrade from one
Connect version to a newer. There are two different upgrade options:
In-place upgrade to install Connect on the same server.
Swing-migration to install Connect on a new server while the existing Azure AD Sync server is still operational.
Migrate from FIM2010 or MIM2016

If you are currently using Forefront Identity Manager 2010 or Microsoft Identity Manager 2016 with the Azure AD
Connector, then your only option is a migration. Follow the steps described in swing-migration. In the steps, replace
any mention of Azure AD Sync with FIM2010/MIM2016.
Next steps
Depending on the option you have selected to use, use the table of content to the left to find your article with the
detailed steps.
Getting started with Azure AD Connect using
express settings
Azure AD Connect Express Settings is used when you have a single-forest topology and password hash
synchronization for authentication. Express Settings is the default option and is used for the most commonly
deployed scenario. You are only a few short clicks away to extend your on-premises directory to the cloud.
Before you start installing Azure AD Connect, make sure to download Azure AD Connect and complete the pre-
requisite steps in Azure AD Connect: Hardware and prerequisites.
If express settings does not match your topology, see related documentation for other scenarios.
Express installation of Azure AD Connect

You can see these steps in action in the videos section.
1. Sign in as a local administrator to the server you wish to install Azure AD Connect on. You should do this on
the server you wish to be the sync server.
4. On the Express settings screen, click Use express settings .
5. On the Connect to Azure AD screen, enter the username and password of a global administrator for your
Azure AD. Click Next .
If you receive an error and have problems with connectivity, then see Troubleshoot connectivity problems.
6. On the Connect to AD DS screen, enter the username and password for an enterprise admin account. You can
enter the domain part in either NetBios or FQDN format, that is, FABRIKAM\administrator or
fabrikam.com\administrator. Click Next .
7. The Azure AD sign-in configuration page only shows if you did not complete verify your domains in the
prerequisites.
If you see this page, then review every domain marked Not Added and Not Verified . Make sure those
domains you use have been verified in Azure AD. Click the Refresh symbol when you have verified your
domains.
Optionally on the Ready to configure page, you can unselect the Star t the synchronization
process as soon as configuration completes checkbox. You should unselect this checkbox if you
want to do additional configuration, such as filtering. If you unselect this option, the wizard configures
sync but leaves the scheduler disabled. It does not run until you enable it manually by rerunning the
Leaving the Star t the synchronization process as soon as configuration completes checkbox
enabled will immediately trigger a full synchronization to Azure AD of all users, groups, and contacts.
If you have Exchange in your on-premises Active Directory, then you also have an option to enable
Exchange Hybrid deployment . Enable this option if you plan to have Exchange mailboxes both in
the cloud and on-premises at the same time.
10. After the installation has completed, sign off and sign in again before you use Synchronization Service
Videos
For a video on using the express installation, see:
Next steps
Now that you have Azure AD Connect installed you can verify the installation and assign licenses.
Learn more about these features, which were enabled with the installation: Automatic upgrade, Prevent
accidental deletes, and Azure AD Connect Health.
Learn more about these common topics: scheduler and how to trigger sync.
Related documentation
TO P IC L IN K
Azure AD Connect overview Integrate your on-premises directories with Azure Active
Directory
Install using customized settings Custom installation of Azure AD Connect

TO P IC L IN K
Accounts used for installation More about Azure AD Connect credentials and permissions
Custom installation of Azure AD Connect
Azure AD Connect Custom settings is used when you want more options for the installation. It is used if you
have multiple forests or if you want to configure optional features not covered in the express installation. It is
used in all cases where the express installation option does not satisfy your deployment or topology.
Before you start installing Azure AD Connect, make sure to download Azure AD Connect and complete the
pre-requisite steps in Azure AD Connect: Hardware and prerequisites. Also make sure you have required
accounts available as described in Azure AD Connect accounts and permissions.
If customized settings does not match your topology, for example to upgrade DirSync, see related
documentation for other scenarios.
Custom settings installation of Azure AD Connect

Express Settings
On this page, click Customize to start a customized settings installation.
Install required components
When you install the synchronization services, you can leave the optional configuration section unchecked
and Azure AD Connect sets up everything automatically. It sets up a SQL Server 2012 Express LocalDB
instance, create the appropriate groups, and assign permissions. If you wish to change the defaults, you can
use the following table to understand the optional configuration options that are available.
O P T IO N A L C O N F IGURAT IO N DESC RIP T IO N
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 ser vice 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.
User sign-in
After installing the required components, you are asked to select your users single sign-on method. The
following table provides a brief description of the available options. For a full description of the sign-in
methods, see User sign-in.
SIN GL E SIGN O N O P T IO N DESC RIP T IO N
Password Hash Sync Users are able to sign in to Microsoft cloud services, such
as Office 365, using the same password they use in their
on-premises network. The users passwords are
synchronized to Azure AD as a password hash and
authentication occurs in the cloud. See Password hash
synchronization for more information.
Pass-through Authentication Users are able to sign in to Microsoft cloud services, such
on-premises network. The users password is passed
through to the on-premises Active Directory domain
controller to be validated.
Federation with AD FS Users are able to sign in to Microsoft cloud services, such
on-premises network. The users are redirected to their on-
premises AD FS instance to sign in and authentication
occurs on-premises.
Federation with PingFederate Users are able to sign in to Microsoft cloud services, such
on-premises network. The users are redirected to their on-
premises PingFederate instance to sign in and
authentication occurs on-premises.
Do not configure No user sign-in feature is installed and configured. Choose

this option if you already have a 3rd party federation
server or another existing solution in place.
SIN GL E SIGN O N O P T IO N DESC RIP T IO N
Enable Single Sign on This options is available with both password hash sync and
pass-through authentication and provides a single sign on
experience for desktop users on the corporate network. See
Single sign-on for more information.
Note for AD FS customers this option is not available
because AD FS already offers the same level of single sign
on.
Connect to Azure AD
On the Connect to Azure AD screen, enter a global admin account and password. If you selected Federation
with AD FS on the previous page, do not sign in with an account in a domain you plan to enable for
federation. A recommendation is to use an account in the default onmicrosoft.com domain, which comes
with your Azure AD tenant.
This account is only used to create a service account in Azure AD and is not used after the wizard has
completed.
If your global admin account has MFA enabled, then you need to provide the password again in the sign-in
popup and complete the MFA challenge. The challenge could be a providing a verification code or a phone call.
The global admin account can also have Privileged Identity Management enabled.
If you receive an error and have problems with connectivity, then see Troubleshoot connectivity problems.
Pages under the Sync section

Connect your directories
To connect to your Active Directory Domain Service, Azure AD Connect needs the forest name and credentials
of an account with sufficient permissions.
After entering the forest name and clicking Add Director y , a pop-up dialog appears and prompts you with
the following options:
O P T IO N DESC RIP T IO N
Create new account Select this option if you want Azure AD Connect wizard to
create the AD DS account required by Azure AD Connect
for connecting to the AD forest during directory
synchronization. When this option is selected, enter the
username and password for an enterprise admin account.
The enterprise admin account provided will be used by
Azure AD Connect wizard to create the required AD DS
account. You can enter the domain part in either NetBios or
FQDN format, that is, FABRIKAM\administrator or
fabrikam.com\administrator.
Use existing account Select this option if you want to provide an existing AD DS
account to be used Azure AD Connect for connecting to
the AD forest during directory synchronization. You can
enter the domain part in either NetBios or FQDN format,
that is, FABRIKAM\syncuser or fabrikam.com\syncuser. This
account can be a regular user account because it only
needs the default read permissions. However, depending on
your scenario, you may need more permissions. For more
information, see Azure AD Connect Accounts and
permissions.
Enterprise Admin and Domain Admin accounts not supported
As of build 1.4.18.0 it is no longer supported to use an Enterprise Admin or a Domain Admin account as the
AD DS Connector account. If you attempt to enter an account that is an enterprise admin or domain admin
when specifying use existing account , you will receive the following error:
“Using an Enterprise or Domain administrator account for your AD forest account is not allowed.
Let Azure AD Connect create the account for you or specify a synchronization account with the
correct permissions. <Learn More>”
Azure AD sign-in configuration
This page allows you to review the UPN domains present in on-premises AD DS and which have been verified
in Azure AD. This page also allows you to configure the attribute to use for the userPrincipalName.
Review every domain marked Not Added and Not Verified . Make sure those domains you use have been
verified in Azure AD. Click the Refresh symbol when you have verified your domains. For more information,
see add and verify the domain
UserPrincipalName - The attribute userPrincipalName is the attribute users use when they sign in to Azure
AD and Office 365. The domains used, also known as the UPN-suffix, should be verified in Azure AD before
the users are synchronized. Microsoft recommends to keep the default attribute userPrincipalName. If this
attribute is non-routable and cannot be verified, then it is possible to select another attribute. You can for
example select email as the attribute holding the sign-in ID. Using another attribute than userPrincipalName is
known as Alternate ID . The Alternate ID attribute value must follow the RFC822 standard. An Alternate ID
can be used with password hash sync, pass-through authentication, and federation. The attribute must not be
defined in Active Directory as multi-valued, even if it only has a single value. For more information on the
Alternate ID, see the Frequently asked questions topic.
NOTE
When you enable Pass-through Authentication you must have at least one verified domain in order to continue
through the wizard.
WARNING
Using an Alternate ID is not compatible with all Office 365 workloads. For more information, refer to Configuring
Alternate Login ID.
Domain and OU filtering

By default all domains and OUs are synchronized. If there are some domains or OUs you do not want to
synchronize to Azure AD, you can unselect these domains and OUs.
This page in the wizard is configuring domain-based and OU-based filtering. If you plan to make changes,
then see domain-based filtering and ou-based filtering before you make these changes. Some OUs are
essential for the functionality and should not be unselected.
If you use OU-based filtering with Azure AD Connect version before 1.1.524.0, new OUs added later are
synchronized by default. If you want the behavior that new OUs should not be synchronized, then you can
configure it after the wizard has completed with ou-based filtering. For Azure AD Connect version 1.1.524.0 or
after, you can indicate whether you want new OUs to be synchronized or not.
If you plan to use group-based filtering, then make sure the OU with the group is included and not filtered
with OU-filtering. OU filtering is evaluated before group-based filtering.
It is also possible that some domains are not reachable due to firewall restrictions. These domains are
unselected by default and have a warning.
If you see this warning, make sure that these domains are indeed unreachable and the warning is expected.
Uniquely identifying your users
Select how users should be identified in your on-premises directories
The Matching across forests feature allows you to define how users from your AD DS forests are represented
in Azure AD. A user might either be represented only once across all forests or have a combination of enabled
and disabled accounts. The user might also be represented as a contact in some forests.
SET T IN G DESC RIP T IO N
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- This option joins an enabled user in an account forest with
OriginatorSid 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: Only attributes that can already be found in
the metaverse are available for this option.".
Select how users should be identified with Azure AD - Source Anchor

The attribute sourceAnchor is an attribute that is immutable during the lifetime of a user object. It is the
primary key linking the on-premises user with the user in Azure AD.
Let Azure manage the source anchor for me Select this option if you want Azure AD to pick the attribute
for you. If you select this option, Azure AD Connect wizard
applies the sourceAnchor attribute selection logic described
in article section Azure AD Connect: Design concepts -
Using ms-DS-ConsistencyGuid as sourceAnchor. The wizard
informs you which attribute has been picked as the Source
Anchor attribute after Custom installation completes.
A specific attribute Select this option if you wish to specify an existing AD

attribute as the sourceAnchor attribute.
Since the attribute cannot be changed, you must plan for a good attribute to use. A good candidate is
objectGUID. This attribute is not changed, unless the user account is moved between forests/domains. Avoid
attributes that would change when a person marries or change assignments. You cannot use attributes with an
@-sign, so email and userPrincipalName cannot be used. The attribute is also case-sensitive so when you
move an object between forests, make sure to preserve the upper/lower case. Binary attributes are base64-
encoded, but other attribute types remain in its unencoded state. In federation scenarios and some Azure AD
interfaces, this attribute is also known as immutableID. More information about the source anchor can be
found in the design concepts.
Sync filtering based on groups
The filtering on groups feature allows you to sync only a small subset of objects for a pilot. To use this feature,
create a group for this purpose in your on-premises Active Directory. Then add users and groups that should
be synchronized to Azure AD as direct members. You can later add and remove users to this group to maintain
the list of objects that should be present in Azure AD. All objects you want to synchronize must be a direct
member of the group. Users, groups, contacts, and computers/devices must all be direct members. Nested
group membership is not resolved. When you add a group as a member, only the group itself is added and
not its members.
WARNING
This feature is only intended to support a pilot deployment. Do not use it in a full-blown production deployment.
In a full-blown production deployment, it is going to be hard to maintain a single group with all objects to
synchronize. Instead you should use one of the methods in Configure filtering.
Optional Features
This screen allows you to select the optional features for your specific scenarios.
WARNING
Azure AD Connect versions 1.0.8641.0 and older rely on the Azure Access Control service for password writeback.
This service will be retired on November 7th 2018 . If you are using any of these versions of Azure AD Connect and
have enabled password writeback, users may lose the ability to change or reset their passwords once the service is
retired. Password writeback with these versions of Azure AD Connect will not be supported.
For more information on the Azure Access Control service see How to: Migrate from the Azure Access Control service
To download the latest version of Azure AD Connect click here.
WARNING
If you currently have DirSync or Azure AD Sync active, do not activate any of the writeback features in Azure AD
Connect.
O P T IO N A L F EAT URES DESC RIP T IO N

O P T IO N A L F EAT URES DESC RIP T IO N
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. For more
information see Azure AD Connect group writeback
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.
Azure AD app and attribute filtering

If you want to limit which attributes to synchronize to Azure AD, then start by selecting which services you are
using. If you make configuration changes on this page, a new service has to be selected explicitly by rerunning
the installation wizard.
Based on the services selected in the previous step, this page shows all attributes that are synchronized. This
list is a combination of all object types being synchronized. If there are some particular attributes you need to
not synchronize, you can unselect those attributes.
WARNING
Removing attributes can impact functionality. For best practices and recommendations, see attributes synchronized.
Directory Extension attribute sync
You can extend the schema in Azure AD with custom attributes added by your organization or other attributes
in Active Directory. To use this feature, select Director y Extension attribute sync on the Optional
Features page. You can select more attributes to sync on this page.
NOTE
The Available attributes box is case sensitive.
For more information, see Directory extensions.

Enabling Single sign on (SSO )
Configuring single sign-on for use with Password Synchronization or Pass-through authentication is a simple
process that you only need to complete once for each forest that is being synchronized to Azure AD.
Configuration involves two steps as follows:
1. Create the necessary computer account in your on-premises Active Directory.
2. Configure the intranet zone of the client machines to support single sign on.
Create the computer account in Active Directory
For each forest that has been added in Azure AD Connect, you will need to supply Domain Administrator
credentials so that the computer account can be created in each forest. The credentials are only used to create
the account and are not stored or used for any other operation. Simply add the credentials on the Enable
Single sign on page of the Azure AD Connect wizard as shown:
NOTE
You can skip a particular forest if you do not wish to use Single sign on with that forest.
Configure the Intranet Zone for client machines

To ensure that the client sign-ins automatically in the intranet zone you need to ensure that the URL is part of
the intranet zone. This ensures that the domain joined computer automatically sends a Kerberos ticket to
Azure AD when it is connected to the corporate network. On a computer that has the Group Policy
management tools.
1. Open the Group Policy Management tools
2. Edit the Group policy that will be applied to all users. For example, the Default Domain Policy.
3. Navigate to User Configuration\Administrative Templates\Windows Components\Internet
Explorer\Internet Control Panel\Security Page and select Site to Zone Assignment List per the
image below.
4. Enable the policy, and enter a value name of https://autologon.microsoftazuread-sso.com and value of
1 in the dialog box.
5. It should look similar to the following:

6. Click Ok twice.
Configuring federation with AD FS

Configuring AD FS with Azure AD Connect is simple and only requires a few clicks. The following is required
before the configuration.
A Windows Server 2012 R2 or later server for the federation server with remote management enabled
A Windows Server 2012 R2 or later server for the Web Application Proxy server with remote management
enabled
A TLS/SSL certificate for the federation service name you intend to use (for example sts.contoso.com)
NOTE
You can update a TLS/SSL certificate for your AD FS farm using Azure AD Connect even if you do not use it to manage
your federation trust.
AD FS configuration pre -requisites

To configure your AD FS farm using Azure AD Connect, ensure WinRM is enabled on the remote servers.
Make sure you have completed the other tasks in federation prerequisites. In addition, go through the ports
requirement listed in Table 3 - Azure AD Connect and Federation Servers/WAP.
Create a new AD FS farm or use an existing AD FS farm
You can use an existing AD FS farm or you can choose to create a new AD FS farm. If you choose to create a
new one, you are required to provide the TLS/SSL certificate. If the TLS/SSL certificate is protected by a
password, you are prompted for the password.
If you choose to use an existing AD FS farm, you are taken directly to the configuring the trust relationship
between AD FS and Azure AD screen.
NOTE
Azure AD Connect can be used to manage only one AD FS farm. If you have existing federation trust with Azure AD
configured on the selected AD FS farm, the trust will be re-created again from scratch by Azure AD Connect.
Specify the AD FS servers

Enter the servers that you want to install AD FS on. You can add one or more servers based on your capacity
planning needs. Join all AD FS servers (not required for the WAP servers) to Active Directory before you
perform this configuration. Microsoft recommends installing a single AD FS server for test and pilot
deployments. Then add and deploy more servers to meet your scaling needs by running Azure AD Connect
again after initial configuration.
NOTE
Ensure that all your servers are joined to an AD domain before you do this configuration.
Specify the Web Application Proxy servers
Enter the servers that you want as your Web Application proxy servers. The web application proxy server is
deployed in your DMZ (extranet facing) and supports authentication requests from the extranet. You can add
one or more servers based on your capacity planning needs. Microsoft recommends installing a single Web
application proxy server for test and pilot deployments. Then add and deploy more servers to meet your
scaling needs by running Azure AD Connect again after initial configuration. We recommend having an
equivalent number of proxy servers to satisfy authentication from the intranet.
NOTE
If the account you use is not a local admin on the WAP servers, then you are prompted for admin credentials.
Ensure that there is HTTP/HTTPS connectivity between the Azure AD Connect server and the Web Application Proxy
server before you run this step.
Ensure that there is HTTP/HTTPS connectivity between the Web Application Server and the AD FS server to allow
authentication requests to flow through.
You are prompted to enter credentials so that the web application server can establish a secure connection to
the AD FS server. These credentials need to be a local administrator on the AD FS server.
Specify the service account for the AD FS service

The AD FS service requires a domain service account to authenticate users and lookup user information in
Active Directory. It can support two types of service accounts:
Group Managed Ser vice Account - Introduced in Active Directory Domain Services with Windows
Server 2012. This type of account provides services, such as AD FS, a single account without needing to
update the account password regularly. Use this option if you already have Windows Server 2012 domain
controllers in the domain that your AD FS servers belong to.
Domain User Account - This type of account requires you to provide a password and regularly update
the password when the password changes or expires. Use this option only when you do not have Windows
Server 2012 domain controllers in the domain that your AD FS servers belong to.
If you selected Group Managed Service Account and this feature has never been used in Active Directory, you
are prompted for Enterprise Admin credentials. These credentials are used to initiate the key store and enable
the feature in Active Directory.
NOTE
Azure AD Connect performs a check to detect if the AD FS service is already registered as a SPN in the domain. AD DS
will not allow duplicate SPN’s to be registered at once. If a duplicate SPN is found, you will not be able to proceed
further until the SPN is removed.
Select the Azure AD domain that you wish to federate

This configuration is used to setup the federation relationship between AD FS and Azure AD. It configures AD
FS to issue security tokens to Azure AD and configures Azure AD to trust the tokens from this specific AD FS
instance. This page only allows you to configure a single domain in the initial installation. You can configure
more domains later by running Azure AD Connect again.
Verify the Azure AD domain selected for federation
When you select the domain to be federated, Azure AD Connect provides you with necessary information to
verify an unverified domain. See Add and verify the domain for how to use this information.
NOTE
AD Connect tries to verify the domain during the configure stage. If you continue to configure without adding the
necessary DNS records, the wizard is not able to complete the configuration.
Configuring federation with PingFederate

Configuring PingFederate with Azure AD Connect is simple and only requires a few clicks. However, the
following prerequisites are required.
PingFederate 8.4 or higher. For more information see PingFederate Integration with Azure Active Directory
and Office 365
A TLS/SSL certificate for the federation service name you intend to use (for example sts.contoso.com)
Verify the domain
After selecting Federation with PingFederate, you will be asked to verify the domain you want to federate.
Select the domain from the drop-down box.
Export the PingFederate settings

PingFederate must be configured as the federation server for each federated Azure domain. Click the Export
Settings button and share this information with your PingFederate administrator. The federation server
administrator will update the configuration, then provide the PingFederate server URL and port number so
Azure AD Connect can verify the metadata settings.
Contact your PingFederate administrator to resolve any validation issues. The following is an example of a
PingFederate server that does not have a valid trust relationship with Azure:
Verify federation connectivity

Azure AD Connect will attempt to validate the authentication endpoints retrieved from the PingFederate
metadata in the previous step. Azure AD Connect will first attempt to resolve the endpoints using your local
DNS servers. Next it will attempt to resolve the endpoints using an external DNS provider. Contact your
PingFederate administrator to resolve any validation issues.
Verify federation login

Finally, you can verify the newly configured federated login flow by signing in to the federated domain. When
this succeeds, the federation with PingFederate is successfully configured.
Configure and verify pages
The configuration happens on this page.
NOTE
Before you continue installation and if you configured federation, make sure that you have configured Name resolution
for federation servers.
Staging mode
It is possible to setup a new sync server in parallel with staging mode. It is only supported to have one sync
server exporting to one directory in the cloud. But if you want to move from another server, for example one
running DirSync, then you can enable Azure AD Connect in staging mode. When enabled, the sync engine
import and synchronize data as normal, but it does not export anything to Azure AD or AD. The features
password sync and password writeback are disabled while in staging mode.
While in staging mode, it is possible to make required changes to the sync engine and review what is about to
be exported. When the configuration looks good, run the installation wizard again and disable staging mode.
Data is now exported to Azure AD from this server. Make sure to disable the other server at the same time so
only one server is actively exporting.
For more information, see Staging mode.
Verify your federation configuration
Azure AD Connect verifies the DNS settings for you when you click the Verify button.
Intranet connectivity checks
Resolve federation FQDN: Azure AD Connect checks if the federation FQDN can be resolved by DNS to
ensure connectivity. If Azure AD Connect cannot resolve the FQDN, the verification will fail. Ensure that a
DNS record is present for the federation service FQDN in order to successfully complete the verification.
DNS A record: Azure AD Connect checks if there is an A record for your federation service. In the absence
of an A record, the verification will fail. Create an A record and not CNAME record for your federation
FQDN in order to successfully complete the verification.
Extranet connectivity checks
Resolve federation FQDN: Azure AD Connect checks if the federation FQDN can be resolved by DNS to
ensure connectivity.
To validate end-to-end authentication is successful you should manually perform one or more the following
tests:
Once synchronization in complete, use the Verify federated login additional task in Azure AD Connect to
verify authentication for an on-premises user account of your choice.
Validate that you can sign in from a browser from a domain joined machine on the intranet: Connect to
https://myapps.microsoft.com and verify the sign-in with your logged in account. The built-in AD DS
administrator account is not synchronized and cannot be used for verification.
Validate that you can sign in from a device from the extranet. On a home machine or a mobile device,
connect to https://myapps.microsoft.com and supply your credentials.
Validate rich client sign-in. Connect to https://testconnectivity.microsoft.com, choose the Office 365 tab
and chose the Office 365 Single Sign-On Test .
Troubleshooting
The following section contains troubleshooting and information that you can use if you encounter an issue
installing Azure AD Connect.
“The ADSync database already contains data and cannot be overwritten”
When you custom install Azure AD Connect and select the option Use an existing SQL ser ver on the
Install required components page, you might encounter an error that states The ADSync database
already contains data and cannot be over written. Please remove the existing database and tr y
again.
This is because there is already an existing database named ADSync on the SQL instance of the SQL server,
which you specified in the above textboxes.
This typically occurs after you have uninstalled Azure AD Connect. The database will not be deleted from the
SQL Server when you uninstall.
To fix this issue, first verify that the ADSync database that was used by Azure AD Connect prior to being
uninstalled, is no longer being used.
Next, it is recommended that you backup the database prior to deleting it.
Finally, you need to delete the database. You can do this by using Microsoft SQL Ser ver Management
Studio and connect to the SQL instance. Find the ADSync database, right click on it, and select Delete from
the context menu. Then click OK button to delete it.
After you delete the ADSync database, you can click the install button, to retry installation.
Next steps
After the installation has completed, sign out and sign in again to Windows before you use Synchronization
Service Manager or Synchronization Rule Editor.
Learn more about these features, which were enabled with the installation: Prevent accidental deletes and
Azure AD Connect Health.
Import and export Azure AD Connect configuration
settings (public preview)
Azure Active Directory (Azure AD) Connect deployments vary from a single forest Express mode installation to
complex deployments that synchronize across multiple forests by using custom synchronization rules. Because of
the large number of configuration options and mechanisms, it's essential to understand what settings are in effect
and be able to quickly deploy a server with an identical configuration. This feature introduces the ability to catalog
the configuration of a given synchronization server and import the settings into a new deployment. Different
synchronization settings snapshots can be compared to easily visualize the differences between two servers, or the
same server over time.
Each time the configuration is changed from the Azure AD Connect wizard, a new time-stamped JSON settings file
is automatically exported to%ProgramData%\AADConnect . The settings file name is of the form Applied-
SynchronizationPolicy-*.JSON , where the last part of the file name is a time stamp.
IMPORTANT
Only changes made by Azure AD Connect are automatically exported. Any changes made by using PowerShell, the
Synchronization Service Manager, or the Synchronization Rules Editor must be exported on demand as needed to maintain
an up-to-date copy. Export on demand can also be used to place a copy of the settings in a secure location for disaster
recovery purposes.
Export Azure AD Connect settings

To view a summary of your configuration settings, open the Azure AD Connect tool, and select the additional task
named View or Expor t Current Configuration . A quick summary of your settings is shown along with the
ability to export the full configuration of your server.
By default, the settings are exported to %ProgramData%\AADConnect . You also can choose to save the settings
to a protected location to ensure availability if a disaster occurs. Settings are exported by using the JSON file
format and should not be hand-created or edited to ensure logical consistency. Importing a hand-created or edited
file isn't supported and might lead to unexpected results.
Import Azure AD Connect settings

To import previously exported settings:
1. Install Azure AD Connect on a new server.
2. Select the Customize option after the Welcome page.
3. Select Impor t synchronization settings . Browse for the previously exported JSON settings file.
4. Select Install .
NOTE
Override settings on this page like the use of SQL Server instead of LocalDB or the use of an existing service account instead
of a default VSA. These settings aren't imported from the configuration settings file. They are there for information and
comparison purposes.
Import installation experience

The import installation experience is intentionally kept simple with minimal inputs from the user to easily provide
reproducibility of an existing server.
Here are the only changes that can be made during the installation experience. All other changes can be made after
installation from the Azure AD Connect wizard:
Azure Active Director y credentials : The account name for the Azure Global Administrator used to configure
the original server is suggested by default. It mustbe changed if you want to synchronize information to a new
directory.
User sign-in : The sign-on options configured for your original server are selected by default and automatically
prompt for credentials or other information that's needed during configuration. In rare cases, there might be a
need to set up a server with different options to avoid changing the behavior of the active server. Otherwise,
select Next to use the same settings.
On-premises director y credentials : For each on-premises directory included in your synchronization
settings, you must provide credentials to create a synchronization account or supply a pre-created custom
synchronization account. This procedure is identical to the clean install experience with the exception that you
can't add or remove directories.
Configuration options : As with a clean install, you might choose to configure the initial settings for whether
to start automatic synchronization or enable Staging mode. The main difference is that Staging mode is
intentionally enabled by default to allow comparison of the configuration and synchronization results prior to
actively exporting the results to Azure.
NOTE
Only one synchronization server can be in the primary role and actively exporting configuration changes to Azure. All other
servers must be placed in Staging mode.
Migrate settings from an existing server

If an existing server doesn't support settings management, you can either choose to upgrade the server in-place or
migrate the settings for use on a new staging server.
Migration requires running a PowerShell script that extracts the existing settings for use in a new installation.Use
this method to catalog the settings of your existing server and then apply them to a newly installed staging
server.Comparing the settings for the original server to a newly created server will quickly visualize the changes
between the servers.As always, follow your organization's certification process to ensure no additional
configuration is required.
Migration process
To migrate the settings:
1. Start AzureADConnect.msi on the new staging server, and stop at the Welcome page of Azure AD
Connect.
2. Copy MigrateSettings.ps1 from the Microsoft Azure AD Connect\Tools directory to a location on the
existing server. An example is C:\setup, where setup is a directory that was created on the existing server.
3. Run the script as shown here, and save the entire down-level server configuration directory. Copy this
directory to the new staging server. You must copy the entire Expor ted-Ser verConfiguration- * folder to
the new server.
4. Start Azure AD Connect by double-clicking the icon on the desktop. Accept the Microsoft Software License
Terms, and on the next page, select Customize .
5. Select the Impor t synchronization settings check box. Select Browse to browse the copied-over
Exported-ServerConfiguration-* folder. Select the MigratedPolicy.json to import the migrated settings.
Post-installation verification
Comparing the originally imported settings file with the exported settings file of the newly deployed server is an
essential step in understanding any differences between the intended versus the resulting deployment. Using your
favorite side-by-side text comparison application yields an instant visualization that quickly highlights any desired
or accidental changes.
While many formerly manual configuration steps are now eliminated, you should still follow your organization's
certification process to ensure no additional configuration is required. This configuration might occur if you use
advanced settings, which aren't currently captured in the public preview release of settings management.
Here are known limitations:
Synchronization rules : The precedence for a custom rule must be in the reserved range of 0 to 99 to avoid
conflicts with Microsoft's standard rules. Placing a custom rule outside the reserved range might result in your
custom rule being shifted around as standard rules are added to the configuration. A similar issue will occur if
your configuration contains modified standard rules. Modifying a standard rule is discouraged, and rule
placement is likely to be incorrect.
Device writeback : These settings are cataloged. They aren't currently applied during configuration. If device
writeback was enabled for your original server, you must manually configure the feature on the newly deployed
server.
Synchronized object types : Although it's possible to constrain the list of synchronized object types (such as
users, contacts, and groups) by using the Synchronization Service Manager, this feature isn't currently
supported via synchronization settings. After you finish the installation, you must manually reapply the
advanced configuration.
Custom run profiles : Although it's possible to modify the default set of run profiles by using the
Synchronization Service Manager, this feature isn't currently supported via synchronization settings. After you
finish the installation, you must manually reapply the advanced configuration.
Configuring the provisioning hierarchy : This advanced feature of the Synchronization Service Manager
isn't supported via synchronization settings. It must be manually reconfigured after you finish the initial
deployment.
Active Director y Federation Ser vices (AD FS) and PingFederate authentication : The sign-on methods
associated with these authentication features are automatically preselected. You must interactively supply all
other required configuration parameters.
A disabled custom synchronization rule will be impor ted as enabled : A disabled custom
synchronization rule is imported as enabled. Make sure to disable it on the new server too.
Next steps
Express settings
Customized settings
Quickstart
Deploy Azure AD Pass-through Authentication

Azure Active Directory (Azure AD) Pass-through Authentication allows your users to sign in to both on-premises
and cloud-based applications by using the same passwords. Pass-through Authentication signs users in by
validating their passwords directly against on-premises Active Directory.
IMPORTANT
If you are migrating from AD FS (or other federation technologies) to Pass-through Authentication, we highly recommend
that you follow our detailed deployment guide published here.
NOTE
If you deploying Pass Through Authentication with the Azure Government cloud, view Hybrid Identity Considerations for
Azure Government.
Follow these instructions to deploy Pass-through Authentication on your tenant:
Step 1: Check the prerequisites

Ensure that the following prerequisites are in place.
IMPORTANT
From a security standpoint, administrators should treat the server running the PTA agent as if it were a domain controller. The
PTA agent servers should be hardened along the same lines as outlined in Securing Domain Controllers Against Attack
In the Azure Active Directory admin center

1. Create a cloud-only global administrator account on your Azure AD tenant. This way, you can manage the
configuration of your tenant should your on-premises services fail or become unavailable. Learn about adding a
cloud-only global administrator account. Completing this step is critical to ensure that you don't get locked out
of your tenant.
2. Add one or more custom domain names to your Azure AD tenant. Your users can sign in with one of these
domain names.
In your on-premises environment
1. Identify a server running Windows Server 2012 R2 or later to run Azure AD Connect. If not enabled already,
enable TLS 1.2 on the server. Add the server to the same Active Directory forest as the users whose
passwords you need to validate.
2. Install the latest version of Azure AD Connect on the server identified in the preceding step. If you already
have Azure AD Connect running, ensure that the version is 1.1.750.0 or later.
NOTE
Azure AD Connect versions 1.1.557.0, 1.1.558.0, 1.1.561.0, and 1.1.614.0 have a problem related to password hash
synchronization. If you don't intend to use password hash synchronization in conjunction with Pass-through
Authentication, read the Azure AD Connect release notes.
3. Identify one or more additional servers (running Windows Server 2012 R2 or later, with TLS 1.2 enabled)
where you can run standalone Authentication Agents. These additional servers are needed to ensure the high
availability of requests to sign in. Add the servers to the same Active Directory forest as the users whose
passwords you need to validate.
IMPORTANT
In production environments, we recommend that you have a minimum of 3 Authentication Agents running on your
tenant. There is a system limit of 40 Authentication Agents per tenant. And as best practice, treat all servers running
Authentication Agents as Tier 0 systems (see reference).
4. If there is a firewall between your servers and Azure AD, configure the following items:
Ensure that Authentication Agents can make outbound requests to Azure AD over the following ports:
P O RT N UM B ER H O W IT 'S USED
80 Downloads the certificate revocation lists (CRLs) while

validating the TLS/SSL certificate
443 Handles all outbound communication with the service
8080 (optional) Authentication Agents report their status every ten

minutes over port 8080, if port 443 is unavailable. This
status is displayed on the Azure AD portal. Port 8080
is not used for user sign-ins.
If your firewall enforces rules according to the originating users, open these ports for traffic from
Windows services that run as a network service.
If your firewall or proxy allows DNS whitelisting, add connections to *.msappproxy.net and
*.ser vicebus.windows.net . If not, allow access to the Azure datacenter IP ranges, which are updated
weekly.
Your Authentication Agents need access to login.windows.net and login.microsoftonline.com for
initial registration. Open your firewall for those URLs as well.
For certificate validation, unblock the following URLs: mscrl.microsoft.com:80 ,
crl.microsoft.com:80 , ocsp.msocsp.com:80 , and www.microsoft.com:80 . Since these URLs are
used for certificate validation with other Microsoft products you may already have these URLs
unblocked.
Azure Government cloud prerequisite
Prior to enabling Pass-through Authentication through Azure AD Connect with Step 2, download the latest release
of the PTA agent from the Azure portal. You need to ensure that your agent is versions 1.5.1742.0. or later. To verify
your agent see Upgrade authentication agents
After downloading the latest release of the agent, proceed with the below instructions to configure Pass-Through
Authentication through Azure AD Connect.
Step 2: Enable the feature
Enable Pass-through Authentication through Azure AD Connect.
IMPORTANT
You can enable Pass-through Authentication on the Azure AD Connect primary or staging server. It is highly recommended
that you enable it from the primary server. If you are setting up an Azure AD Connect staging server in the future, you must
continue to choose Pass-through Authentication as the sign-in option; choosing another option will disable Pass-through
Authentication on the tenant and override the setting in the primary server.
If you're installing Azure AD Connect for the first time, choose the custom installation path. At the User sign-in
page, choose Pass-through Authentication as the Sign On method . On successful completion, a Pass-through
Authentication Agent is installed on the same server as Azure AD Connect. In addition, the Pass-through
Authentication feature is enabled on your tenant.
If you have already installed Azure AD Connect by using the express installation or the custom installation path,
select the Change user sign-in task on Azure AD Connect, and then select Next . Then select Pass-through
Authentication as the sign-in method. On successful completion, a Pass-through Authentication Agent is installed
on the same server as Azure AD Connect and the feature is enabled on your tenant.
IMPORTANT
Pass-through Authentication is a tenant-level feature. Turning it on affects the sign-in for users across all the managed
domains in your tenant. If you're switching from Active Directory Federation Services (AD FS) to Pass-through Authentication,
you should wait at least 12 hours before shutting down your AD FS infrastructure. This wait time is to ensure that users can
keep signing in to Exchange ActiveSync during the transition. For more help on migrating from AD FS to Pass-through
Authentication, check out our detailed deployment plan published here.
Step 3: Test the feature

Follow these instructions to verify that you have enabled Pass-through Authentication correctly:
1. Sign in to the Azure Active Directory admin center with the global administrator credentials for your tenant.
2. Select Azure Active Director y in the left pane.
3. Select Azure AD Connect .
4. Verify that the Pass-through authentication feature appears as Enabled .
5. Select Pass-through authentication . The Pass-through authentication pane lists the servers where your
Authentication Agents are installed.
At this stage, users from all the managed domains in your tenant can sign in by using Pass-through Authentication.
However, users from federated domains continue to sign in by using AD FS or another federation provider that you
have previously configured. If you convert a domain from federated to managed, all users from that domain
automatically start signing in by using Pass-through Authentication. The Pass-through Authentication feature does
not affect cloud-only users.
Step 4: Ensure high availability

If you plan to deploy Pass-through Authentication in a production environment, you should install additional
standalone Authentication Agents. Install these Authentication Agent(s) on server(s) other than the one running
Azure AD Connect. This setup provides you with high availability for user sign-in requests.
IMPORTANT
In production environments, we recommend that you have a minimum of 3 Authentication Agents running on your tenant.
There is a system limit of 40 Authentication Agents per tenant. And as best practice, treat all servers running Authentication
Agents as Tier 0 systems (see reference).
Installing multiple Pass-through Authentication Agents ensures high availability, but not deterministic load
balancing between the Authentication Agents. To determine how many Authentication Agents you need for your
tenant, consider the peak and average load of sign-in requests that you expect to see on your tenant. As a
benchmark, a single Authentication Agent can handle 300 to 400 authentications per second on a standard 4-core
CPU, 16-GB RAM server.
To estimate network traffic, use the following sizing guidance:
Each request has a payload size of (0.5K + 1K * num_of_agents) bytes, that is, data from Azure AD to the
Authentication Agent. Here, "num_of_agents" indicates the number of Authentication Agents registered on your
tenant.
Each response has a payload size of 1K bytes, that is, data from the Authentication Agent to Azure AD.
For most customers, three Authentication Agents in total are sufficient for high availability and capacity. You should
install Authentication Agents close to your domain controllers to improve sign-in latency.
To begin, follow these instructions to download the Authentication Agent software:
1. To download the latest version of the Authentication Agent (version 1.5.193.0 or later), sign in to the Azure Active
Directory admin center with your tenant's global administrator credentials.
3. Select Azure AD Connect , select Pass-through authentication , and then select Download Agent .
4. Select the Accept terms & download button.
NOTE
You can also directly download the Authentication Agent software. Review and accept the Authentication Agent's Terms of
Service before installing it.
There are two ways to deploy a standalone Authentication Agent:
First, you can do it interactively by just running the downloaded Authentication Agent executable and providing
your tenant's global administrator credentials when prompted.
Second, you can create and run an unattended deployment script. This is useful when you want to deploy multiple
Authentication Agents at once, or install Authentication Agents on Windows servers that don't have user interface
enabled, or that you can't access with Remote Desktop. Here are the instructions on how to use this approach:
1. Run the following command to install an Authentication Agent:
AADConnectAuthAgentSetup.exe REGISTERCONNECTOR="false" /q .
2. You can register the Authentication Agent with our service using Windows PowerShell. Create a PowerShell
Credentials object $cred that contains a global administrator username and password for your tenant. Run the
following command, replacing <username> and <password>:
$User = "<username>"
$PlainPassword = '<password>'
$SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, $SecurePassword
3. Go to C:\Program Files\Microsoft Azure AD Connect Authentication Agent and run the following script
using the $cred object that you created:
RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft Azure AD Connect Authentication Agent\Modules\" -

moduleName "PassthroughAuthPSModule" -Authenticationmode Credentials -Usercredentials $cred -Feature
PassthroughAuthentication
IMPORTANT
If an Authentication Agent is installed on a Virtual Machine, you can't clone the Virtual Machine to setup another
Authentication Agent. This method is unsuppor ted .
Step 5: Configure Smart Lockout capability

Smart Lockout assists in locking out bad actors who are trying to guess your users’ passwords or using brute-force
methods to get in. By configuring Smart Lockout settings in Azure AD and / or appropriate lockout settings in on-
premises Active Directory, attacks can be filtered out before they reach Active Directory. Read this article to learn
more on how to configure Smart Lockout settings on your tenant to protect your user accounts.
Next steps
Current limitations: Learn which scenarios are supported with the Pass-through Authentication and which ones
are not.
Security deep dive: Get technical information on the Pass-through Authentication feature.
Azure AD Connect Health Agent Installation
This document walks you through installing and configuring the Azure AD Connect Health Agents. You can
download the agents from here.
Requirements
The following table is a list of requirements for using Azure AD Connect Health.
REQ UIREM EN T DESC RIP T IO N
Azure AD Premium Azure AD Connect Health is an Azure AD Premium feature

and requires Azure AD Premium.
For more information, see Getting started with Azure AD

Premium
To start a free 30-day trial, see Start a trial.
You must be a global administrator of your Azure AD to get By default, only the global administrators can install and
started with Azure AD Connect Health configure the health agents to get started, access the portal,
and perform any operations within Azure AD Connect
Health. For more information, see Administering your Azure
AD directory.
Using Azure role-based access control (Azure RBAC) you can

allow access to Azure AD Connect Health to other users in
your organization. For more information, see Azure role-
based access control (Azure RBAC) for Azure AD Connect
Health.
Impor tant: The account used when installing the agents

must be a work or school account. It cannot be a Microsoft
account. For more information, see Sign up for Azure as an
organization
Azure AD Connect Health Agent is installed on each targeted Azure AD Connect Health requires the Health Agents to be
server installed and configured on targeted servers to receive the
data and provide the Monitoring and Analytics capabilities.
For example, to get data from your AD FS infrastructure, the

agent must be installed on the AD FS and Web Application
Proxy servers. Similarly, to get data on your on-premises AD
DS infrastructure, the agent must be installed on the domain
controllers.
Outbound connectivity to the Azure service endpoints During installation and runtime, the agent requires
connectivity to Azure AD Connect Health service endpoints.
If outbound connectivity is blocked using Firewalls, ensure
that the following endpoints are added to the allowed list.
See outbound connectivity endpoints
Outbound connectivity based on IP Addresses For IP address based filtering on firewalls, refer to the Azure
IP Ranges.
REQ UIREM EN T DESC RIP T IO N
TLS Inspection for outbound traffic is filtered or disabled The agent registration step or data upload operations may
fail if there is TLS inspection or termination for outbound
traffic at the network layer. Read more about how to setup
TLS inspection
Firewall ports on the server running the agent The agent requires the following firewall ports to be open in
order for the agent to communicate with the Azure AD
Health service endpoints.
TCP port 443

TCP port 5671
Note that port 5671 is no longer required for the latest

version of agent. Upgrade to the latest version so only port
443 is required. Read more about enable firewall ports
Allow the following websites if IE Enhanced Security is If IE Enhanced Security is enabled, then the following
enabled websites must be allowed on the server that is going to have
the agent installed.
https://login.microsoftonline.com
https://secure.aadcdn.microsoftonline-p.com
https://login.windows.net
https://aadcdn.msftauth.net
The federation server for your organization trusted by
Azure Active Directory. For example: https://sts.contoso.com
Read more about how to configure IE. In case you have a
proxy within your network , please see note below.
Ensure PowerShell v4.0 or newer is installed Windows Server 2008 R2 ships with PowerShell v2.0,
which is insufficient for the agent. Update PowerShell as
explained below under Agent installation on Windows Server
2008 R2 Servers.
Windows Server 2012 ships with PowerShell v3.0, which is
insufficient for the agent.
Windows Server 2012 R2 and later ship with a sufficiently
recent version of PowerShell.
Disable FIPS FIPS is not supported by Azure AD Connect Health agents.
NOTE
If you have a highly locked-down and extremely restricted environment, you would require to add the URLs mentioned in
the Service endpoint lists below in addition to the ones listed in the Allowed IE enhanced Security configuration above.
Outbound connectivity to the Azure service endpoints

During installation and runtime, the agent requires connectivity to Azure AD Connect Health service endpoints. If
outbound connectivity is blocked using Firewalls, make sure that the following URLs are not blocked by default.
Do not disable security monitoring or inspection of these URLs, but allow them as you would other internet
traffic. They permit communication with Azure AD Connect Health service endpoints. Learn how to check
outbound connectivity with Test-AzureADConnectHealthConnectivity.
DO M A IN EN VIRO N M EN T REQ UIRED A Z URE SERVIC E EN DP O IN T S

DO M A IN EN VIRO N M EN T REQ UIRED A Z URE SERVIC E EN DP O IN T S
General Public *.blob.core.windows.net

*.aadconnecthealth.azure.com
*.servicebus.windows.net - Port: 5671
*.adhybridhealth.azure.com/
https://management.azure.com
https://policykeyservice.dc.ad.msft.net/
https://login.windows.net
https://www.office.com *this endpoint is only used for
discovery purposes during registration.
Azure Germany *.blob.core.cloudapi.de

*.servicebus.cloudapi.de
*.aadconnecthealth.microsoftazure.de
https://management.microsoftazure.de
https://policykeyservice.aadcdi.microsoftazure.de
https://login.microsoftonline.de
https://secure.aadcdn.microsoftonline-p.de
https://www.office.de *this endpoint is only used for
Azure Government *.blob.core.usgovcloudapi.net

*.servicebus.usgovcloudapi.net
*.aadconnecthealth.microsoftazure.us
https://management.usgovcloudapi.net
https://policykeyservice.aadcdi.azure.us
https://login.microsoftonline.us
https://www.office.com *this endpoint is only used for
Download and install the Azure AD Connect Health Agent

Make sure that you satisfy the requirements for Azure AD Connect Health.
Get started using Azure AD Connect Health for AD FS
Download Azure AD Connect Health Agent for AD FS.
Get started using Azure AD Connect Health for sync
Download and install the latest version of Azure AD Connect. The Health Agent for sync will be
installed as part of the Azure AD Connect installation (version 1.0.9125.0 or higher).
Get started using Azure AD Connect Health for AD DS
Download Azure AD Connect Health Agent for AD DS.
Installing the Azure AD Connect Health Agent for AD FS

NOTE
AD FS server should be different from your Sync server. Do not install AD FS agent to your Sync server.
Before installation, make sure your AD FS server host name is unique and not present in the AD FS service. To
start the agent installation, double-click the .exe file that you downloaded. On the first screen, click Install.
Once the installation is finished, click Configure Now.
This launches a PowerShell window to initiate the agent registration process. When prompted, sign in with an
Azure AD account that has access to perform agent registration. By default the Global Admin account has access.
After signing in, PowerShell will continue. Once it completes, you can close PowerShell and the configuration is
complete.
At this point, the agent services should be started automatically allowing the agent upload the required data to
the cloud service in a secure manner.
If you have not met all the pre-requisites outlined in the previous sections, warnings appear in the PowerShell
window. Be sure to complete the requirements before installing the agent. The following screenshot is an
example of these errors.
To verify the agent has been installed, look for the following services on the server. If you completed the
configuration, they should already be running. Otherwise, they are stopped until the configuration is complete.
Azure AD Connect Health AD FS Diagnostics Service
Azure AD Connect Health AD FS Insights Service
Azure AD Connect Health AD FS Monitoring Service
Agent installation on Windows Server 2008 R2 Servers
Steps for Windows Server 2008 R2 servers:
1. Ensure that the server is running at Service Pack 1 or higher.
2. Turn off IE ESC for agent installation:
3. Install Windows PowerShell 4.0 on each of the servers ahead of installing the AD Health agent. To install
Windows PowerShell 4.0:
Install Microsoft .NET Framework 4.5 using the following link to download the offline installer.
Install PowerShell ISE (From Windows Features)
Install Internet Explorer version 10 or above on the server. (Required by the Health Service to
authenticate, using your Azure Admin credentials.)
4. For more information on installing Windows PowerShell 4.0 on Windows Server 2008 R2, see the wiki article
here.
Enable Auditing for AD FS
NOTE
This section only applies to AD FS servers. You do not have to follow these steps on the Web Application Proxy Servers.
In order for the Usage Analytics feature to gather and analyze data, the Azure AD Connect Health agent needs the
information in the AD FS Audit Logs. These logs are not enabled by default. Use the following procedures to
enable AD FS auditing and to locate the AD FS audit logs, on your AD FS servers.
To enable auditing for AD FS on Windows Server 2008 R2
1. Click Star t , point to Programs , point to Administrative Tools , and then click Local Security Policy .
2. Navigate to the Security Settings\Local Policies\User Rights Assignment folder, and then double-click
Generate security audits .
3. On the Local Security Setting tab, verify that the AD FS 2.0 service account is listed. If it is not present, click
Add User or Group and add it to the list, and then click OK .
4. To enable auditing, open a Command Prompt with elevated privileges and run the following command:
auditpol.exe /set /subcategory:{0CCE9222-69AE-11D9-BED3-505054503030} /failure:enable /success:enable
5. Close Local Security Policy .
-- The following steps are only required for primar y AD FS ser vers. --
6. Open the AD FS Management snap-in. To open the AD FS Management snap-in, click Star t , point to
Programs , point to Administrative Tools , and then click AD FS 2.0 Management .
7. In the Actions pane, click Edit Federation Ser vice Proper ties .
8. In the Federation Ser vice Proper ties dialog box, click the Events tab.
9. Select the Success audits and Failure audits check boxes.
10. Click OK .
To enable auditing for AD FS on Windows Server 2012 R2
1. Open Local Security Policy by opening Ser ver Manager on the Start screen, or Server Manager in the
taskbar on the desktop, then click Tools/Local Security Policy .
3. On the Local Security Setting tab, verify that the AD FS service account is listed. If it is not present, click
Add User or Group and add it to the list, and then click OK .
4. To enable auditing, open a command prompt with elevated privileges and run the following command:
6. Open the AD FS Management snap-in (in Server Manager, click Tools, and then select AD FS Management).
9. Select the Success audits and Failure audits check boxes and then click OK .
10. Verbose logging can be enabled through powershell using the command:
Set-AdfsProperties -LOGLevel Verbose .
To enable auditing for AD FS on Windows Server 2016

1. Open Local Security Policy by opening Ser ver Manager on the Start screen, or Server Manager in the
taskbar on the desktop, then click Tools/Local Security Policy .
3. On the Local Security Setting tab, verify that the AD FS service account is listed. If it is not present, click
Add User or Group and add the AD FS service account to the list, and then click OK .
4. To enable auditing, open a command prompt with elevated privileges and run the following command:
6. Open the AD FS Management snap-in (in Server Manager, click Tools, and then select AD FS Management).
9. Select the Success audits and Failure audits check boxes and then click OK . This should be enabled by
default.
10. Open a PowerShell window and run the following command: Set-AdfsProperties -AuditLevel Verbose .
Note that "basic" audit level is enabled by default. Read more about the AD FS Audit enhancement in Windows
Server 2016
To locate the AD FS audit logs
1. Open Event Viewer .
2. Go to Windows Logs and select Security .
3. On the right, click Filter Current Logs .
4. Under Event Source, select AD FS Auditing .
And quick FAQ note for Audit logs.
WARNING
A group policy can disable AD FS auditing. If AD FS auditing is disabled, usage analytics about login activities are not
available. Ensure that you don’t have a group policy that disables AD FS auditing.>
Installing the Azure AD Connect Health agent for sync

The Azure AD Connect Health agent for sync is installed automatically in the latest build of Azure AD Connect. To
use Azure AD Connect for sync, you need to download the latest version of Azure AD Connect and install it. You
can download the latest version here.
To verify the agent has been installed, look for the following services on the server. If you completed the
configuration, they should already be running. Otherwise, they are stopped until the configuration is complete.
Azure AD Connect Health Sync Insights Service
Azure AD Connect Health Sync Monitoring Service
NOTE
Remember that using Azure AD Connect Health requires Azure AD Premium. If you do not have Azure AD Premium, you
are unable to complete the configuration in the Azure portal. For more information, see the requirements page.
Manual Azure AD Connect Health for Sync registration

If the Azure AD Connect Health for Sync agent registration fails after successfully installing Azure AD Connect,
you can use the following PowerShell command to manually register the agent.
IMPORTANT
Using this PowerShell command is only required if the agent registration fails after installing Azure AD Connect.
The following PowerShell command is required ONLY when the health agent registration fails even after a
successful installation and configuration of Azure AD Connect. The Azure AD Connect Health services will start
after the agent has been successfully registered.
You can manually register the Azure AD Connect Health agent for sync using the following PowerShell command:
Register-AzureADConnectHealthSyncAgent -AttributeFiltering $false -StagingMode $false
The command takes following parameters:

AttributeFiltering: $true (default) - if Azure AD Connect is not syncing the default attribute set and has been
customized to use a filtered attribute set. $false otherwise.
StagingMode: $false (default) - if the Azure AD Connect server is NOT in staging mode, $true if the server is
configured to be in staging mode.
When prompted for authentication you should use the same global admin account (such as
admin@domain.onmicrosoft.com) that was used for configuring Azure AD Connect.
Installing the Azure AD Connect Health Agent for AD DS

To start the agent installation, double-click the .exe file that you downloaded. On the first screen, click Install.
Once the installation is finished, click Configure Now.

A command prompt is launched, followed by some PowerShell that executes Register-
AzureADConnectHealthADDSAgent. When prompted to sign in to Azure, go ahead and sign in.
After signing in, PowerShell will continue. Once it completes, you can close PowerShell and the configuration is
complete.
At this point, the services should be started automatically allowing the agent to monitor and gather data. If you
have not met all the pre-requisites outlined in the previous sections, warnings appear in the PowerShell window.
Be sure to complete the requirements before installing the agent. The following screenshot is an example of
these errors.
To verify the agent has been installed, look for the following services on the domain controller.
Azure AD Connect Health AD DS Insights Service
Azure AD Connect Health AD DS Monitoring Service
If you completed the configuration, these services should already be running. Otherwise, they are stopped until
the configuration is complete.
Quick agent installation in multiple servers

1. Create a user account in Azure AD with a password.
2. Assign the Owner role for this local AAD account in Azure AD Connect Health via the portal. Follow the steps
here. Assign the role to all service instances.
3. Download the .exe MSI file in local domain controller for installation.
4. Run the following script to registration. Replace the parameters with the new user account created and its
password.
AdHealthAddsAgentSetup.exe /quiet
Start-Sleep 30
$userName = "NEWUSER@DOMAIN"
$secpasswd = ConvertTo-SecureString "PASSWORD" -AsPlainText -Force
$myCreds = New-Object System.Management.Automation.PSCredential ($userName, $secpasswd)
import-module "C:\Program Files\Azure Ad Connect Health Adds Agent\PowerShell\AdHealthAdds"
Register-AzureADConnectHealthADDSAgent -Credential $myCreds
1. Once you are done, you can remove access for the local account by doing one or more of the following:
Remove the role assignment for the local account for AAD Connect Health
Rotate the password for the local account.
Disable the AAD local account
Delete the AAD local account
Agent Registration using PowerShell

After installing the appropriate agent setup.exe, you can perform the agent registration step using the following
PowerShell commands depending on the role. Open a PowerShell Window and execute the appropriate
command:
Register-AzureADConnectHealthADFSAgent
Register-AzureADConnectHealthADDSAgent
Register-AzureADConnectHealthSyncAgent
These commands accept "Credential" as a parameter to complete the registration in a non-interactive manner or
on a Server-Core machine.
The Credential can be captured in a PowerShell variable that is passed as a parameter.
You can provide any Azure AD Identity that has access to register the agents and does NOT have MFA enabled.
By default Global Admins have access to perform agent registration. You can also allow other less privileged
identities to perform this step. Read more about Azure role-based access control (Azure RBAC).
$cred = Get-Credential
Register-AzureADConnectHealthADFSAgent -Credential $cred
Configure Azure AD Connect Health Agents to use HTTP Proxy

You can configure Azure AD Connect Health Agents to work with an HTTP Proxy.
NOTE
Using “Netsh WinHttp set ProxyServerAddress” is not supported as the agent uses System.Net to make web requests
instead of Microsoft Windows HTTP Services.
The configured Http Proxy address is used to pass-through encrypted Https messages.
Authenticated proxies (using HTTPBasic) are not supported.
Change Health Agent Proxy Configuration

You have the following options to configure Azure AD Connect Health Agent to use an HTTP Proxy.
NOTE
All Azure AD Connect Health Agent services must be restarted, in order for the proxy settings to be updated. Run the
following command:
Restart-Service AzureADConnectHealth*
Import existing proxy Settings

I m p o r t fr o m I n t e r n e t Ex p l o r e r
Internet Explorer HTTP proxy settings can be imported, to be used by the Azure AD Connect Health Agents. On
each of the servers running the Health agent, execute the following PowerShell command:
Set-AzureAdConnectHealthProxySettings -ImportFromInternetSettings
I m p o r t fr o m W i n H T T P
WinHTTP proxy settings can be imported, to be used by the Azure AD Connect Health Agents. On each of the
servers running the Health agent, execute the following PowerShell command:
Set-AzureAdConnectHealthProxySettings -ImportFromWinHttp
Specify Proxy addresses manually

You can manually specify a proxy server on each of the servers running the Health Agent, by executing the
following PowerShell command:
Set-AzureAdConnectHealthProxySettings -HttpsProxyAddress address:port
Example: Set-AzureAdConnectHealthProxySettings -HttpsProxyAddress myproxyserver: 443

"address" can be a DNS resolvable server name or an IPv4 address
"port" can be omitted. If omitted then 443 is chosen as default port.
Clear existing proxy configuration
You can clear the existing proxy configuration by running the following command:
Set-AzureAdConnectHealthProxySettings -NoProxy
Read current proxy settings

You can read the currently configured proxy settings by running the following command:
Get-AzureAdConnectHealthProxySettings
Test Connectivity to Azure AD Connect Health Service

It is possible that issues may arise that cause the Azure AD Connect Health agent to lose connectivity with the
Azure AD Connect Health service. These include network issues, permission issues, or various other reasons.
If the agent is unable to send data to the Azure AD Connect Health service for longer than two hours, it is
indicated with the following alert in the portal: "Health Service data is not up to date." You can confirm if the
affected Azure AD Connect Health agent is able to upload data to the Azure AD Connect Health service by
running the following PowerShell command:
Test-AzureADConnectHealthConnectivity -Role ADFS
The role parameter currently takes the following values:

ADFS
Sync
ADDS
NOTE
To use the connectivity tool, you must first complete the agent registration. If you are not able to complete the agent
registration, make sure that you have met all the requirements for Azure AD Connect Health. This connectivity test is
performed by default during agent registration.
Related links
Using Azure AD Connect Health with AD FS
Using Azure AD Connect Health for sync
Using Azure AD Connect Health with AD DS
Azure AD Connect Health Version History
Azure AD Connect: Automatic upgrade
This feature was introduced with build 1.1.105.0 (released February 2016). This feature was updated in build
1.1.561 and now supports additional scenarios that were previously not supported.
Overview
Making sure your Azure AD Connect installation is always up to date has never been easier with the automatic
upgrade feature. This feature is enabled by default for express installations and DirSync upgrades. When a new
version is released, your installation is automatically upgraded. Automatic upgrade is enabled by default for the
following:
Express settings installation and DirSync upgrades.
Using SQL Express LocalDB, which is what Express settings always use. DirSync with SQL Express also use
LocalDB.
The AD account is the default MSOL_ account created by Express settings and DirSync.
Have less than 100,000 objects in the metaverse.
The current state of automatic upgrade can be viewed with the PowerShell cmdlet Get-ADSyncAutoUpgrade . It has
the following states:
STAT E C O M M EN T
Enabled Automatic upgrade is enabled.
Suspended Set by the system only. The system is not currently eligible
to receive automatic upgrades.
Disabled Automatic upgrade is disabled.
You can change between Enabled and Disabled with Set-ADSyncAutoUpgrade . Only the system should set the
state Suspended . Prior to 1.1.750.0 the Set-ADSyncAutoUpgrade cmdlet would block Autoupgrade if the auto-
upgrade state was set to Suspended. This functionality has now changed so it does not block AutoUpgrade.
Automatic upgrade is using Azure AD Connect Health for the upgrade infrastructure. For automatic upgrade to
work, make sure you have opened the URLs in your proxy server for Azure AD Connect Health as
documented in Office 365 URLs and IP address ranges.
If the Synchronization Ser vice Manager UI is running on the server, then the upgrade is suspended until the
UI is closed.
Troubleshooting
If your Connect installation does not upgrade itself as expected, then follow these steps to find out what could be
wrong.
First, you should not expect the automatic upgrade to be attempted the first day a new version is released. There
is an intentional randomness before an upgrade is attempted so don't be alarmed if your installation isn't
upgraded immediately.
If you think something is not right, then first run Get-ADSyncAutoUpgrade to ensure automatic upgrade is enabled.
If the state is suspended, you can use the Get-ADSyncAutoUpgrade -Detail to view the reason. The suspension
reason can contain any string value but will usually contain the string value of the UpgradeResult, that is,
UpgradeNotSupportedNonLocalDbInstall or UpgradeAbortedAdSyncExeInUse . A compound value may also be
returned, such as UpgradeFailedRollbackSuccess-GetPasswordHashSyncStateFailed .
It is also possible to get a result that is not an UpgradeResult i.e. 'AADHealthEndpointNotDefined' or
'DirSyncInPlaceUpgradeNonLocalDb'.
Then, make sure you have opened the required URLs in your proxy or firewall. Automatic update is using Azure
AD Connect Health as described in the overview. If you use a proxy, make sure Health has been configured to use
a proxy server. Also test the Health connectivity to Azure AD.
With the connectivity to Azure AD verified, it is time to look into the eventlogs. Start the event viewer and look in
the Application eventlog. Add an eventlog filter for the source Azure AD Connect Upgrade and the event id
range 300-399 .
You can now see the eventlogs associated with the status for automatic upgrade.
The result code has a prefix with an overview of the state.
RESULT C O DE P REF IX DESC RIP T IO N
Success The installation was successfully upgraded.
UpgradeAborted A temporary condition stopped the upgrade. It will be retried

again and the expectation is that it succeeds later.
UpgradeNotSupported The system has a configuration that is blocking the system

from being automatically upgraded. It will be retried to see if
the state is changing, but the expectation is that the system
must be upgraded manually.
Here is a list of the most common messages you find. It does not list all, but the result message should be clear
with what the problem is.
RESULT M ESSA GE DESC RIP T IO N
UpgradeAbor ted
UpgradeAbortedCouldNotSetUpgradeMarker Could not write to the registry.
UpgradeAbortedInsufficientDatabasePermissions The built-in administrators group does not have permissions

to the database. Manually upgrade to the latest version of
Azure AD Connect to address this issue.
UpgradeAbortedInsufficientDiskSpace There is not enough disc space to support an upgrade.
UpgradeAbortedSecurityGroupsNotPresent Could not find and resolve all security groups used by the
sync engine.
UpgradeAbortedServiceCanNotBeStarted The NT Service Microsoft Azure AD Sync failed to start.
UpgradeAbortedServiceCanNotBeStopped The NT Service Microsoft Azure AD Sync failed to stop.
UpgradeAbortedServiceIsNotRunning The NT Service Microsoft Azure AD Sync is not running.
UpgradeAbortedSyncCycleDisabled The SyncCycle option in the scheduler has been disabled.
UpgradeAbortedSyncExeInUse The synchronization service manager UI is open on the

server.
UpgradeAbortedSyncOrConfigurationInProgress The installation wizard is running or a sync was scheduled

outside the scheduler.
UpgradeNotSuppor ted
UpgradeNotSupportedCustomizedSyncRules You have added your own custom rules to the configuration.
UpgradeNotSupportedInvalidPersistedState The installation is not an Express settings or a DirSync

upgrade.
UpgradeNotSupportedNonLocalDbInstall You are not using a SQL Server Express LocalDB database.
UpgradeNotSupportedLocalDbSizeExceeded Local DB size is greater than or equal to 8 GB
UpgradeNotSupportedAADHealthUploadDisabled Health data uploads have been disabled from the portal
Next steps
Azure AD Connect sync: Running the installation
wizard a second time
The first time you run the Azure AD Connect installation wizard, it walks you through how to configure your
installation. If you run the installation wizard again, it offers options for maintenance.
IMPORTANT
Be aware that you cannot run the installation wizard while a synchronization is in progress. Please verify that a
synchronization is not running before launching the wizard.
You can find the installation wizard in the start menu named Azure AD Connect .
When you start the installation wizard, you see a page with these options:
If you have installed ADFS with Azure AD Connect, you have even more options. The additional options you have
for ADFS are documented in ADFS management.
Select one of the tasks and click Next to continue.
IMPORTANT
While you have the installation wizard open, all operations in the sync engine are suspended. Make sure you close the
installation wizard as soon as you have completed your configuration changes.
View current configuration

This option gives you a quick view of your currently configured options.
Click Previous to go back. If you select Exit , you close the installation wizard.
Customize synchronization options

This option is used to make changes to the sync configuration. You see a subset of options from the custom
configuration installation path. You see this option even if you used express installation initially.
Add more directories. For removing a directory, see Delete a Connector.
Change Domain and OU filtering.
Remove Group filtering.
Change optional features.
The other options from the initial installation cannot be changed and are not available. These options are:
Change the attribute to use for userPrincipalName and sourceAnchor.
Change the joining method for objects from different forest.
Enable group-based filtering.
Refresh directory schema

This option is used if you have changed the schema in one of your on-premises AD DS forests. For example, you
might have installed Exchange or upgraded to a Windows Server 2012 schema with device objects. In this case,
you need to instruct Azure AD Connect to read the schema again from AD DS and update its cache. This action also
regenerates the Sync Rules. If you add the Exchange schema, as an example, the Sync Rules for Exchange are
added to the configuration.
When you select this option, all the directories in your configuration are listed. You can keep the default setting and
refresh all forests or unselect some of them.
Configure staging mode

This option allows you to enable and disable staging mode on the server. More information about staging mode
and how it is used can be found in Operations.
The option shows if staging is currently enabled or disabled:
To change the state, select this option and select or unselect the checkbox.
Change user sign-in

This option allows you to change the user sign-in method to and from password hash sync, pass-through
authentication or federation. You cannot change to do not configure .
For more information on this option, see user sign-in.
Next steps
Learn more about the configuration model used by Azure AD Connect sync in Understanding Declarative
Provisioning.
Over view topics
Azure AD Connect: Upgrade from a previous version
to the latest
This topic describes the different methods that you can use to upgrade your Azure Active Directory (Azure AD)
Connect installation to the latest release. We recommend that you keep yourself current with the releases of
Azure AD Connect. You also use the steps in the Swing migration section when you make a substantial
configuration change.
NOTE
It is currently supported to upgrade from any version of Azure AD Connect to the current version. In-place upgrades of
DirSync or ADSync are not supported and a swing migration is required. If you want to upgrade from DirSync, see Upgrade
from Azure AD sync tool (DirSync) or the Swing migration section.
In practice, customers on extremely old versions may encounter problems not directly related to Azure AD Connect. Servers
that have been in production for several years, typically have had several patches applied to them and not all of these can
be accounted for. Generally, customers who have not upgraded in 12-18 months should consider a swing upgrade instead
as this is the most conservative and least risky option.
If you want to upgrade from DirSync, see Upgrade from Azure AD sync tool (DirSync) instead.
There are a few different strategies that you can use to upgrade Azure AD Connect.
M ET H O D DESC RIP T IO N
Automatic upgrade This is the easiest method for customers with an express
installation.
In-place upgrade If you have a single server, you can upgrade the installation
in-place on the same server.
Swing migration With two servers, you can prepare one of the servers with
the new release or configuration, and change the active
server when you're ready.
For permissions information, see the permissions required for an upgrade.
NOTE
After you've enabled your new Azure AD Connect server to start synchronizing changes to Azure AD, you must not roll
back to using DirSync or Azure AD Sync. Downgrading from Azure AD Connect to legacy clients, including DirSync and
Azure AD Sync, isn't supported and can lead to issues such as data loss in Azure AD.
In-place upgrade
An in-place upgrade works for moving from Azure AD Sync or Azure AD Connect. It doesn't work for moving
from DirSync or for a solution with Forefront Identity Manager (FIM) + Azure AD Connector.
This method is preferred when you have a single server and less than about 100,000 objects. If there are any
changes to the out-of-box sync rules, a full import and full synchronization occur after the upgrade. This method
ensures that the new configuration is applied to all existing objects in the system. This run might take a few hours,
depending on the number of objects that are in scope of the sync engine. The normal delta synchronization
scheduler (which synchronizes every 30 minutes by default) is suspended, but password synchronization
continues. You might consider doing the in-place upgrade during a weekend. If there are no changes to the out-
of-box configuration with the new Azure AD Connect release, then a normal delta import/sync starts instead.
If you've made changes to the out-of-box synchronization rules, then these rules are set back to the default
configuration on upgrade. To make sure that your configuration is kept between upgrades, make sure that you
make changes as they're described in Best practices for changing the default configuration.
During in-place upgrade, there may be changes introduced that require specific synchronization activities
(including Full Import step and Full Synchronization step) to be executed after upgrade completes. To defer such
activities, refer to section How to defer full synchronization after upgrade.
If you are using Azure AD Connect with non-standard connector (for example, Generic LDAP Connector and
Generic SQL Connector), you must refresh the corresponding connector configuration in the Synchronization
Service Manager after in-place upgrade. For details on how to refresh the connector configuration, refer to article
section Connector Version Release History - Troubleshooting. If you do not refresh the configuration, import and
export run steps will not work correctly for the connector. You will receive the following error in the application
event log with message "Assembly version in AAD Connector configuration ("X.X.XXX.X") is earlier than the actual
version ("X.X.XXX.X") of "C:\Program Files\Microsoft Azure AD
Sync\Extensions\Microsoft.IAM.Connector.GenericLdap.dll".
Swing migration
If you have a complex deployment or many objects, it might be impractical to do an in-place upgrade on the live
system. For some customers, this process might take multiple days--and during this time, no delta changes are
processed. You can also use this method when you plan to make substantial changes to your configuration and
you want to try them out before they're pushed to the cloud.
The recommended method for these scenarios is to use a swing migration. You need (at least) two servers--one
active server and one staging server. The active server (shown with solid blue lines in the following picture) is
responsible for the active production load. The staging server (shown with dashed purple lines) is prepared with
the new release or configuration. When it's fully ready, this server is made active. The previous active server,
which now has the old version or configuration installed, is made into the staging server and is upgraded.
The two servers can use different versions. For example, the active server that you plan to decommission can use
Azure AD Sync, and the new staging server can use Azure AD Connect. If you use swing migration to develop a
new configuration, it's a good idea to have the same versions on the two servers.
NOTE
Some customers prefer to have three or four servers for this scenario. When the staging server is upgraded, you don't have
a backup server for disaster recovery. With three or four servers, you can prepare one set of primary/standby servers with
the new version, which ensures that there is always a staging server that's ready to take over.
These steps also work to move from Azure AD Sync or a solution with FIM + Azure AD Connector. These steps
don't work for DirSync, but the same swing migration method (also called parallel deployment) with steps for
DirSync is in Upgrade Azure Active Directory sync (DirSync).
Use a swing migration to upgrade
1. If you use Azure AD Connect on both servers and plan to only make a configuration change, make sure that
your active server and staging server are both using the same version. That makes it easier to compare
differences later. If you're upgrading from Azure AD Sync, then these servers have different versions. If you're
upgrading from an older version of Azure AD Connect, it's a good idea to start with the two servers that are
using the same version, but it's not required.
2. If you've made a custom configuration and your staging server doesn't have it, follow the steps under Move a
custom configuration from the active server to the staging server.
3. If you're upgrading from an earlier release of Azure AD Connect, upgrade the staging server to the latest
version. If you're moving from Azure AD Sync, then install Azure AD Connect on your staging server.
4. Let the sync engine run full import and full synchronization on your staging server.
5. Verify that the new configuration didn't cause any unexpected changes by using the steps under "Verify" in
Verify the configuration of a server. If something isn't as expected, correct it, run the import and sync, and
verify the data until it looks good, by following the steps.
6. Switch the staging server to be the active server. This is the final step "Switch active server" in Verify the
configuration of a server.
7. If you're upgrading Azure AD Connect, upgrade the server that's now in staging mode to the latest release.
Follow the same steps as before to get the data and configuration upgraded. If you upgraded from Azure AD
Sync, you can now turn off and decommission your old server.
Move a custom configuration from the active server to the staging server
If you've made configuration changes to the active server, you need to make sure that the same changes are
applied to the staging server. To help with this move, you can use the Azure AD Connect configuration
documenter.
You can move the custom sync rules that you've created by using PowerShell. You must apply other changes the
same way on both systems, and you can't migrate the changes. The configuration documenter can help you
comparing the two systems to make sure they are identical. The tool can also help in automating the steps found
in this section.
You need to configure the following things the same way on both servers:
Connection to the same forests
Any domain and OU filtering
The same optional features, such as password sync and password writeback
Move custom synchronization rules
To move custom synchronization rules, do the following:
1. Open Synchronization Rules Editor on your active server.
2. Select a custom rule. Click Expor t . This brings up a Notepad window. Save the temporary file with a PS1
extension. This makes it a PowerShell script. Copy the PS1 file to the staging server.
3. The Connector GUID is different on the staging server, and you must change it. To get the GUID, start
Synchronization Rules Editor , select one of the out-of-box rules that represent the same connected system,
and click Expor t . Replace the GUID in your PS1 file with the GUID from the staging server.
4. In a PowerShell prompt, run the PS1 file. This creates the custom synchronization rule on the staging server.
5. Repeat this for all your custom rules.
How to defer full synchronization after upgrade

During in-place upgrade, there may be changes introduced that require specific synchronization activities
(including Full Import step and Full Synchronization step) to be executed. For example, connector schema
changes require full impor t step and out-of-box synchronization rule changes require full synchronization
step to be executed on affected connectors. During upgrade, Azure AD Connect determines what synchronization
activities are required and records them as overrides. In the following synchronization cycle, the synchronization
scheduler picks up these overrides and executes them. Once an override is successfully executed, it is removed.
There may be situations where you do not want these overrides to take place immediately after upgrade. For
example, you have numerous synchronized objects and you would like these synchronization steps to occur after
business hours. To remove these overrides:
1. During upgrade, uncheck the option Star t the synchronization process when configuration
completes . This disables the synchronization scheduler and prevents synchronization cycle from taking
place automatically before the overrides are removed.
2. After upgrade completes, run the following cmdlet to find out what overrides have been added:
Get-ADSyncSchedulerConnectorOverride | fl
NOTE
The overrides are connector-specific. In the following example, Full Import step and Full Synchronization step have
been added to both the on-premises AD Connector and Azure AD Connector.
3. Note down the existing overrides that have been added.

4. To remove the overrides for both full import and full synchronization on an arbitrary connector, run the
following cmdlet:
Set-ADSyncSchedulerConnectorOverride -ConnectorIdentifier <Guid-of-ConnectorIdentifier> -
FullImportRequired $false -FullSyncRequired $false
To remove the overrides on all connectors, execute the following PowerShell script:
foreach ($connectorOverride in Get-ADSyncSchedulerConnectorOverride)

{
Set-ADSyncSchedulerConnectorOverride -ConnectorIdentifier
$connectorOverride.ConnectorIdentifier.Guid -FullSyncRequired $false -FullImportRequired $false
}
5. To resume the scheduler, run the following cmdlet: Set-ADSyncScheduler -SyncCycleEnabled $true
IMPORTANT
Remember to execute the required synchronization steps at your earliest convenience. You can either manually
execute these steps using the Synchronization Service Manager or add the overrides back using the Set-
ADSyncSchedulerConnectorOverride cmdlet.
To add the overrides for both full import and full synchronization on an arbitrary connector, run the following
cmdlet:
Set-ADSyncSchedulerConnectorOverride -ConnectorIdentifier <Guid> -FullImportRequired $true -FullSyncRequired
$true
Troubleshooting
The following section contains troubleshooting and information that you can use if you encounter an issue
upgrading Azure AD Connect.
Azure Active Directory connector missing error during Azure AD Connect upgrade
When you upgrade Azure AD Connect from a previous version, you might hit following error at the beginning of
the upgrade
This error happens because the Azure Active Directory connector with identifier, b891884f-051e-4a83-95af-
2544101c9083, does not exist in the current Azure AD Connect configuration. To verify this is the case, open a
PowerShell window, run Cmdlet Get-ADSyncConnector -Identifier b891884f-051e-4a83-95af-2544101c9083
PS C:\> Get-ADSyncConnector -Identifier b891884f-051e-4a83-95af-2544101c9083
Get-ADSyncConnector : Operation failed because the specified MA could not be found.
At line:1 char:1
+ Get-ADSyncConnector -Identifier b891884f-051e-4a83-95af-2544101c9083
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ReadError: (Microsoft.Ident...ConnectorCmdlet:GetADSyncConnectorCmdlet) [Get-
ADSyncConne
ctor], ConnectorNotFoundException
+ FullyQualifiedErrorId : Operation failed because the specified MA could not be
found.,Microsoft.IdentityManageme
nt.PowerShell.Cmdlet.GetADSyncConnectorCmdlet
The PowerShell Cmdlet reports the error the specified MA could not be found .
The reason that this occurs is because the current Azure AD Connect configuration is not supported for upgrade.
If you want to install a newer version of Azure AD Connect: close the Azure AD Connect wizard, uninstall the
existing Azure AD Connect, and perform a clean install of the newer Azure AD Connect.
Next steps
Learn more about integrating your on-premises identities with Azure Active Directory.
Azure AD Connect: Upgrade from DirSync
Azure AD Connect is the successor to DirSync. You find the ways you can upgrade from DirSync in this topic.
These steps do not work for upgrading from another release of Azure AD Connect or from Azure AD Sync.
Before you start installing Azure AD Connect, make sure to download Azure AD Connect and complete the pre-
requisite steps in Azure AD Connect: Hardware and prerequisites. In particular, you want to read about the
following, since these areas are different from DirSync:
The required version of .NET and PowerShell. Newer versions are required to be on the server than what
DirSync needed.
The proxy server configuration. If you use a proxy server to reach the internet, this setting must be configured
before you upgrade. DirSync always used the proxy server configured for the user installing it, but Azure AD
Connect uses machine settings instead.
The URLs required to be open in the proxy server. For basic scenarios, those scenarios also supported by
DirSync, the requirements are the same. If you want to use any of the new features included with Azure AD
Connect, some new URLs must be opened.
NOTE
Once you have enabled your new Azure AD Connect server to start synchronizing changes to Azure AD, you must not roll
back to using DirSync or Azure AD Sync. Downgrading from Azure AD Connect to legacy clients including DirSync and
Azure AD Sync is not supported and can lead to issues such as data loss in Azure AD.
If you are not upgrading from DirSync, see related documentation for other scenarios.
Upgrade from DirSync

Depending on your current DirSync deployment, there are different options for the upgrade. If the expected
upgrade time is less than three hours, then the recommendation is to do an in-place upgrade. If the expected
upgrade time is more than three hours, then the recommendation is to do a parallel deployment on another
server. It is estimated that if you have more than 50,000 objects it takes more than three hours to do the upgrade.
SC EN A RIO
In-place upgrade
Parallel deployment
NOTE
When you plan to upgrade from DirSync to Azure AD Connect, do not uninstall DirSync yourself before the upgrade. Azure
AD Connect will read and migrate the configuration from DirSync and uninstall after inspecting the server.
In-place upgrade
The expected time to complete the upgrade is displayed by the wizard. This estimate is based on the assumption
that it takes three hours to complete an upgrade for a database with 50,000 objects (users, contacts, and groups).
If the number of objects in your database is less than 50,000, then Azure AD Connect recommends an in-place
upgrade. If you decide to continue, your current settings are automatically applied during upgrade and your
server automatically resumes active synchronization.
If you want to do a configuration migration and do a parallel deployment, then you can override the in-place
upgrade recommendation. You might for example take the opportunity to refresh the hardware and operating
system. For more information, see the parallel deployment section.
Parallel deployment
If you have more than 50,000 objects, then a parallel deployment is recommended. This deployment avoids any
operational delays experienced by your users. The Azure AD Connect installation attempts to estimate the
downtime for the upgrade, but if you've upgraded DirSync in the past, your own experience is likely to be the
best guide.
Supported DirSync configurations to be upgraded
The following configuration changes are supported with upgraded DirSync:
Domain and OU filtering
Alternate ID (UPN)
Password sync and Exchange hybrid settings
Your forest/domain and Azure AD settings
Filtering based on user attributes
The following change cannot be upgraded. If you have this configuration, the upgrade is blocked:
Unsupported DirSync changes, for example removed attributes and using a custom extension DLL
In those cases, the recommendation is to install a new Azure AD Connect server in staging mode and verify the
old DirSync and new Azure AD Connect configuration. Reapply any changes using custom configuration, as
described in Azure AD Connect Sync custom configuration.
The passwords used by DirSync for the service accounts cannot be retrieved and are not migrated. These
passwords are reset during the upgrade.
High-level steps for upgrading from DirSync to Azure AD Connect
1. Welcome to Azure AD Connect
2. Analysis of current DirSync configuration
3. Collect Azure AD global admin password
4. Collect credentials for an enterprise admin account (only used during the installation of Azure AD Connect)
5. Installation of Azure AD Connect
Uninstall DirSync (or temporarily disable it)
Install Azure AD Connect
Optionally begin synchronization
Additional steps are required when:
You're currently using Full SQL Server - local or remote
You have more than 50,000 objects in scope for synchronization
In-place upgrade
1. Launch the Azure AD Connect installer (MSI).
2. Review and agree to license terms and privacy notice.
3. Click next to begin analysis of your existing DirSync installation.

4. When the analysis completes, you see the recommendations on how to proceed.
If you use SQL Server Express and have less than 50,000 objects, the following screen is shown:
If you use a full SQL Server for DirSync, you see this page instead:
The information regarding the existing SQL Server database server being used by DirSync is displayed.
Make appropriate adjustments if needed. Click Next to continue the installation.
If you have more than 50,000 objects, you see this screen instead:
To proceed with an in-place upgrade, click the checkbox next to this message: Continue upgrading
DirSync on this computer. To do a parallel deployment instead, you export the DirSync
configuration settings and move the configuration to the new server.
5. Provide the password for the account you currently use to connect to Azure AD. This must be the account
currently used by DirSync.
If you receive an error and have problems with connectivity, see Troubleshoot connectivity problems.
6. Provide an enterprise admin account for Active Directory.
7. You're now ready to configure. When you click Upgrade , DirSync is uninstalled and Azure AD Connect is
configured and begins synchronizing.
8. After the installation has completed, sign out and sign in again to Windows before you use Synchronization
Service Manager, Synchronization Rule Editor, or try to make any other configuration changes.
Parallel deployment
Export the DirSync configuration
Parallel deployment with more than 50,000 objects
If you have more than 50,000 objects, then the Azure AD Connect installation recommends a parallel
deployment.
A screen similar to the following is displayed:
If you want to proceed with parallel deployment, you need to perform the following steps:
Click the Expor t settings button. When you install Azure AD Connect on a separate server, these settings are
migrated from your current DirSync to your new Azure AD Connect installation.
Once your settings have been successfully exported, you can exit the Azure AD Connect wizard on the DirSync
server. Continue with the next step to install Azure AD Connect on a separate server
Parallel deployment with less than 50,000 objects
If you have less than 50,000 objects but still want to do a parallel deployment, then do the following:
1. Run the Azure AD Connect installer (MSI).
2. When you see the Welcome to Azure AD Connect screen, exit the installation wizard by clicking the "X" in
the top right corner of the window.
3. Open a command prompt.
4. From the install location of Azure AD Connect (Default: C:\Program Files\Microsoft Azure Active Directory
Connect) execute the following command: AzureADConnect.exe /ForceExport .
5. Click the Expor t settings button. When you install Azure AD Connect on a separate server, these settings are
migrated from your current DirSync to your new Azure AD Connect installation.
Once your settings have been successfully exported, you can exit the Azure AD Connect wizard on the DirSync
server. Continue with the next step to install Azure AD Connect on a separate server.
Install Azure AD Connect on separate server
When you install Azure AD Connect on a new server, the assumption is that you want to perform a clean install of
Azure AD Connect. Since you want to use the DirSync configuration, there are some extra steps to take:
1. Run the Azure AD Connect installer (MSI).
2. When you see the Welcome to Azure AD Connect screen, exit the installation wizard by clicking the "X" in
the top right corner of the window.
3. Open a command prompt.
4. From the install location of Azure AD Connect (Default: C:\Program Files\Microsoft Azure Active Directory
Connect) execute the following command: AzureADConnect.exe /migrate . The Azure AD Connect installation
wizard starts and presents you with the following screen:
5. Select the settings file that exported from your DirSync installation.
6. Configure any advanced options including:
A custom installation location for Azure AD Connect.
An existing instance of SQL Server (Default: Azure AD Connect installs SQL Server 2012 Express). Do
not use the same database instance as your DirSync server.
A service account used to connect to SQL Server (If your SQL Server database is remote then this
account must be a domain service account). These options can be seen on this screen:
7. Click Next .
8. On the Ready to configure page, leave the Star t the synchronization process as soon as the
configuration completes checked. The server is now in staging mode so changes are not exported to Azure
AD.
9. Click Install .
10. After the installation has completed, sign out and sign in again to Windows before you use Synchronization
Service Manager, Synchronization Rule Editor, or try to make any other configuration changes.
NOTE
Synchronization between Windows Server Active Directory and Azure Active Directory begins, but no changes are
exported to Azure AD. Only one synchronization tool can be actively exporting changes at a time. This state is called
staging mode.
Verify that Azure AD Connect is ready to begin synchronization

To verify that Azure AD Connect is ready to take over from DirSync, you need to open Synchronization Ser vice
Manager in the group Azure AD Connect from the start menu.
In the application, go to the Operations tab. On this tab, confirm that the following operations have completed:
Import on the AD Connector
Import on the Azure AD Connector
Full Sync on the AD Connector
Full Sync on the Azure AD Connector
Review the result from these operations and ensure there are no errors.
If you want to see and inspect the changes that are about to be exported to Azure AD, then read how to verify the
configuration under staging mode. Make required configuration changes until you do not see anything
unexpected.
You are ready to switch from DirSync to Azure AD when you have completed these steps and are happy with the
result.
Uninstall DirSync (old server)
In Programs and features find Windows Azure Active Director y sync tool
Uninstall Windows Azure Active Director y sync tool
The uninstallation might take up to 15 minutes to complete.
If you prefer to uninstall DirSync later, you can also temporarily shut down the server or disable the service. If
something goes wrong, this method allows you to re-enable it. However, it is not expected that the next step will
fail so this should not be needed.
With DirSync uninstalled or disabled, there is no active server exporting to Azure AD. The next step to enable
Azure AD Connect must be completed before any changes in your on-premises Active Directory will continue to
be synchronized to Azure AD.
Enable Azure AD Connect (new server)
After installation, reopening Azure AD connect will allow you to make additional configuration changes. Start
Azure AD Connect from the start menu or from the shortcut on the desktop. Make sure you do not try to run
the installation MSI again.
You should see the following:
Select Configure staging mode .

Turn off staging by unchecking the Enabled staging mode checkbox.
Click the Next button
On the confirmation page, click the install button.
Azure AD Connect is now your active server and you must not switch back to using your existing DirSync server.
Next steps
Learn more about these new features, which were enabled with the installation: Automatic upgrade, Prevent
accidental deletes, and Azure AD Connect Health.
Install Azure AD Connect using an existing ADSync
database
Azure AD Connect requires a SQL Server database to store data. You can either use the default SQL Server 2012
Express LocalDB installed with Azure AD Connect or use your own full version of SQL. Previously, when you
installed Azure AD Connect, a new database named ADSync was always created. With Azure AD Connect version
1.1.613.0 (or after), you have the option to install Azure AD Connect by pointing it to an existing ADSync database.
Benefits of using an existing ADSync database

By pointing to an existing ADSync database:
Except for credentials information, synchronization configuration stored in the ADSync database (including
custom synchronization rules, connectors, filtering, and optional features configuration) is automatically
recovered and used during installation. Credentials used by Azure AD Connect to synchronize changes with on-
premises AD and Azure AD are encrypted and can only be accessed by the previous Azure AD Connect server.
All the identity data (associated with connector spaces and metaverse) and synchronization cookies stored in
the ADSync database are also recovered. The newly installed Azure AD Connect server can continue to
synchronize from where the previous Azure AD Connect server left off, instead of having the need to perform a
full sync.
Scenarios where using an existing ADSync database is beneficial

These benefits are useful in the following scenarios:
You have an existing Azure AD Connect deployment. Your existing Azure AD Connect server is no longer
working but the SQL server containing the ADSync database is still functioning. You can install a new Azure AD
Connect server and point it to the existing ADSync database.
You have an existing Azure AD Connect deployment. Your SQL server containing the ADSync database is no
longer functioning. However, you have a recent back up of the database. You can restore the ADSync database
to a new SQL server first. After which, you can install a new Azure AD Connect server and point it to the
restored ADSync database.
You have an existing Azure AD Connect deployment that is using LocalDB. Due to the 10-GB limit imposed by
LocalDB, you would like to migrate to full SQL. You can back up the ADSync database from LocalDB and restore
it to a SQL server. After which, you can reinstall a new Azure AD Connect server and point it to the restored
ADSync database.
You are trying to set up a staging server and wants to make sure its configuration matches that of the current
active server. You can back up the ADSync database and restore it to another SQL server. After which, you can
reinstall a new Azure AD Connect server and point it to the restored ADSync database.
Prerequisite information
Important notes to take note of before you proceed:
Make sure to review the pre-requisites for installing Azure AD Connect at Hardware and prerequisites, and
account and permissions required for installing Azure AD Connect. The permissions required for installing
Azure AD Connect using “use existing database” mode is the same as “custom” installation.
Deploying Azure AD Connect against an existing ADSync database is only supported with full SQL. It is not
supported with SQL Express LocalDB. If you have an existing ADSync database in LocalDB that you wish to use,
you must first backup the ADSync database (LocalDB) and restore it to full SQL. After which, you can deploy
Azure AD Connect against the restored database using this method.
The version of the Azure AD Connect used for installation must satisfy the following criteria:
1.1.613.0 or above, AND
Same or higher than the version of the Azure AD Connect last used with the ADSync database. If the
Azure AD Connect version used for installation is higher than the version last used with the ADSync
database, then a full sync may be required. Full sync is required if there are schema or sync rule changes
between the two versions.
The ADSync database used should contain a synchronization state that is relatively recent. The last
synchronization activity with the existing ADSync database should be within the last three weeks.
When installing Azure AD Connect using “use existing database” method, sign-in method configured on the
previous Azure AD Connect server is not preserved. Further, you cannot configure sign-in method during
installation. You can only configure sign-in method after installation is complete.
You cannot have multiple Azure AD Connect servers share the same ADSync database. The “use existing
database” method allows you to reuse an existing ADSync database with a new Azure AD Connect server. It
does not support sharing.
Steps to install Azure AD Connect with “use existing database” mode

1. Download Azure AD Connect installer (AzureADConnect.MSI) to the Windows server. Double-click the Azure AD
Connect installer to start installing Azure AD Connect.
2. Once the MSI installation completes, the Azure AD Connect wizard starts with the Express mode setup. Close
the screen by clicking the Exit icon.
3. Start a new command prompt or PowerShell session. Navigate to folder "C:\Program Files\Microsoft Azure
Active Directory Connect". Run command .\AzureADConnect.exe /useexistingdatabase to start the Azure AD
Connect wizard in “Use existing database” setup mode.
NOTE
Use the switch /UseExistingDatabase only when the database already contains data from an earlier Azure AD Connect
installation. For instance, when you are moving from a local database to a full SQL Server database or when the Azure AD
Connect server was rebuilt and you restored a SQL backup of the ADSync database from an earlier installation of Azure AD
Connect. If the database is empty, that is, it doesn't contain any data from a previous Azure AD Connect installation, skip
this step.
1. You are greeted with the Welcome to Azure AD Connect screen. Once you agree to the license terms and
privacy notice, click Continue .
2. On the Install required components screen, the Use an existing SQL Ser ver option is enabled.
Specify the name of the SQL server that is hosting the ADSync database. If the SQL engine instance used to
host the ADSync database is not the default instance on the SQL server, you must specify the SQL engine
instance name. Further, if SQL browsing is not enabled, you must also specify the SQL engine instance port
number. For example:
3. On the Connect to Azure AD screen, you must provide the credentials of a global admin of your Azure
AD directory. The recommendation is to use an account in the default onmicrosoft.com domain. This
account is only used to create a service account in Azure AD and is not used after the wizard has completed.
4. On the Connect your directories screen, the existing AD forest configured for directory synchronization
is listed with a red cross icon beside it. To synchronize changes from an on-premises AD forest, an AD DS
account is required. The Azure AD Connect wizard is unable to retrieve the credentials of the AD DS account
stored in the ADSync database because the credentials are encrypted and can only be decrypted by the
previous Azure AD Connect server. Click Change Credentials to specify the AD DS account for the AD
forest.
5. In the pop-up dialog, you can either (i) provide an Enterprise Admin credential and let Azure AD Connect
create the AD DS account for you, or (ii) create the AD DS account yourself and provide its credential to
Azure AD Connect. Once you have selected an option and provide the necessary credentials, click OK to
close the pop-up dialog.
6. Once the credentials are provided, the red cross icon is replaced with a green tick icon. Click Next .
8. Once installation completes, the Azure AD Connect server is automatically enabled for Staging Mode. It is
recommended that you review the server configuration and pending exports for unexpected changes
before disabling Staging Mode.
Post installation tasks

When restoring a database backup created by a version of Azure AD Connect prior to 1.2.65.0, the staging server
will automatically select a sign-in method of Do Not Configure . While your password hash sync and password
writeback preferences will be restored, you must subsequently change the sign-in method to match the other
policies in effect for your active synchronization server. Failure to complete these steps may prevent users from
signing in should this server becomes active.
Use the table below to verify any additional steps that are required.
F EAT URE ST EP S
Password Hash Synchronization the Password Hash Synchronization and Password writeback
settings are fully restored for versions of Azure AD Connect
starting with 1.2.65.0. If restoring using an older version of
Azure AD Connect, review the synchronization option settings
for these features to ensure they match your active
synchronization server. No other configuration steps should
be necessary.
Federation with AD FS Azure authentications will continue to use the AD FS policy

configured for your active synchronization server. If you use
Azure AD Connect to manage your AD FS farm, you may
optionally change the sign-in method to AD FS federation in
preparation for your standby server becoming the active
synchronization instance. If device options are enabled on the
active synchronization server, configure those options on this
server by running the "Configure device options" task.
Pass-through authentication and Desktop Single Sign-On Update the sign in method to match the configuration on
your active synchronization server. If this is not followed
before promoting the server to primary, pass-through
authentication along with Seamless Single Sign on will be
disabled and your tenant might be locked out if you don’t
have password hash sync as back-up sign in option. Also note
that when you enable pass-through authentication in staging
mode, a new authentication agent will be installed, registered
and will run as a high-availability agent which will accept sign
in requests.
Federation with PingFederate Azure authentications will continue to use the PingFederate
policy configured for your active synchronization server. You
may optionally change the sign-in method to PingFederate in
preparation for your standby server becoming the active
synchronization instance. This step may be deferred until you
need to federate additional domains with PingFederate.
Next steps
Learn more about these features, which were enabled with the installation: Prevent accidental deletes and
Install Azure AD Connect using SQL delegated
administrator permissions
Prior to the latest Azure AD Connect build, administrative delegation, when deploying configurations that required
SQL, was not supported. Users who wanted to install Azure AD Connect needed to have server administrator (SA)
permissions on the SQL server.
With the latest release of Azure AD Connect, 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.
Before you begin

To use this feature, you need to realize that there are several moving parts and each one may involve a different
administrator in your organization. The following table summarizes the individual roles and their respective duties
in deploying Azure AD Connect with this feature.
RO L E DESC RIP T IO N
Domain or Forest AD administrator Creates the domain level service account that is used by
Azure AD Connect to run the sync service. For more
information on service accounts, see Accounts and
permissions.
SQL administrator Creates the ADSync database and grants login + dbo access
to the Azure AD Connect administrator and the service
account created by the domain/forest admin.
Azure AD Connect administrator Installs Azure AD Connect and specifies the service account
during custom installation.
Steps for installing Azure AD Connect using SQL delegated permissions

To provision the database out of band and install Azure AD Connect with database owner permissions, use the
following steps.
NOTE
Although it is not required, it is highly recommended that the Latin1_General_CI_AS collation is selected when creating
the database.
1. Have the SQL Administrator create the ADSync database with a case insensitive collation sequence
(Latin1_General_CI_AS) . The database must be named ADSync . The recovery model, compatibility level,
and containment type are updated to the correct values when Azure AD Connect is installed. However the
collation sequence must be set correctly by the SQL administrator otherwise Azure AD Connect will block
the installation. To recover the SA must delete and recreate the database.
2. Grant the Azure AD Connect administrator and the domain service account the following permissions:
SQL Login
database owner(dbo) rights.
NOTE
Azure AD Connect does not support logins with a nested membership. This means your Azure AD Connect
administrator account and domain service account must be linked to a login that is granted dbo rights. It cannot
simply be the member of a group that is assigned to a login with dbo rights.
3. Send an email to the Azure AD Connect administrator indicating the SQL server and instance name that
should be used when installing Azure AD Connect.
Additional information
Once the database is provisioned, the Azure AD Connect administrator can install and configure on-premises
synchronization at their convenience.
In case the SQL Administrator has restored ADSync database from a previous Azure AD Connect backup, you will
need to install the new Azure AD Connect server by using an existing database. For more information on installing
Azure AD Connect with an existing database, see Install Azure AD Connect using an existing ADSync database.
Next steps
Getting started with Azure AD Connect using express settings
Install Azure AD Connect using an existing ADSync database
Upgrade preview Authentication Agents
Overview
This article is for customers using Azure AD Pass-through Authentication through preview. We recently upgraded
(and rebranded) the Authentication Agent software. You need to manually upgrade preview Authentication Agents
installed on your on-premises servers. This manual upgrade is a one-time action only. All future updates to
Authentication Agents are automatic. The reasons to upgrade are as follows:
The preview versions of Authentication Agents will not receive any further security or bug fixes.
The preview versions of Authentication Agents can't be installed on additional servers, for high availability.
Check versions of your Authentication Agents

Step 1: Check where your Authentication Agents are installed
Follow these steps to check where your Authentication Agents are installed:
1. Sign in to the Azure Active Directory admin center with the Global Administrator credentials for your tenant.
2. Select Azure Active Director y on the left-hand navigation.
4. Select Pass-through Authentication . This blade lists the servers where your Authentication Agents are
installed.
Step 2: Check the versions of your Authentication Agents

To check the versions of your Authentication Agents, on each server identified in the preceding step, follow these
instructions:
1. Go to Control Panel -> Programs -> Programs and Features on the on-premises server.
2. If there is an entry for "Microsoft Azure AD Connect Authentication Agent ", you don't need to take any
action on this server.
3. If there is an entry for "Microsoft Azure AD Application Proxy Connector ", you need to manually upgrade
on this server.
Best practices to follow before starting the upgrade
Before upgrading, ensure that you have the following items in place:
1. Create cloud-only Global Administrator account : Don’t upgrade without having a cloud-only Global
Administrator account to use in emergency situations where your Pass-through Authentication Agents are not
working properly. Learn about adding a cloud-only Global Administrator account. Doing this step is critical and
ensures that you don't get locked out of your tenant.
2. Ensure high availability : If not completed previously, install a second standalone Authentication Agent to
provide high availability for sign-in requests, using these instructions.
Upgrading the Authentication Agent on your Azure AD Connect server

You need upgrade Azure AD Connect before upgrading the Authentication Agent on the same server. Follow these
steps on both your primary and staging Azure AD Connect servers:
1. Upgrade Azure AD Connect : Follow this article and upgrade to the latest Azure AD Connect version.
2. Uninstall the preview version of the Authentication Agent : Download this PowerShell script and run it
as an Administrator on the server.
3. Download the latest version of the Authentication Agent (versions 1.5.389.0 or later) : Sign in to the
Azure Active Directory admin center with your tenant's Global Administrator credentials. Select Azure Active
Director y -> Azure AD Connect -> Pass-through Authentication -> Download agent . Accept the
terms of service and download the latest version of the Authentication Agent. You can also download the
Authentication Agent from here.
4. Install the latest version of the Authentication Agent : Run the executable downloaded in Step 3. Provide
your tenant's Global Administrator credentials when prompted.
5. Verify that the latest version has been installed : As shown before, go to Control Panel -> Programs -
> Programs and Features and verify that there is an entry for "Microsoft Azure AD Connect
Authentication Agent ".
NOTE
If you check the Pass-through Authentication blade on the Azure Active Directory admin center after completing the
preceding steps, you'll see two Authentication Agent entries per server - one entry showing the Authentication Agent as
Active and the other as Inactive . This is expected. The Inactive entry is automatically dropped after a few days.
Upgrading the Authentication Agent on other servers

Follow these steps to upgrade Authentication Agents on other servers (where Azure AD Connect is not installed):
1. Uninstall the preview version of the Authentication Agent : Download this PowerShell script and run it
as an Administrator on the server.
2. Download the latest version of the Authentication Agent (versions 1.5.389.0 or later) : Sign in to the
Azure Active Directory admin center with your tenant's Global Administrator credentials. Select Azure Active
Director y -> Azure AD Connect -> Pass-through Authentication -> Download agent . Accept the
terms of service and download the latest version.
3. Install the latest version of the Authentication Agent : Run the executable downloaded in Step 2. Provide
your tenant's Global Administrator credentials when prompted.
4. Verify that the latest version has been installed : As shown before, go to Control Panel -> Programs -
> Programs and Features and verify that there is an entry called Microsoft Azure AD Connect
Authentication Agent .
NOTE
If you check the Pass-through Authentication blade on the Azure Active Directory admin center after completing the
preceding steps, you'll see two Authentication Agent entries per server - one entry showing the Authentication Agent as
Active and the other as Inactive . This is expected. The Inactive entry is automatically dropped after a few days.
Next steps
Move Azure AD Connect database from SQL Server
Express to SQL Server
This document describes how to move the Azure AD Connect database from the local SQL Server Express server to
a remote SQL Server. You can use the following procedures below to accomplish this task.
About this scenario

The following is some brief information about this scenario. In this scenario, Azure AD Connect version (1.1.819.0)
is installed on a single Windows Server 2016 domain controller. It is using the built-in SQL Server 2012 Express
Edition for its database. The database will be moved to a SQL Server 2017 server.
Move the Azure AD Connect database

Use the following steps to move the Azure AD Connect database to a remote SQL Server.
1. On the Azure AD Connect server, go to Ser vices and stop the Microsoft Azure AD Sync service.
2. Locate the %ProgramFiles%\Microsoft Azure AD Sync\Data folder and copy the ADSync.mdf and
ADSync_log.ldf files to the remote SQL Server.
3. Restart the Microsoft Azure AD Sync service on the Azure AD Connect server.
4. Un-install Azure AD Connect by going to Control Panel - - Programs - Programs and Features. Select
Microsoft Azure AD Connect and click uninstall at the top.
5. On the remote SQL server, open SQL Server Management Studio.
6. On Databases, right-click and select Attach.
7. On the Attach Databases screen, click Add and navigate to the ADSync.mdf file. Click OK .
8. Once the database is attached, go back to the Azure AD Connect server and install Azure AD Connect.
9. Once the MSI installation completes, the Azure AD Connect wizard starts with the Express mode setup. Close
the screen by clicking the Exit icon.
10. Start a new command prompt or PowerShell session. Navigate to folder <drive>\program files\Microsoft
Azure AD Connect. Run command .\AzureADConnect.exe /useexistingdatabase to start the Azure AD
Connect wizard in “Use existing database” setup mode.
11. You are greeted with the Welcome to Azure AD Connect screen. Once you agree to the license terms and
privacy notice, click Continue .
12. On the Install required components screen, the Use an existing SQL Ser ver option is enabled. Specify
the name of the SQL server that is hosting the ADSync database. If the SQL engine instance used to host the
ADSync database is not the default instance on the SQL server, you must specify the SQL engine instance
name. Further, if SQL browsing is not enabled, you must also specify the SQL engine instance port number.
For example:
13. On the Connect to Azure AD screen, you must provide the credentials of a global admin of your Azure AD
directory. The recommendation is to use an account in the default onmicrosoft.com domain. This account is
only used to create a service account in Azure AD and is not used after the wizard has completed.
14. On the Connect your directories screen, the existing AD forest configured for directory synchronization is
listed with a red cross icon beside it. To synchronize changes from an on-premises AD forest, an AD DS
account is required. The Azure AD Connect wizard is unable to retrieve the credentials of the AD DS account
stored in the ADSync database because the credentials are encrypted and can only be decrypted by the
previous Azure AD Connect server. Click Change Credentials to specify the AD DS account for the AD
forest.
15. In the pop-up dialog, you can either (i) provide an Enterprise Admin credential and let Azure AD Connect
create the AD DS account for you, or (ii) create the AD DS account yourself and provide its credential to
Azure AD Connect. Once you have selected an option and provide the necessary credentials, click OK to
close the pop-up dialog.
16. Once the credentials are provided, the red cross icon is replaced with a green tick icon. Click Next .

18. Once installation completes, the Azure AD Connect server is automatically enabled for Staging Mode. It is
recommended that you review the server configuration and pending exports for unexpected changes before
disabling Staging Mode.
Next steps
Install Azure AD Connect using an existing ADSync database
Install Azure AD Connect using SQL delegated administrator permissions
Azure AD Connect: When you have an existing
tenant
Most of the topics for how to use Azure AD Connect assumes you start with a new Azure AD tenant and that there
are no users or other objects there. But if you have started with an Azure AD tenant, populated it with users and
other objects, and now want to use Connect, then this topic is for you.
The basics
An object in Azure AD is either mastered in the cloud (Azure AD) or on-premises. For one single object, you cannot
manage some attributes on-premises and some other attributes in Azure AD. Each object has a flag indicating
where the object is managed.
You can manage some users on-premises and other in the cloud. A common scenario for this configuration is an
organization with a mix of accounting workers and sales workers. The accounting workers have an on-premises AD
account, but the sales workers do not, they have an account in Azure AD. You would manage some users on-
premises and some in Azure AD.
If you started to manage users in Azure AD that are also in on-premises AD and later want to use Connect, then
there are some additional concerns you need to consider.
Sync with existing users in Azure AD

When you install Azure AD Connect and you start synchronizing, the Azure AD sync service (in Azure AD) does a
check on every new object and tries to find an existing object to match. There are three attributes used for this
process: userPrincipalName , proxyAddresses , and sourceAnchor /immutableID . A match on
userPrincipalName and proxyAddresses is known as a soft match . A match on sourceAnchor is known as
hard match . For the proxyAddresses attribute only the value with SMTP:, that is the primary email address, is
used for the evaluation.
The match is only evaluated for new objects coming from Connect. If you change an existing object so it is
matching any of these attributes, then you see an error instead.
If Azure AD finds an object where the attribute values are the same for an object coming from Connect and that it is
already present in Azure AD, then the object in Azure AD is taken over by Connect. The previously cloud-managed
object is flagged as on-premises managed. All attributes in Azure AD with a value in on-premises AD are
overwritten with the on-premises value. The exception is when an attribute has a NULL value on-premises. In this
case, the value in Azure AD remains, but you can still only change it on-premises to something else.
WARNING
Since all attributes in Azure AD are going to be overwritten by the on-premises value, make sure you have good data on-
premises. For example, if you only have managed email address in Office 365 and not kept it updated in on-premises AD DS,
then you lose any values in Azure AD/Office 365 not present in AD DS.
IMPORTANT
If you use password sync, which is always used by express settings, then the password in Azure AD is overwritten with the
password in on-premises AD. If your users are used to manage different passwords, then you need to inform them that they
should use the on-premises password when you have installed Connect.
The previous section and warning must be considered in your planning. If you have made many changes in Azure
AD not reflected in on-premises AD DS, then you need to plan for how to populate AD DS with the updated values
before you sync your objects with Azure AD Connect.
If you matched your objects with a soft-match, then the sourceAnchor is added to the object in Azure AD so a
hard match can be used later.
IMPORTANT
Microsoft strongly recommends against synchronizing on-premises accounts with pre-existing administrative accounts in
Azure Active Directory.
Hard-match vs Soft-match
For a new installation of Connect, there is no practical difference between a soft- and a hard-match. The difference
is in a disaster recovery situation. If you have lost your server with Azure AD Connect, you can reinstall a new
instance without losing any data. An object with a sourceAnchor is sent to Connect during initial install. The match
can then be evaluated by the client (Azure AD Connect), which is a lot faster than doing the same in Azure AD. A
hard match is evaluated both by Connect and by Azure AD. A soft match is only evaluated by Azure AD.
Other objects than users
For mail-enabled groups and contacts, you can soft-match based on proxyAddresses. Hard-match is not applicable
since you can only update the sourceAnchor/immutableID (using PowerShell) on Users only. For groups that aren't
mail-enabled, there is currently no support for soft-match or hard-match.
Admin role considerations
To prevent untrusted on-premises users from matching with a cloud user that has any admin role, Azure AD
Connect will not match on-premises user objects with objects that have an admin role. This is by default. To
workaround this behavior you can do the following:
1. Remove the directory roles from the cloud-only user object.
2. If there was a failed user sync attempt, hard delete the Quarantined object in the cloud.
3. Trigger a sync.
4. Optionally add the directory roles back to the user object in cloud once the matching has occurred.
Create a new on-premises Active Directory from data in Azure AD

Some customers start with a cloud-only solution with Azure AD and they do not have an on-premises AD. Later
they want to consume on-premises resources and want to build an on-premises AD based on Azure AD data. Azure
AD Connect cannot help you for this scenario. It does not create users on-premises and it does not have any ability
to set the password on-premises to the same as in Azure AD.
If the only reason why you plan to add on-premises AD is to support LOBs (Line-of-Business apps), then maybe you
should consider to use Azure AD domain services instead.
Next steps
Next steps and how to manage Azure AD Connect
Use the operational procedures in this article to customize Azure Active Directory (Azure AD) Connect to meet
your organization's needs and requirements.
Add additional sync admins

By default, only the user who did the installation and local admins are able to manage the installed sync engine.
For additional people to be able to access and manage the sync engine, locate the group named ADSyncAdmins
on the local server and add them to this group.
Assign licenses to Azure AD Premium and Enterprise Mobility Suite

users
Now that your users have been synchronized to the cloud, you need to assign them a license so they can get
going with cloud apps such as Office 365.
To assign an Azure AD Premium or Enterprise Mobility Suite License
1. Sign in to the Azure portal as an admin.
2. On the left, select Active Director y .
3. On the Active Director y page, double-click the directory that has the users you want to set up.
4. At the top of the directory page, select Licenses .
5. On the Licenses page, select Active Director y Premium or Enterprise Mobility Suite , and then click
Assign .
6. In the dialog box, select the users you want to assign licenses to, and then click the check mark icon to save the
changes.
Verify the scheduled synchronization task

Use the Azure portal to check the status of a synchronization.
To verify the scheduled synchronization task
1. Sign in to the Azure portal as an admin.
2. On the left, select Active Director y .
3. On the left, select Azure AD Connect
4. At the top of the page, note the last synchronization.
Start a scheduled synchronization task

If you need to run a synchronization task, you can do this by:
1. Double-click on the Azure AD Connect desktop shortcut to start the wizard.
3. On the tasks screen, select the Customize synchronization options and click Next
4. Enter your Azure AD credentials
5. Click Next . Click Next . Click Next .
6. On the Ready to Configure screen, ensure that the Star t the synchronization process when
configuration completes box is selected.
For more information on the Azure AD Connect sync Scheduler, see Azure AD Connect Scheduler.
Additional tasks available in Azure AD Connect

After your initial installation of Azure AD Connect, you can always start the wizard again from the Azure AD
Connect start page or desktop shortcut. You will notice that going through the wizard again provides some new
options in the form of additional tasks.
The following table provides a summary of these tasks and a brief description of each task.
A DDIT IO N A L TA SK DESC RIP T IO N
Privacy Settings View what telemetry data is being shared with Microsoft.
View current configuration View your current Azure AD Connect solution. This includes
general settings, synchronized directories, and sync settings.
Customize synchronization options Change the current configuration like adding additional
Active Directory forests to the configuration, or enabling sync
options such as user, group, device, or password write-back.
Configure device options Device options available for synchronization

A DDIT IO N A L TA SK DESC RIP T IO N
Refresh director y schema Allows you to add new on-premises directory objects for
synchronization
Configure Staging Mode Stage information that is not immediately synchronized and is
not exported to Azure AD or on-premises Active Directory.
With this feature, you can preview the synchronizations
before they occur.
Change user sign-in Change the authentication method users are using to sign-in
Manage federation Manage your AD FS infrastructure, renew certificates, and

add AD FS servers
Troubleshoot Help with troubleshooting Azure AD Connect issues
Next steps
Azure AD Connect: Design concepts
The purpose of this document is to describe areas that must be thought through during the implementation
design of Azure AD Connect. This document is a deep dive on certain areas and these concepts are briefly
described in other documents as well.
sourceAnchor
The sourceAnchor attribute is defined as an attribute immutable during the lifetime of an object. It uniquely
identifies an object as being the same object on-premises and in Azure AD. The attribute is also called
immutableId and the two names are used interchangeable.
The word immutable, that is "cannot be changed", is important to this document. Since this attribute’s value
cannot be changed after it has been set, it is important to pick a design that supports your scenario.
The attribute is used for the following scenarios:
When a new sync engine server is built, or rebuilt after a disaster recovery scenario, this attribute links existing
objects in Azure AD with objects on-premises.
If you move from a cloud-only identity to a synchronized identity model, then this attribute allows objects to
"hard match" existing objects in Azure AD with on-premises objects.
If you use federation, then this attribute together with the userPrincipalName is used in the claim to uniquely
identify a user.
This topic only talks about sourceAnchor as it relates to users. The same rules apply to all object types, but it is
only for users this problem usually is a concern.
Selecting a good sourceAnchor attribute
The attribute value must follow the following rules:
Fewer than 60 characters in length
Characters not being a-z, A-Z, or 0-9 are encoded and counted as 3 characters
Not contain a special character: \ ! # $ % & * + / = ? ^ ` { } | ~ < > ( ) ' ; : , [ ] " @ _
Must be globally unique
Must be either a string, integer, or binary
Should not be based on user's name because these can change
Should not be case-sensitive and avoid values that may vary by case
Should be assigned when the object is created
If the selected sourceAnchor is not of type string, then Azure AD Connect Base64Encode the attribute value to
ensure no special characters appear. If you use another federation server than ADFS, make sure your server can
also Base64Encode the attribute.
The sourceAnchor attribute is case-sensitive. A value of “JohnDoe” is not the same as “johndoe”. But you should
not have two different objects with only a difference in case.
If you have a single forest on-premises, then the attribute you should use is objectGUID . This is also the attribute
used when you use express settings in Azure AD Connect and also the attribute used by DirSync.
If you have multiple forests and do not move users between forests and domains, then objectGUID is a good
attribute to use even in this case.
If you move users between forests and domains, then you must find an attribute that does not change or can be
moved with the users during the move. A recommended approach is to introduce a synthetic attribute. An
attribute that could hold something that looks like a GUID would be suitable. During object creation, a new GUID is
created and stamped on the user. A custom sync rule can be created in the sync engine server to create this value
based on the objectGUID and update the selected attribute in ADDS. When you move the object, make sure to
also copy the content of this value.
Another solution is to pick an existing attribute you know does not change. Commonly used attributes include
employeeID . If you consider an attribute that contains letters, make sure there is no chance the case (upper case
vs. lower case) can change for the attribute's value. Bad attributes that should not be used include those attributes
with the name of the user. In a marriage or divorce, the name is expected to change, which is not allowed for this
attribute. This is also one reason why attributes such as userPrincipalName , mail , and targetAddress are not
even possible to select in the Azure AD Connect installation wizard. Those attributes also contain the "@" character,
which is not allowed in the sourceAnchor.
Changing the sourceAnchor attribute
The sourceAnchor attribute value cannot be changed after the object has been created in Azure AD and the
identity is synchronized.
For this reason, the following restrictions apply to Azure AD Connect:
The sourceAnchor attribute can only be set during initial installation. If you rerun the installation wizard, this
option is read-only. If you need to change this setting, then you must uninstall and reinstall.
If you install another Azure AD Connect server, then you must select the same sourceAnchor attribute as
previously used. If you have earlier been using DirSync and move to Azure AD Connect, then you must use
objectGUID since that is the attribute used by DirSync.
If the value for sourceAnchor is changed after the object has been exported to Azure AD, then Azure AD
Connect sync throws an error and does not allow any more changes on that object before the issue has been
fixed and the sourceAnchor is changed back in the source directory.
Using ms-DS-ConsistencyGuid as sourceAnchor

By default, Azure AD Connect (version 1.1.486.0 and older) uses objectGUID as the sourceAnchor attribute.
ObjectGUID is system-generated. You cannot specify its value when creating on-premises AD objects. As explained
in section sourceAnchor, there are scenarios where you need to specify the sourceAnchor value. If the scenarios
are applicable to you, you must use a configurable AD attribute (for example, ms-DS-ConsistencyGuid) as the
sourceAnchor attribute.
Azure AD Connect (version 1.1.524.0 and after) now facilitates the use of ms-DS-ConsistencyGuid as
sourceAnchor attribute. When using this feature, Azure AD Connect automatically configures the synchronization
rules to:
1. Use ms-DS-ConsistencyGuid as the sourceAnchor attribute for User objects. ObjectGUID is used for other
object types.
2. For any given on-premises AD User object whose ms-DS-ConsistencyGuid attribute isn't populated, Azure
AD Connect writes its objectGUID value back to the ms-DS-ConsistencyGuid attribute in on-premises Active
Directory. After the ms-DS-ConsistencyGuid attribute is populated, Azure AD Connect then exports the
object to Azure AD.
NOTE
Once an on-premises AD object is imported into Azure AD Connect (that is, imported into the AD Connector Space and
projected into the Metaverse), you cannot change its sourceAnchor value anymore. To specify the sourceAnchor value for a
given on-premises AD object, configure its ms-DS-ConsistencyGuid attribute before it is imported into Azure AD Connect.
Permission required
For this feature to work, the AD DS account used to synchronize with on-premises Active Directory must be
granted write permission to the ms-DS-ConsistencyGuid attribute in on-premises Active Directory.
How to enable the ConsistencyGuid feature - New installation
You can enable the use of ConsistencyGuid as sourceAnchor during new installation. This section covers both
Express and Custom installation in details.
NOTE
Only newer versions of Azure AD Connect (1.1.524.0 and after) support the use of ConsistencyGuid as sourceAnchor during
new installation.
How to enable the ConsistencyGuid feature

Express Installation
When installing Azure AD Connect with Express mode, the Azure AD Connect wizard automatically determines the
most appropriate AD attribute to use as the sourceAnchor attribute using the following logic:
First, the Azure AD Connect wizard queries your Azure AD tenant to retrieve the AD attribute used as the
sourceAnchor attribute in the previous Azure AD Connect installation (if any). If this information is available,
Azure AD Connect uses the same AD attribute.
NOTE
Only newer versions of Azure AD Connect (1.1.524.0 and after) store information in your Azure AD tenant about the
sourceAnchor attribute used during installation. Older versions of Azure AD Connect do not.
If information about the sourceAnchor attribute used isn't available, the wizard checks the state of the ms-
DS-ConsistencyGuid attribute in your on-premises Active Directory. If the attribute isn't configured on any
object in the directory, the wizard uses the ms-DS-ConsistencyGuid as the sourceAnchor attribute. If the
attribute is configured on one or more objects in the directory, the wizard concludes the attribute is being
used by other applications and is not suitable as sourceAnchor attribute...
In which case, the wizard falls back to using objectGUID as the sourceAnchor attribute.
Once the sourceAnchor attribute is decided, the wizard stores the information in your Azure AD tenant. The
information will be used by future installation of Azure AD Connect.
Once Express installation completes, the wizard informs you which attribute has been picked as the Source Anchor
attribute.
Custom installation
When installing Azure AD Connect with Custom mode, the Azure AD Connect wizard provides two options when
configuring sourceAnchor attribute:

Let Azure manage the source anchor for me Select this option if you want Azure AD to pick the attribute
for you. If you select this option, Azure AD Connect wizard
applies the same sourceAnchor attribute selection logic used
during Express installation. Similar to Express installation, the
wizard informs you which attribute has been picked as the
Source Anchor attribute after Custom installation completes.
A specific attribute Select this option if you wish to specify an existing AD

attribute as the sourceAnchor attribute.
How to enable the ConsistencyGuid feature - Existing deployment

If you have an existing Azure AD Connect deployment which is using objectGUID as the Source Anchor attribute,
you can switch it to using ConsistencyGuid instead.
NOTE
Only newer versions of Azure AD Connect (1.1.552.0 and after) support switching from ObjectGuid to ConsistencyGuid as
the Source Anchor attribute.
To switch from objectGUID to ConsistencyGuid as the Source Anchor attribute:

1. Start the Azure AD Connect wizard and click Configure to go to the Tasks screen.
2. Select the Configure Source Anchor task option and click Next .
3. Enter your Azure AD Administrator credentials and click Next .

4. Azure AD Connect wizard analyzes the state of the ms-DS-ConsistencyGuid attribute in your on-premises
Active Directory. If the attribute isn't configured on any object in the directory, Azure AD Connect concludes
that no other application is currently using the attribute and is safe to use it as the Source Anchor attribute.
Click Next to continue.
5. In the Ready to Configure screen, click Configure to make the configuration change.
6. Once the configuration completes, the wizard indicates that ms-DS-ConsistencyGuid is now being used as
the Source Anchor attribute.
During the analysis (step 4), if the attribute is configured on one or more objects in the directory, the wizard
concludes the attribute is being used by another application and returns an error as illustrated in the diagram
below. This error can also occur if you have previously enabled the ConsistencyGuid feature on your primary
Azure AD Connect server and you are trying to do the same on your staging server.
If you are certain that the attribute isn't used by other existing applications, you can suppress the error by
restarting the Azure AD Connect wizard with the /SkipLdapSearch switch specified. To do so, run the following
command in command prompt:
"c:\Program Files\Microsoft Azure Active Directory Connect\AzureADConnect.exe" /SkipLdapSearch
Impact on AD FS or third-party federation configuration

If you are using Azure AD Connect to manage on-premises AD FS deployment, the Azure AD Connect
automatically updates the claim rules to use the same AD attribute as sourceAnchor. This ensures that the
ImmutableID claim generated by ADFS is consistent with the sourceAnchor values exported to Azure AD.
If you are managing AD FS outside of Azure AD Connect or you are using third-party federation servers for
authentication, you must manually update the claim rules for ImmutableID claim to be consistent with the
sourceAnchor values exported to Azure AD as described in article section Modify AD FS claim rules. The wizard
returns the following warning after installation completes:
Adding new directories to existing deployment

Suppose you have deployed Azure AD Connect with the ConsistencyGuid feature enabled, and now you would like
to add another directory to the deployment. When you try to add the directory, Azure AD Connect wizard checks
the state of the ms-DS-ConsistencyGuid attribute in the directory. If the attribute is configured on one or more
objects in the directory, the wizard concludes the attribute is being used by other applications and returns an error
as illustrated in the diagram below. If you are certain that the attribute isn't used by existing applications, you can
suppress the error by restarting the Azure AD Connect wizard with the /SkipLdapSearch switch specified as
described above or you need to contact Support for more information.
Azure AD sign-in
While integrating your on-premises directory with Azure AD, it is important to understand how the
synchronization settings can affect the way user authenticates. Azure AD uses userPrincipalName (UPN) to
authenticate the user. However, when you synchronize your users, you must choose the attribute to be used for
value of userPrincipalName carefully.
Choosing the attribute for userPrincipalName
When you are selecting the attribute for providing the value of UPN to be used in Azure one should ensure
The attribute values conform to the UPN syntax (RFC 822), that is it should be of the format
username@domain
The suffix in the values matches to one of the verified custom domains in Azure AD
In express settings, the assumed choice for the attribute is userPrincipalName. If the userPrincipalName attribute
does not contain the value you want your users to sign in to Azure, then you must choose Custom Installation .
Custom domain state and UPN
It is important to ensure that there is a verified domain for the UPN suffix.
John is a user in contoso.com. You want John to use the on-premises UPN john@contoso.com to sign in to Azure
after you have synced users to your Azure AD directory contoso.onmicrosoft.com. To do so, you need to add and
verify contoso.com as a custom domain in Azure AD before you can start syncing the users. If the UPN suffix of
John, for example contoso.com, does not match a verified domain in Azure AD, then Azure AD replaces the UPN
suffix with contoso.onmicrosoft.com.
Non-routable on-premises domains and UPN for Azure AD
Some organizations have non-routable domains, like contoso.local, or simple single label domains like contoso.
You are not able to verify a non-routable domain in Azure AD. Azure AD Connect can sync to only a verified
domain in Azure AD. When you create an Azure AD directory, it creates a routable domain that becomes default
domain for your Azure AD for example, contoso.onmicrosoft.com. Therefore, it becomes necessary to verify any
other routable domain in such a scenario in case you don't want to sync to the default onmicrosoft.com domain.
Read Add your custom domain name to Azure Active Directory for more info on adding and verifying domains.
Azure AD Connect detects if you are running in a non-routable domain environment and would appropriately
warn you from going ahead with express settings. If you are operating in a non-routable domain, then it is likely
that the UPN, of the users, have non-routable suffixes too. For example, if you are running under contoso.local,
Azure AD Connect suggests you to use custom settings rather than using express settings. Using custom settings,
you are able to specify the attribute that should be used as UPN to sign in to Azure after the users are synced to
Azure AD.
Next steps
Topologies for Azure AD Connect
This article describes various on-premises and Azure Active Directory (Azure AD) topologies that use Azure AD
Connect sync as the key integration solution. This article includes both supported and unsupported
configurations.
Here's the legend for pictures in the article:
DESC RIP T IO N SY M B O L
On-premises Active Directory forest
On-premises Active Directory with filtered import
Azure AD Connect sync server
Azure AD Connect sync server “staging mode”
GALSync with Forefront Identity Manager (FIM) 2010 or

Microsoft Identity Manager (MIM) 2016
Azure AD Connect sync server, detailed
Azure AD
Unsupported scenario
IMPORTANT
Microsoft doesn't support modifying or operating Azure AD Connect sync outside of the configurations or actions that are
formally documented. Any of these configurations or actions might result in an inconsistent or unsupported state of Azure
AD Connect sync. As a result, Microsoft can't provide technical support for such deployments.
Single forest, single Azure AD tenant
The most common topology is a single on-premises forest, with one or multiple domains, and a single Azure AD
tenant. For Azure AD authentication, password hash synchronization is used. The express installation of Azure AD
Connect supports only this topology.
Single forest, multiple sync servers to one Azure AD tenant
Having multiple Azure AD Connect sync servers connected to the same Azure AD tenant is not supported, except
for a staging server. It's unsupported even if these servers are configured to synchronize with a mutually
exclusive set of objects. You might have considered this topology if you can't reach all domains in the forest from
a single server, or if you want to distribute load across several servers.
Multiple forests, single Azure AD tenant
Many organizations have environments with multiple on-premises Active Directory forests. There are various
reasons for having more than one on-premises Active Directory forest. Typical examples are designs with
account-resource forests and the result of a merger or acquisition.
When you have multiple forests, all forests must be reachable by a single Azure AD Connect sync server. The
server must be joined to a domain. If necessary to reach all forests, you can place the server in a perimeter
network (also known as DMZ, demilitarized zone, and screened subnet).
The Azure AD Connect installation wizard offers several options to consolidate users who are represented in
multiple forests. The goal is that a user is represented only once in Azure AD. There are some common topologies
that you can configure in the custom installation path in the installation wizard. On the Uniquely identifying
your users page, select the corresponding option that represents your topology. The consolidation is configured
only for users. Duplicated groups are not consolidated with the default configuration.
Common topologies are discussed in the sections about separate topologies, full mesh, and the account-resource
topology.
The default configuration in Azure AD Connect sync assumes:
Each user has only one enabled account, and the forest where this account is located is used to authenticate
the user. This assumption is for password hash sync, pass-through authentication and federation.
UserPrincipalName and sourceAnchor/immutableID come from this forest.
Each user has only one mailbox.
The forest that hosts the mailbox for a user has the best data quality for attributes visible in the Exchange
Global Address List (GAL). If there's no mailbox for the user, any forest can be used to contribute these attribute
values.
If you have a linked mailbox, there's also an account in a different forest used for sign-in.
If your environment does not match these assumptions, the following things happen:
If you have more than one active account or more than one mailbox, the sync engine picks one and ignores
the other.
A linked mailbox with no other active account is not exported to Azure AD. The user account is not represented
as a member in any group. A linked mailbox in DirSync is always represented as a normal mailbox. This
change is intentionally a different behavior to better support multiple-forest scenarios.
You can find more details in Understanding the default configuration.
Multiple forests, multiple sync servers to one Azure AD tenant
Having more than one Azure AD Connect sync server connected to a single Azure AD tenant is not supported. The
exception is the use of a staging server.
This topology differs from the one below in that multiple sync ser vers connected to a single Azure AD tenant is
not supported.
Multiple forests, single sync server, users are represented in only one directory
In this environment, all on-premises forests are treated as separate entities. No user is present in any other forest.
Each forest has its own Exchange organization, and there's no GALSync between the forests. This topology might
be the situation after a merger/acquisition or in an organization where each business unit operates
independently. These forests are in the same organization in Azure AD and appear with a unified GAL. In the
preceding picture, each object in every forest is represented once in the metaverse and aggregated in the target
Azure AD tenant.
Multiple forests: match users
Common to all these scenarios is that distribution and security groups can contain a mix of users, contacts, and
Foreign Security Principals (FSPs). FSPs are used in Active Directory Domain Services (AD DS) to represent
members from other forests in a security group. All FSPs are resolved to the real object in Azure AD.
Multiple forests: full mesh with optional GALSync
A full mesh topology allows users and resources to be located in any forest. Commonly, there are two-way trusts
between the forests.
If Exchange is present in more than one forest, there might be (optionally) an on-premises GALSync solution.
Every user is then represented as a contact in all other forests. GALSync is commonly implemented through FIM
2010 or MIM 2016. Azure AD Connect cannot be used for on-premises GALSync.
In this scenario, identity objects are joined via the mail attribute. A user who has a mailbox in one forest is joined
with the contacts in the other forests.
Multiple forests: account-resource forest
In an account-resource forest topology, you have one or more account forests with active user accounts. You also
have one or more resource forests with disabled accounts.
In this scenario, one (or more) resource forest trusts all account forests. The resource forest typically has an
extended Active Directory schema with Exchange and Lync. All Exchange and Lync services, along with other
shared services, are located in this forest. Users have a disabled user account in this forest, and the mailbox is
linked to the account forest.
Office 365 and topology considerations

Some Office 365 workloads have certain restrictions on supported topologies:
W O RK LO A D REST RIC T IO N S
Exchange Online For more information about hybrid topologies supported by

Exchange Online, see Hybrid deployments with multiple
Active Directory forests.
Skype for Business When you're using multiple on-premises forests, only the
account-resource forest topology is supported. For more
information, see Environmental requirements for Skype for
Business Server 2015.
If you are a larger organization, then you should consider to use the Office 365 PreferredDataLocation feature. It
allows you to define in which datacenter region the user's resources are located.
Staging server
Azure AD Connect supports installing a second server in staging mode. A server in this mode reads data from all
connected directories but does not write anything to connected directories. It uses the normal synchronization
cycle and therefore has an updated copy of the identity data.
In a disaster where the primary server fails, you can fail over to the staging server. You do this in the Azure AD
Connect wizard. This second server can be located in a different datacenter because no infrastructure is shared
with the primary server. You must manually copy any configuration change made on the primary server to the
second server.
You can use a staging server to test a new custom configuration and the effect that it has on your data. You can
preview the changes and adjust the configuration. When you're happy with the new configuration, you can make
the staging server the active server and set the old active server to staging mode.
You can also use this method to replace the active sync server. Prepare the new server and set it to staging mode.
Make sure it's in a good state, disable staging mode (making it active), and shut down the currently active server.
It's possible to have more than one staging server when you want to have multiple backups in different
datacenters.
Multiple Azure AD tenants

We recommend having a single tenant in Azure AD for an organization. Before you plan to use multiple Azure AD
tenants, see the article Administrative units management in Azure AD. It covers common scenarios where you can
use a single tenant.
There's a 1:1 relationship between an Azure AD Connect sync server and an Azure AD tenant. For each Azure AD
tenant, you need one Azure AD Connect sync server installation. The Azure AD tenant instances are isolated by
design. That is, users in one tenant can't see users in the other tenant. If you want this separation, this is a
supported configuration. Otherwise, you should use the single Azure AD tenant model.
Each object only once in an Azure AD tenant
In this topology, one Azure AD Connect sync server is connected to each Azure AD tenant. The Azure AD Connect
sync servers must be configured for filtering so that each has a mutually exclusive set of objects to operate on.
You can, for example, scope each server to a particular domain or organizational unit.
A DNS domain can be registered in only a single Azure AD tenant. The UPNs of the users in the on-premises
Active Directory instance must also use separate namespaces. For example, in the preceding picture, three
separate UPN suffixes are registered in the on-premises Active Directory instance: contoso.com, fabrikam.com,
and wingtiptoys.com. The users in each on-premises Active Directory domain use a different namespace.
NOTE
Global Address List Synchronization (GalSync) is not done automatically in this topology and requires an additional custom
MIM implementation to ensure each tenant has a complete Global Address List (GAL) in Exchange Online and Skype for
Business Online.
This topology has the following restrictions on otherwise supported scenarios:

Only one of the Azure AD tenants can enable an Exchange hybrid with the on-premises Active Directory
instance.
Windows 10 devices can be associated with only one Azure AD tenant.
The single sign-on (SSO) option for password hash synchronization and pass-through authentication can be
used with only one Azure AD tenant.
The requirement for a mutually exclusive set of objects also applies to writeback. Some writeback features are not
supported with this topology because they assume a single on-premises configuration. These features include:
Group writeback with default configuration.
Device writeback.
Each object multiple times in an Azure AD tenant
These tasks are unsupported:

Sync the same user to multiple Azure AD tenants.
Make a configuration change so that users in one Azure AD tenant appear as contacts in another Azure AD
tenant.
Modify Azure AD Connect sync to connect to multiple Azure AD tenants.
GALSync by using writeback
Azure AD tenants are isolated by design. These tasks are unsupported:

Change the configuration of Azure AD Connect sync to read data from another Azure AD tenant.
Export users as contacts to another on-premises Active Directory instance by using Azure AD Connect sync.
GALSync with on-premises sync server
You can use FIM 2010 or MIM 2016 on-premises to sync users (via GALSync) between two Exchange
organizations. The users in one organization appear as foreign users/contacts in the other organization. These
different on-premises Active Directory instances can then be synchronized with their own Azure AD tenants.
Using unauthorized clients to access the Azure AD Connect backend
The Azure Active Directory Connect server communicates with Azure Active Directory through the Azure Active
Directory Connect backend. The only software that can be used to communicate with this backend is Azure Active
Directory Connect. It is not supported to communicate with the Azure Active Directory Connect backend using
any other software or method.
Next steps
To learn how to install Azure AD Connect for these scenarios, see Custom installation of Azure AD Connect.
Factors influencing the performance of Azure AD
Connect
Azure AD Connect syncs your Active Directory to Azure AD. This server is a critical component of moving your user
identities to the cloud. The primary factors that affect the performance of an Azure AD Connect are:
DESIGN FA C TO R DEF IN IT IO N
Topology The distribution of the endpoints and components Azure AD

Connect must manage on the network.
Scale The number of objects like the users, groups, and OUs, to be
managed by Azure AD Connect.
Hardware The hardware (physical or virtual) for the Azure AD Connect

and dependent performance capacity of each hardware
component including CPU, memory, network, and hard drive
configuration.
Configuration How Azure AD Connect processes the directories and

information.
Load Frequency of object changes. The loads may vary during an

hour, day, or week. Depending on the component, you may
have to design for peak load or average load.
The purpose of this document is to describe the factors influencing the performance of the Azure AD Connect
provisioning engine. Large or complex organizations (organizations provisioning more than 100,000 objects) can
use the recommendations to optimize their Azure AD Connect implementation, if they experience any performance
issues outlined here. The other components of Azure AD Connect, such as Azure AD Connect health and agents
aren't covered here.
IMPORTANT
Microsoft doesn't support modifying or operating Azure AD Connect outside of the actions that are formally documented.
Any of these actions might result in an inconsistent or unsupported state of Azure AD Connect sync. As a result, Microsoft
can't provide technical support for such deployments.
Azure AD Connect component factors

The following diagram shows a high-level architecture of provisioning engine connecting to a single forest,
although multiple forests are supported. This architecture shows how the various components interact with each
other.
The provisioning engine connects to each Active Directory forest and to Azure AD. The process of reading
information from each directory is called Import. Export refers to updating the directories from the provisioning
engine. Sync evaluates the rules of how the objects will flow inside the provisioning engine. For a deeper dive you
can refer to Azure AD Connect sync: Understanding the architecture.
Azure AD Connect uses the following staging areas, rules, and processes to allow the sync from Active Directory to
Azure AD:
Connector Space (CS) - Objects from each connected directory (CD), the actual directories, are staged here
first before they can be processed by the provisioning engine. Azure AD has its own CS and each forest you
connect to has its own CS.
Metaverse (MV) - Objects that need to be synced are create here based on the sync rules. Objects must exist in
the MV before they can populate objects and attributes to the other connected directories. There's only one MV.
Sync rules - They decide which objects will be created (projected) or connected ( joined) to objects in the MV.
The sync rules also decide which attribute values will be copied or transformed to and from the directories.
Run profiles - Bundles the process steps of copying objects and their attribute values according to the sync
rules between the staging areas and connected directories.
Different run profiles exist to optimize the performance of the provisioning engine. Most organizations will use the
default schedules and run profiles for normal operations, but some organizations may have to change the schedule
or trigger other run profiles to cater for uncommon situations. The following run profiles are available:
Initial sync profile
The Initial sync profile is the process of reading the connected directories, like an Active Directory forest, for the first
time. It then does an analysis on all entries in the sync engine database. The initial cycle will create new objects in
Azure AD and will take extra time to complete if your Active Directory forests are large. The initial sync includes the
following steps:
1. Full import on all connectors
2. Full sync on all connectors
3. Export on all connectors
Delta sync profile
To optimize the sync process this run profile only process the changes (creates, deletes and updates) of objects in
your connected directories, since the last sync process. By default, the delta sync profile runs every 30 minutes.
Organizations should strive to keep the time it takes to below 30 minutes, to make sure the Azure AD is up-to-date.
To monitor the health of Azure AD Connect, use the health monitoring agent to see any issues with the process. The
delta sync profile includes the following steps:
1. Delta import on all connectors
2. Delta sync on all connectors
A typical enterprise organization delta sync scenario is:
~1% of objects are deleted
~1% of objects are created
~5% of objects are modified
Your rate of change may vary depending on how often your organization updates users in your Active Directory.
For example, higher rates of change can occur with the seasonality of hiring and reducing work force.
Full sync profile
A full sync cycle is required if you have made any of the following configuration changes:
Increased the scope of the objects or attributes to be imported from the connected directories. For example,
when you add a domain or OU to your import scope.
Made changes to the sync rules. For example, when you create a new rule to populate a user’s title in Azure AD
from extension_attribute3 in Active Directory. This update requires that the provisioning engine re-examine all
existing users to update their titles to apply the change going forward.
The following operations are included in a full sync cycle:
1. Full import on all connectors
2. Full/Delta sync on all connectors
NOTE
Careful planning is required when doing bulk updates to many objects in your Active Directory or Azure AD. Bulk updates will
cause the delta sync process to take longer when importing, since a lot of objects have changed. Long imports can happen
even if the bulk update doesn't influence the sync process. For example, assigning licenses to many users in Azure AD will
cause a long import cycle from Azure AD, but will not result in any attribute changes in Active Directory.
Synchronization
The sync process runtime has the following performance characteristics:
Sync is single threaded, meaning the provisioning engine doesn't do any parallel processing of run profiles of
connected directories, objects, or attributes.
Import time grows linearly with the number of objects being synced. For example, if 10,000 objects take 10
minutes to import, then 20,000 objects will take approximately 20 minutes on the same server.
Export is also linear.
The sync will grow exponentially based on the number of objects with references to other objects. Group
memberships and nested groups have the main performance impact, because their members refer to user
objects or other groups. These references must be found and referenced to actual objects in the MV to complete
the sync cycle.
Filtering
The size of the Active Directory topology you want to import is the number one factor influencing the performance
and overall time the internal components of the provisioning engine will take.
Filtering should be used to reduce the objects to the synced. It will prevent unnecessary objects from being
processed and exported to Azure AD. In order of preference, the following techniques of filtering are available:
Domain-based filtering – use this option to select specific domains to sync to Azure AD. You must add and
remove domains from the sync engine configuration when you make changes to your on-premises
infrastructure after you install Azure AD Connect sync.
Organization Unit (OU) filtering - uses OUs to target specific objects in Active Directory domains for
provisioning to Azure AD. OU filtering is the second recommended filtering mechanism, because it uses simple
LDAP scope queries to import a smaller subset of objects from Active Directory.
Attribute filtering per object - uses the attribute values on objects to decide whether specific object in Active
Directory is provisioned in Azure AD. Attribute filtering is great for fine-tuning your filters, when domain and OU
filtering doesn't meet the specific filtering requirements. Attribute filtering doesn't reduce the import time but
can reduce sync and export times.
Group-based filtering - uses group membership to decide whether objects should be provisioned in Azure
AD. Group-based filtering is only suited for testing situations and not recommended for production, because of
the extra overhead required to check group membership during the sync cycle.
Many persistent disconnector objects in your Active Directory CS can cause longer sync times, because the
provisioning engine must reevaluate each disconnector object for possible connection in the sync cycle. To
overcome this issue, consider one of the following recommendations:
Place the disconnector objects out of scope for import using domain or OU filtering.
Project/join the objects to the MV and set the cloudFiltered attribute equal to True, to prevent provisioning of
these objects in the Azure AD CS.
NOTE
Users can get confused or application permissions issues can occur, when too many objects are filtered. For example, in a
hybrid Exchange online implementation, users with on-premises mailboxes will see more users in their global address list than
users with mailboxes in Exchange online. In other cases, a user may want to grant access in a cloud app to another user which
is not part of the scope of the filtered set of objects.
Attribute flows
Attribute flows is the process for copying or transforming the attribute values of objects from one connected
directory to another connected directory. They're defined as part of the sync rules. For example, when the
telephone number of a user is changed in your Active Directory, the telephone number in Azure AD will be updated.
Organizations can modify the attribute flows to suite various requirements. It's recommended you copy the existing
attribute flows before changing them.
Simple redirects, like flowing an attribute value to a different attribute doesn't have material performance impact.
An example of a redirect is flowing a mobile number in Active Directory to the office phone number in Azure AD.
Transforming attribute values can have a performance impact on the sync process. Transforming attribute values
includes modifying, reformatting, concatenating, or subtracting values of attributes.
Organizations can prevent certain attributes to flow to Azure AD, but it won't influence the performance of the
provisioning engine.
NOTE
Don’t delete unwanted attribute flows in your sync rules. It is recommended you rather disable them, because deleted rules
are recreated during Azure AD Connect upgrades.
Azure AD Connect dependency factors

The performance of Azure AD Connect is dependent on the performance of the connected directories it imports
and exports to. For example, the size of the Active Directory it needs to import or the network latency to the Azure
AD service. The SQL database that the provisioning engine uses also impacts the overall performance of the sync
cycle.
Active Directory factors
As mentioned previously, the number of objects to be imported influences the performance significantly. The
hardware and prerequisites for Azure AD Connect outline specific hardware tiers based on the size of your
deployment. Azure AD Connect only support specific topologies as outlined in Topologies for Azure AD Connect.
There are no performance optimizations and recommendations for unsupported topologies.
Make sure your Azure AD Connect server meets the hardware requirements based on your Active Directory size
you want to import. Bad or slow network connectivity between the Azure AD Connect server and your Active
Directory domain controllers can slow down your import.
Azure AD factors
Azure AD uses throttling to protect the cloud service from denial-of-service (DoS) attacks. Currently Azure AD has a
throttling limit of 7,000 writes per 5 minutes (84,000 per hour). For example, the following operations can be
throttled:
Azure AD Connect export to Azure AD.
PowerShell scripts or applications updating the Azure AD directly even in the background, such as Dynamic
group memberships.
Users updating their own identity records such as registering for MFA or SSPR (self-service password reset).
Operations within the graphical user interface.
Plan for deployment and maintenance tasks, to make sure your Azure AD Connect sync cycle is not impacted by
throttling limits. For example, if you have a large hiring wave where you create thousands of user identities, it can
cause updates to dynamic group memberships, licensing assignments, and self-service password reset
registrations. It's better to spread these writes over several hours or a few days.
SQL database factors
The size of your source Active Directory topology will influence your SQL database performance. Follow the
hardware requirements for the SQL server database and consider the following recommendations:
Organizations with more than 100,000 users can reduce network latencies by colocating SQL database and the
provisioning engine on the same server.
Due to the high disk input and output (I/O) requirements of the sync process, use Solid State Drives (SSD) for
the SQL database of the provisioning engine for optimal results, if not possible, consider RAID 0 or RAID 1
configurations.
Don’t do a full sync preemptively; it causes unnecessary churn and slower response times.
Conclusion
To optimize the performance of your Azure AD Connect implementation, consider the following recommendations:
Use the recommended hardware configuration based on your implementation size for the Azure AD Connect
server.
When upgrading Azure AD Connect in large-scale deployments, consider using swing migration method, to
make sure you have the least downtime and best reliability.
Use SSD for the SQL database for best writing performance.
Filter the Active Directory scope to only include objects that need to be provisioned in Azure AD, using domain,
OU, or attribute filtering.
If you require to change the default attribute flow rules, first copy the rule, then change the copy and disable the
original rule. Remember to rerun a full sync.
Plan adequate time for the initial full sync run profile.
Strive to complete the delta sync cycle in 30 minutes. If the delta sync profile doesn’t complete in 30 minutes,
modify the default sync frequency to include a complete delta sync cycle.
Monitor your Azure AD Connect sync health in Azure AD.
Next steps
Azure AD Connect user sign-in options
Azure Active Directory (Azure AD) Connect allows your users to sign in to both cloud and on-premises resources
by using the same passwords. This article describes key concepts for each identity model to help you choose the
identity that you want to use for signing in to Azure AD.
If you’re already familiar with the Azure AD identity model and want to learn more about a specific method, see
the appropriate link:
Password hash synchronization with Seamless Single Sign-on (SSO)
Pass-through authentication with Seamless Single Sign-on (SSO)
Federated SSO (with Active Directory Federation Services (AD FS))
NOTE
It is important to remember that by configuring federation for Azure AD, you establish trust between your Azure AD tenant
and your federated domains. With this trust federated domain users will have access to Azure AD cloud resources within the
tenant.
Choosing the user sign-in method for your organization

The first decision of implementing Azure AD Connect is choosing which authentication method your users will use
to sign in. It's important to make sure you choose the right method that meets your organization's security and
advanced requirements. Authentication is critical, because it will validate user's identities to access apps and data
in the cloud. To choose the right authentication method, you need to consider the time, existing infrastructure,
complexity, and cost of implementing your choice. These factors are different for every organization and might
change over time.
Azure AD supports the following authentication methods:
Cloud Authentication - When you choose this authentication method Azure AD handles the authentication
process for user's sign-in. With cloud authentication you can choose from two options:
Password hash synchronization (PHS) - Password Hash Sync enables users to use the same
username and password that they use on-premises without having to deploy any additional
infrastructure besides Azure AD Connect.
Pass-through authentication (PTA) - This option is similar to password hash sync, but provides a
simple password validation using on-premises software agents for organizations with strong security
and compliance policies.
Federated authentication - When you choose this authentication method Azure AD will hand off the
authentication process to a separate trusted authentication system, such as AD FS or a third-party federation
system, to validate the user's sign-in.
For most organizations that just want to enable user sign-in to Office 365, SaaS applications, and other Azure AD-
based resources, we recommend the default password hash synchronization option.
For detailed information on choosing an authentication method, see Choose the right authentication method for
your Azure Active Directory hybrid identity solution
With password hash synchronization, hashes of user passwords are synchronized from on-premises Active
Directory to Azure AD. When passwords are changed or reset on-premises, the new password hashes are
synchronized to Azure AD immediately so that your users can always use the same password for cloud resources
and on-premises resources. The passwords are never sent to Azure AD or stored in Azure AD in clear text. You can
use password hash synchronization together with password write-back to enable self-service password reset in
Azure AD.
In addition, you can enable Seamless SSO for users on domain-joined machines that are on the corporate
network. With single sign-on, enabled users only need to enter a username to help them securely access cloud
resources.
For more information, see the password hash synchronization article.

With pass-through authentication, the user’s password is validated against the on-premises Active Directory
controller. The password doesn't need to be present in Azure AD in any form. This allows for on-premises policies,
such as sign-in hour restrictions, to be evaluated during authentication to cloud services.
Pass-through authentication uses a simple agent on a Windows Server 2012 R2 domain-joined machine in the
on-premises environment. This agent listens for password validation requests. It doesn't require any inbound
ports to be open to the Internet.
In addition, you can also enable single sign-on for users on domain-joined machines that are on the corporate
network. With single sign-on, enabled users only need to enter a username to help them securely access cloud
resources.
For more information, see:

Single sign-on
Federation that uses a new or existing farm with AD FS in Windows Server 2012 R2
With federated sign-in, your users can sign in to Azure AD-based services with their on-premises passwords.
While they're on the corporate network, they don't even have to enter their passwords. By using the federation
option with AD FS, you can deploy a new or existing farm with AD FS in Windows Server 2012 R2. If you choose
to specify an existing farm, Azure AD Connect configures the trust between your farm and Azure AD so that your
users can sign in.
Deploy federation with AD FS in Windows Server 2012 R2
If you're deploying a new farm, you need:
A Windows Server 2012 R2 server for the federation server.
A Windows Server 2012 R2 server for the Web Application Proxy.
A .pfx file with one TLS/SSL certificate for your intended federation service name. For example: fs.contoso.com.
If you're deploying a new farm or using an existing farm, you need:
Local administrator credentials on your federation servers.
Local administrator credentials on any workgroup servers (not domain-joined) that you intend to deploy the
Web Application Proxy role on.
The machine that you run the wizard on to be able to connect to any other machines that you want to install
AD FS or Web Application Proxy on by using Windows Remote Management.
For more information, see Configuring SSO with AD FS.
With federated sign-in, your users can sign in to Azure AD-based services with their on-premises passwords.
While they're on the corporate network, they don't even have to enter their passwords.
For more information on configuring PingFederate for use with Azure Active Directory, see PingFederate
Integration with Azure Active Directory and Office 365
For information on setting up Azure AD Connect using PingFederate, see Azure AD Connect custom installation
Sign in by using an earlier version of AD FS or a third-party solution
If you've already configured cloud sign-in by using an earlier version of AD FS (such as AD FS 2.0) or a third-party
federation provider, you can choose to skip user sign-in configuration through Azure AD Connect. This will enable
you to get the latest synchronization and other capabilities of Azure AD Connect while still using your existing
solution for sign-in.
For more information, see the Azure AD third-party federation compatibility list.
User sign-in and user principal name

Understanding user principal name
In Active Directory, the default user principal name (UPN) suffix is the DNS name of the domain where the user
account was created. In most cases, this is the domain name that's registered as the enterprise domain on the
Internet. However, you can add more UPN suffixes by using Active Directory Domains and Trusts.
The UPN of the user has the format username@domain. For example, for an Active Directory domain named
"contoso.com", a user named John might have the UPN "john@contoso.com". The UPN of the user is based on
RFC 822. Although the UPN and email share the same format, the value of the UPN for a user might or might not
be the same as the email address of the user.
User principal name in Azure AD
The Azure AD Connect wizard uses the userPrincipalName attribute or lets you specify the attribute (in a custom
installation) to be used from on-premises as the user principal name in Azure AD. This is the value that is used for
signing in to Azure AD. If the value of the userPrincipalName attribute doesn't correspond to a verified domain in
Azure AD, then Azure AD replaces it with a default .onmicrosoft.com value.
Every directory in Azure Active Directory comes with a built-in domain name, with the format
contoso.onmicrosoft.com, that lets you get started using Azure or other Microsoft services. You can improve and
simplify the sign-in experience by using custom domains. For information on custom domain names in Azure AD
and how to verify a domain, see Add your custom domain name to Azure Active Directory.
Azure AD sign-in configuration
Azure AD sign-in configuration with Azure AD Connect
The Azure AD sign-in experience depends on whether Azure AD can match the user principal name suffix of a user
that's being synced to one of the custom domains that are verified in the Azure AD directory. Azure AD Connect
provides help while you configure Azure AD sign-in settings, so that the user sign-in experience in the cloud is
similar to the on-premises experience.
Azure AD Connect lists the UPN suffixes that are defined for the domains and tries to match them with a custom
domain in Azure AD. Then it helps you with the appropriate action that needs to be taken. The Azure AD sign-in
page lists the UPN suffixes that are defined for on-premises Active Directory and displays the corresponding
status against each suffix. The status values can be one of the following:
STAT E DESC RIP T IO N A C T IO N N EEDED
Verified Azure AD Connect found a matching No action is needed.

verified domain in Azure AD. All users
for this domain can sign in by using
their on-premises credentials.
Not verified Azure AD Connect found a matching Verify the custom domain in Azure AD.
custom domain in Azure AD, but it isn't
verified. The UPN suffix of the users of
this domain will be changed to the
default .onmicrosoft.com suffix after
synchronization if the domain isn't
verified.
Not added Azure AD Connect didn't find a custom Add and verify a custom domain that
domain that corresponded to the UPN corresponds to the UPN suffix.
suffix. The UPN suffix of the users of
this domain will be changed to the
default .onmicrosoft.com suffix if the
domain isn't added and verified in
Azure.
The Azure AD sign-in page lists the UPN suffixes that are defined for on-premises Active Directory and the
corresponding custom domain in Azure AD with the current verification status. In a custom installation, you can
now select the attribute for the user principal name on the Azure AD sign-in page.
You can click the refresh button to re-fetch the latest status of the custom domains from Azure AD.
Selecting the attribute for the user principal name in Azure AD
The attribute userPrincipalName is the attribute that users use when they sign in to Azure AD and Office 365. You
should verify the domains (also known as UPN suffixes) that are used in Azure AD before the users are
synchronized.
We strongly recommend that you keep the default attribute userPrincipalName. If this attribute is nonroutable
and can't be verified, then it's possible to select another attribute (email, for example) as the attribute that holds
the sign-in ID. This is known as the Alternate ID. The Alternate ID attribute value must follow the RFC 822
standard. You can use an Alternate ID with both password SSO and federation SSO as the sign-in solution.
NOTE
Using an Alternate ID isn't compatible with all Office 365 workloads. For more information, see Configuring Alternate Login
ID.
Different custom domain states and their effect on the Azure sign-in experience
It's very important to understand the relationship between the custom domain states in your Azure AD directory
and the UPN suffixes that are defined on-premises. Let's go through the different possible Azure sign-in
experiences when you're setting up synchronization by using Azure AD Connect.
For the following information, let's assume that we're concerned with the UPN suffix contoso.com, which is used
in the on-premises directory as part of UPN--for example user@contoso.com.
E x p re s s s e t t i n g s /P a s s w o rd h a s h s y n c h ro n i z a t i o n
STAT E EF F EC T O N USER A Z URE SIGN - IN EXP ERIEN C E

STAT E EF F EC T O N USER A Z URE SIGN - IN EXP ERIEN C E
Not added In this case, no custom domain for contoso.com has been
added in the Azure AD directory. Users who have UPN on-
premises with the suffix @contoso.com won't be able to use
their on-premises UPN to sign in to Azure. They'll instead
have to use a new UPN that's provided to them by Azure AD
by adding the suffix for the default Azure AD directory. For
example, if you're syncing users to the Azure AD directory
azurecontoso.onmicrosoft.com, then the on-premises user
user@contoso.com will be given a UPN of
user@azurecontoso.onmicrosoft.com.
Not verified In this case, we have a custom domain contoso.com that's

added in the Azure AD directory. However, it's not yet
verified. If you go ahead with syncing users without verifying
the domain, then the users will be assigned a new UPN by
Azure AD, just like in the "Not added" scenario.
Verified In this case, we have a custom domain contoso.com that's

already added and verified in Azure AD for the UPN suffix.
Users will be able to use their on-premises user principal
name, for example user@contoso.com, to sign in to Azure
after they're synced to Azure AD.
A D F S f e d e ra t i o n
You can't create a federation with the default .onmicrosoft.com domain in Azure AD or an unverified custom
domain in Azure AD. When you're running the Azure AD Connect wizard, if you select an unverified domain to
create a federation with, then Azure AD Connect prompts you with the necessary records to be created where
your DNS is hosted for the domain. For more information, see Verify the Azure AD domain selected for federation.
If you selected the user sign-in option Federation with AD FS , then you must have a custom domain to
continue creating a federation in Azure AD. For our discussion, this means that we should have a custom domain
contoso.com added in the Azure AD directory.
STAT E EF F EC T O N T H E USER A Z URE SIGN - IN EXP ERIEN C E
Not added In this case, Azure AD Connect didn't find a matching custom
domain for the UPN suffix contoso.com in the Azure AD
directory. You need to add a custom domain contoso.com if
you need users to sign in by using AD FS with their on-
premises UPN (like user@contoso.com).
Not verified In this case, Azure AD Connect prompts you with appropriate
details on how you can verify your domain at a later stage.
Verified In this case, you can go ahead with the configuration without
any further action.
Changing the user sign-in method

You can change the user sign-in method from federation, password hash synchronization, or pass-through
authentication by using the tasks that are available in Azure AD Connect after the initial configuration of Azure AD
Connect with the wizard. Run the Azure AD Connect wizard again, and you'll see a list of tasks that you can
perform. Select Change user sign-in from the list of tasks.
On the next page, you're asked to provide the credentials for Azure AD.
On the User sign-in page, select the desired user sign-in.

NOTE
If you're only making a temporary switch to password hash synchronization, then select the Do not conver t user
accounts check box. Not checking the option will convert each user to federated, and it can take several hours.
Next steps
Learn more about Azure AD Connect design concepts.
This article describes how the UserPrincipalName attribute is populated in Azure Active Directory (Azure AD). The
UserPrincipalName attribute value is the Azure AD username for the user accounts.
UPN terminology
The following terminology is used in this article:
T ERM DESC RIP T IO N
Initial domain The default domain (onmicrosoft.com) in the Azure AD Tenant.

For example, contoso.onmicrosoft.com.
Microsoft Online Email Routing Address (MOERA) Azure AD calculates the MOERA from Azure AD
MailNickName attribute and Azure AD initial domain as
<MailNickName>@<initial domain>.
On-premises mailNickName attribute An attribute in Active Directory, the value of which represents
the alias of a user in an Exchange organization.
On-premises mail attribute An attribute in Active Directory, the value of which represents
the email address of a user
Primary SMTP Address The primary email address of an Exchange recipient object. For
example, SMTP:user@contoso.com.
Alternate login ID An on-premises attribute other than UserPrincipalName, such

as mail attribute, used for sign-in.
What is UserPrincipalName?
UserPrincipalName is an attribute that is an Internet-style login name for a user based on the Internet standard RFC
822.
UPN format
A UPN consists of a UPN prefix (the user account name) and a UPN suffix (a DNS domain name). The prefix is
joined with the suffix using the "@" symbol. For example, "someone@example.com". A UPN must be unique
among all security principal objects within a directory forest.
UPN in Azure AD
The UPN is used by Azure AD to allow users to sign-in. The UPN that a user can use, depends on whether or not the
domain has been verified. If the domain has been verified, then a user with that suffix will be allowed to sign-in to
Azure AD.
The attribute is synchronized by Azure AD Connect. During installation, you can view the domains that have been
verified and the ones that have not.
Alternate login ID
In some environments, end users may only be aware of their email address and not their UPN. The use of email
address may be due to a corporate policy or an on-premises line-of-business application dependency.
Alternate login ID allows you to configure a sign-in experience where users can sign-in with an attribute other than
their UPN, such as mail.
To enable Alternate login ID with Azure AD, no additional configurations steps are needed when using Azure AD
Connect. Alternate ID can be configured directly from the wizard. See Azure AD sign-in configuration for your users
under the section Sync. Under the User Principal Name drop-down, select the attribute for Alternate login ID.
For more information, see Configure Alternate login ID and Azure AD sign-in configuration
Non-verified UPN Suffix

If the on-premises UserPrincipalName attribute/Alternate login ID suffix is not verified with Azure AD Tenant, then
the Azure AD UserPrincipalName attribute value is set to MOERA. Azure AD calculates the MOERA from the Azure
AD MailNickName attribute and Azure AD initial domain as <MailNickName>@<initial domain>.
Verified UPN suffix

If the on-premises UserPrincipalName attribute/Alternate login ID suffix is verified with the Azure AD Tenant, then
the Azure AD UserPrincipalName attribute value is going to be the same as the on-premises UserPrincipalName
attribute/Alternate login ID value.
Azure AD MailNickName attribute value calculation

Because the Azure AD UserPrincipalName attribute value could be set to MOERA, it is important to understand
how the Azure AD MailNickName attribute value, which is the MOERA prefix, is calculated.
When a user object is synchronized to an Azure AD Tenant for the first time, Azure AD checks the following items in
the given order and sets the MailNickName attribute value to the first existing one:
On-premises mailNickName attribute
Prefix of primary SMTP address
Prefix of on-premises mail attribute
Prefix of on-premises userPrincipalName attribute/Alternate login ID
Prefix of secondary smtp address
When the updates to a user object are synchronized to the Azure AD Tenant, Azure AD updates the MailNickName
attribute value only in case there is an update to the on-premises mailNickName attribute value.
IMPORTANT
Azure AD recalculates the UserPrincipalName attribute value only in case an update to the on-premises UserPrincipalName
attribute/Alternate login ID value is synchronized to the Azure AD Tenant.
Whenever Azure AD recalculates the UserPrincipalName attribute, it also recalculates the MOERA.
UPN scenarios
The following are example scenarios of how the UPN is calculated based on the given scenario.
Scenario 1: Non-verified UPN suffix – initial synchronization
On-Premises user object:

mailNickName : <not set>
proxyAddresses : {SMTP:us1@contoso.com}
mail : us2@contoso.com
userPrincipalName : us3@contoso.com
Synchronized the user object to Azure AD Tenant for the first time
Set Azure AD MailNickName attribute to primary SMTP address prefix.
Set MOERA to <MailNickName>@<initial domain>.
Set Azure AD UserPrincipalName attribute to MOERA.
Azure AD Tenant user object:
MailNickName : us1
UserPrincipalName : us1@contoso.onmicrosoft.com
Scenario 2: Non-verified UPN suffix – set on-premises mailNickName attribute
mailNickName : us4
Synchronize update on on-premises mailNickName attribute to Azure AD Tenant
Update Azure AD MailNickName attribute with on-premises mailNickName attribute.
Because there is no update to the on-premises userPrincipalName attribute, there is no change to the Azure AD
UserPrincipalName attribute.
MailNickName : us4
Scenario 3: Non-verified UPN suffix – update on-premises userPrincipalName attribute

mailNickName : us4
Synchronize update on on-premises userPrincipalName attribute to Azure AD Tenant
Update on on-premises userPrincipalName attribute triggers recalculation of MOERA and Azure AD
UserPrincipalName attribute.
Set MOERA to <MailNickName>@<initial domain>.
Set Azure AD UserPrincipalName attribute to MOERA.
MailNickName : us4
Scenario 4: Non-verified UPN suffix – update primary SMTP address and on-premises mail attribute

mailNickName : us4
Synchronize update on on-premises mail attribute and primary SMTP address to Azure AD Tenant
After the initial synchronization of the user object, updates to the on-premises mail attribute and the primary
SMTP address will not affect the Azure AD MailNickName or the UserPrincipalName attribute.
MailNickName : us4
Scenario 5: Verified UPN suffix – update on-premises userPrincipalName attribute suffix
mailNickName : us4
userPrincipalName : us5@verified.contoso.com
Synchronize update on on-premises userPrincipalName attribute to the Azure AD Tenant
Update on on-premises userPrincipalName attribute triggers recalculation of Azure AD UserPrincipalName
attribute.
Set Azure AD UserPrincipalName attribute to on-premises userPrincipalName attribute as the UPN suffix is
verified with the Azure AD Tenant.
MailNickName : us4
UserPrincipalName : us5@verified.contoso.com
Next Steps
Azure AD Connect: Special considerations for
instances
Azure AD Connect is most commonly used with the world-wide instance of Azure AD and Office 365. But there are
also other instances and these have different requirements for URLs and other special considerations.
Microsoft Cloud Germany

The Microsoft Cloud Germany is a sovereign cloud operated by a German data trustee.
URL S TO O P EN IN P RO XY SERVER
*.microsoftonline.de
*.windows.net
+Certificate Revocation Lists
When you sign in to your Azure AD tenant, you must use an account in the onmicrosoft.de domain.
Features currently not present in the Microsoft Cloud Germany:
Password writeback is available for preview with Azure AD Connect version 1.1.570.0 and after.
Other Azure AD Premium services are not available.
Microsoft Azure Government

The Microsoft Azure Government cloud is a cloud for US government.
This cloud has been supported by earlier releases of DirSync. From build 1.1.180 of Azure AD Connect, the next
generation of the cloud is supported. This generation is using US-only based endpoints and have a different list of
URLs to open in your proxy server.
URL S TO O P EN IN P RO XY SERVER
*.microsoftonline.com
*.microsoftonline.us
*.windows.net (Required for automatic Azure Government tenant detection)
*.gov.us.microsoftonline.com
+Certificate Revocation Lists

NOTE
As of Azure AD Connect version 1.1.647.0, setting the AzureInstance value in the registry is no longer required provided that
*.windows.net is open on your proxy server(s). However, for customers that do not allow Internet connectivity from their
Azure AD Connect server(s), the following manual configuration can be used.
Manual Configuration
The following manual configuration steps are used to ensure Azure AD Connect uses Azure Government
synchronization endpoints.
1. Start the Azure AD Connect installation.
2. When you see the first page where you are supposed to accept the EULA, do not continue but leave the
installation wizard running.
3. Start regedit and change the registry key HKLM\SOFTWARE\Microsoft\Azure AD Connect\AzureInstance to the value
4 .
4. Go back to the Azure AD Connect installation wizard, accept the EULA, and continue. During installation, make
sure to use the custom configuration installation path (and not Express installation), then continue the
installation as usual.
Next steps
Migrate from federation to password hash
synchronization for Azure Active Directory
This article describes how to move your organization domains from Active Directory Federation Services (AD FS)
to password hash synchronization.
NOTE
Changing your authentication method requires planning, testing, and potentially downtime. Staged rollout provides an
alternative way to test and gradually migrate from federation to cloud authentication using password hash synchronization.
If you plan on using staged rollout, you should remember to turn off the staged rollout features once you have finished
cutting over. For more information see Migrate to cloud authentication using staged rollout
Prerequisites for migrating to password hash synchronization

The following prerequisites are required to migrate from using AD FS to using password hash synchronization.
Update Azure AD Connect
As a minimum to successfully perform the steps to migrate to password hash synchronization, you should have
Azure AD connect 1.1.819.0. This version contains significant changes to the way sign-in conversion is performed
and reduces the overall time to migrate from Federation to Cloud Authentication from potentially hours to
minutes.
IMPORTANT
You might read in outdated documentation, tools, and blogs that user conversion is required when you convert domains
from federated identity to managed identity. Converting users is no longer required. Microsoft is working to update
documentation and tools to reflect this change.
To update Azure AD Connect, complete the steps in Azure AD Connect: Upgrade to the latest version.
Password hash synchronization required permissions
You can configure Azure AD Connect by using express settings or a custom installation. If you used the custom
installation option, the required permissions for password hash synchronization might not be in place.
The Azure AD Connect Active Directory Domain Services (AD DS) service account requires the following
permissions to synchronize password hashes:
Replicate Directory Changes
Replicate Directory Changes All
Now is a good time to verify that these permissions are in place for all domains in the forest.
Plan the migration method
You can choose from two methods to migrate from federated identity management to password hash
synchronization and seamless single sign-on (SSO). The method you use depends on how your AD FS instance was
originally configured.
Azure AD Connect . If you originally configured AD FS by using Azure AD Connect, you must change to
password hash synchronization by using the Azure AD Connect wizard.
Azure AD Connect automatically runs the Set-MsolDomainAuthentication cmdlet when you change the
user sign-in method. Azure AD Connect automatically unfederates all the verified federated domains in your
Azure AD tenant.
NOTE
Currently, if you originally used Azure AD Connect to configure AD FS, you can't avoid unfederating all domains in
your tenant when you change the user sign-in to password hash synchronization.
Azure AD Connect with PowerShell . You can use this method only if you didn't originally configure AD
FS by using Azure AD Connect. For this option, you still must change the user sign-in method via the Azure
AD Connect wizard. The core difference with this option is that the wizard doesn't automatically run the Set-
MsolDomainAuthentication cmdlet. With this option, you have full control over which domains are
converted and in which order.
To understand which method you should use, complete the steps in the following sections.
Verify current user sign-in settings
To verify your current user sign-in settings:
1. Sign in to the Azure AD portal by using a Global Administrator account.
2. In the User sign-in section, verify the following settings:
Federation is set to Enabled .
Seamless single sign-on is set to Disabled .
Pass-through authentication is set to Disabled .
Verify the Azure AD Connect configuration

1. On your Azure AD Connect server, open Azure AD Connect. Select Configure .
2. On the Additional tasks page, select View current configuration , and then select Next .
3. On the Review Your Solution page, note the Password hash synchronization status.
If Password hash synchronization is set to Disabled , complete the steps in this article to enable it.
If Password hash synchronization is set to Enabled , you can skip the section Step 1: Enable
password hash synchronization in this article.
4. On the Review your solution page, scroll to Active Director y Federation Ser vices (AD FS) .
If the AD FS configuration appears in this section, you can safely assume that AD FS was originally
configured by using Azure AD Connect. You can convert your domains from federated identity to
managed identity by using the Azure AD Connect Change user sign-in option. The process is detailed
in the section Option A: Switch from federation to password hash synchronization by using
Azure AD Connect .
If AD FS isn't listed in the current settings, you must manually convert your domains from federated
identity to managed identity by using PowerShell. For more information about this process, see the
section Option B: Switch from federation to password hash synchronization by using Azure
AD Connect and PowerShell .
Document current federation settings
To find your current federation settings, run the Get-MsolDomainFederationSettings cmdlet:
Get-MsolDomainFederationSettings -DomainName YourDomain.extention | fl *
Example:
Get-MsolDomainFederationSettings -DomainName Contoso.com | fl *
Verify any settings that might have been customized for your federation design and deployment documentation.
Specifically, look for customizations in PreferredAuthenticationProtocol , Suppor tsMfa , and
PromptLoginBehavior .
For more information, see these articles:
AD FS prompt=login parameter support
Set-MsolDomainAuthentication
NOTE
If Suppor tsMfa is set to True , you're using an on-premises multi-factor authentication solution to inject a second-factor
challenge into the user authentication flow. This setup no longer works for Azure AD authentication scenarios after
converting this domain from federated to managed authentication. After you disable federation, you sever the relationship
to your on-premises federation and this includes on-premises MFA adapters.
Instead, use the Azure Multi-Factor Authentication cloud-based service to perform the same function. Carefully evaluate
your multi-factor authentication requirements before you continue. Before you convert your domains, make sure that you
understand how to use Azure Multi-Factor Authentication, the licensing implications, and the user registration process.
Back up federation settings

Although no changes are made to other relying parties in your AD FS farm during the processes described in this
article, we recommend that you have a current valid backup of your AD FS farm that you can restore from. You can
create a current valid backup by using the free Microsoft AD FS Rapid Restore Tool. You can use the tool to back up
AD FS, and to restore an existing farm or create a new farm.
If you choose not to use the AD FS Rapid Restore Tool, at a minimum, you should export the Microsoft Office 365
Identity Platform relying party trust and any associated custom claim rules you added. You can export the relying
party trust and associated claim rules by using the following PowerShell example:
(Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform") | Export-CliXML "C:\temp\O365-

RelyingPartyTrust.xml"
Deployment considerations and using AD FS

This section describes deployment considerations and details about using AD FS.
Current AD FS use
Before you convert from federated identity to managed identity, look closely at how you currently use AD FS for
Azure AD, Office 365, and other applications (relying party trusts). Specifically, consider the scenarios that are
described in the following table:
IF T H EN
You plan to keep using AD FS with other applications (other After you convert your domains, you'll use both AD FS and
than Azure AD and Office 365). Azure AD. Consider the user experience. In some scenarios,
users might be required to authenticate twice: once to Azure
AD (where a user gets SSO access to other applications, like
Office 365), and again for any applications that are still bound
to AD FS as a relying party trust.
Your AD FS instance is heavily customized and relies on Before you continue, you must verify that Azure AD can meet
specific customization settings in the onload.js file (for your current customization requirements. For more
example, if you changed the sign-in experience so that users information and for guidance, see the sections on AD FS
use only a SamAccountName format for their username branding and AD FS customization.
instead of a User Principal Name (UPN), or your organization
has heavily branded the sign-in experience). The onload.js file
can't be duplicated in Azure AD.
IF T H EN
You use AD FS to block earlier versions of authentication Consider replacing AD FS controls that block earlier versions
clients. of authentication clients by using a combination of
Conditional Access controls and Exchange Online Client Access
Rules.
You require users to perform multi-factor authentication In a managed identity domain, you can't inject a multi-factor
against an on-premises multi-factor authentication server authentication challenge via the on-premises multi-factor
solution when users authenticate to AD FS. authentication solution into the authentication flow. However,
you can use the Azure Multi-Factor Authentication service for
multi-factor authentication after the domain is converted.
If your users don't currently use Azure Multi-Factor

Authentication, a onetime user registration step is required.
You must prepare for and communicate the planned
registration to your users.
You currently use access control policies (AuthZ rules) in AD FS Consider replacing the policies with the equivalent Azure AD
to control access to Office 365. Conditional Access policies and Exchange Online Client Access
Rules.
Common AD FS customizations
This section describes common AD FS customizations.
InsideCorporateNetwork claim
AD FS issues the InsideCorporateNetwork claim if the user who is authenticating is inside the corporate
network. This claim can then be passed on to Azure AD. The claim is used to bypass multi-factor authentication
based on the user's network location. To learn how to determine whether this functionality currently is enabled in
AD FS, see Trusted IPs for federated users.
The InsideCorporateNetwork claim isn't available after your domains are converted to password hash
synchronization. You can use named locations in Azure AD to replace this functionality.
After you configure named locations, you must update all Conditional Access policies that were configured to
either include or exclude the network All trusted locations or MFA Trusted IPs values to reflect the new named
locations.
For more information about the Location condition in Conditional Access, see Active Directory Conditional Access
locations.
Hybrid Azure AD-joined devices
When you join a device to Azure AD, you can create Conditional Access rules that enforce that devices meet your
access standards for security and compliance. Also, users can sign in to a device by using an organizational work or
school account instead of a personal account. When you use hybrid Azure AD-joined devices, you can join your
Active Directory domain-joined devices to Azure AD. Your federated environment might have been set up to use
this feature.
To ensure that hybrid join continues to work for any devices that are joined to the domain after your domains are
converted to password hash synchronization, for Windows 10 clients, you must use Azure AD Connect device
options to sync Active Directory computer accounts to Azure AD.
For Windows 8 and Windows 7 computer accounts, hybrid join uses seamless SSO to register the computer in
Azure AD. You don't have to sync Windows 8 and Windows 7 computer accounts like you do for Windows 10
devices. However, you must deploy an updated workplacejoin.exe file (via an .msi file) to Windows 8 and Windows
7 clients so they can register themselves by using seamless SSO. Download the .msi file.
For more information, see Configure hybrid Azure AD-joined devices.
Branding
If your organization customized your AD FS sign-in pages to display information that's more pertinent to the
organization, consider making similar customizations to the Azure AD sign-in page.
Although similar customizations are available, some visual changes on sign-in pages should be expected after the
conversion. You might want to provide information about expected changes in your communications to users.
NOTE
Organization branding is available only if you purchase the Premium or Basic license for Azure Active Directory or if you have
an Office 365 license.
Plan deployment and support

Complete the tasks that are described in this section to help you plan for deployment and support.
Plan the maintenance window
Although the domain conversion process is relatively quick, Azure AD might continue to send some authentication
requests to your AD FS servers for up to four hours after the domain conversion is finished. During this four-hour
window, and depending on various service side caches, Azure AD might not accept these authentications. Users
might receive an error. The user can still successfully authenticate against AD FS, but Azure AD no longer accepts
the user’s issued token because that federation trust is now removed.
Only users who access the services via a web browser during this post-conversion window before the service side
cache is cleared are affected. Legacy clients (Exchange ActiveSync, Outlook 2010/2013) aren't expected to be
affected because Exchange Online keeps a cache of their credentials for a set period of time. The cache is used to
silently reauthenticate the user. The user doesn't have to return to AD FS. Credentials stored on the device for these
clients are used to silently reauthenticate themselves after this cached is cleared. Users aren't expected to receive
any password prompts as a result of the domain conversion process.
Modern authentication clients (Office 2016 and Office 2013, iOS, and Android apps) use a valid refresh token to
obtain new access tokens for continued access to resources instead of returning to AD FS. These clients are
immune to any password prompts resulting from the domain conversion process. The clients will continue to
function without additional configuration.
IMPORTANT
Don’t shut down your AD FS environment or remove the Office 365 relying party trust until you have verified that all users
can successfully authenticate by using cloud authentication.
Plan for rollback

If you encounter a major issue that you can't resolve quickly, you might decide to roll back the solution to
federation. It’s important to plan what to do if your deployment doesn’t roll out as intended. If conversion of the
domain or users fails during deployment, or if you need to roll back to federation, you must understand how to
mitigate any outage and reduce the effect on your users.
To roll back
To plan for rollback, check the federation design and deployment documentation for your specific deployment
details. The process should include these tasks:
Converting managed domains to federated domains by using the Conver t-MSOLDomainToFederated
cmdlet.
If necessary, configuring additional claims rules.
Plan communications
An important part of planning deployment and support is ensuring that your users are proactively informed about
upcoming changes. Users should know in advance what they might experience and what is required of them.
After both password hash synchronization and seamless SSO are deployed, the user sign-in experience for
accessing Office 365 and other resources that are authenticated through Azure AD changes. Users who are outside
the network see only the Azure AD sign-in page. These users aren't redirected to the forms-based page that's
presented by external-facing web application proxy servers.
Include the following elements in your communication strategy:
Notify users about upcoming and released functionality by using:
Email and other internal communication channels.
Visuals, such as posters.
Executive, live, or other communications.
Determine who will customize the communications and who will send the communications, and when.
Implement your solution

You planned your solution. Now, you can now implement it. Implementation involves the following components:
Enabling password hash synchronization.
Preparing for seamless SSO.
Changing the sign-in method to password hash synchronization and enabling seamless SSO.
Step 1: Enable password hash synchronization
The first step to implement this solution is to enable password hash synchronization by using the Azure AD
Connect wizard. Password hash synchronization is an optional feature that you can enable in environments that
use federation. There's no effect on the authentication flow. In this case, Azure AD Connect will start syncing
password hashes without affecting users who sign in by using federation.
For this reason, we recommend that you complete this step as a preparation task well before you change your
domain's sign-in method. Then, you'll have ample time to verify that password hash synchronization works
correctly.
To enable password hash synchronization:
1. On the Azure AD Connect server, open the Azure AD Connect wizard, and then select Configure .
2. Select Customize synchronization options , and then select Next .
3. On the Connect to Azure AD page, enter the username and password of a Global Administrator account.
4. On the Connect your directories page, select Next .
5. On the Domain and OU filtering page, select Next .
6. On the Optional features page, select Password synchronization , and then select Next .
7. Select Next on the remaining pages. On the last page, select Configure .
8. Azure AD Connect starts to sync password hashes on the next synchronization.
After password hash synchronization is enabled, the password hashes for all users in the Azure AD Connect
synchronization scope are rehashed and written to Azure AD. Depending on the number of users, this operation
might take minutes or several hours.
For planning purposes, you should estimate that approximately 20,000 users are processed in 1 hour.
To verify that password hash synchronization works correctly, complete the Troubleshooting task in the Azure AD
Connect wizard:
1. Open a new Windows PowerShell session on your Azure AD Connect server by using the Run as Administrator
option.
2. Run Set-ExecutionPolicy RemoteSigned or Set-ExecutionPolicy Unrestricted .
3. Start the Azure AD Connect wizard.
4. Go to the Additional tasks page, select Troubleshoot , and then select Next .
5. On the Troubleshooting page, select Launch to start the troubleshooting menu in PowerShell.
6. On the main menu, select Troubleshoot password hash synchronization .
7. On the submenu, select Password hash synchronization does not work at all .
For troubleshooting issues, see Troubleshoot password hash synchronization with Azure AD Connect sync.
Step 2: Prepare for seamless SSO
For your devices to use seamless SSO, you must add an Azure AD URL to users' intranet zone settings by using a
group policy in Active Directory.
By default, web browsers automatically calculate the correct zone, either internet or intranet, from a URL. For
example, http://contoso/ maps to the intranet zone and http://intranet.contoso.com maps to the internet
zone (because the URL contains a period). Browsers send Kerberos tickets to a cloud endpoint, like the Azure AD
URL, only if you explicitly add the URL to the browser's intranet zone.
Complete the steps to roll out the required changes to your devices.
IMPORTANT
Making this change doesn't modify the way your users sign in to Azure AD. However, it’s important that you apply this
configuration to all your devices before you proceed. Users who sign in on devices that haven't received this configuration
simply are required to enter a username and password to sign in to Azure AD.
Step 3: Change the sign-in method to password hash synchronization and enable seamless SSO
You have two options for changing the sign-in method to password hash synchronization and enabling seamless
SSO.
Option A: Switch from federation to password hash synchronization by using Azure AD Connect
Use this method if you initially configured your AD FS environment by using Azure AD Connect. You can't use this
method if you didn't originally configure your AD FS environment by using Azure AD Connect.
First, change the sign-in method:
1. On the Azure AD Connect server, open the Azure AD Connect wizard.
2. Select Change user sign-in , and then select Next .
4. On the User sign-in page, select the Password hash synchronization button . Make sure to select the
Do not conver t user accounts check box. The option is deprecated. Select Enable single sign-on , and
then select Next .
NOTE
Starting with Azure AD Connect version 1.1.880.0, the Seamless single sign-on check box is selected by default.
IMPORTANT
You can safely ignore the warnings that indicate that user conversion and full password hash synchronization are
required steps for converting from federation to cloud authentication. Note that these steps aren't required anymore.
If you still see these warnings, make sure that you're running the latest version of Azure AD Connect and that you're
using the latest version of this guide. For more information, see the section Update Azure AD Connect.
5. On the Enable single sign-on page, enter the credentials of Domain Administrator account, and then
select Next .
NOTE
Domain Administrator account credentials are required to enable seamless SSO. The process completes the following
actions, which require these elevated permissions. The Domain Administrator account credentials aren't stored in
Azure AD Connect or in Azure AD. The Domain Administrator account credentials are used only to turn on the
feature. The credentials are discarded when the process successfully finishes.
1. A computer account named AZUREADSSOACC (which represents Azure AD) is created in your on-premises Active
Directory instance.
2. The computer account's Kerberos decryption key is securely shared with Azure AD.
3. Two Kerberos service principal names (SPNs) are created to represent two URLs that are used during Azure AD
sign-in.
6. On the Ready to configure page, make sure that the Star t the synchronization process when
configuration completes check box is selected. Then, select Configure .
IMPORTANT
At this point, all your federated domains will change to managed authentication. Password hash synchronization is
the new method of authentication.
7. In the Azure AD portal, select Azure Active Director y > Azure AD Connect .
8. Verify these settings:
Federation is set to Disabled .
Seamless single sign-on is set to Enabled .
Password Sync is set to Enabled .
Skip to Testing and next steps.
IMPORTANT
Skip the section Option B: Switch from federation to password hash synchronization by using Azure AD
Connect and PowerShell. The steps in that section don't apply if you chose Option A to change the sign-in method to
password hash synchronization and enable seamless SSO.
Option B: Switch from federation to password hash synchronization using Azure AD Connect and PowerShell
Use this option if you didn't initially configure your federated domains by using Azure AD Connect. During this
process, you enable seamless SSO and switch your domains from federated to managed.
3. On the Connect to Azure AD page, enter the username and password for a Global Administrator account.
4. On the User sign-in page, select the Password hash synchronization button. Select Enable single
sign-on , and then select Next .
Before you enable password hash synchronization:
After you enable password hash synchronization:

NOTE
Starting with Azure AD Connect version 1.1.880.0, the Seamless single sign-on check box is selected by default.
5. On the Enable single sign-on page, enter the credentials for a Domain Administrator account, and then
select Next .
NOTE
Directory instance.
sign-in.
When you select the Configure button, seamless SSO is configured as indicated in the preceding step.
Password hash synchronization configuration isn't modified because it was enabled earlier.
IMPORTANT
No changes are made to the way users sign in at this time.
7. In the Azure AD portal, verify these settings:

Password Sync is set to Enabled .
Convert domains from federated to managed
At this point, federation is still enabled and operational for your domains. To continue with the deployment, each
domain needs to be converted from federated to managed to force user authentication via password hash
synchronization.
IMPORTANT
You don't have to convert all domains at the same time. You might choose to start with a test domain on your production
tenant or start with your domain that has the lowest number of users.
Complete the conversion by using the Azure AD PowerShell module:

1. In PowerShell, sign in to Azure AD by using a Global Administrator account.
2. To convert the first domain, run the following command:
Set-MsolDomainAuthentication -Authentication Managed -DomainName <domain name>
4. Verify that the domain has been converted to managed by running the following command:
Get-MsolDomain -DomainName <domain name>
Testing and next steps

Complete the following tasks to verify password hash synchronization and to finish the conversion process.
Test authentication by using password hash synchronization
When your tenant used federated identity, users were redirected from the Azure AD sign-in page to your AD FS
environment. Now that the tenant is configured to use password hash synchronization instead of federated
authentication, users aren't redirected to AD FS. Instead, users sign in directly on the Azure AD sign-in page.
To test password hash synchronization:
1. Open Internet Explorer in InPrivate mode so that seamless SSO doesn't sign you in automatically.
2. Go to the Office 365 sign-in page (https://portal.office.com).
3. Enter a user UPN, and then select Next . Make sure that you enter the UPN of a hybrid user who was synced
from your on-premises Active Directory instance, and who previously used federated authentication. A page
on which you enter the username and password appears:
4. After you enter the password and select Sign in , you're redirected to the Office 365 portal.
Test seamless SSO
1. Sign in to a domain-joined machine that is connected to the corporate network.
2. In Internet Explorer or Chrome, go to one of the following URLs (replace "contoso" with your domain):
https://myapps.microsoft.com/contoso.com
https://myapps.microsoft.com/contoso.onmicrosoft.com
The user is briefly redirected to the Azure AD sign-in page, which shows the message "Trying to sign you in."
The user isn't prompted for a username or password.
3. The user is redirected and is successfully signed in to the access panel:

NOTE
Seamless SSO works on Office 365 services that support domain hint (for example,
myapps.microsoft.com/contoso.com). Currently, the Office 365 portal (portal.office.com) doesn’t support domain
hints. Users are required to enter a UPN. After a UPN is entered, seamless SSO retrieves the Kerberos ticket on behalf
of the user. The user is signed in without entering a password.
TIP
Consider deploying Azure AD hybrid join on Windows 10 for an improved SSO experience.
Remove the relying party trust

After you validate that all users and clients are successfully authenticating via Azure AD, it's safe to remove the
Office 365 relying party trust.
If you don't use AD FS for other purposes (that is, for other relying party trusts), it's safe to decommission AD FS at
this point.
Rollback
If you discover a major issue and can't resolve it quickly, you might choose to roll back the solution to federation.
Consult the federation design and deployment documentation for your specific deployment details. The process
should involve these tasks:
Convert managed domains to federated authentication by using the Conver t-MSOLDomainToFederated
cmdlet.
If necessary, configure additional claims rules.
Sync userPrincipalName updates
Historically, updates to the UserPrincipalName attribute, which uses the sync service from the on-premises
environment, are blocked unless both of these conditions are true:
The user is in a managed (non-federated) identity domain.
The user hasn't been assigned a license.
To learn how to verify or turn on this feature, see Sync userPrincipalName updates.
Troubleshooting
Your support team should understand how to troubleshoot any authentication issues that arise either during, or
after the change from federation to managed. Use the following troubleshooting documentation to help your
support team familiarize themselves with the common troubleshooting steps and appropriate actions that can help
to isolate and resolve the issue.
Troubleshoot Azure Active Directory password hash synchronization
Troubleshoot Azure Active Directory Seamless Single Sign-On
Roll over the seamless SSO Kerberos decryption key

It's important to frequently roll over the Kerberos decryption key of the AZUREADSSOACC computer account
(which represents Azure AD). The AZUREADSSOACC computer account is created in your on-premises Active
Directory forest. We highly recommend that you roll over the Kerberos decryption key at least every 30 days to
align with the way that Active Directory domain members submit password changes. There's no associated device
attached to the AZUREADSSOACC computer account object, so you must perform the rollover manually.
Initiate the rollover of the seamless SSO Kerberos decryption key on the on-premises server that's running Azure
AD Connect.
For more information, see How do I roll over the Kerberos decryption key of the AZUREADSSOACC computer
account?.
Next steps
Learn about Azure AD Connect design concepts.
Choose the right authentication.
Learn about supported topologies.
Migrate from federation to pass-through
authentication for Azure Active Directory
This article describes how to move your organization domains from Active Directory Federation Services (AD FS)
to pass-through authentication.
NOTE
Changing your authentication method requires planning, testing, and potentially downtime. Staged rollout provides an
alternative way to test and gradually migrate from federation to cloud authentication using pass-through authentication.
If you plan on using staged rollout, you should remember to turn off the staged rollout features once you have finished
cutting over. For more information see Migrate to cloud authentication using staged rollout
Prerequisites for migrating to pass-through authentication

The following prerequisites are required to migrate from using AD FS to using pass-through authentication.
Update Azure AD Connect
To successfully complete the steps it takes to migrate to using pass-through authentication, you must have Azure
Active Directory Connect (Azure AD Connect) 1.1.819.0 or a later version. In Azure AD Connect 1.1.819.0, the way
sign-in conversion is performed changes significantly. The overall time to migrate from AD FS to cloud
authentication in this version is reduced from potentially hours to minutes.
IMPORTANT
You might read in outdated documentation, tools, and blogs that user conversion is required when you convert domains
from federated identity to managed identity. Converting users is no longer required. Microsoft is working to update
documentation and tools to reflect this change.
To update Azure AD Connect, complete the steps in Azure AD Connect: Upgrade to the latest version.
Plan authentication agent number and placement
Pass-through authentication requires deploying lightweight agents on the Azure AD Connect server and on your
on-premises computer that's running Windows Server. To reduce latency, install the agents as close as possible to
your Active Directory domain controllers.
For most customers, two or three authentication agents are sufficient to provide high availability and the required
capacity. A tenant can have a maximum of 12 agents registered. The first agent is always installed on the Azure AD
Connect server itself. To learn about agent limitations and agent deployment options, see Azure AD pass-through
authentication: Current limitations.
Plan the migration method
You can choose from two methods to migrate from federated identity management to pass-through authentication
and seamless single sign-on (SSO). The method you use depends on how your AD FS instance was originally
configured.
Azure AD Connect . If you originally configured AD FS by using Azure AD Connect, you must change to
pass-through authentication by using the Azure AD Connect wizard.
Azure AD Connect automatically runs the Set-MsolDomainAuthentication cmdlet when you change the
user sign-in method. Azure AD Connect automatically unfederates all the verified federated domains in your
Azure AD tenant.
NOTE
Currently, if you originally used Azure AD Connect to configure AD FS, you can't avoid unfederating all domains in
your tenant when you change the user sign-in to pass-through authentication.
Azure AD Connect with PowerShell . You can use this method only if you didn't originally configure AD
FS by using Azure AD Connect. For this option, you still must change the user sign-in method via the Azure
AD Connect wizard. The core difference with this option is that the wizard doesn't automatically run the Set-
MsolDomainAuthentication cmdlet. With this option, you have full control over which domains are
converted and in which order.
To understand which method you should use, complete the steps in the following sections.
Verify current user sign-in settings
1. Sign in to the Azure AD portal by using a Global Administrator account.
2. In the User sign-in section, verify the following settings:
Seamless single sign-on is set to Disabled .
Pass-through authentication is set to Disabled .
Verify how federation was configured

1. On your Azure AD Connect server, open Azure AD Connect. Select Configure .
2. On the Additional tasks page, select View current configuration , and then select Next .
3. Under Additional Tasks > Manage Federation , scroll to Active Director y Federation Ser vices (AD
FS) .
If the AD FS configuration appears in this section, you can safely assume that AD FS was originally
configured by using Azure AD Connect. You can convert your domains from federated identity to
managed identity by using the Azure AD Connect Change user sign-in option. For more information
about the process, see the section Option A: Configure pass-through authentication by using
Azure AD Connect .
If AD FS isn't listed in the current settings, you must manually convert your domains from federated
identity to managed identity by using PowerShell. For more information about this process, see the
section Option B: Switch from federation to pass-through authentication by using Azure AD
Connect and PowerShell .
Document current federation settings
To find your current federation settings, run the Get-MsolDomainFederationSettings cmdlet:
Get-MsolDomainFederationSettings -DomainName YourDomain.extention | fl *
Example:
Get-MsolDomainFederationSettings -DomainName Contoso.com | fl *
Verify any settings that might have been customized for your federation design and deployment documentation.
Specifically, look for customizations in PreferredAuthenticationProtocol , Suppor tsMfa , and
PromptLoginBehavior .
For more information, see these articles:
AD FS prompt=login parameter support
Set-MsolDomainAuthentication
NOTE
If Suppor tsMfa is set to True , you're using an on-premises multi-factor authentication solution to inject a second-factor
challenge into the user authentication flow. This setup no longer works for Azure AD authentication scenarios.
Instead, use the Azure Multi-Factor Authentication cloud-based service to perform the same function. Carefully evaluate your
multi-factor authentication requirements before you continue. Before you convert your domains, make sure that you
understand how to use Azure Multi-Factor Authentication, the licensing implications, and the user registration process.
Back up federation settings

Although no changes are made to other relying parties in your AD FS farm during the processes described in this
article, we recommend that you have a current valid backup of your AD FS farm that you can restore from. You can
create a current valid backup by using the free Microsoft AD FS Rapid Restore Tool. You can use the tool to back up
AD FS, and to restore an existing farm or create a new farm.
If you choose not to use the AD FS Rapid Restore Tool, at a minimum, you should export the Microsoft Office 365
Identity Platform relying party trust and any associated custom claim rules you added. You can export the relying
party trust and associated claim rules by using the following PowerShell example:
(Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform") | Export-CliXML "C:\temp\O365-

RelyingPartyTrust.xml"
Deployment considerations and using AD FS

This section describes deployment considerations and details about using AD FS.
Current AD FS use
Before you convert from federated identity to managed identity, look closely at how you currently use AD FS for
Azure AD, Office 365, and other applications (relying party trusts). Specifically, consider the scenarios that are
described in the following table:
IF T H EN
You plan to keep using AD FS with other applications (other After you convert your domains, you'll use both AD FS and
than Azure AD and Office 365). Azure AD. Consider the user experience. In some scenarios,
users might be required to authenticate twice: once to Azure
AD (where a user gets SSO access to other applications, like
Office 365), and again for any applications that are still bound
to AD FS as a relying party trust.
Your AD FS instance is heavily customized and relies on Before you continue, you must verify that Azure AD can meet
specific customization settings in the onload.js file (for your current customization requirements. For more
example, if you changed the sign-in experience so that users information and for guidance, see the sections on AD FS
use only a SamAccountName format for their username branding and AD FS customization.
instead of a User Principal Name (UPN), or your organization
has heavily branded the sign-in experience). The onload.js file
can't be duplicated in Azure AD.
You use AD FS to block earlier versions of authentication Consider replacing AD FS controls that block earlier versions of
clients. authentication clients by using a combination of Conditional
Access controls and Exchange Online Client Access Rules.
IF T H EN
You require users to perform multi-factor authentication In a managed identity domain, you can't inject a multi-factor
against an on-premises multi-factor authentication server authentication challenge via the on-premises multi-factor
solution when users authenticate to AD FS. authentication solution into the authentication flow. However,
you can use the Azure Multi-Factor Authentication service for
multi-factor authentication after the domain is converted.
If your users don't currently use Azure Multi-Factor

Authentication, a onetime user registration step is required.
You must prepare for and communicate the planned
registration to your users.
You currently use access control policies (AuthZ rules) in AD FS Consider replacing the policies with the equivalent Azure AD
to control access to Office 365. Conditional Access policies and Exchange Online Client Access
Rules.
Common AD FS customizations
This section describes common AD FS customizations.
InsideCorporateNetwork claim
AD FS issues the InsideCorporateNetwork claim if the user who is authenticating is inside the corporate
network. This claim can then be passed on to Azure AD. The claim is used to bypass multi-factor authentication
based on the user's network location. To learn how to determine whether this functionality currently is available in
AD FS, see Trusted IPs for federated users.
The InsideCorporateNetwork claim isn't available after your domains are converted to pass-through
authentication. You can use named locations in Azure AD to replace this functionality.
After you configure named locations, you must update all Conditional Access policies that were configured to either
include or exclude the network All trusted locations or MFA Trusted IPs values to reflect the new named
locations.
For more information about the Location condition in Conditional Access, see Active Directory Conditional Access
locations.
Hybrid Azure AD-joined devices
When you join a device to Azure AD, you can create Conditional Access rules that enforce that devices meet your
access standards for security and compliance. Also, users can sign in to a device by using an organizational work or
school account instead of a personal account. When you use hybrid Azure AD-joined devices, you can join your
Active Directory domain-joined devices to Azure AD. Your federated environment might have been set up to use
this feature.
To ensure that hybrid join continues to work for any devices that are joined to the domain after your domains are
converted to pass-through authentication, for Windows 10 clients, you must use Azure AD Connect to sync Active
Directory computer accounts to Azure AD.
For Windows 8 and Windows 7 computer accounts, hybrid join uses seamless SSO to register the computer in
Azure AD. You don't have to sync Windows 8 and Windows 7 computer accounts like you do for Windows 10
devices. However, you must deploy an updated workplacejoin.exe file (via an .msi file) to Windows 8 and Windows
7 clients so they can register themselves by using seamless SSO. Download the .msi file.
For more information, see Configure hybrid Azure AD-joined devices.
Branding
If your organization customized your AD FS sign-in pages to display information that's more pertinent to the
organization, consider making similar customizations to the Azure AD sign-in page.
Although similar customizations are available, some visual changes on sign-in pages should be expected after the
conversion. You might want to provide information about expected changes in your communications to users.
NOTE
Organization branding is available only if you purchase the Premium or Basic license for Azure Active Directory or if you have
an Office 365 license.
Plan for smart lockout

Azure AD smart lockout protects against brute-force password attacks. Smart lockout prevents an on-premises
Active Directory account from being locked out when pass-through authentication is being used and an account
lockout group policy is set in Active Directory.
For more information, see Azure Active Directory smart lockout.
Plan deployment and support

Complete the tasks that are described in this section to help you plan for deployment and support.
Plan the maintenance window
Although the domain conversion process is relatively quick, Azure AD might continue to send some authentication
requests to your AD FS servers for up to four hours after the domain conversion is finished. During this four-hour
window, and depending on various service side caches, Azure AD might not accept these authentications. Users
might receive an error. The user can still successfully authenticate against AD FS, but Azure AD no longer accepts
the user’s issued token because that federation trust is now removed.
Only users who access the services via a web browser during this post-conversion window before the service side
cache is cleared are affected. Legacy clients (Exchange ActiveSync, Outlook 2010/2013) aren't expected to be
affected because Exchange Online keeps a cache of their credentials for a set period of time. The cache is used to
silently reauthenticate the user. The user doesn't have to return to AD FS. Credentials stored on the device for these
clients are used to silently reauthenticate themselves after this cached is cleared. Users aren't expected to receive
any password prompts as a result of the domain conversion process.
Modern authentication clients (Office 2016 and Office 2013, iOS, and Android apps) use a valid refresh token to
obtain new access tokens for continued access to resources instead of returning to AD FS. These clients are
immune to any password prompts resulting from the domain conversion process. The clients will continue to
function without additional configuration.
IMPORTANT
Don’t shut down your AD FS environment or remove the Office 365 relying party trust until you have verified that all users
can successfully authenticate by using cloud authentication.
Plan for rollback

If you encounter a major issue that you can't resolve quickly, you might decide to roll back the solution to
federation. It’s important to plan what to do if your deployment doesn’t roll out as intended. If conversion of the
domain or users fails during deployment, or if you need to roll back to federation, you must understand how to
mitigate any outage and reduce the effect on your users.
To roll back
To plan for rollback, check the federation design and deployment documentation for your specific deployment
details. The process should include these tasks:
Converting managed domains to federated domains by using the Conver t-MSOLDomainToFederated
cmdlet.
If necessary, configuring additional claims rules.
Plan communications
An important part of planning deployment and support is ensuring that your users are proactively informed about
upcoming changes. Users should know in advance what they might experience and what is required of them.
After both pass-through authentication and seamless SSO are deployed, the user sign-in experience for accessing
Office 365 and other resources that are authenticated through Azure AD changes. Users who are outside the
network see only the Azure AD sign-in page. These users aren't redirected to the forms-based page that's presented
by external-facing web application proxy servers.
Include the following elements in your communication strategy:
Notify users about upcoming and released functionality by using:
Email and other internal communication channels.
Visuals, such as posters.
Executive, live, or other communications.
Determine who will customize the communications and who will send the communications, and when.
Implement your solution

You planned your solution. Now, you can now implement it. Implementation involves the following components:
Preparing for seamless SSO.
Changing the sign-in method to pass-through authentication and enabling seamless SSO.
Step 1: Prepare for seamless SSO
For your devices to use seamless SSO, you must add an Azure AD URL to users' intranet zone settings by using a
group policy in Active Directory.
By default, web browsers automatically calculate the correct zone, either internet or intranet, from a URL. For
example, http://contoso/ maps to the intranet zone and http://intranet.contoso.com maps to the internet zone
(because the URL contains a period). Browsers send Kerberos tickets to a cloud endpoint, like the Azure AD URL,
only if you explicitly add the URL to the browser's intranet zone.
Complete the steps to roll out the required changes to your devices.
IMPORTANT
Making this change doesn't modify the way your users sign in to Azure AD. However, it’s important that you apply this
configuration to all your devices before you proceed. Users who sign in on devices that haven't received this configuration
simply are required to enter a username and password to sign in to Azure AD.
Step 2: Change the sign-in method to pass-through authentication and enable seamless SSO
You have two options for changing the sign-in method to pass-through authentication and enabling seamless SSO.
Option A: Configure pass-through authentication by using Azure AD Connect
Use this method if you initially configured your AD FS environment by using Azure AD Connect. You can't use this
method if you didn't originally configure your AD FS environment by using Azure AD Connect.
IMPORTANT
After you complete the following steps, all your domains are converted from federated identity to managed identity. For
more information, review Plan the migration method.
First, change the sign-in method:

4. On the User sign-in page, select the Pass-through authentication button, select Enable single sign-
on , and then select Next .
5. On the Enable single sign-on page, enter the credentials of a Domain Administrator account, and then
select Next .
NOTE
Directory instance.
sign-in.
7. In the Azure AD portal, select Azure Active Director y , and then select Azure AD Connect .
Pass-through authentication is set to Enabled .
Next. deploy additional authentication methods:

1. In the Azure portal, go to Azure Active Director y > Azure AD Connect , and then select Pass-through
authentication .
2. On the Pass-through authentication page, select the Download button.
3. On the Download agent page, select Accept terms and download .
Additional authentication agents start to download. Install the secondary authentication agent on a domain-
joined server.
NOTE
The first agent is always installed on the Azure AD Connect server itself as part of the configuration changes made in
the User sign-in section of the Azure AD Connect tool. Install any additional authentication agents on a separate
server. We recommend that you have two or three additional authentication agents available.
4. Run the authentication agent installation. During installation, you must enter the credentials of a Global
Administrator account.
5. When the authentication agent is installed, you can return to the pass-through authentication agent health
page to check the status of the additional agents.
Skip to Testing and next steps.
IMPORTANT
Skip the section Option B: Switch from federation to pass-through authentication by using Azure AD Connect
and PowerShell. The steps in that section don't apply if you chose Option A to change the sign-in method to pass-through
authentication and enable seamless SSO.
Option B: Switch from federation to pass-through authentication by using Azure AD Connect and PowerShell
Use this option if you didn't initially configure your federated domains by using Azure AD Connect.
First, enable pass-through authentication:
1. On the Azure AD Connect Server, open the Azure AD Connect wizard.
4. On the User sign-in page, select the Pass-through authentication button. Select Enable single sign-
on , and then select Next .
5. On the Enable single sign-on page, enter the credentials of a Domain Administrator account, and then
select Next .
NOTE
Directory instance.
sign-in.
The following steps occur when you select Configure :

a. The first pass-through authentication agent is installed.
b. The pass-through feature is enabled.
c. Seamless SSO is enabled.
8. Select Pass-through authentication and verify that the status is Active .
If the authentication agent isn't active, complete some troubleshooting steps before you continue with the
domain conversion process in the next step. You risk causing an authentication outage if you convert your
domains before you validate that your pass-through authentication agents are successfully installed and that
their status Active in the Azure portal.
Next, deploy additional authentication agents:
1. In the Azure portal, go to Azure Active Director y > Azure AD Connect , and then select Pass-through
authentication .
2. On the Pass-through authentication page, select the Download button.
3. On the Download agent page, select Accept terms and download .
The authentication agent starts to download. Install the secondary authentication agent on a domain-joined
server.
NOTE
The first agent is always installed on the Azure AD Connect server itself as part of the configuration changes made in
the User sign-in section of the Azure AD Connect tool. Install any additional authentication agents on a separate
server. We recommend that you have two or three additional authentication agents available.
4. Run the authentication agent installation. During the installation, you must enter the credentials of a Global
Administrator account.
5. After the authentication agent is installed, you can return to the pass-through authentication agent health
page to check the status of the additional agents.
At this point, federated authentication is still active and operational for your domains. To continue with the
deployment, you must convert each domain from federated identity to managed identity so that pass-through
authentication starts serving authentication requests for the domain.
You don't have to convert all domains at the same time. You might choose to start with a test domain on your
production tenant or start with your domain that has the lowest number of users.
Complete the conversion by using the Azure AD PowerShell module:
1. In PowerShell, sign in to Azure AD by using a Global Administrator account.
2. To convert the first domain, run the following command:
Set-MsolDomainAuthentication -Authentication Managed -DomainName <domain name>
4. After you convert all your federated domains, verify these settings:
Testing and next steps

Complete the following tasks to verify pass-through authentication and to finish the conversion process.
Test pass-through authentication
When your tenant used federated identity, users were redirected from the Azure AD sign-in page to your AD FS
environment. Now that the tenant is configured to use pass-through authentication instead of federated
authentication, users aren't redirected to AD FS. Instead, users sign in directly on the Azure AD sign-in page.
To test pass-through authentication:
1. Open Internet Explorer in InPrivate mode so that seamless SSO doesn't sign you in automatically.
2. Go to the Office 365 sign-in page (https://portal.office.com).
3. Enter a user UPN, and then select Next . Make sure that you enter the UPN of a hybrid user who was synced
from your on-premises Active Directory instance, and who previously used federated authentication. A page
on which you enter the username and password appears:
4. After you enter the password and select Sign in , you're redirected to the Office 365 portal.
Test seamless SSO
To test seamless SSO:
1. Sign in to a domain-joined machine that is connected to the corporate network.
2. In Internet Explorer or Chrome, go to one of the following URLs (replace "contoso" with your domain):
https://myapps.microsoft.com/contoso.com
https://myapps.microsoft.com/contoso.onmicrosoft.com
The user is briefly redirected to the Azure AD sign-in page, which shows the message "Trying to sign you in."
The user isn't prompted for a username or password.
3. The user is redirected and is successfully signed in to the access panel:

NOTE
Seamless SSO works on Office 365 services that support domain hint (for example,
myapps.microsoft.com/contoso.com). Currently, the Office 365 portal (portal.office.com) doesn’t support domain
hints. Users are required to enter a UPN. After a UPN is entered, seamless SSO retrieves the Kerberos ticket on behalf
of the user. The user is signed in without entering a password.
TIP
Consider deploying Azure AD hybrid join on Windows 10 for an improved SSO experience.
Remove the relying party trust

After you validate that all users and clients are successfully authenticating via Azure AD, it's safe to remove the
Office 365 relying party trust.
If you don't use AD FS for other purposes (that is, for other relying party trusts), it's safe to decommission AD FS at
this point.
Rollback
If you discover a major issue and can't resolve it quickly, you might choose to roll back the solution to federation.
Consult the federation design and deployment documentation for your specific deployment details. The process
should involve these tasks:
Convert managed domains to federated authentication by using the Conver t-MSOLDomainToFederated
cmdlet.
If necessary, configure additional claims rules.
Sync userPrincipalName updates
Historically, updates to the UserPrincipalName attribute, which uses the sync service from the on-premises
environment, are blocked unless both of these conditions are true:
The user is in a managed (non-federated) identity domain.
The user hasn't been assigned a license.
To learn how to verify or turn on this feature, see Sync userPrincipalName updates.
Roll over the seamless SSO Kerberos decryption key

It's important to frequently roll over the Kerberos decryption key of the AZUREADSSOACC computer account
(which represents Azure AD). The AZUREADSSOACC computer account is created in your on-premises Active
Directory forest. We highly recommend that you roll over the Kerberos decryption key at least every 30 days to
align with the way that Active Directory domain members submit password changes. There's no associated device
attached to the AZUREADSSOACC computer account object, so you must perform the rollover manually.
Initiate the rollover of the seamless SSO Kerberos decryption key on the on-premises server that's running Azure
AD Connect.
For more information, see How do I roll over the Kerberos decryption key of the AZUREADSSOACC computer
account?.
Monitoring and logging

Monitor the servers that run the authentication agents to maintain the solution availability. In addition to general
server performance counters, the authentication agents expose performance objects that can help you understand
authentication statistics and errors.
Authentication agents log operations to the Windows event logs that are located under Application and Service
Logs\Microsoft\AzureAdConnect\AuthenticationAgent\Admin.
You can also turn on logging for troubleshooting.
For more information, see Troubleshoot Azure Active Directory pass-through authentication.
Next steps
Learn about Azure AD Connect design concepts.
Choose the right authentication.
Learn about supported topologies.
Migrate groups from one forest to another for Azure
AD Connect
This article describes how to migrate groups from one forest to another so that the migrated group objects match
the existing objects in the cloud.
Prerequisites
Azure AD Connect version 1.5.18.0 or later
Source anchor attribute set to mS-DS-ConsistencyGuid
Migrate groups
Starting in version 1.5.18.0, Azure AD Connect supports the use of the mS-DS-ConsistencyGuid attribute for groups.
If you choose mS-DS-ConsistencyGuid as the source anchor attribute and the value is populated in Active Directory,
Azure AD Connect uses the value of mS-DS-ConsistencyGuid as the immutableId . Otherwise, it falls back to using
objectGUID . But note that Azure AD Connect doesn't write the value back to the mS-DS-ConsistencyGuid attribute in
Active Directory.
During a cross-forest move, when a group object is moving from one forest (say F1) to another forest (say F2), you
need to copy either the mS-DS-ConsistencyGuid value (if it's present) or the objectGUID value from the object in
forest F1 to the mS-DS-ConsistencyGuid attribute of the object in F2.
Use the following scripts as a guide to learn how to migrate a single group from one forest to another. You can also
use these scripts as a guide for the migration of multiple groups. The scripts use the forest name F1 for the source
forest and F2 for the destination forest.
First, we get the objectGUID and mS-DS-ConsistencyGuid of the group object in forest F1. These attributes are
exported to a CSV file.
<#
DESCRIPTION
============
This script will take DN of a group as input.
It then copies the objectGUID and mS-DS-ConsistencyGuid values along with other attributes of the given group
to a CSV file.
This CSV file can then be used as input to the Export-Group script.
#>
Param(
[ValidateNotNullOrEmpty()]
[string]
$dn,
[string]
$outputCsv
)
$defaultProperties = @('samAccountName', 'distinguishedName', 'objectGUID', 'mS-DS-ConsistencyGuid')

$group = Get-ADGroup -Filter "DistinguishedName -eq '$dn'" -Properties $defaultProperties -ErrorAction Stop
$results = @()
if ($group -eq $null)
{
Write-Error "Group not found"
}
else
{
$objectGUIDValue = [GUID]$group.'objectGUID'
$mSDSConsistencyGuidValue = "N/A"
if ($group.'mS-DS-ConsistencyGuid' -ne $null)
{
$mSDSConsistencyGuidValue = [GUID]$group.'mS-DS-ConsistencyGuid'
}
$adgroup = New-Object -TypeName PSObject
$adgroup | Add-Member -MemberType NoteProperty -Name samAccountName -Value $($group.'samAccountName')
$adgroup | Add-Member -MemberType NoteProperty -Name distinguishedName -Value
$($group.'distinguishedName')
$adgroup | Add-Member -MemberType NoteProperty -Name objectGUID -Value $($objectGUIDValue)
$adgroup | Add-Member -MemberType NoteProperty -Name mS-DS-ConsistencyGuid -Value
$($mSDSConsistencyGuidValue)
$results += $adgroup
}
Write-Host "Exporting group to output file"

$results | Export-Csv "$outputCsv" -NoTypeInformation
Next, we use the generated output CSV file to stamp the mS-DS-ConsistencyGuid attribute on the target object in
forest F2:
<#
DESCRIPTION
============
This script will take DN of a group as input and the CSV file that was generated by the Import-Group script.
It copies either the objectGUID or the mS-DS-ConsistencyGuid value from the CSV file to the given object.
#>
Param(
[string]
$dn,
[string]
$inputCsv
)
$group = Get-ADGroup -Filter "DistinguishedName -eq '$dn'" -ErrorAction Stop

if ($group -eq $null)
{
Write-Error "Group not found"
}
$csvFile = Import-Csv -Path $inputCsv -ErrorAction Stop

$msDSConsistencyGuid = $csvFile.'mS-DS-ConsistencyGuid'
$objectGuid = [GUID] $csvFile.'objectGUID'
$targetGuid = $msDSConsistencyGuid
if ($msDSConsistencyGuid -eq "N/A")

{
$targetGuid = $objectGuid
}
Set-ADGroup -Identity $dn -Replace @{'mS-DS-ConsistencyGuid'=$targetGuid} -ErrorAction Stop
Next steps
Migrate to cloud authentication using staged rollout
(preview)
Staged rollout allows you to selectively test groups of users with cloud authentication capabilities like Azure
Multi-Factor Authentication (MFA), Conditional Access, Identity Protection for leaked credentials, Identity
Governance, and others, before cutting over your domains. This article discusses how to make the switch. Before
you begin the staged rollout, however, you should consider the implications if one or more of the following
conditions is true:
You're currently using an on-premises Multi-Factor Authentication server.
You're using smart cards for authentication.
Your current server offers certain federation-only features.
Before you try this feature, we suggest that you review our guide on choosing the right authentication method.
For more information, see the "Comparing methods" table in Choose the right authentication method for your
Azure Active Directory hybrid identity solution.
For an overview of the feature, view this "Azure Active Directory: What is staged rollout?" video:
Prerequisites
You have an Azure Active Directory (Azure AD) tenant with federated domains.
You have decided to move to either of two options:
Option A - password hash synchronization (sync) + seamless single sign-on (SSO). For more
information, see What is password hash sync and What is seamless SSO
Option B - pass-through authentication + seamless SSO. For more information, see What is pass-
through authentication
Although seamless SSO is optional, we recommend enabling it to achieve a silent sign-in experience for
users who are running domain-joined machines from inside a corporate network.
You have configured all the appropriate tenant-branding and conditional access policies you need for
users who are being migrated to cloud authentication.
If you plan to use Azure Multi-Factor Authentication, we recommend that you use combined registration
for self-service password reset (SSPR) and Multi-Factor Authentication to have your users register their
authentication methods once.
To use the staged rollout feature, you need to be a global administrator on your tenant.
To enable seamless SSO on a specific Active Directory forest, you need to be a domain administrator.
If you are deploying Hybrid Azure AD or Azure AD join, you must upgrade to Windows 10 1903 update.
Supported scenarios
The following scenarios are supported for staged rollout. The feature works only for:
Users who are provisioned to Azure AD by using Azure AD Connect. It does not apply to cloud-only users.
User sign-in traffic on browsers and modern authentication clients. Applications or cloud services that use
legacy authentication will fall back to federated authentication flows. An example might be Exchange
online with modern authentication turned off, or Outlook 2010, which does not support modern
authentication.
Group size is currently limited to 50,000 users. If you have groups that are larger then 50,000 users, it is
recommended to split this group over multiple groups for staged rollout.
Unsupported scenarios
The following scenarios are not supported for staged rollout:
Certain applications send the "domain_hint" query parameter to Azure AD during authentication. These flows
will continue, and users who are enabled for staged rollout will continue to use federation for authentication.
Admins can roll out cloud authentication by using security groups. To avoid sync latency when you're
using on-premises Active Directory security groups, we recommend that you use cloud security groups.
The following conditions apply:
You can use a maximum of 10 groups per feature. That is, you can use 10 groups each for password
hash sync, pass-through authentication, and seamless SSO.
Nested groups are not supported. This scope applies to public preview as well.
Dynamic groups are not supported for staged rollout.
Contact objects inside the group will block the group from being added.
You still need to make the final cutover from federated to cloud authentication by using Azure AD Connect
or PowerShell. Staged rollout doesn't switch domains from federated to managed. For more information
about domain cutover, see Migrate from federation to password hash synchronization and Migrate from
federation to pass-through authentication
When you first add a security group for staged rollout, you're limited to 200 users to avoid a UX time-out.
After you've added the group, you can add more users directly to it, as required.
While users are in Staged Rollout, when EnforceCloudPasswordPolicyForPasswordSyncedUsers is enabled,
password expiration policy is set to 90 days with no option to customize it.
Get started with staged rollout

To test the password hash sync sign-in by using staged rollout, follow the pre-work instructions in the next
section.
For information about which PowerShell cmdlets to use, see Azure AD 2.0 preview.
Pre-work for password hash sync

1. Enable password hash sync from the Optional features page in Azure AD Connect.
2. Ensure that a full password hash sync cycle has run so that all the users' password hashes have
been synchronized to Azure AD. To check the status of password hash sync, you can use the PowerShell
diagnostics in Troubleshoot password hash sync with Azure AD Connect sync.
If you want to test pass-through authentication sign-in by using staged rollout, enable it by following the pre-
work instructions in the next section.
Pre-work for pass-through authentication

1. Identify a server that's running Windows Server 2012 R2 or later where you want the pass-through
authentication agent to run.
Do not choose the Azure AD Connect server. Ensure that the server is domain-joined,
can authenticate selected users with Active Directory, and can communicate with Azure AD on outbound
ports and URLs. For more information, see the "Step 1: Check the prerequisites" section of Quickstart:
Azure AD seamless single sign-on.
2. Download the Azure AD Connect authentication agent, and install it on the server.
3. To enable high availability, install additional authentication agents on other servers.
4. Make sure that you've configured your Smart Lockout settings appropriately. Doing so helps ensure that
your users' on-premises Active Directory accounts don't get locked out by bad actors.
We recommend enabling seamless SSO irrespective of the sign-in method (password hash sync or pass-through
authentication) you select for staged rollout. To enable seamless SSO, follow the pre-work instructions in the next
section.
Pre-work for seamless SSO

Enable seamless SSO on the Active Directory forests by using PowerShell. If you have more than one Active
Directory forest, enable it for each forest individually. Seamless SSO is triggered only for users who are
selected for staged rollout. It doesn't affect your existing federation setup.
Enable seamless SSO by doing the following:
1. Sign in to Azure AD Connect Server.
2. Go to the %programfiles%\Microsoft Azure Active Directory Connect folder.
3. Import the seamless SSO PowerShell module by running the following command:
Import-Module .\AzureADSSO.psd1
4. Run PowerShell as an administrator. In PowerShell, call New-AzureADSSOAuthenticationContext . This

command opens a pane where you can enter your tenant's global administrator credentials.
5. Call Get-AzureADSSOStatus | ConvertFrom-Json . This command displays a list of Active Directory forests
(see the "Domains" list) on which this feature has been enabled. By default, it is set to false at the tenant
level.
6. Call $creds = Get-Credential . At the prompt, enter the domain administrator credentials for the intended
Active Directory forest.
7. Call Enable-AzureADSSOForest -OnPremCredentials $creds . This command creates the AZUREADSSOACC
computer account from the on-premises domain controller for the Active Directory forest that's required
for seamless SSO.
8. Seamless SSO requires URLs to be in the intranet zone. To deploy those URLs by using group policies, see
Quickstart: Azure AD seamless single sign-on.
9. For a complete walkthrough, you can also download our deployment plans for seamless SSO.
Enable staged rollout
To roll out a specific feature (pass-through authentication, password hash sync, or seamless SSO) to a select set
of users in a group, follow the instructions in the next sections.
Enable a staged rollout of a specific feature on your tenant
You can roll out one of these options:
Option A - password hash sync + seamless SSO
Option B - pass-through authentication + seamless SSO
Not suppor ted - password hash sync + pass-through authentication + seamless SSO
Do the following:
1. To access the preview UX, sign in to the Azure AD portal.
2. Select the Enable staged rollout for managed user sign-in (Preview) link.
For example, if you want to enable Option A, slide the Password Hash Sync and Seamless single
sign-on controls to On , as shown in the following images.
3. Add the groups to the feature to enable pass-through authentication and seamless SSO. To avoid a UX
time-out, ensure that the security groups contain no more than 200 members initially.
NOTE
The members in a group are automatically enabled for staged rollout. Nested and dynamic groups are not
supported for staged rollout. When adding a new group, users in the group (up to 200 users for a new group) will
be updated to use managed auth immidiatly. Editing a group (adding or removing users), it can take up to 24
hours for changes to take effect.
Auditing
We've enabled audit events for the various actions we perform for staged rollout:
Audit event when you enable a staged rollout for password hash sync, pass-through authentication, or
seamless SSO.
NOTE
An audit event is logged when seamless SSO is turned on by using staged rollout.
Audit event when a group is added to password hash sync, pass-through authentication, or seamless SSO.
NOTE
An audit event is logged when a group is added to password hash sync for staged rollout.
Audit event when a user who was added to the group is enabled for staged rollout.
Validation
To test the sign-in with password hash sync or pass-through authentication (username and password sign-in), do
the following:
1. On the extranet, go to the Apps page in a private browser session, and then enter the UserPrincipalName
(UPN) of the user account that's selected for staged rollout.
Users who've been targeted for staged rollout are not redirected to your federated login page. Instead,
they're asked to sign in on the Azure AD tenant-branded sign-in page.
2. Ensure that the sign-in successfully appears in the Azure AD sign-in activity report by filtering with the
UserPrincipalName.
To test sign-in with seamless SSO:
1. On the intranet, go to the Apps page in a private browser session, and then enter the UserPrincipalName
(UPN) of the user account that's selected for staged rollout.
Users who've been targeted for staged rollout of seamless SSO are presented with a "Trying to sign you in
..." message before they're silently signed in.
2. Ensure that the sign-in successfully appears in the Azure AD sign-in activity report by filtering with the
UserPrincipalName.
To track user sign-ins that still occur on Active Directory Federation Services (AD FS) for selected staged
rollout users, follow the instructions at AD FS troubleshooting: Events and logging. Check vendor
documentation about how to check this on third-party federation providers.
Remove a user from staged rollout

Removing a user from the group disables staged rollout for that user. To disable the staged rollout feature, slide
the control back to Off .
Frequently asked questions

Q: Can I use this capability in production?
A: Yes, you can use this feature in your production tenant, but we recommend that you first try it out in your test
tenant.
Q: Can this feature be used to maintain a permanent "co-existence," where some users use
federated authentication and others use cloud authentication?
A: No, this feature is designed for migrating from federated to cloud authentication in stages and then to
eventually cut over to cloud authentication. We do not recommend using a permanent mixed state, because this
approach could lead to unexpected authentication flows.
Q: Can I use PowerShell to perform staged rollout?
A: Yes. To learn how to use PowerShell to perform staged rollout, see Azure AD Preview.
Next steps
Azure AD 2.0 preview
Azure Active Directory Hybrid Identity Design
Considerations
Consumer-based devices are proliferating the corporate world, and cloud-based software-as-a-service (SaaS)
applications are easy to adopt. As a result, maintaining control of users’ application access across internal
datacenters and cloud platforms is challenging.
Microsoft’s identity solutions span on-premises and cloud-based capabilities, creating a single user identity for
authentication and authorization to all resources, regardless of location. This concept is known as Hybrid Identity.
There are different design and configuration options for hybrid identity using Microsoft solutions, and in some
case it might be difficult to determine which combination will best meet the needs of your organization.
This Hybrid Identity Design Considerations Guide will help you to understand how to design a hybrid identity
solution that best fits the business and technology needs for your organization. This guide details a series of steps
and tasks that you can follow to help you design a hybrid identity solution that meets your organization’s unique
requirements. Throughout the steps and tasks, the guide will present the relevant technologies and feature
options available to organizations to meet functional and service quality (such as availability, scalability,
performance, manageability, and security) level requirements.
Specifically, the hybrid identity design considerations guide goals are to answer the following questions:
What questions do I need to ask and answer to drive a hybrid identity-specific design for a technology or
problem domain that best meets my requirements?
What sequence of activities should I complete to design a hybrid identity solution for the technology or
problem domain?
What hybrid identity technology and configuration options are available to help me meet my requirements?
What are the trade-offs between those options so that I can select the best option for my business?
Who is this guide intended for?

CIO, CITO, Chief Identity Architects, Enterprise Architects, and IT Architects responsible for designing a hybrid
identity solution for medium or large organizations.
How can this guide help you?

You can use this guide to understand how to design a hybrid identity solution that is able to integrate a cloud-
based identity management system with your current on-premises identity solution.
The following graphic shows an example a hybrid identity solution that enables IT Admins to manage to integrate
their current Windows Server Active Directory solution located on-premises with Microsoft Azure Active
Directory to enable users to use Single Sign-On (SSO) across applications located in the cloud and on-premises.
The above illustration is an example of a hybrid identity solution that is leveraging cloud services to integrate with
on-premises capabilities in order to provide a single experience to the end-user authentication process and to
facilitate IT managing those resources. Although this example can be a common scenario, every organization’s
hybrid identity design is likely to be different than the example illustrated in Figure 1 due to different
requirements.
This guide provides a series of steps and tasks that you can follow to design a hybrid identity solution that meets
your organization’s unique requirements. Throughout the following steps and tasks, the guide presents the
relevant technologies and feature options available to you to meet functional and service quality level
requirements for your organization.
Assumptions : You have some experience with Windows Server, Active Directory Domain Services, and Azure
Active Directory. In this document, it is assumed you are looking for how these solutions can meet your business
needs on their own, or in an integrated solution.
Design considerations overview

This document provides a set of steps and tasks that you can follow to design a hybrid identity solution that best
meets your requirements. The steps are presented in an ordered sequence. Design considerations you learn in
later steps may require you to change decisions you made in earlier steps, however, due to conflicting design
choices. Every attempt is made to alert you to potential design conflicts throughout the document.
You will arrive at the design that best meets your requirements only after iterating through the steps as many
times as necessary to incorporate all of the considerations within the document.
H Y B RID IDEN T IT Y P H A SE TO P IC L IST
Determine identity requirements Determine business needs

Determine directory synchronization requirements
Determine multi-factor authentication requirements
Define a hybrid identity adoption strategy
Plan for enhancing data security through strong identity Determine data protection requirements
solution Determine content management requirements
Define data protection strategy
Plan for hybrid identity lifecycle Determine hybrid identity management tasks
Synchronization Management
Determine hybrid identity management adoption strategy
Next Steps
Determine identity requirements
Determine identity requirements for your hybrid
identity solution
The first step in designing a hybrid identity solution is to determine the requirements for the business organization
that will be leveraging this solution. Hybrid identity starts as a supporting role (it supports all other cloud solutions
by providing authentication) and goes on to provide new and interesting capabilities that unlock new workloads
for users. These workloads or services that you wish to adopt for your users will dictate the requirements for the
hybrid identity design. These services and workloads need to leverage hybrid identity both on-premises and in the
cloud.
You need to go over these key aspects of the business to understand what it is a requirement now and what the
company plans for the future. If you don’t have the visibility of the long term strategy for hybrid identity design,
chances are that your solution will not be scalable as the business needs grow and change. The diagram below
shows an example of a hybrid identity architecture and the workloads that are being unlocked for users. This is just
an example of all the new possibilities that can be unlocked and delivered with a solid hybrid identity strategy.
Some components that are part of the hybrid identity architecture
Determine business needs

Each company will have different requirements, even if these companies are part of the same industry, the real
business requirements might vary. You can still leverage best practices from the industry, but ultimately it is the
company’s business needs that will lead you to define the requirements for the hybrid identity design.
Make sure to answer the following questions to identify your business needs:
Is your company looking to cut IT operational cost?
Is your company looking to secure cloud assets (SaaS apps, infrastructure)?
Is your company looking to modernize your IT?
Are your users more mobile and demanding IT to create exceptions into your DMZ to allow different
type of traffic to access different resources?
Does your company have legacy apps that needed to be published to these modern users but are not
easy to rewrite?
Does your company need to accomplish all these tasks and bring it under control at the same time?
Is your company looking to secure users’ identities and reduce risk by bringing new tools that leverage the
expertise of Microsoft’s Azure security expertise on-premises?
Is your company trying to get rid of the dreaded “external” accounts on premises and move them to the cloud
where they are no longer a dormant threat inside your on-premises environment?
Analyze on-premises identity infrastructure

Now that you have an idea regarding your company business requirements, you need to evaluate your on-
premises identity infrastructure. This evaluation is important for defining the technical requirements to integrate
your current identity solution to the cloud identity management system. Make sure to answer the following
questions:
What authentication and authorization solution does your company use on-premises?
Does your company currently have any on-premises synchronization services?
Does your company use any third-party Identity Providers (IdP)?
You also need to be aware of the cloud services that your company might have. Performing an assessment to
understand the current integration with SaaS, IaaS or PaaS models in your environment is very important. Make
sure to answer the following questions during this assessment:
Does your company have any integration with a cloud service provider?
If yes, which services are being used?
Is this integration currently in production or is it a pilot?
NOTE
Cloud Discovery analyzes your traffic logs against Microsoft Cloud App Security's cloud app catalog of over 16,000 cloud
apps that are ranked and scored based on more than 70 risk factors, to provide you with ongoing visibility into cloud use,
Shadow IT, and the risk Shadow IT poses into your organization.To get started see Set up Cloud Discovery.
Evaluate identity integration requirements

Next, you need to evaluate the identity integration requirements. This evaluation is important to define the
technical requirements for how users will authenticate, how the organization’s presence will look in the cloud, how
the organization will allow authorization and what the user experience is going to be. Make sure to answer the
following questions:
Will your organization be using federation, standard authentication or both?
Is federation a requirement? Because of the following:
Kerberos-based SSO
Your company has an on-premises applications (either built in-house or 3rd party) that uses SAML or
similar federation capabilities.
MFA via Smart Cards. RSA SecurID, etc.
Client access rules that address the questions below:
1. Can I block all external access to Office 365 based on the IP address of the client?
2. Can I block all external access to Office 365, except Exchange ActiveSync?
3. Can I block all external access to Office 365, except for browser-based apps (OWA, SPO)
4. Can I block all external access to Office 365 for members of designated AD groups
Security/auditing concerns
Already existing investment in federated authentication
What name will our organization use for our domain in the cloud?
Does the organization have a custom domain?
1. Is that domain public and easily verifiable via DNS?
2. If it is not, then do you have a public domain that can be used to register an alternate UPN in AD?
Are the user identifiers consistent for cloud representation?
Does the organization have apps that require integration with cloud services?
Does the organization have multiple domains and will they all use standard or federated authentication?
Evaluate applications that run in your environment

Now that you have an idea regarding your on-premises and cloud infrastructure, you need to evaluate the
applications that run in these environments. This evaluation is important to define the technical requirements to
integrate these applications to the cloud identity management system. Make sure to answer the following
questions:
Where will our applications live?
Will users be accessing on-premises applications? In the cloud? Or both?
Are there plans to take the existing application workloads and move them to the cloud?
Are there plans to develop new applications that will reside either on-premises or in the cloud that will use
cloud authentication?
Evaluate user requirements

You also have to evaluate the user requirements. This evaluation is important to define the steps that will be
needed for on-boarding and assisting users as they transition to the cloud. Make sure to answer the following
questions:
Will users be accessing applications on-premises?
Will users be accessing applications in the cloud?
How do users typically login to their on-premises environment?
How will users sign-in to the cloud?
NOTE
Make sure to take notes of each answer and understand the rationale behind the answer. Determine incident response
requirements will go over the options available and pros/cons of each option. By having answered those questions you will
select which option best suits your business needs.
Next steps
See also
Synchronization is all about providing users an identity in the cloud based on their on-premises identity. Whether
or not they will use synchronized account for authentication or federated authentication, the users will still need to
have an identity in the cloud. This identity will need to be maintained and updated periodically. The updates can
take many forms, from title changes to password changes.
Start by evaluating the organizations on-premises identity solution and user requirements. This evaluation is
important to define the technical requirements for how user identities will be created and maintained in the cloud.
For a majority of organizations, Active Directory is on-premises and will be the on-premises directory that users
will by synchronized from, however in some cases this will not be the case.
Make sure to answer the following questions:
Do you have one AD forest, multiple, or none?
How many Azure AD directories will you be synchronizing to?
1. Are you using filtering?
2. Do you have multiple Azure AD Connect servers planned?
Do you currently have a synchronization tool on-premises?
If yes, does your users if users have a virtual directory/integration of identities?
Do you have any other directory on-premises that you want to synchronize (e.g. LDAP Directory, HR
database, etc)?
Are you going to be doing any GALSync?
What is the current state of UPNs in your organization?
Do you have a different directory that users authenticate against?
Does your company use Microsoft Exchange?
Do they plan of having a hybrid exchange deployment?
Now that you have an idea about your synchronization requirements, you need to determine which tool is the
correct one to meet these requirements. Microsoft provides several tools to accomplish directory integration and
synchronization. See the Hybrid Identity directory integration tools comparison table for more information.
Now that you have your synchronization requirements and the tool that will accomplish this for your company,
you need to evaluate the applications that use these directory services. This evaluation is important to define the
technical requirements to integrate these applications to the cloud. Make sure to answer the following questions:
Will these applications be moved to the cloud and use the directory?
Are there special attributes that need to be synchronized to the cloud so these applications can use them
successfully?
Will these applications need to be re-written to take advantage of cloud auth?
Will these applications continue to live on-premises while users access them using the cloud identity?
You also need to determine the security requirements and constraints directory synchronization. This evaluation is
important to get a list of the requirements that will be needed in order to create and maintain user’s identities in
the cloud. Make sure to answer the following questions:
Where will the synchronization server be located?
Will it be domain joined?
Will the server be located on a restricted network behind a firewall, such as a DMZ?
Will you be able to open the required firewall ports to support synchronization?
Do you have a disaster recovery plan for the synchronization server?
Do you have an account with the correct permissions for all forests you want to synch with?
If your company doesn’t know the answer for this question, review the section “Permissions for
password synchronization” in the article Install the Azure Active Directory Sync Service and determine if
you already have an account with these permissions or if you need to create one.
If you have mutli-forest sync is the sync server able to get to each forest?
NOTE
Make sure to take notes of each answer and understand the rationale behind the answer. Determine incident response
requirements will go over the options available. By having answered those questions you will select which option best suits
your business needs.
Next steps
See also
for your hybrid identity solution
In this world of mobility, with users accessing data and applications in the cloud and from any device, securing this
information has become paramount. Every day there is a new headline about a security breach. Although, there is
no guarantee against such breaches, multi-factor authentication, provides an additional layer of security to help
prevent these breaches. Start by evaluating the organizations requirements for multi-factor authentication. That is,
what is the organization trying to secure. This evaluation is important to define the technical requirements for
setting up and enabling the organizations users for multi-factor authentication.
Make sure to answer the following:
Is your company trying to secure Microsoft apps?
How these apps are published?
Does your company provide remote access to allow employees to access on-premises apps?
If yes, what type of remote access?You also need to evaluate where the users who are accessing these applications
will be located. This evaluation is another important step to define the proper multi-factor authentication strategy.
Make sure to answer the following questions:
Where are the users going to be located?
Can they be located anywhere?
Does your company want to establish restrictions according to the user’s location?
Once you understand these requirements, it is important to also evaluate the user’s requirements for multi-factor
authentication. This evaluation is important because it will define the requirements for rolling out multi-factor
authentication. Make sure to answer the following questions:
Are the users familiar with multi-factor authentication?
Will some uses be required to provide additional authentication?
If yes, all the time, when coming from external networks, or accessing specific applications, or under
other conditions?
Will the users require training on how to setup and implement multi-factor authentication?
What are the key scenarios that your company wants to enable multi-factor authentication for their users?
After answering the previous questions, you will be able to understand if there are multi-factor authentication
already implemented on-premises. This evaluation is important to define the technical requirements for setting up
and enabling the organizations users for multi-factor authentication. Make sure to answer the following questions:
Does your company need to protect privileged accounts with MFA?
Does your company need to enable MFA for certain application for compliance reasons?
Does your company need to enable MFA for all eligible users of these application or only administrators?
Do you need have MFA always enabled or only when the users are logged outside of your corporate network?
Next steps
See also
Determine hybrid identity lifecycle adoption strategy
In this task, you’ll define the identity management strategy for your hybrid identity solution to meet the business
requirements that you defined in Determine hybrid identity management tasks.
To define the hybrid identity management tasks according to the end-to-end identity lifecycle presented earlier in
this step, you will have to consider the options available for each lifecycle phase.
Access management and provisioning

With a good account access management solution, your organization can track precisely who has access to what
information across the organization.
Access control is a critical function of a centralized, single-point provisioning system. Besides protecting sensitive
information, access controls expose existing accounts that have unapproved authorizations or are no longer
necessary. To control obsolete accounts, the provisioning system links together account information with
authoritative information about the users who own the accounts. Authoritative user identity information is typically
maintained in the databases and directories of human resources.
Accounts in sophisticated IT enterprises include hundreds of parameters that define the authorities, and these
details can be controlled by your provisioning system. New users can be identified with the data that you provide
from the authoritative source. The access request approval capability initiates the processes that approve (or reject)
resource provisioning for them.
L IF EC Y C L E M A N A GEM EN T
P H A SE O N P REM ISES C LO UD H Y B RID
L IF EC Y C L E M A N A GEM EN T
P H A SE O N P REM ISES C LO UD H Y B RID
Account Management and By using the Active You have to create an Extend Active Directory
Provisioning Directory® Domain account for every user who identities into the cloud
Services (AD DS) server role, will access a Microsoft cloud through synchronization and
you can create a scalable, service. You can also change federation
secure, and manageable user accounts or delete
infrastructure for user and them when they’re no
resource management, and longer needed. By default,
provide support for users do not have
directory-enabled administrator permissions,
applications such as but you can optionally
Microsoft® Exchange assign them.
Server.
Within Azure Active
You can provision groups in Directory, one of the major
AD DS through an Identity features is the ability to
manager manage access to resources.
You can provision users in These resources can be part
AD DS of the directory, as in the
case of permissions to
Administrators can use manage objects through
access control to manage roles in the directory, or
user access to shared resources that are external
resources for security to the directory, such as
purposes. In Active SaaS applications, Azure
Directory, access control is services, and SharePoint
administered at the object sites or on-premises
level by setting different resources.
levels of access, or
permissions, to objects, such At the center of Azure Active
as Full Control, Write, Read, Directory’s access
or No Access. Access control management solution is the
in Active Directory defines security group. The resource
how different users can use owner (or the administrator
Active Directory objects. By of the directory) can assign a
default, permissions on group to provide a certain
objects in Active Directory access right to the resources
are set to the most secure they own. The members of
setting. the group will be provided
the access, and the resource
owner can delegate the right
to manage the members list
of a group to someone else
– such as a department
manager or a helpdesk
administrator
The Managing groups in

Azure AD section, provides
more information on
managing access through
groups.
Role-based access control

Azure role-based access control (Azure RBAC) uses roles and provisioning policies to evaluate, test, and enforce
your business processes and rules for granting access to users. Key administrators create provisioning policies and
assign users to roles and that define sets of entitlements to resources for these roles. Azure RBAC extends the
identity management solution to use software-based processes and reduce user manual interaction in the
provisioning process. Azure RBAC enables the company to restrict the number of operations that an individual can
do once they have access to the Azure portal. By using Azure RBAC to control access to the portal, IT Admins ca
delegate access by using the following access management approaches:
Group-based role assignment : You can assign access to Azure AD groups that can be synced from your local
Active Directory. This enables you to leverage the existing investments that your organization has made in
tooling and processes for managing groups. You can also use the delegated group management feature of
Azure AD Premium.
Leverage built in roles in Azure : You can use three roles — Owner, Contributor, and Reader, to ensure that
users and groups have permission to do only the tasks they need to do their jobs.
Granular access to resources : You can assign roles to users and groups for a particular subscription,
resource group, or an individual Azure resource such as a website or database. In this way, you can ensure that
users have access to all the resources they need and no access to resources that they do not need to manage.
Provisioning and other customization options

Your team can use business plans and requirements to decide how much to customize the identity solution. For
example, a large enterprise might require a phased roll-out plan for workflows and custom adapters that is based
on a time line for incrementally provisioning applications that are widely used across geographies. Another
customization plan might provide for two or more applications to be provisioned across an entire organization,
after successful testing. User-application interaction can be customized, and procedures for provisioning resources
might be changed to accommodate automated provisioning.
You can deprovision to remove a service or component. For example, deprovisioning an account means that the
account is deleted from a resource.
The hybrid model of provisioning resources combines request and role-based approaches, which are both
supported by Azure AD. For a subset of employees or managed systems, a business might want to automate
access with role-based assignment. A business might also handle all other access requests or exceptions through a
request-based model. Some businesses might start with manual assignment, and evolve toward a hybrid model,
with an intention of a fully role-based deployment at a future time.
Other companies might find it impractical for business reasons to achieve complete role-based provisioning, and
target a hybrid approach as a wanted goal. Still other companies might be satisfied with only request-based
provisioning, and not want to invest additional effort to define and manage role-based, automated provisioning
policies.
License management
Group-based license management in Azure AD lets administrators assign users to a security group and Azure AD
automatically assigns licenses to all the members of the group. If a user is subsequently added to, or removed from
the group, a license will be automatically assigned or removed as appropriate.
You can use groups you synchronize from on-premises AD or manage in Azure AD. Pairing this up with Azure AD
premium Self-Service Group Management you can easily delegate license assignment to the appropriate decision
makers. You can be assured that problems like license conflicts and missing location data are automatically sorted
out.
Self-regulating user administration

When your organization starts to provision resources across all internal organizations, you implement the self-
regulating user administration capability. You can realize the advantages and benefits of provisioning users across
organizational boundaries. In this environment, a change in a user's status is automatically reflected in access
rights across organization boundaries and geographies. You can reduce provisioning costs and streamline the
access and approval processes. The implementation realizes the full potential of implementing role-based access
control for end-to-end access management in your organization. You can reduce administrative costs through
automated procedures for governing user provisioning. You can improve security by automating security policy
enforcement, and streamline and centralize user lifecycle management and resource provisioning for large user
populations.
NOTE
For more information, see Setting up Azure AD for self service application access management
License-based (Entitlement-based) Azure AD services work by activating a subscription in your Azure AD

directory/service tenant. Once the subscription is active the service capabilities can be managed by
directory/service administrators and used by licensed users.
Integration with other 3rd party providers

Azure Active Directory provides single-sign on and enhanced application access security to thousands of SaaS
applications and on-premises web applications. For more information, see Integrating applications with Azure
Active Directory
Define synchronization management

Integrating your on-premises directories with Azure AD makes your users more productive by providing a
common identity for accessing both cloud and on-premises resources. With this integration, users and
organizations can take advantage of the following:
Organizations can provide users with a common hybrid identity across on-premises or cloud-based services
leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
Administrators can provide Conditional Access based on application resource, device and user identity, network
location and multi-factor authentication.
Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps, and
third-party applications.
Developers can build applications that leverage the common identity model, integrating applications into Active
Directory on-premises or Azure for cloud-based applications
The following figure has an example of a high-level view of identity synchronization process.
Identity synchronization process

Review the following table to compare the synchronization options:
SY N C H RO N IZ AT IO N M A N A GEM EN T
O P T IO N A DVA N TA GES DISA DVA N TA GES
Sync-based (through DirSync or Users, and groups synchronized from

AADConnect) on-premises and cloud
Policy control: Account policies can be
set through Active Directory, which
gives the administrator the ability to
manage password policies, workstation,
restrictions, lock-out controls, and
more, without having to perform
additional tasks in the cloud.
Access control: Can restrict access to
the cloud service so that, the services
can be accessed through the corporate
environment, through online servers, or
both.
Reduced support calls: If users have
fewer passwords to remember, they are
less likely to forget them.
Security: User identities and information
are protected because all of the servers
and services used in single sign-on, are
mastered and controlled on-premises.
Support for strong authentication: You
can use strong authentication (also
called two-factor authentication) with
the cloud service. However, if you use
strong authentication, you must use
single sign-on.
Federation-based (through AD FS) Enabled by Security Token Service (STS). Requires specialized personnel for
When you configure an STS to provide deployment and maintenance of
single sign-on access with a Microsoft dedicated on premises AD FS servers.
cloud service, you will be creating a There are restrictions on the use of
federated trust between your on- strong authentication if you plan to use
premises STS and the federated domain AD FS for your STS. For more
you’ve specified in your Azure AD information, see Configuring Advanced
tenant. Options for AD FS 2.0.
Allows end users to use the same set of
credentials to obtain access to multiple
resources
end users do not have to maintain
multiple sets of credentials. Yet, the
users have to provide their credentials
to each one of the participating
resources.,B2B and B2C scenarios
supported.
NOTE
For more information see, Integrating your on-premises identities with Azure Active Directory.
See Also
Define data protection strategy for your hybrid
identity solution
In this task, you’ll define the data protection strategy for your hybrid identity solution to meet the business
requirements that you defined in:
Determine data protection requirements
Define data protection options

As explained in Determine directory synchronization requirements, Microsoft Azure AD can synchronize with your
on-premises Active Directory Domain Services (AD DS). This integration lets organizations use Azure AD to verify
users' credentials when they are trying to access corporate resources. You can do this for both scenarios: data at
rest on-premises and in the cloud. Access to data in Azure AD requires user authentication via a security token
service (STS).
Once authenticated, the user principal name (UPN) is read from the authentication token. Then, the authorization
system determines the replicated partition and container corresponding to the user’s domain. Information on the
user’s existence, enabled state, and role then helps the authorization system determine whether access to the
target tenant is authorized for the user in that session. Certain authorized actions (specifically, create user and
password reset) create an audit trail that a tenant administrator then uses to manage compliance efforts or
investigations.
Moving data from your on-premises datacenter into Azure Storage over an Internet connection may not always be
feasible due to data volume, bandwidth availability, or other considerations. The Azure Storage Import/Export
Service provides a hardware-based option for placing/retrieving large volumes of data in blob storage. It allows
you to send BitLocker-encrypted hard disk drives directly to an Azure datacenter where cloud operators upload the
contents to your storage account, or they can download your Azure data to your drives to return to you. Only
encrypted disks are accepted for this process (using a BitLocker key generated by the service itself during the job
setup). The BitLocker key is provided to Azure separately, thus providing out of band key sharing.
Since data in transit can take place in different scenarios, is also relevant to know that Microsoft Azure uses virtual
networking to isolate tenants’ traffic from one another, employing measures such as host- and guest-level
firewalls, IP packet filtering, port blocking, and HTTPS endpoints. However, most of Azure’s internal
communications, including infrastructure-to-infrastructure and infrastructure-to-customer (on-premises), are also
encrypted. Another important scenario is the communications within Azure datacenters; Microsoft manages
networks to assure that no VM can impersonate or eavesdrop on the IP address of another. TLS/SSL is used when
accessing Azure Storage or SQL Databases, or when connecting to Cloud Services. In this case, the customer
administrator is responsible for obtaining a TLS/SSL certificate and deploying it to their tenant infrastructure. Data
traffic moving between Virtual Machines in the same deployment or between tenants in a single deployment via
Microsoft Azure Virtual Network can be protected through encrypted communication protocols such as HTTPS,
SSL/TLS, or others.
Depending on how you answered the questions in Determine data protection requirements, you should be able to
determine how you want to protect your data and how the hybrid identity solution can assist you with that
process. The following table shows the options supported by Azure that are available for each data protection
scenario.
DATA P ROT EC T IO N
O P T IO N S AT REST IN T H E C LO UD AT REST O N - P REM ISES IN T RA N SIT
BitLocker Drive Encryption X X
SQL Server to encrypt X X

databases
VM-to-VM Encryption X
SSL/TLS X
VPN X
NOTE
Read Compliance by Feature at Microsoft Azure Trust Center to know more about the certifications that each Azure service
is compliant with. Since the options for data protection use a multilayer approach, comparison between those options are
not applicable for this task. Ensure that you are leveraging all options available for each state of the data.
Define content management options

One advantage of using Azure AD to manage a hybrid identity infrastructure is that the process is fully transparent
from the end user’s perspective. The user tries to access a shared resource, the resource requires authentication,
the user has to send an authentication request to Azure AD in order to obtain the token and access the resource.
This entire process happens in the background, without user interaction.
Organizations that are concern about data privacy usually require data classification for their solution. If their
current on-premises infrastructure is already using data classification, it is possible to use Azure AD as the main
repository for the user’s identity. A common tool that it is used on-premises for data classification is called Data
Classification Toolkit for Windows Server 2012 R2. This tool can help to identify, classify, and protect data on file
servers in your private cloud. It is also possible to use the Automatic File Classification in Windows Server 2012 to
accomplish this task.
If your organization doesn’t have data classification in place but needs to protect sensitive files without adding
new Servers on-premises, they can use Microsoft Azure Rights Management Service. Azure RMS uses encryption,
identity, and authorization policies to help secure your files and email, and it works across multiple devices—
phones, tablets, and PCs. Because Azure RMS is a cloud service, there’s no need to explicitly configure trusts with
other organizations before you can share protected content with them. If they already have an Office 365 or an
Azure AD directory, collaboration across organizations is automatically supported. You can also synchronize just
the directory attributes that Azure RMS needs to support a common identity for your on-premises Active
Directory accounts, by using Azure Active Directory Synchronization Services (AAD Sync) or Azure AD Connect.
A vital part of content management is to understand who is accessing which resource, therefore a rich logging
capability is important for the identity management solution. Azure AD provides log over 30 days including:
Changes in role membership (ex: user added to Global Admin role)
Credential updates (ex: password changes)
Domain management (ex: verifying a custom domain, removing a domain)
Adding or removing applications
User management (ex: adding, removing, updating a user)
Adding or removing licenses
NOTE
Read Microsoft Azure Security and Audit Log Management to know more about logging capabilities in Azure. Depending on
how you answered the questions in Determine content management requirements, you should be able to determine how
you want the content to be managed in your hybrid identity solution. While all options exposed in Table 6 are capable of
integrating with Azure AD, it is important to define which is more appropriate for your business needs.
C O N T EN T M A N A GEM EN T O P T IO N S A DVA N TA GES DISA DVA N TA GES
Centralized on-premises (Active Full control over the server Higher maintenance (keep up with
Directory Rights Management Server) infrastructure responsible for classifying updates, configuration and potential
the data upgrades), since IT owns the Server
Built-in capability in Windows Server, no Require a server infrastructure on-
need for extra license or subscription premises
Can be integrated with Azure AD in a Doesn’t leverage Azure capabilities
hybrid scenario natively
Supports information rights
management (IRM) capabilities in
Microsoft Online services such as
Exchange Online and SharePoint Online,
as well as Office 365
Supports on-premises Microsoft server
products, such as Exchange Server,
SharePoint Server, and file servers that
run Windows Server and File
Classification Infrastructure (FCI).
Centralized in the cloud (Azure RMS) Easier to manage compared to the on- Your organization must have a cloud
premises solution subscription that supports RMS
Can be integrated with AD DS in a Your organization must have an Azure
hybrid scenario AD directory to support user
Fully integrated with Azure AD authentication for RMS
Doesn’t require a server on-premises in
order to deploy the service
Supports on-premises Microsoft server
products such as Exchange Server,
SharePoint, Server, and file servers that
run Windows Server and File
Classification, Infrastructure (FCI)
IT, can have complete control over their
tenant’s key with BYOK capability.
Hybrid (Azure RMS integrated with, This scenario accumulates the Your organization must have a cloud
On-Premises Active Directory Rights advantages of both, centralized on- subscription that supports RMS
Management Server) premises and in the cloud. Your organization must have an Azure
AD directory to support user
authentication for RMS,
Requires a connection between Azure
cloud service and on-premises
infrastructure
Define access control options

By leveraging the authentication, authorization and access control capabilities available in Azure AD you can
enable your company to use a central identity repository while allowing users and partners to use single sign-on
(SSO) as shown in the following figure:
Centralized management and fully integration with other directories
Azure Active Directory provides single sign-on to thousands of SaaS applications and on-premises web
applications. See the Azure Active Directory federation compatibility list: third-party identity providers that can be
used to implement single sign-on article for more details about the SSO third-party that were tested by Microsoft.
This capability enables organization to implement a variety of B2B scenarios while keeping control of the identity
and access management. However, during the B2B designing process, is important to understand the
authentication method that is used by the partner and validate if this method is supported by Azure. Currently, the
following methods are supported by Azure AD:
Security Assertion Markup Language (SAML)
OAuth
Kerberos
Tokens
Certificates
NOTE
read Azure Active Directory Authentication Protocols to know more details about each protocol and its capabilities in Azure.
Using the Azure AD support, mobile business applications can use the same easy Mobile Services authentication
experience to allow employees to sign into their mobile applications with their corporate Active Directory
credentials. With this feature, Azure AD is supported as an identity provider in Mobile Services alongside the other
identity providers already supported (which include Microsoft Accounts, Facebook ID, Google ID, and Twitter ID). If
the on-premises apps use the user’s credential located at the company’s AD DS, the access from partners and
users coming from the cloud should be transparent. You can manage user’s Conditional Access control to (cloud-
based) web applications, web API, Microsoft cloud services, third-party SaaS applications, and native (mobile)
client applications, and have the benefits of security, auditing, reporting all in one place. However, it is
recommended to validate the implementation in a non-production environment or with a limited number of users.
TIP
it is important to mention that Azure AD does not have Group Policy as AD DS has. In order to enforce policy for devices,
you need a mobile device management solution such as Microsoft Intune.
Once the user is authenticated using Azure AD, it is important to evaluate the level of access that the user has. The
level of access that the user has over a resource can vary. While Azure AD can add an additional security layer by
controlling access to some resources, keep in mind that the resource itself can also have its own access control list
separately, such as the access control for files located in a File Server. The following figure summarizes the levels of
access control that you can have in a hybrid scenario:
Each interaction in the diagram showed in Figure X represents one access control scenario that can be covered by
Azure AD. Below you have a description of each scenario:
1. Conditional Access to applications that are hosted on-premises: You can use registered devices with access
policies for applications that are configured to use AD FS with Windows Server 2012 R2.
2. Access Control to the Azure portal: Azure also lets you control access to the portal by using Azure role-
based access control (Azure RBAC)). This method enables the company to restrict the number of operations
that an individual can do in the Azure portal. By using Azure RBAC to control access to the portal, IT Admins
can delegate access by using the following access management approaches:
Group-based role assignment: You can assign access to Azure AD groups that can be synced from your
local Active Directory. This lets you leverage the existing investments that your organization has made in
tooling and processes for managing groups. You can also use the delegated group management feature
of Azure AD Premium.
Use built-in roles in Azure: You can use three roles — Owner, Contributor, and Reader, to ensure that
users and groups have permission to do only the tasks they need to do their jobs.
Granular access to resources: You can assign roles to users and groups for a particular subscription,
resource group, or an individual Azure resource such as a website or database. In this way, you can
ensure that users have access to all the resources they need and no access to resources that they do not
need to manage.
NOTE
If you are building applications and want to customize the access control for them, it is also possible to use Azure AD
Application Roles for authorization. Review this WebApp-RoleClaims-DotNet example on how to build your app to
use this capability.
3. Conditional Access for Office 365 applications with Microsoft Intune: IT admins can provision Conditional
Access device policies to secure corporate resources, while at the same time allowing information workers
on compliant devices to access the services.
4. Conditional Access for Saas apps: This feature allows you to configure per-application multi-factor
authentication access rules and the ability to block access for users not on a trusted network. You can apply
the multi-factor authentication rules to all users that are assigned to the application, or only for users within
specified security groups. Users may be excluded from the multi-factor authentication requirement if they
are accessing the application from an IP address that in inside the organization’s network.
Since the options for access control use a multilayer approach, comparison between those options are not
applicable for this task. Ensure that you are leveraging all options available for each scenario that requires you to
control access to your resources.
Define incident response options

Azure AD can assist IT to identity potential security risks in the environment by monitoring user’s activity. IT can
use Azure AD Access and Usage reports to gain visibility into the integrity and security of your organization’s
directory. With this information, an IT admin can better determine where possible security risks may lie so that
they can adequately plan to mitigate those risks. Azure AD Premium subscription has a set of security reports that
can enable IT to obtain this information. Azure AD reports are categorized as follows:
Anomaly repor ts : Contain sign-in events that were found to be anomalous. The goal is to make you aware of
such activity and enable you to make a determination about whether an event is suspicious.
Integrated Application repor t : Provides insights into how cloud applications are being used in your
organization. Azure Active Directory offers integration with thousands of cloud applications.
Error repor ts : Indicate errors that may occur when provisioning accounts to external applications.
User-specific repor ts : Display device/sign in activity data for a specific user.
Activity logs : Contain a record of all audited events within the last 24 hours, last 7 days, or last 30 days, as
well as group activity changes, and password reset and registration activity.
TIP
Another report that can also help the Incident Response team working on a case is the user with leaked credentials report.
This report surfaces any matches between the leaked credentials list and your tenant.
Other important built-in reports in Azure AD that can be used during an incident response investigation and are:
Password reset activity : provide the admin with insights into how actively password reset is being used in
the organization.
Password reset registration activity : provides insights into which users have registered their methods for
password reset, and which methods they have selected.
Group activity : provides a history of changes to the group (ex: users added or removed) that were initiated in
the Access Panel.
In addition to the core reporting capability of Azure AD Premium that you can use during an Incident Response
investigation process, IT can also take advantage of the Audit Report to obtain information such as:
Changes in role membership (for example, user added to Global Admin role)
Credential updates (for example, password changes)
Domain management (for example, verifying a custom domain, removing a domain)
Adding or removing applications
User management (for example, adding, removing, updating a user)
Adding or removing licenses
Since the options for incident response use a multilayer approach, comparison between those options is not
applicable for this task. Ensure that you are leveraging all options available for each scenario that requires you to
use Azure AD reporting capability as part of your company’s incident response process.
Next steps
Determine hybrid identity management tasks
See Also
Plan for enhancing data security through a strong
identity solution
The first step in protecting data is to identify who can access that data. Also, you need to have an identity solution
that can integrate with your system to provide authentication and authorization capabilities. Authentication and
authorization are often confused with each other and their roles misunderstood. In reality, they are different, as
shown in the figure below:
Mobile device management lifecycle stages

When planning your hybrid identity solution, you must understand the data protection requirements for your
business and which options are available to best fulfil these requirements.
NOTE
Once you finish planning for data security, review Determine multi-factor authentication requirements to ensure that your
selections regarding multi-factor authentication requirements were not affected by the decisions you made in this section.

In the age of mobility, most companies have a common goal: enable their users to be productive on their mobile
devices, while on-premises, or remotely from anywhere in order to increase productivity. Companies that have
such requirements will also be concerned about the number of threats that must be mitigated in order to keep the
company’s data secure and maintain user’s privacy. Each company might have different requirements in this
regard; different compliance rules that will vary according to which industry the company is acting will lead to
different design decisions.
However, there are some security aspects that should be explored and validated, regardless of the industry.
Data protection paths

Data protection paths
In the above diagram, the identity component will be the first one to be verified before data is accessed. However,
this data can be in different states during the time it was accessed. Each number on this diagram represents a path
in which data can be located at some point in time. These numbers are explained below:
1. Data protection at the device level.
2. Data protection while in transit.
3. Data protection while at rest on-premises.
4. Data protection while at rest in the cloud.
It is necessary that the hybrid identity solution is capable of leveraging both on-premises and cloud identity
management resources to identify the user before it grants access to the data. When planning your hybrid identity
solution, ensure that the following questions are answered according to your organization’s requirements:
Data protection at rest

Regardless of where the data is at rest (device, cloud or on-premises), it is important to perform an assessment to
understand the organization needs in this regard. For this area, ensure that the following questions are asked:
Does your company need to protect data at rest?
If yes, is the hybrid identity solution able to integrate with your current on-premises infrastructure?
If yes, is the hybrid identity solution able to integrate with your workloads located in the cloud?
Is the cloud identity management able to protect the user’s credentials and other data stored in the cloud?
Data protection in transit

Data in transit between the device and the datacenter or between the device and the cloud must be protected.
However, being in-transit does not necessarily mean a communications process with a component outside of your
cloud service; it moves internally, also, such as between two virtual networks. For this area, ensure that the
following questions are asked:
Does your company need to protect data in transit?
If yes, is the hybrid identity solution able to integrate with secure controls such as SSL/TLS?
Does the cloud identity management keep the traffic to and within the directory store (within and between
datacenters) signed?
Compliance
Regulations, laws, and regulatory compliance requirements will vary according to the industry that your company
belongs. Companies in high regulated industries must address identity-management concerns related to
compliance issues. Regulations such as Sarbanes-Oxley (SOX), the Health Insurance Portability and Accountability
Act (HIPAA), the Gramm-Leach-Bliley Act (GLBA) and the Payment Card Industry Data Security Standard (PCI DSS)
are strict regarding identity and access. The hybrid identity solution that your company will adopt must have the
core capabilities that will fulfill the requirements of one or more of these regulations. For this area, ensure that the
following questions are asked:
Is the hybrid identity solution compliant with the regulatory requirements for your business?
Does the hybrid identity solution has built
in capabilities that will enable your company to be compliant regulatory requirements?
NOTE
Make sure to take notes of each answer and understand the rationale behind the answer. Define Data Protection Strategy
will go over the options available and advantages/disadvantages of each option. By having answered those questions you
will select which option best suits your business needs.
Next steps
See Also
Determine content management requirements for
your hybrid identity solution
Understanding the content management requirements for your business may direct affect your decision on which
hybrid identity solution to use. With the proliferation of multiple devices and the capability of users to bring their
own devices (BYOD), the company must protect its own data but it also must keep user’s privacy intact. Usually
when a user has their own device, they might also have multiple credentials that will be alternating according to
the application that they use. It is important to differentiate what content was created using personal credentials
versus the ones created using corporate credentials. Your identity solution should be able to interact with cloud
services to provide a seamless experience to the end user while ensure their privacy and increase the protection
against data leakage.
Your identity solution will be leveraged by different technical controls in order to provide content management as
shown in the figure below:
Security controls that will be leveraging your identity management system

In general, content management requirements will leverage your identity management system in the following
areas:
Privacy: identifying the user that owns a resource and applying the appropriate controls to maintain integrity.
Data Classification: identify the user or group and level of access to an object according to its classification.
Data Leakage Protection: security controls responsible for protecting data to avoid leakage will need to interact
with the identity system to validate the user’s identity. This is also important for auditing trail purpose.
NOTE
Read data classification for cloud readiness for more information about best practices and guidelines for data classification.
When planning your hybrid identity solution ensure that the following questions are answered according to your
organization’s requirements:
Does your company have security controls in place to enforce data privacy?
If yes, will the security controls be able to integrate with the hybrid identity solution that you are going
to adopt?
Does your company use data classification?
If yes, is the current solution able to integrate with the hybrid identity solution that you are going to
adopt?
Does your company currently have any solution for data leakage?
If yes, is the current solution able to integrate with the hybrid identity solution that you are going to
adopt?
Does your company need to audit access to resources?
If yes, what type of resources?
If yes, what level of information is necessary?
If yes, where the audit log must reside? On-premises or in the cloud?
Does your company need to encrypt any emails that contain sensitive data (SSNs, credit card numbers, etc.)?
Does your company need to encrypt all documents/contents shared with external business partners?
Does your company need to enforce corporate policies on certain kinds of emails (do no reply all, do not
forward)?
NOTE
Next steps
See Also
Determine access control requirements for your
hybrid identity solution
When an organization is designing their hybrid identity solution, they can also use this opportunity to review
access requirements for the resources that they are planning to make it available for users. The data access cross
all four pillars of identity, which are:
Administration
Authentication
Authorization
Auditing
The sections that follow will cover authentication and authorization in more details, administration, and auditing
are part of the hybrid identity lifecycle. Read Determine hybrid identity management tasks for more information
about these capabilities.
NOTE
Read The Four Pillars of Identity - Identity Management in the Age of Hybrid IT for more information about each one of
those pillars.
Authentication and authorization

There are different scenarios for authentication and authorization, these scenarios will have specific requirements
that must be fulfilled by the hybrid identity solution that the company is going to adopt. Scenarios involving
Business to Business (B2B) communication can add an extra challenge for IT Admins since they will need to ensure
that the authentication and authorization method used by the organization can communicate with their business
partners. During the designing process for authentication and authorization requirements, ensure that the
following questions are answered:
Will your organization authenticate and authorize only users located at their identity management system?
Are there any plans for B2B scenarios?
If yes, do you already know which protocols (SAML, OAuth, Kerberos, or Certificates) will be used to
connect both businesses?
Does the hybrid identity solution that you are going to adopt support those protocols?
Another important point to consider is where the authentication repository that will be used by users and partners
will be located and the administrative model to be used. Consider the following two core options:
Centralized: in this model, the user’s credentials, policies and administration can be centralized on-premises or
in the cloud.
Hybrid: in this model, the user’s credentials, policies and administration will be centralized on-premises and a
replicated in the cloud.
Which model your organization will adopt will vary according to their business requirements, you want to answer
the following questions to identify where the identity management system will reside and the administrative mode
to use:
Does your organization currently have an identity management on-premises?
If yes, do they plan to keep it?
Are there any regulation or compliance requirements that your organization must follow that dictates
where the identity management system should reside?
Does your organization use single sign-on for apps located on-premises or in the cloud?
If yes, does the adoption of a hybrid identity model affect this process?
Access Control
While authentication and authorization are core elements to enable access to corporate data through user’s
validation, it is also important to control the level of access that these users will have and the level of access
administrators will have over the resources that they are managing. Your hybrid identity solution must be able to
provide granular access to resources, delegation, and role base access control. Ensure that the following question
is answered regarding access control:
Does your company have more than one user with elevated privilege to manage your identity system?
If yes, does each user need the same access level?
Would your company need to delegate access to users to manage specific resources?
If yes, how frequently this happens?
Would your company need to integrate access control capabilities between on-premises and cloud resources?
Would your company need to limit access to resources according to some conditions?
Would your company have any application that needs custom control access to some resources?
If yes, where are those apps located (on-premises or in the cloud)?
If yes, where are those target resources located (on-premises or in the cloud)?
NOTE
will go over the options available and advantages/disadvantages of each option. By answering those questions you will
select which option best suits your business needs.
Next steps
See Also
Determine incident response requirements for your
hybrid identity solution
Large or medium organizations most likely will have a security incident response in place to help IT take actions
accordingly to the level of incident. The identity management system is an important component in the incident
response process because it can be used to help identifying who performed a specific action against the target.
The hybrid identity solution must be able to provide monitoring and reporting capabilities that can be leveraged
by IT to take actions to identify and mitigate a potential threat. In a typical incident response plan you will have the
following phases as part of the plan:
1. Initial assessment.
2. Incident communication.
3. Damage control and risk reduction.
4. Identification of what it was compromise and severity.
5. Evidence preservation.
6. Notification to appropriate parties.
7. System recovery.
8. Documentation.
9. Damage and cost assessment.
10. Process and plan revision.
During the identification of what it was compromise and severity- phase, it will be necessary to identify the
systems that have been compromised, files that have been accessed and determine the sensitivity of those files.
Your hybrid identity system should be able to fulfill these requirements to assist you identifying the user that
made those changes.
Monitoring and reporting

Many times the identity system can also help in initial assessment phase mainly if the system has built in auditing
and reporting capabilities. During the initial assessment, IT Admin must be able to identify a suspicious activity, or
the system should be able to trigger it automatically based on a pre-configured task. Many activities could
indicate a possible attack, however in other cases, a badly configured system might lead to a number of false
positives in an intrusion detection system.
The identity management system should assist IT admins to identify and report those suspicious activities. Usually
these technical requirements can be fulfilled by monitoring all systems and having a reporting capability that can
highlight potential threats. Use the questions below to help you design your hybrid identity solution while taking
into consideration incident response requirements:
Does your company has a security incident response in place?
If yes, is the current identity management system used as part of the process?
Does your company need to identify suspicious sign-on attempts from users across different devices?
Does your company need to detect potential compromised user’s credentials?
Does your company need to audit user’s access and action?
Does your company need to know when a user resets their password?
Policy enforcement
During damage control and risk reduction-phase, it is important to quickly reduce the actual and potential effects
of an attack. That action that you will take at this point can make the difference between a minor and a major one.
The exact response will depend on your organization and the nature of the attack that you face. If the initial
assessment concluded that an account was compromised, you will need to enforce policy to block this account.
That’s just one example where the identity management system will be leveraged. Use the questions below to help
you design your hybrid identity solution while taking into consideration how policies will be enforced to react to
an ongoing incident:
Does your company have policies in place to block users from access the network if necessary?
If yes, does the current solution integrate with the hybrid identity management system that you are
going to adopt?
Does your company need to enforce Conditional Access for users that are in quarantine?
NOTE
Make sure to take notes of each answer and understand the rationale behind the answer. Define data protection strategy
Next steps
Define data protection strategy
See Also
Plan for Hybrid Identity Lifecycle
Identity is one of the foundations of your enterprise mobility and application access strategy. Whether you are
signing on to your mobile device or SaaS app, your identity is the key to gaining access to everything. At its
highest level, an identity management solution encompasses unifying and syncing between your identity
repositories, which includes automating and centralizing the process of provisioning resources. The identity
solution should be a centralized identity across on-premises and cloud and also use some form of identity
federation to maintain centralized authentication and securely share and collaborate with external users and
businesses. Resources range from operating systems and applications to people in, or affiliated with, an
organization. Organizational structure can be altered to accommodate the provisioning policies and procedures.
It is also important to have an identity solution geared to empower your users by providing them with self-service
experiences to keep them productive. Your identity solution is more robust if it enables single sign-on for users
across all the resources they need access. Administrators at all levels can use standardized procedures for
managing user credentials. Some levels of administration can be reduced or eliminated, depending on the breadth
of the provisioning management solution. Furthermore, you can securely distribute administration capabilities,
manually or automatically, among various organizations. For example, a domain administrator can serve only the
people and resources in that domain. This user can do administrative and provisioning tasks, but is not authorized
to do configuration tasks, such as creating workflows.
Determine Hybrid Identity Management Tasks

Distributing administrative tasks in your organization improves the accuracy and effectiveness of administration
and improves the balance of the workload of an organization. Following are the pivots that define a robust
identity management system.
To define hybrid identity management tasks, you must understand some essential characteristics of the
organization that will be adopting hybrid identity. It is important to understand the current repositories being
used for identity sources. By knowing those core elements, you will have the foundational requirements and
based on that you will need to ask more granular questions that will lead you to a better design decision for your
Identity solution.
While defining those requirements, ensure that at least the following questions are answered
Provisioning options:
Does the hybrid identity solution support a robust account access management and provisioning
system?
How are users, groups, and passwords going to be managed?
Is the identity lifecycle management responsive?
How long does password updates account suspension take?
License management:
Does the hybrid identity solution handles license management?
If yes, what capabilities are available?
Does the solution handle group-based license management?
If yes, is it possible to assign a security group to it?
If yes, will the cloud directory automatically assign licenses to all the members of the group?
What happens if a user is subsequently added to, or removed from the group, will a license be
automatically assigned or removed as appropriate?
Integration with other third-party identity providers:
Can this hybrid solution be integrated with third-party identity providers to implement single sign-on?
Is it possible to unify all the different identity providers into a cohesive identity system?
If yes, how and which are they and what capabilities are available?
Synchronization Management
One of the goals of an identity manager, to be able to bring all the identity providers and keep them synchronized.
You keep the data synchronized based on an authoritative master identity provider. In a hybrid identity scenario,
with a synchronized management model, you manage all user and device identities in an on-premises server and
synchronize the accounts and, optionally, passwords to the cloud. The user enters the same password on-premises
as they do in the cloud, and at sign-in, the password is verified by the identity solution. This model uses a
directory synchronization tool.
To proper design the

synchronization of your hybrid identity solution ensure that the following questions are answered:
What are the sync solutions available for the hybrid identity solution?
What are the single sign on capabilities available?
What are the options for identity federation between B2B and B2C?
Next steps
Determine hybrid identity management adoption strategy
See Also
In this task, you define the hybrid identity adoption strategy for your hybrid identity solution to meet the business
requirements that were discussed in:
Determine business needs
Define business needs strategy

The first task addresses determining the organizations business needs. This can be very broad and scope creep can
occur if you are not careful. In the beginning, keep it simple but always remember to plan for a design that will
accommodate and facilitate change in the future. Regardless of whether it is a simple design or an extremely
complex one, Azure Active Directory is the Microsoft Identity platform that supports Office 365, Microsoft Online
Services, and cloud aware applications.
Define an integration strategy

Microsoft has three main integration scenarios which are cloud identities, synchronized identities, and federated
identities. You should plan on adopting one of these integration strategies. The strategy you choose can vary and
the decisions in choosing one may include, what type of user experience you want to provide, do you have an
existing infrastructure, and what is the most cost effective.
The scenarios defined in the above figure are:

Cloud identities : these are identities that exist solely in the cloud. In the case of Azure AD, they would reside
specifically in your Azure AD directory.
Synchronized : these are identities that exist on-premises and in the cloud. Using Azure AD Connect, these
users are either created or joined with existing Azure AD accounts. The user’s password hash is synchronized
from the on-premises environment to the cloud in what is called a password hash. When using synchronized
the one caveat is that if a user is disabled in the on-premises environment, it can take up to three hours for that
account status to show up in Azure AD. This is due to the synchronization time interval.
Federated : these identities exist both on-premises and in the cloud. Using Azure AD Connect, these users are
either created or joined with existing Azure AD accounts.
NOTE
For more information about the Synchronization options, read Integrating your on-premises identities with Azure Active
Directory.
The following table helps in determining the advantages and disadvantages of each of the following strategies:
ST RAT EGY A DVA N TA GES DISA DVA N TA GES
Cloud identities Easier to manage for small organization. Users will need to sign in when
Nothing to install on-premises. No accessing workloads in the cloud
additional hardware needed Passwords may or may not be the same
Easily disabled if the user leaves the for cloud and on-premises identities
company
Synchronized On-premises password authenticates Some customers may be reluctant to

both on-premises and cloud directories synchronize their directories with the
Easier to manage for small, medium, or cloud due specific company’s police
large organizations
Users can have single sign-on (SSO) for
some resources
Microsoft preferred method for
synchronization
Easier to manage
Federated Users can have single sign-on (SSO) More steps to set up and configure
If a user is terminated or leaves, the Higher maintenance
account can be immediately disabled May require additional hardware for the
and access revoked, STS infrastructure
Supports advanced scenarios that May require additional hardware to
cannot be accomplished with install the federation server. Additional
synchronized software is required if AD FS is used
Require extensive setup for SSO
Critical point of failure if the federation
server is down, users won’t be able to
authenticate
Client experience
The strategy that you use will dictate the user sign-in experience. The following tables provide you with
information on what the users should expect their sign-in experience to be. Not all federated identity providers
support SSO in all scenarios.
Doman-joined and private network applications :
A P P L IC AT IO N SY N C H RO N IZ ED IDEN T IT Y F EDERAT ED IDEN T IT Y
Web Browsers Forms-based authentication single sign-on, sometimes required to

supply organization ID
Outlook Prompt for credentials Prompt for credentials
Skype for Business (Lync) Prompt for credentials single sign-on for Lync, prompted
credentials for Exchange
OneDrive for Business Prompt for credentials single sign-on

Office Pro Plus Subscription Prompt for credentials single sign-on
External or untrusted sources :
Web Browsers Forms-based authentication Forms-based authentication
Outlook, Skype for Business (Lync), Prompt for credentials Prompt for credentials
OneDrive for Business, Office
subscription
Exchange ActiveSync Prompt for credentials single sign-on for Lync, prompted
credentials for Exchange
Mobile apps Prompt for credentials Prompt for credentials
If you have determined from task 1 that you have a third-party IdP or are going to use one to provide federation
with Azure AD, you need to be aware of the following supported capabilities:
Any SAML 2.0 provider that is compliant for the SP-Lite profile can support authentication to Azure AD and
associated applications
Supports passive authentication, which facilitates authentication to OWA, SPO, etc.
Exchange Online clients can be supported via the SAML 2.0 Enhanced Client Profile (ECP)
You must also be aware of what capabilities will not be available:
Without WS-Trust/Federation support, all other active clients break
That means no Lync client, OneDrive client, Office Subscription, Office Mobile prior to Office 2016
Transition of Office to passive authentication allows them to support pure SAML 2.0 IdPs, but support will still
be on a client-by-client basis
NOTE
For the most updated list read the article Azure AD federation compatibility list.
Define synchronization strategy

In this task you will define the tools that will be used to synchronize the organization’s on-premises data to the
cloud and what topology you should use. Because, most organizations use Active Directory, information on using
Azure AD Connect to address the questions above is provided in some detail. For environments that do not have
Active Directory, there is information about using FIM 2010 R2 or MIM 2016 to help plan this strategy. However,
future releases of Azure AD Connect will support LDAP directories, so depending on your timeline, this information
may be able to assist.
Synchronization tools
Over the years, several synchronization tools have existed and used for various scenarios. Currently Azure AD
Connect is the go to tool of choice for all supported scenarios. AAD Sync and DirSync are also still around and may
even be present in your environment now.
NOTE
For the latest information regarding the supported capabilities of each tool, read Directory integration tools comparison
article.
Supported topologies
When defining a synchronization strategy, the topology that is used must be determined. Depending on the
information that was determined in step 2 you can determine which topology is the proper one to use. The single
forest, single Azure AD topology is the most common and consists of a single Active Directory forest and a single
instance of Azure AD. This is going to be used in a majority of the scenarios and is the expected topology when
using Azure AD Connect Express installation as shown in the figure below.
Single
Forest Scenario It is common for large and even small organizations to have multiple forests, as shown in Figure 5.
NOTE
For more information about the different on-premises and Azure AD topologies with Azure AD Connect sync read the article
Topologies for Azure AD Connect.
Multi-Forest Scenario
If this is the case, then the multi-forest single Azure AD topology should be considered if the following items are
true:
Users have only 1 identity across all forests – the uniquely identifying users section below describes this in
more detail.
The user authenticates to the forest in which their identity is located
UPN and Source Anchor (immutable id) will come from this forest
All forests are accessible by Azure AD Connect – this means it does not need to be domain joined and can be
placed in a DMZ if this facilitates this.
Users have only one mailbox
The forest that hosts a user’s mailbox has the best data quality for attributes visible in the Exchange Global
Address List (GAL)
If there is no mailbox on the user, then any forest may be used to contribute these values
If you have a linked mailbox, then there is also another account in a different forest used to sign in.
NOTE
Objects that exist in both on-premises and in the cloud are “connected” via a unique identifier. In the context of Directory
Synchronization, this unique identifier is referred to as the SourceAnchor. In the context of Single Sign-On, this is referred to
as the ImmutableId. Design concepts for Azure AD Connect for more considerations regarding the use of SourceAnchor.
If the above are not true and you have more than one active account or more than one mailbox, Azure AD Connect
will pick one and ignore the other. If you have linked mailboxes but no other account, these accounts will not be
exported to Azure AD and that user will not be a member of any groups. This is different from how it was in the
past with DirSync and is intentional to better support these multi-forest scenarios. A multi-forest scenario is shown
in the figure below.
Multi-forest multiple Azure AD scenario

It is recommended to have just a single directory in Azure AD for an organization but it is supported it a 1:1
relationship is kept between an Azure AD Connect sync server and an Azure AD directory. For each instance of
Azure AD, you need an installation of Azure AD Connect. Also, Azure AD, by design is isolated and users in one
instance of Azure AD will not be able to see users in another instance.
It is possible and supported to connect one on-premises instance of Active Directory to multiple Azure AD
directories as shown in the figure below:
Single-forest filtering scenario
To do this, the following must be true:
Azure AD Connect sync servers must be configured for filtering so they each have a mutually exclusive set of
objects. This done, for example, by scoping each server to a particular domain or OU.
A DNS domain can only be registered in a single Azure AD directory so the UPNs of the users in the on-
premises AD must use separate namespaces
Users in one instance of Azure AD will only be able to see users from their instance. They will not be able to see
users in the other instances
Only one of the Azure AD directories can enable Exchange hybrid with the on-premises AD
Mutual exclusivity also applies to write-back. This makes some write-back features not supported with this
topology since these assume a single on-premises configuration. This includes:
Group write-back with default configuration
Device write-back
The following is not supported and should not be chosen as an implementation:
It is not supported to have multiple Azure AD Connect sync servers connecting to the same Azure AD directory
even if they are configured to synchronize mutually exclusive set of object
It is unsupported to sync the same user to multiple Azure AD directories.
It is also unsupported to make a configuration change to make users in one Azure AD to appear as contacts in
another Azure AD directory.
It is also unsupported to modify Azure AD Connect sync to connect to multiple Azure AD directories.
Azure AD directories are by design isolated. It is unsupported to change the configuration of Azure AD Connect
sync to read data from another Azure AD directory in an attempt to build a common and unified GAL between
the directories. It is also unsupported to export users as contacts to another on-premises AD using Azure AD
Connect sync.
NOTE
If your organization restricts computers on your network from connecting to the Internet, this article lists the endpoints
(FQDNs, IPv4, and IPv6 address ranges) that you should include in your outbound allow lists and Internet Explorer Trusted
Sites Zone of client computers to ensure your computers can successfully use Office 365. For more information read Office
365 URLs and IP address ranges.
Define multi-factor authentication strategy

In this task you will define the multi-factor authentication strategy to use. Azure Multi-Factor Authentication comes
in two different versions. One is a cloud-based and the other is on-premises based using the Azure MFA Server.
Based on the evaluation you did above you can determine which solution is the correct one for your strategy. Use
the table below to determine which design option best fulfills your company’s security requirement:
Multi-factor design options:
A SSET TO SEC URE M FA IN T H E C LO UD M FA O N - P REM ISES
Microsoft apps yes yes
SaaS apps in the app gallery yes yes
IIS applications published through yes yes

Azure AD App Proxy
IIS applications not published through no yes

the Azure AD App Proxy
Remote access as VPN, RDG no yes
Even though you may have settled on a solution for your strategy, you still need to use the evaluation from above
on where your users are located. This may cause the solution to change. Use the table below to assist you
determining this:
USER LO C AT IO N P REF ERRED DESIGN O P T IO N
Azure Active Directory Multi-FactorAuthentication in the cloud
Azure AD and on-premises AD using federation with AD FS Both
Azure AD and on-premises AD using Azure AD Connect no Both

password sync
Azure AD and on-premises using Azure AD Connect with Both

password sync
On-premises AD Multi-Factor Authentication Server
NOTE
You should also ensure that the multi-factor authentication design option that you selected supports the features that are
required for your design. For more information read Choose the multi-factor security solution for you.
Multi-Factor Auth Provider
Multi-factor authentication is available by default for global administrators who have an Azure Active Directory
tenant. However, if you wish to extend multi-factor authentication to all of your users and/or want to your global
administrators to be able to take advantage features such as the management portal, custom greetings, and
reports, then you must purchase and configure Multi-Factor Authentication Provider.
NOTE
You should also ensure that the multi-factor authentication design option that you selected supports the features that are
required for your design.
Next steps
See also
Azure Active Directory hybrid identity design
considerations- next steps
Now that you’ve completed defining your requirements and examining all the options for your mobile device
management solution, you’re ready to take the next steps for deploying the supporting infrastructure that’s right
for you and your organization.
Hybrid identity documentation

Conceptual and procedural planning, deployment, and administration content are useful when implementing your
mobile device management solution:
Microsoft System Center solutions can help you capture and aggregate knowledge about your infrastructure,
policies, processes, and best practices so that your IT staff can build manageable systems and automate
operations.
Microsoft Intune is a cloud-based device management service that helps you to manage your computers and
mobile devices and to secure your company’s information.
MDM for Office 365 allows you to manage and secure mobile devices when they're connected to your Office
365 organization. You can use MDM for Office 365 to set device security policies and access rules, and to wipe
mobile devices if they’re lost or stolen.
Hybrid identity resources

Monitoring the following resources often provides the latest news and updates on mobile device management
solutions:
Microsoft Enterprise Mobility blog
Microsoft In The Cloud blog
Microsoft Intune blog
Microsoft Endpoint Configuration Manager blog
See also
Hybrid Identity directory integration tools
comparison
Over the years the directory integration tools have grown and evolved.
FIM and MIM are still supported and primarily enable synchronization between on-premises systems. The FIM
Windows Azure AD Connector is supported in both FIM and MIM, but not recommended for new deployments
- customers with on-premises sources such as Notes or SAP HCM should use MIM to populate Active Directory
Domain Services (AD DS) and then also use either Azure AD Connect sync or Azure AD Connect cloud
provisioning to synchronize from AD DS to Azure AD.
Azure AD Connect sync incorporates the components and functionality previously released in DirSync and
Azure AD Sync, for synchronizing between AD DS forests and Azure AD.
Azure AD Connect cloud provisioning is a new Microsoft agent for synching from AD DS to Azure AD, useful for
scenarios such as merger and acquisition where the acquired company's AD forests are isolated from the
parent company's AD forests.
To learn more about the differences between Azure AD Connect sync and Azure AD Connect cloud provisioning,
see the article What is Azure AD Connect cloud provisioning?
Next steps
Azure AD Connect: Enabling device writeback
NOTE
A subscription to Azure AD Premium is required for device writeback.
The following documentation provides information on how to enable the device writeback feature in Azure AD
Connect. Device Writeback is used in the following scenarios:
Enable Windows Hello for Business using hybrid certificate trust deployment
Enable Conditional Access based on devices to ADFS (2012 R2 or higher) protected applications (relying party
trusts).
This provides additional security and assurance that access to applications is granted only to trusted devices. For
more information on Conditional Access, see Managing Risk with Conditional Access and Setting up On-
premises Conditional Access using Azure Active Directory Device Registration.
IMPORTANT
Devices must be located in the same forest as the users. Since devices must be written back to a single forest, this feature
does not currently support a deployment with multiple user forests.
Only one device registration configuration object can be added to the on-premises Active Directory forest. This feature is not
compatible with a topology where the on-premises Active Directory is synchronized to multiple Azure AD directories.
Part 1: Install Azure AD Connect

Install Azure AD Connect using Custom or Express settings. Microsoft recommends to start with all users and
groups successfully synchronized before you enable device writeback.
Part 2: Enable device writeback in Azure AD Connect

1. Run the installation wizard again. Select Configure device options from the Additional Tasks page and
click Next .
NOTE
The new Configure device options is available only in version 1.1.819.0 and newer.
2. On the device options page, select Configure device writeback . Option to Disable device writeback
will not be available until device writeback is enabled. Click on Next to move to the next page in the
wizard.
3. On the writeback page, you will see the supplied domain as the default Device writeback forest.
4. Device container page provides option of preparing the active directory by using one of the two
available options:
a. Provide enterprise administrator credentials : If the enterprise administrator credentials are
provided for the forest where devices need to be written back, Azure AD Connect will prepare the forest
automatically during the configuration of device writeback.
b. Download PowerShell script : Azure AD Connect auto-generates a PowerShell script that can prepare
the active directory for device writeback. In case the enterprise administrator credentials cannot be
provided in Azure AD Connect, it is suggested to download the PowerShell script. Provide the downloaded
PowerShell script CreateDeviceContainer.ps1 to the enterprise administrator of the forest where
devices will be written back to.
The following operations are performed for preparing the active directory forest:
If they do not exist already, creates and configures new containers and objects under CN=Device
Registration Configuration,CN=Services,CN=Configuration,[forest-dn].
If they do not exist already, creates and configures new containers and objects under
CN=RegisteredDevices,[domain-dn]. Device objects will be created in this container.
Sets necessary permissions on the Azure AD Connector account, to manage devices on your Active
Directory.
Only needs to run on one forest, even if Azure AD Connect is being installed on multiple forests.
Verify Devices are synchronized to Active Directory

Device writeback should now be working properly. Be aware that it can take up to 3 hours for device objects to be
written-back to AD. To verify that your devices are being synced properly, do the following after the sync rules
complete:
1. Launch Active Directory Administrative Center.
2. Expand RegisteredDevices, within the Domain that is being federated.
3. Current registered devices will be listed there.
Enable Conditional Access

Detailed instructions to enable this scenario are available within Setting up On-premises Conditional Access
using Azure Active Directory Device Registration.
Troubleshooting
The writeback checkbox is still disabled
If the checkbox for device writeback is not enabled even though you have followed the steps above, the following
steps will guide you through what the installation wizard is verifying before the box is enabled.
First things first:
The forest where the devices are present must have the forest schema upgraded to Windows 2012 R2 level so
that the device object and associated attributes are present .
If the installation wizard is already running, then any changes will not be detected. In this case, complete the
installation wizard and run it again.
Make sure the account you provide in the initialization script is actually the correct user used by the Active
Directory Connector. To verify this, follow these steps:
From the start menu, open Synchronization Ser vice .
Open the Connectors tab.
Find the Connector with type Active Directory Domain Services and select it.
Under Actions , select Proper ties .
Go to Connect to Active Director y Forest . Verify that the domain and user name specified on this
screen match the account provided to the script.
Verify configuration in Active Directory:

Verify that the Device Registration Service is located in the location below
(CN=DeviceRegistrationService,CN=Device Registration Services,CN=Device Registration
Configuration,CN=Services,CN=Configuration) under configuration naming context.
Verify there is only one configuration object by searching the configuration namespace. If there is more than
one, delete the duplicate.
On the Device Registration Service object, make sure the attribute msDS-DeviceLocation is present and has a
value. Lookup this location and make sure it is present with the objectType msDS-DeviceContainer.
Verify the account used by the Active Directory Connector has required permissions on the Registered Devices
container found by the previous step. This is the expected permissions on this container:
Verify the Active Directory account has permissions on the CN=Device Registration
Configuration,CN=Services,CN=Configuration object.
Additional Information
Managing Risk With Conditional Access
Setting up On-premises Conditional Access using Azure Active Directory Device Registration
Next steps
Azure AD Connect group writeback
Groups writeback enables customers to leverage cloud groups for their hybrid needs. 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.
Pre-requisites
The following pre-requisites must be met in order to enable group writeback.
Azure Active Directory Premium licenses for your tenant.
A configured hybrid deployment between your Exchange on-premises organization and Office 365 and verified
it's functioning correctly.
Installed a supported version of Exchange on-premises
Configured single sign-on using Azure Active Directory Connect
Enable group writeback

To enable group writeback, use the following steps:
1. Open the Azure AD Connect wizard, select Configure and then click Next .
2. Select Customize synchronization options and then click Next .
3. On the Connect to Azure AD page, enter your credentials. Click Next .
4. On the Optional features page, verify that the options you previously configured are still selected.
5. Select Group writeback and then click Next .
6. On the Writeback page , select an Active Directory organizational unit (OU) to store objects that are
synchronized from Office 365 to your on-premises organization, and then click Next .
7. On the Ready to configure page, click Configure .
8. When the wizard is complete, click Exit on the Configuration complete page.
9. Open the Windows PowerShell as an Administrator on the Azure Active Directory Connect server, and run the
following commands.
$AzureADConnectSWritebackAccountDN = <MSOL_ account DN>

Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"
Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountDN $AzureADConnectSWritebackAccountDN
For additional information on configuring the Office 365 groups see Configure Microsoft 365 Groups with on-
premises Exchange hybrid.
Disabling group writeback

To disable Group Writeback, use the following steps:
1. Launch the Azure Active Directory Connect wizard and navigate to the Additional Tasks page. Select the
Customize synchronization options task and click next .
2. On the Optional Features page, uncheck group writeback. You will receive a warning letting you know that
groups will be deleted. Click Yes .
IMPORTANT
Disabling Group Writeback will cause any groups that were previously created by this feature to be deleted from your
local Active Directory on the next synchronization cycle.
3. Click Next .
NOTE
Disabling Group Writeback will set the Full Import and Full Synchronization flags to 'true' on the Azure Active Directory
Connector, causing the rule changes to propagate through on the next synchronization cycle, deleting the groups that were
previously written back to your Active Directory.
Next steps
Azure AD Connect: Device options
The following documentation provides information about the various device options available in Azure AD Connect.
You can use Azure AD Connect to configure the following two operations:
Hybrid Azure AD join : If your environment has an on-premises AD footprint and you want the benefits of
Azure AD, you can implement hybrid Azure AD joined devices. These devices are joined both to your on-
premises Active Directory, and your Azure Active Directory.
Device writeback : Device writeback is used to enable Conditional Access based on devices to AD FS (2012 R2
or higher) protected devices
Configure device options in Azure AD Connect

1. Run Azure AD Connect. In the Additional tasks page, select Configure device options . Click Next .
The Over view page displays the details.

NOTE
The new Configure device options is available only in version 1.1.819.0 and newer.
2. After providing the credentials for Azure AD, you can chose the operation to be performed on the Device
options page.
Next steps
Configure Hybrid Azure AD join
Configure / Disable device writeback
More details about features in preview
This topic describes how to use features currently in preview.
Azure AD Connect sync V2 endpoint API (public preview)

We have deployed a new endpoint (API) for Azure AD Connect that improves the performance of the
synchronization service operations to Azure Active Directory. By utilizing the new V2 endpoint, you will experience
noticeable performance gains on export and import to Azure AD. This new endpoint also supports syncing groups
with up to 250k members. Using this endpoint also allows you to write back O365 unified groups, with no
maximum membership limit, to your on-premises Active Directory, when group writeback is enabled. For more
information see Azure AD Connect sync V2 endpoint API (public preview).
User writeback
IMPORTANT
The user writeback preview feature was removed in the August 2015 update to Azure AD Connect. If you have enabled it,
then you should disable this feature.
Next steps
Continue your Custom installation of Azure AD Connect.
Azure AD Connect sync: Prevent accidental deletes
This topic describes the prevent accidental deletes (preventing accidental deletions) feature in Azure AD Connect.
When installing Azure AD Connect, prevent accidental deletes is enabled by default and configured to not allow
an export with more than 500 deletes. This feature is designed to protect you from accidental configuration
changes and changes to your on-premises directory that would affect many users and other objects.
What is prevent accidental deletes

Common scenarios when you see many deletes include:
Changes to filtering where an entire OU or domain is unselected.
All objects in an OU are deleted.
An OU is renamed so all objects in it are considered to be out of scope for synchronization.
The default value of 500 objects can be changed with PowerShell using Enable-ADSyncExportDeletionThreshold ,
which is part of the AD Sync module installed with Azure Active Directory Connect. You should configure this
value to fit the size of your organization. Since the sync scheduler runs every 30 minutes, the value is the
number of deletes seen within 30 minutes.
If there are too many deletes staged to be exported to Azure AD, then the export stops and you receive an email
like this:
Hello (technical contact). At (time) the Identity synchronization service detected that the number of deletions
exceeded the configured deletion threshold for (organization name). A total of (number) objects were sent
for deletion in this Identity synchronization run. This met or exceeded the configured deletion threshold
value of (number) objects. We need you to provide confirmation that these deletions should be processed
before we will proceed. Please see the preventing accidental deletions for more information about the error
listed in this email message.
You can also see the status stopped-deletion-threshold-exceeded when you look in the Synchronization
Ser vice Manager UI for the Export profile.
If this was unexpected, then investigate and take corrective actions. To see which objects are about to be deleted,
do the following:
1. Start Synchronization Ser vice from the Start Menu.
2. Go to Connectors .
3. Select the Connector with type Azure Active Director y .
4. Under Actions to the right, select Search Connector Space .
5. In the pop-up under Scope , select Disconnected Since and pick a time in the past. Click Search . This page
provides a view of all objects about to be deleted. By clicking each item, you can get additional information
about the object. You can also click Column Setting to add additional attributes to be visible in the grid.
[!NOTE] If you aren't sure all deletes are desired, and wish to go down a safer route. You can use the PowerShell
cmdlet : Enable-ADSyncExportDeletionThreshold to set a new threshold rather than disabling the threshold which
could allow undesired deletions.
If all deletes are desired

If all the deletes are desired, then do the following:
1. To retrieve the current deletion threshold, run the PowerShell cmdlet Get-ADSyncExportDeletionThreshold .
Provide an Azure AD Global Administrator account and password. The default value is 500.
2. To temporarily disable this protection and let those deletes go through, run the PowerShell cmdlet:
Disable-ADSyncExportDeletionThreshold . Provide an Azure AD Global Administrator account and password.
3. With the Azure Active Directory Connector still selected, select the action Run and select Expor t .
4. To re-enable the protection, run the PowerShell cmdlet:
Enable-ADSyncExportDeletionThreshold -DeletionThreshold 500 . Replace 500 with the value you noticed when
retrieving the current deletion threshold. Provide an Azure AD Global Administrator account and password.
Next steps
Over view topics
Azure AD Connect sync: Enable AD recycle bin
It is recommended that you enable the AD Recycle Bin feature for your on-premises Active Directories, which are
synchronized to Azure AD.
If you accidentally deleted an on-premises AD user object and restore it using the feature, Azure AD restores the
corresponding Azure AD user object. For information about the AD Recycle Bin feature, refer to article Scenario
Overview for Restoring Deleted Active Directory Objects.
Benefits of enabling the AD recycle bin

This feature helps with restoring Azure AD user objects by doing the following:
If you accidentally deleted an on-premises AD user object, the corresponding Azure AD user object will be
deleted in the next sync cycle. By default, Azure AD keeps the deleted Azure AD user object in soft-deleted
state for 30 days.
If you have on-premises AD Recycle Bin feature enabled, you can restore the deleted on-premises AD user
object without changing its Source Anchor value. When the recovered on-premises AD user object is
synchronized to Azure AD, Azure AD will restore the corresponding soft-deleted Azure AD user object. For
information about Source Anchor attribute, refer to article Azure AD Connect: Design concepts.
If you do not have on-premises AD Recycle Bin feature enabled, you may be required to create an AD user
object to replace the deleted object. If Azure AD Connect Synchronization Service is configured to use
system-generated AD attribute (such as ObjectGuid) for the Source Anchor attribute, the newly created AD
user object will not have the same Source Anchor value as the deleted AD user object. When the newly
created AD user object is synchronized to Azure AD, Azure AD creates a new Azure AD user object instead of
restoring the soft-deleted Azure AD user object.
NOTE
By default, Azure AD keeps deleted Azure AD user objects in soft-deleted state for 30 days before they are permanently
deleted. However, administrators can accelerate the deletion of such objects. Once the objects are permanently deleted, they
can no longer be recovered, even if on-premises AD Recycle Bin feature is enabled.
Next steps
Over view topics
Azure AD Connect:Configure AD DS Connector
Account Permissions
The PowerShell Module named ADSyncConfig.psm1 was introduced with build 1.1.880.0 (released in August 2018)
that includes a collection of cmdlets to help you configure the correct Active Directory permissions for your Azure
AD Connect deployment.
Overview
The following PowerShell cmdlets can be used to setup Active Directory permissions of the AD DS Connector
account, for each feature that you select to enable in Azure AD Connect. To prevent any issues, you should prepare
Active Directory permissions in advance whenever you want to install Azure AD Connect using a custom domain
account to connect to your forest. This ADSyncConfig module can also be used to configure permissions after
Azure AD Connect is deployed.
For Azure AD Connect Express installation, an automatically generated account (MSOL_nnnnnnnnnn) is created in
Active Directory with all the necessary permissions, so there’s no need to use this ADSyncConfig module unless
you have blocked permissions inheritance on organizational units or on specific Active Directory objects that you
want to synchronize to Azure AD.
Permissions summary
The following table provides a summary of the permissions required on AD objects:
F EAT URE P ERM ISSIO N S
ms-DS-ConsistencyGuid feature Read and Write permissions to the ms-DS-ConsistencyGuid

attribute documented in Design Concepts - Using ms-DS-
ConsistencyGuid as sourceAnchor.
Password hash sync Replicate Directory Changes

Exchange hybrid deployment Read and Write permissions to the attributes documented in
Exchange hybrid writeback for users, groups, and contacts.
Exchange Mail Public Folder Read permissions to the attributes documented in Exchange
Mail Public Folder for public folders.
Password writeback Read and Write permissions to the attributes documented in

Getting started with password management for users.
Device writeback Read and Write permissions to device objects and containers
documented in device writeback.
Group writeback Read, Create, Update, and Delete group objects for
synchronized Office 365 groups .
Using the ADSyncConfig PowerShell Module

The ADSyncConfig module requires the Remote Server Administration Tools (RSAT) for AD DS since it depends on
the AD DS PowerShell module and tools. To install RSAT for AD DS, open a Windows PowerShell window with ‘Run
As Administrator’ and execute:
Install-WindowsFeature RSAT-AD-Tools
NOTE
You can also copy the file C:\Program Files\Microsoft Azure Active Director y
Connect\AdSyncConfig\ADSyncConfig.psm1 to a Domain Controller which already has RSAT for AD DS installed and
use this PowerShell module from there.
To start using the ADSyncConfig you need to load the module in a Windows PowerShell window:
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"

To check all the cmdlets included in this module you can type:
Get-Command -Module AdSyncConfig
Each cmdlet has the same parameters to input the AD DS Connector Account and an AdminSDHolder switch. To
specify your AD DS Connector Account, you can provide the account name and domain, or just the account
Distinguished Name (DN),
e.g.:
Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountName <ADAccountName> -ADConnectorAccountDomain

<ADDomainName>
Or;
Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountDN <ADAccountDN>
Make sure to replace <ADAccountName> , <ADDomainName> and <ADAccountDN> with the proper values for your
environment.
In case you don’t want to modify permissions on the AdminSDHolder container, use the switch
-SkipAdminSdHolders .
By default, all the set permissions cmdlets will try to set AD DS permissions on the root of each Domain in the
Forest, meaning that the user running the PowerShell session requires Domain Administrator rights on each
domain in the Forest. Because of this requirement, it is recommended to use an Enterprise Administrator from the
Forest root. If your Azure AD Connect deployment has multiple AD DS Connectors, it will be required to run the
same cmdlet on each forest that has an AD DS Connector.
You can also set permissions on a specific OU or AD DS object by using the parameter -ADobjectDN followed by
the DN of the target object where you want to set permissions. When using a target ADobjectDN, the cmdlet will
set permissions on this object only and not on the domain root or AdminSDHolder container. This parameter can
be useful when you have certain OUs or AD DS objects that have permission inheritance disabled (see Locate AD
DS objects with permission inheritance disabled)
Exceptions to these common parameters are the Set-ADSyncRestrictedPermissions cmdlet which is used to set the
permissions on the AD DS Connector Account itself, and the Set-ADSyncPasswordHashSyncPermissions cmdlet since
the permissions required for Password Hash Sync are only set at the domain root, hence this cmdlet does not
include the -ObjectDN or -SkipAdminSdHolders parameters.
Determine your AD DS Connector Account
In case Azure AD Connect is already installed and you want to check what is the AD DS Connector Account
currently in use by Azure AD Connect, you can execute the cmdlet:
Get-ADSyncADConnectorAccount
Locate AD DS objects with permission inheritance disabled

In case you want to check if there is any AD DS object with permission inheritance disabled, you can run:
Get-ADSyncObjectsWithInheritanceDisabled -SearchBase '<DistinguishedName>'
By default, this cmdlet will only look for OUs with disabled inheritance, but you can specify other AD DS object
classes in -ObjectClass parameter or use ‘*’ for all object classes, as follows:
Get-ADSyncObjectsWithInheritanceDisabled -SearchBase '<DistinguishedName>' -ObjectClass *
View AD DS permissions of an object

You can use the cmdlet below to view the list of permissions currently set on an Active Directory object by
providing its DistinguishedName:
Show-ADSyncADObjectPermissions -ADobjectDN '<DistinguishedName>'
Configure AD DS Connector Account Permissions

Configure Basic Read-Only Permissions
To set basic read-only permissions for the AD DS Connector account when not using any Azure AD Connect
feature, run:
Set-ADSyncBasicReadPermissions -ADConnectorAccountName <String> -ADConnectorAccountDomain <String> [-

SkipAdminSdHolders] [<CommonParameters>]
or;
Set-ADSyncBasicReadPermissions -ADConnectorAccountDN <String> [-ADobjectDN <String>] [<CommonParameters>]
This cmdlet will set the following permissions:
TYPE NAME A C C ESS A P P L IES TO
Allow AD DS Connector Account Read all properties Descendant device objects
Allow AD DS Connector Account Read all properties Descendant InetOrgPerson

objects
Allow AD DS Connector Account Read all properties Descendant Computer

objects
Allow AD DS Connector Account Read all properties Descendant

foreignSecurityPrincipal
objects
Allow AD DS Connector Account Read all properties Descendant Group objects

Allow AD DS Connector Account Read all properties Descendant User objects
Allow AD DS Connector Account Read all properties Descendant Contact objects
Configure MS -DS -Consistency-Guid Permissions

To set permissions for the AD DS Connector account when using the ms-Ds-Consistency-Guid attribute as the
source anchor (also known as “Let Azure manage the source anchor for me” option) , run:
Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountName <String> -ADConnectorAccountDomain <String>

[-SkipAdminSdHolders] [<CommonParameters>]
or;
Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountDN <String> [-ADobjectDN <String>]

[<CommonParameters>]
Allow AD DS Connector Account Read/Write property Descendant User objects
Permissions for Password Hash Synchronization

To set permissions for the AD DS Connector account when using Password Hash Synchronization, run:
Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountName <String> -ADConnectorAccountDomain <String>

or;
Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountDN <String> [<CommonParameters>]
Allow AD DS Connector Account Replicating Directory This object only (Domain

Changes root)
Allow AD DS Connector Account Replicating Directory This object only (Domain

Changes All root)
Permissions for Password Writeback

To set permissions for the AD DS Connector account when using Password Writeback, run:
Set-ADSyncPasswordWritebackPermissions -ADConnectorAccountName <String> -ADConnectorAccountDomain <String> [-

or;
Set-ADSyncPasswordWritebackPermissions -ADConnectorAccountDN <String> [-ADobjectDN <String>]
Allow AD DS Connector Account Reset Password Descendant User objects
Allow AD DS Connector Account Write property lockoutTime Descendant User objects
Allow AD DS Connector Account Write property pwdLastSet Descendant User objects
Permissions for Group Writeback

To set permissions for the AD DS Connector account when using Group Writeback, run:
Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountName <String> -ADConnectorAccountDomain <String>

[-SkipAdminSdHolders] [<CommonParameters>]
or;
Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountDN <String> [-ADobjectDN <String>]

Allow AD DS Connector Account Generic Read/Write All attributes of object type

group and subobjects
Allow AD DS Connector Account Create/Delete child object All attributes of object type
Allow AD DS Connector Account Delete/Delete tree objects All attributes of object type
Permissions for Exchange Hybrid Deployment

To set permissions for the AD DS Connector account when using Exchange Hybrid deployment, run:
Set-ADSyncExchangeHybridPermissions -ADConnectorAccountName <String> -ADConnectorAccountDomain <String> [-

or;
Set-ADSyncExchangeHybridPermissions -ADConnectorAccountDN <String> [-ADobjectDN <String>] [<CommonParameters>]

Allow AD DS Connector Account Read/Write all properties Descendant User objects
Allow AD DS Connector Account Read/Write all properties Descendant InetOrgPerson

objects
Allow AD DS Connector Account Read/Write all properties Descendant Group objects
Allow AD DS Connector Account Read/Write all properties Descendant Contact objects
Permissions for Exchange Mail Public Folders (Preview)

To set permissions for the AD DS Connector account when using Exchange Mail Public Folders feature, run:
Set-ADSyncExchangeMailPublicFolderPermissions -ADConnectorAccountName <String> -ADConnectorAccountDomain

<String> [-SkipAdminSdHolders] [<CommonParameters>]
or;
Set-ADSyncExchangeMailPublicFolderPermissions -ADConnectorAccountDN <String> [-ADobjectDN <String>]

Allow AD DS Connector Account Read all properties Descendant PublicFolder

objects
Restrict Permissions on the AD DS Connector Account

This PowerShell script will tighten permissions for the AD Connector Account provided as a parameter. Tightening
permissions involves the following steps:
Disable inheritance on the specified object
Remove all ACEs on the specific object, except ACEs specific to SELF as we want to keep the default
permissions intact when it comes to SELF.
The -ADConnectorAccountDN parameter is the AD account whose permissions need to be tightened. This is
typically the MSOL_nnnnnnnnnnnn domain account that is configured in the AD DS Connector (see
Determine your AD DS Connector Account). The -Credential parameter is necessary to specify the
Administrator account that has the necessary privileges to restrict Active Directory permissions on the
target AD object. This is typically the Enterprise or Domain Administrator.
Set-ADSyncRestrictedPermissions [-ADConnectorAccountDN] <String> [-Credential] <PSCredential> [-

DisableCredentialValidation] [-WhatIf] [-Confirm] [<CommonParameters>]
For Example:
$credential = Get-Credential
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN'CN=ADConnectorAccount,CN=Users,DC=Contoso,DC=com' -
Credential $credential
Allow SYSTEM Full Control This object
Allow Enterprise Admins Full Control This object
Allow Domain Admins Full Control This object
Allow Administrators Full Control This object
Allow Enterprise Domain List Contents This object

Controllers
Allow Enterprise Domain Read All Properties This object

Controllers
Allow Enterprise Domain Read Permissions This object

Controllers
Allow Authenticated Users List Contents This object
Allow Authenticated Users Read All Properties This object
Allow Authenticated Users Read Permissions This object
Next Steps
Azure AD Connect: Accounts and permissions
Custom Installation
ADSyncConfig Reference
Changing the ADSync service account password
If you change the ADSync service account password, the Synchronization Service will not be able start correctly
until you have abandoned the encryption key and reinitialized the ADSync service account password.
Azure AD Connect, as part of the Synchronization Services uses an encryption key to store the passwords of the AD
DS Connector account and ADSync service account. These accounts are encrypted before they are stored in the
database.
The encryption key used is secured using Windows Data Protection (DPAPI). DPAPI protects the encryption key
using the ADSync ser vice account .
If you need to change the service account password you can use the procedures in Abandoning the ADSync service
account encryption key to accomplish this. These procedures should also be used if you need to abandon the
encryption key for any reason.
Issues that arise from changing the password

There are two things that need to be done when you change the service account password.
First, you need to change the password under the Windows Service Control Manager. Until this issue is resolved
you will see following errors:
If you try to start the Synchronization Service in Windows Service Control Manager, you receive the error
"Windows could not star t the Microsoft Azure AD Sync ser vice on Local Computer ". Error 1069:
The ser vice did not star t due to a logon failure."
Under Windows Event Viewer, the system event log contains an error with Event ID 7038 and message “The
ADSync ser vice was unable to log on as with the currently configured password due to the
following error : The user name or password is incorrect."
Second, under specific conditions, if the password is updated, the Synchronization Service can no longer retrieve
the encryption key via DPAPI. Without the encryption key, the Synchronization Service cannot decrypt the
passwords required to synchronize to/from on-premises AD and Azure AD. You will see errors such as:
Under Windows Service Control Manager, if you try to start the Synchronization Service and it cannot retrieve
the encryption key, it fails with error “Windows could not star t the Microsoft Azure AD Sync on Local
Computer. For more information, review the System Event log. If this is a non-Microsoft ser vice,
contact the ser vice vendor, and refer to ser vice-specific error code -21451857952 .”
Under Windows Event Viewer, the application event log contains an error with Event ID 6028 and error
message “The server encryption key cannot be accessed.”
To ensure that you do not receive these errors, follow the procedures in Abandoning the ADSync service account
encryption key when changing the password.
Abandoning the ADSync service account encryption key

IMPORTANT
The following procedures only apply to Azure AD Connect build 1.1.443.0 or older. This cannot be used for newer versions of
Azure AD Connect.
Use the following procedures to abandon the encryption key.
What to do if you need to abandon the encryption key
If you need to abandon the encryption key, use the following procedures to accomplish this.
1. Stop the Synchronization Service
2. Abandon the existing encryption key
3. Provide the password of the AD DS Connector account
4. Reinitialize the password of the ADSync service account
5. Start the Synchronization Service
Stop the Synchronization Service
First you can stop the service in the Windows Service Control Manager. Make sure that the service is not running
when attempting to stop it. If it is, wait until it completes and then stop it.
1. Go to Windows Service Control Manager (START → Services).
2. Select Microsoft Azure AD Sync and click Stop.
Abandon the existing encryption key
Abandon the existing encryption key so that new encryption key can be created:
1. Sign in to your Azure AD Connect Server as administrator.
2. Start a new PowerShell session.
3. Navigate to folder: '$env:ProgramFiles\Microsoft Azure AD Sync\bin\'
4. Run the command: ./miiskmu.exe /a
Provide the password of the AD DS Connector account

As the existing passwords stored inside the database can no longer be decrypted, you need to provide the
Synchronization Service with the password of the AD DS Connector account. The Synchronization Service encrypts
the passwords using the new encryption key:
1. Start the Synchronization Service Manager (START → Synchronization Service).
2. Go to the Connectors tab.

3. Select the AD Connector that corresponds to your on-premises AD. If you have more than one AD connector,
repeat the following steps for each of them.
4. Under Actions , select Proper ties .
5. In the pop-up dialog, select Connect to Active Director y Forest :
6. Enter the password of the AD DS account in the Password textbox. If you do not know its password, you must
set it to a known value before performing this step.
7. Click OK to save the new password and close the pop-up dialog.
Reinitialize the password of the ADSync service account

You cannot directly provide the password of the Azure AD service account to the Synchronization Service. Instead,
you need to use the cmdlet Add-ADSyncAADSer viceAccount to reinitialize the Azure AD service account. The
cmdlet resets the account password and makes it available to the Synchronization Service:
1. Start a new PowerShell session on the Azure AD Connect server.
2. Run cmdlet Add-ADSyncAADServiceAccount .
3. In the pop-up dialog, provide the Azure AD Global admin credentials for your Azure AD tenant.
4. If it is successful, you will see the PowerShell command prompt.

Start the Synchronization Service
Now that the Synchronization Service has access to the encryption key and all the passwords it needs, you can
restart the service in the Windows Service Control Manager:
1. Go to Windows Service Control Manager (START → Services).
2. Select Microsoft Azure AD Sync and click Restart.
Next steps
Over view topics
Change the Azure AD Connector account password
The Azure AD Connector account is supposed to be service free. If you need to reset its credentials, then this topic
is for you. For example, if a Global Administrator has by mistake reset the password on the account using
PowerShell.
Reset the credentials

If the Azure AD Connector account cannot contact Azure AD due to authentication problems, the password can be
reset.
1. Sign in to the Azure AD Connect sync server and start PowerShell.
2. Run Add-ADSyncAADServiceAccount .
3. Provide Azure AD Global admin credentials.
This cmdlet resets the password for the service account and update it both in Azure AD and in the sync engine.
Known issues these steps can solve

This section is a list of errors reported by customers that were fixed by a credentials reset on the Azure AD
Connector account.
Event 6900 The server encountered an unexpected error while processing a password change notification:
AADSTS70002: Error validating credentials. AADSTS50054: Old password is used for authentication.
Event 659 Error while retrieving password policy sync configuration.

Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: AADSTS70002: Error validating credentials.
AADSTS50054: Old password is used for authentication.
Next steps
Over view topics
Changing the AD DS account password
The AD DS account refers to the user account used by Azure AD Connect to communicate with on-premises Active
Directory. If you change the password of the AD DS account, you must update Azure AD Connect Synchronization
Service with the new password. Otherwise, the Synchronization can no longer synchronize correctly with the on-
premises Active Directory and you will encounter the following errors:
In the Synchronization Service Manager, any import or export operation with on-premises AD fails with no-
star t-credentials error.
Under Windows Event Viewer, the application event log contains an error with Event ID 6000 and message
'The management agent "contoso.com" failed to run because the credentials were invalid' .
How to update the Synchronization Service with new password for AD

DS account
To update the Synchronization Service with the new password:

3. Select the AD Connector that corresponds to the AD DS account for which its password was changed.
4. Under Actions , select Proper ties .
5. In the pop-up dialog, select Connect to Active Director y Forest :
6. Enter the new password of the AD DS account in the Password textbox.
7. Click OK to save the new password and close the pop-up dialog.
8. Restart the Azure AD Connect Synchronization Service under Windows Service Control Manager. This is to
ensure that any reference to the old password is removed from the memory cache.
Next steps
Over view topics
Quickstart
Deploy Azure AD Pass-through Authentication

Azure Active Directory (Azure AD) Pass-through Authentication allows your users to sign in to both on-premises
and cloud-based applications by using the same passwords. Pass-through Authentication signs users in by
validating their passwords directly against on-premises Active Directory.
IMPORTANT
If you are migrating from AD FS (or other federation technologies) to Pass-through Authentication, we highly recommend
that you follow our detailed deployment guide published here.
NOTE
If you deploying Pass Through Authentication with the Azure Government cloud, view Hybrid Identity Considerations for
Azure Government.
Follow these instructions to deploy Pass-through Authentication on your tenant:

Ensure that the following prerequisites are in place.
IMPORTANT
From a security standpoint, administrators should treat the server running the PTA agent as if it were a domain controller.
The PTA agent servers should be hardened along the same lines as outlined in Securing Domain Controllers Against Attack
In the Azure Active Directory admin center

1. Create a cloud-only global administrator account on your Azure AD tenant. This way, you can manage the
configuration of your tenant should your on-premises services fail or become unavailable. Learn about
adding a cloud-only global administrator account. Completing this step is critical to ensure that you don't get
locked out of your tenant.
2. Add one or more custom domain names to your Azure AD tenant. Your users can sign in with one of these
domain names.
In your on-premises environment
1. Identify a server running Windows Server 2012 R2 or later to run Azure AD Connect. If not enabled
already, enable TLS 1.2 on the server. Add the server to the same Active Directory forest as the users
whose passwords you need to validate.
2. Install the latest version of Azure AD Connect on the server identified in the preceding step. If you already
have Azure AD Connect running, ensure that the version is 1.1.750.0 or later.
NOTE
Azure AD Connect versions 1.1.557.0, 1.1.558.0, 1.1.561.0, and 1.1.614.0 have a problem related to password
hash synchronization. If you don't intend to use password hash synchronization in conjunction with Pass-through
Authentication, read the Azure AD Connect release notes.
3. Identify one or more additional servers (running Windows Server 2012 R2 or later, with TLS 1.2 enabled)
where you can run standalone Authentication Agents. These additional servers are needed to ensure the
high availability of requests to sign in. Add the servers to the same Active Directory forest as the users
whose passwords you need to validate.
IMPORTANT
In production environments, we recommend that you have a minimum of 3 Authentication Agents running on
your tenant. There is a system limit of 40 Authentication Agents per tenant. And as best practice, treat all servers
running Authentication Agents as Tier 0 systems (see reference).
4. If there is a firewall between your servers and Azure AD, configure the following items:
Ensure that Authentication Agents can make outbound requests to Azure AD over the following
ports:
P O RT N UM B ER H O W IT 'S USED
80 Downloads the certificate revocation lists (CRLs) while

validating the TLS/SSL certificate
443 Handles all outbound communication with the

service
8080 (optional) Authentication Agents report their status every ten

minutes over port 8080, if port 443 is unavailable.
This status is displayed on the Azure AD portal. Port
8080 is not used for user sign-ins.
If your firewall enforces rules according to the originating users, open these ports for traffic from
Windows services that run as a network service.
If your firewall or proxy allows DNS whitelisting, add connections to *.msappproxy.net and
*.ser vicebus.windows.net . If not, allow access to the Azure datacenter IP ranges, which are
updated weekly.
Your Authentication Agents need access to login.windows.net and login.microsoftonline.com
for initial registration. Open your firewall for those URLs as well.
For certificate validation, unblock the following URLs: mscrl.microsoft.com:80 ,
crl.microsoft.com:80 , ocsp.msocsp.com:80 , and www.microsoft.com:80 . Since these URLs
are used for certificate validation with other Microsoft products you may already have these URLs
unblocked.
Azure Government cloud prerequisite
Prior to enabling Pass-through Authentication through Azure AD Connect with Step 2, download the latest
release of the PTA agent from the Azure portal. You need to ensure that your agent is versions 1.5.1742.0. or
later. To verify your agent see Upgrade authentication agents
After downloading the latest release of the agent, proceed with the below instructions to configure Pass-Through
Authentication through Azure AD Connect.

Enable Pass-through Authentication through Azure AD Connect.
IMPORTANT
You can enable Pass-through Authentication on the Azure AD Connect primary or staging server. It is highly
recommended that you enable it from the primary server. If you are setting up an Azure AD Connect staging server in the
future, you must continue to choose Pass-through Authentication as the sign-in option; choosing another option will
disable Pass-through Authentication on the tenant and override the setting in the primary server.
If you're installing Azure AD Connect for the first time, choose the custom installation path. At the User sign-in
page, choose Pass-through Authentication as the Sign On method . On successful completion, a Pass-
through Authentication Agent is installed on the same server as Azure AD Connect. In addition, the Pass-through
Authentication feature is enabled on your tenant.
If you have already installed Azure AD Connect by using the express installation or the custom installation path,
select the Change user sign-in task on Azure AD Connect, and then select Next . Then select Pass-through
Authentication as the sign-in method. On successful completion, a Pass-through Authentication Agent is
installed on the same server as Azure AD Connect and the feature is enabled on your tenant.
IMPORTANT
Pass-through Authentication is a tenant-level feature. Turning it on affects the sign-in for users across all the managed
domains in your tenant. If you're switching from Active Directory Federation Services (AD FS) to Pass-through
Authentication, you should wait at least 12 hours before shutting down your AD FS infrastructure. This wait time is to
ensure that users can keep signing in to Exchange ActiveSync during the transition. For more help on migrating from AD
FS to Pass-through Authentication, check out our detailed deployment plan published here.

Follow these instructions to verify that you have enabled Pass-through Authentication correctly:
1. Sign in to the Azure Active Directory admin center with the global administrator credentials for your tenant.
4. Verify that the Pass-through authentication feature appears as Enabled .
5. Select Pass-through authentication . The Pass-through authentication pane lists the servers where your
Authentication Agents are installed.
At this stage, users from all the managed domains in your tenant can sign in by using Pass-through
Authentication. However, users from federated domains continue to sign in by using AD FS or another federation
provider that you have previously configured. If you convert a domain from federated to managed, all users
from that domain automatically start signing in by using Pass-through Authentication. The Pass-through
Authentication feature does not affect cloud-only users.
Step 4: Ensure high availability

If you plan to deploy Pass-through Authentication in a production environment, you should install additional
standalone Authentication Agents. Install these Authentication Agent(s) on server(s) other than the one running
Azure AD Connect. This setup provides you with high availability for user sign-in requests.
IMPORTANT
In production environments, we recommend that you have a minimum of 3 Authentication Agents running on your
tenant. There is a system limit of 40 Authentication Agents per tenant. And as best practice, treat all servers running
Authentication Agents as Tier 0 systems (see reference).
Installing multiple Pass-through Authentication Agents ensures high availability, but not deterministic load
balancing between the Authentication Agents. To determine how many Authentication Agents you need for your
tenant, consider the peak and average load of sign-in requests that you expect to see on your tenant. As a
benchmark, a single Authentication Agent can handle 300 to 400 authentications per second on a standard 4-
core CPU, 16-GB RAM server.
Each request has a payload size of (0.5K + 1K * num_of_agents) bytes, that is, data from Azure AD to the
Authentication Agent. Here, "num_of_agents" indicates the number of Authentication Agents registered on
your tenant.
Each response has a payload size of 1K bytes, that is, data from the Authentication Agent to Azure AD.
For most customers, three Authentication Agents in total are sufficient for high availability and capacity. You
should install Authentication Agents close to your domain controllers to improve sign-in latency.
To begin, follow these instructions to download the Authentication Agent software:
1. To download the latest version of the Authentication Agent (version 1.5.193.0 or later), sign in to the Azure
Active Directory admin center with your tenant's global administrator credentials.
3. Select Azure AD Connect , select Pass-through authentication , and then select Download Agent .
4. Select the Accept terms & download button.
NOTE
You can also directly download the Authentication Agent software. Review and accept the Authentication Agent's Terms of
Service before installing it.
There are two ways to deploy a standalone Authentication Agent:

First, you can do it interactively by just running the downloaded Authentication Agent executable and providing
your tenant's global administrator credentials when prompted.
Second, you can create and run an unattended deployment script. This is useful when you want to deploy
multiple Authentication Agents at once, or install Authentication Agents on Windows servers that don't have user
interface enabled, or that you can't access with Remote Desktop. Here are the instructions on how to use this
approach:
1. Run the following command to install an Authentication Agent:
AADConnectAuthAgentSetup.exe REGISTERCONNECTOR="false" /q .
2. You can register the Authentication Agent with our service using Windows PowerShell. Create a PowerShell
Credentials object $cred that contains a global administrator username and password for your tenant. Run
the following command, replacing <username> and <password>:
$User = "<username>"
$PlainPassword = '<password>'
$SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, $SecurePassword
3. Go to C:\Program Files\Microsoft Azure AD Connect Authentication Agent and run the following
script using the $cred object that you created:
RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft Azure AD Connect Authentication

Agent\Modules\" -moduleName "PassthroughAuthPSModule" -Authenticationmode Credentials -Usercredentials $cred
-Feature PassthroughAuthentication
IMPORTANT
If an Authentication Agent is installed on a Virtual Machine, you can't clone the Virtual Machine to setup another
Authentication Agent. This method is unsuppor ted .
Step 5: Configure Smart Lockout capability

Smart Lockout assists in locking out bad actors who are trying to guess your users’ passwords or using brute-
force methods to get in. By configuring Smart Lockout settings in Azure AD and / or appropriate lockout settings
in on-premises Active Directory, attacks can be filtered out before they reach Active Directory. Read this article to
learn more on how to configure Smart Lockout settings on your tenant to protect your user accounts.
Next steps
Current limitations: Learn which scenarios are supported with the Pass-through Authentication and which
ones are not.
Security deep dive: Get technical information on the Pass-through Authentication feature.
This article addresses frequently asked questions about Azure Active Directory (Azure AD) Pass-through
Authentication. Keep checking back for updated content.
Which of the methods to sign in to Azure AD, Pass-through

Authentication, password hash synchronization, and Active Directory
Federation Services (AD FS), should I choose?
Review this guide for a comparison of the various Azure AD sign-in methods and how to choose the right sign-in
method for your organization.
Is Pass-through Authentication a free feature?

Pass-through Authentication is a free feature. You don't need any paid editions of Azure AD to use it.
Is Pass-through Authentication available in the Microsoft Azure

Germany cloud and the Microsoft Azure Government cloud?
No. Pass-through Authentication is only available in the worldwide instance of Azure AD.
Does Conditional Access work with Pass-through Authentication?

Yes. All Conditional Access capabilities, including Azure Multi-Factor Authentication, work with Pass-through
Authentication.
Does Pass-through Authentication support "Alternate ID" as the

username, instead of "userPrincipalName"?
Yes, sign-in using a non-UPN value, such as an alternate email, is supported for both pass-through
authentication (PTA) and password hash sync (PHS). For more information about Alternate Login ID.
Does password hash synchronization act as a fallback to Pass-through

Authentication?
No. Pass-through Authentication does not automatically failover to password hash synchronization. To avoid
user sign-in failures, you should configure Pass-through Authentication for high availability.
What happens when I switch from password hash synchronization to

Pass-through Authentication?
When you use Azure AD Connect to switch the sign-in method from password hash synchronization to Pass-
through Authentication, Pass-through Authentication becomes the primary sign-in method for your users in
managed domains. Please note that all users' password hashes which were previously synchronized by
password hash synchronization remain stored on Azure AD.
Can I install an Azure AD Application Proxy connector on the same
server as a Pass-through Authentication Agent?
Yes. The rebranded versions of the Pass-through Authentication Agent, version 1.5.193.0 or later, support this
configuration.
What versions of Azure AD Connect and Pass-through Authentication

Agent do you need?
For this feature to work, you need version 1.1.750.0 or later for Azure AD Connect and 1.5.193.0 or later for the
Pass-through Authentication Agent. Install all the software on servers with Windows Server 2012 R2 or later.
What happens if my user's password has expired and they try to sign
in by using Pass-through Authentication?
If you have configured password writeback for a specific user, and if the user signs in by using Pass-through
Authentication, they can change or reset their passwords. The passwords are written back to on-premises Active
Directory as expected.
If you have not configured password writeback for a specific user or if the user doesn't have a valid Azure AD
license assigned, the user can't update their password in the cloud. They can't update their password, even if their
password has expired. The user instead sees this message: "Your organization doesn't allow you to update your
password on this site. Update it according to the method recommended by your organization, or ask your admin
if you need help." The user or the administrator must reset their password in on-premises Active Directory.
How does Pass-through Authentication protect you against brute-

force password attacks?
Read information about Smart Lockout.
What do Pass-through Authentication Agents communicate over

ports 80 and 443?
The Authentication Agents make HTTPS requests over port 443 for all feature operations.
The Authentication Agents make HTTP requests over port 80 to download the TLS/SSL certificate
revocation lists (CRLs).
NOTE
Recent updates reduced the number of ports that the feature requires. If you have older versions of Azure AD
Connect or the Authentication Agent, keep these ports open as well: 5671, 8080, 9090, 9091, 9350, 9352, and
10100-10120.
Can the Pass-through Authentication Agents communicate over an

outbound web proxy server?
Yes. If Web Proxy Auto-Discovery (WPAD) is enabled in your on-premises environment, Authentication Agents
automatically attempt to locate and use a web proxy server on the network.
If you don't have WPAD in your environment, you can add proxy information (as shown below) to allow a Pass-
through Authentication Agent to communicate with Azure AD:
Configure proxy information in Internet Explorer before you install the Pass-through Authentication Agent on
the server. This will allow you to complete the installation of the Authentication Agent, but it will still show up
as Inactive on the Admin portal.
On the server, navigate to "C:\Program Files\Microsoft Azure AD Connect Authentication Agent".
Edit the "AzureADConnectAuthenticationAgentService" configuration file and add the following lines (replace
"http://contosoproxy.com:8080" with your actual proxy address):
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy
proxyaddress="http://contosoproxy.com:8080"
/>
</defaultProxy>
</system.net>
Can I install two or more Pass-through Authentication Agents on the

same server?
No, you can only install one Pass-through Authentication Agent on a single server. If you want to configure Pass-
through Authentication for high availability, follow the instructions here.
Do I have to manually renew certificates used by Pass-through

Authentication Agents?
The communication between each Pass-through Authentication Agent and Azure AD is secured using certificate-
based authentication. These certificates are automatically renewed every few months by Azure AD. There is no
need to manually renew these certificates. You can clean up older expired certificates as required.
How do I remove a Pass-through Authentication Agent?

As long as a Pass-through Authentication Agent is running, it remains active and continually handles user sign-in
requests. If you want to uninstall an Authentication Agent, go to Control Panel -> Programs -> Programs
and Features and uninstall both the Microsoft Azure AD Connect Authentication Agent and the
Microsoft Azure AD Connect Agent Updater programs.
If you check the Pass-through Authentication blade on the Azure Active Directory admin center after completing
the preceding step, you'll see the Authentication Agent showing as Inactive . This is expected. The Authentication
Agent is automatically dropped from the list after 10 days.
I already use AD FS to sign in to Azure AD. How do I switch it to Pass-

through Authentication?
If you are migrating from AD FS (or other federation technologies) to Pass-through Authentication, we highly
recommend that you follow our detailed deployment guide published here.
Can I use Pass-through Authentication in a multi-forest Active

Directory environment?
Yes. Multi-forest environments are supported if there are forest trusts (two-way) between your Active Directory
forests and if name suffix routing is correctly configured.
Does Pass-through Authentication provide load balancing across
multiple Authentication Agents?
No, installing multiple Pass-through Authentication Agents ensures only high availability. It does not provide
deterministic load balancing between the Authentication Agents. Any Authentication Agent (at random) can
process a particular user sign-in request.
How many Pass-through Authentication Agents do I need to install?

Installing multiple Pass-through Authentication Agents ensures high availability. But, it does not provide
deterministic load balancing between the Authentication Agents.
Consider the peak and average load of sign-in requests that you expect to see on your tenant. As a benchmark, a
single Authentication Agent can handle 300 to 400 authentications per second on a standard 4-core CPU, 16-GB
RAM server.
Each request has a payload size of (0.5K + 1K * num_of_agents) bytes; i.e., data from Azure AD to the
Authentication Agent. Here, "num_of_agents" indicates the number of Authentication Agents registered on
your tenant.
Each response has a payload size of 1K bytes; i.e., data from the Authentication Agent to Azure AD.
For most customers, two or three Authentication Agents in total are sufficient for high availability and capacity.
You should install Authentication Agents close to your domain controllers to improve sign-in latency.
NOTE
There is a system limit of 40 Authentication Agents per tenant.
Can I install the first Pass-through Authentication Agent on a server

other than the one that runs Azure AD Connect?
No, this scenario is not supported.
Why do I need a cloud-only Global Administrator account to enable

Pass-through Authentication?
It is recommended that you enable or disable Pass-through Authentication using a cloud-only Global
Administrator account. Learn about adding a cloud-only Global Administrator account. Doing it this way ensures
that you don't get locked out of your tenant.
How can I disable Pass-through Authentication?

Rerun the Azure AD Connect wizard and change the user sign-in method from Pass-through Authentication to
another method. This change disables Pass-through Authentication on the tenant and uninstalls the
Authentication Agent from the server. You must manually uninstall the Authentication Agents from the other
servers.
What happens when I uninstall a Pass-through Authentication Agent?

If you uninstall a Pass-through Authentication Agent from a server, it causes the server to stop accepting sign-in
requests. To avoid breaking the user sign-in capability on your tenant, ensure that you have another
Authentication Agent running before you uninstall a Pass-through Authentication Agent.
I have an older tenant that was originally setup using AD FS. We

recently migrated to PTA but now are not seeing our UPN changes
synchronizing to Azure AD. Why are our UPN changes not being
synchronized?
A: Under the following circumstances your on-premises UPN changes may not synchronize if:
Your Azure AD tenant was created prior to June 15th 2015
You initially were federated with your Azure AD tenant using AD FS for authentication
You switched to having managed users using PTA as authentication
This is because the default behavior of tenants created prior to June 15th 2015 was to block UPN changes. If you
need to un-block UPN changes you need to run the following PowerShell cmdlt:
Set-MsolDirSyncFeature -Feature SynchronizeUpnForManagedUsers -Enable $True
Tenants created after June 15th 2015 have the default behavior of synchronizing UPN changes.
Next steps
Quick start: Get up and running on Azure AD Pass-through Authentication.
Security deep dive: Get deep technical information on the Pass-through Authentication feature.
Disable PTA when using Azure AD Connect "Do not
configure"
If you are using Pass-through Authentication with Azure AD Connect and you have it set to "Do not configure", you
can disable it. Disabling PTA can be done using the following cmdlets.
Prerequisites
The following prerequisites are required:
Any windows machine that has the PTA agent installed.
Agent must be at version 1.5.1742.0 or later.
An Azure global administrator account in order to run the PowerShell cmdlets to disable PTA.
NOTE
If your agent is older then it may not have the cmdlets required to complete this operation. You can get a new agent from
Azure Portal an install it on any windows machine and provide admin credentials. (Installing the agent does not affect the PTA
status in the cloud)
IMPORTANT
If you are using the Azure Government cloud then you will have to pass in the ENVIRONMENTNAME parameter with the
following value.
ENVI R O NM ENT NAM E CLO UD
AzureUSGovernment US Gov
To disable PTA
From within a PowerShell session, use the following to disable PTA:
1. PS C:\Program Files\Microsoft Azure AD Connect Authentication Agent>
Import-Module .\Modules\PassthroughAuthPSModule
2. Get-PassthroughAuthenticationEnablementStatus -Feature PassthroughAuth or
Get-PassthroughAuthenticationEnablementStatus -Feature PassthroughAuth -EnvironmentName <identifier>
3. Disable-PassthroughAuthentication -Feature PassthroughAuth or
Disable-PassthroughAuthentication -Feature PassthroughAuth -EnvironmentName <identifier>
If you don't have access to an agent

If you do not have an agent machine you can use following command to install an agent.
1. Download the latest Auth Agent from portal.azure.com.
2. Install the feature: .\AADConnectAuthAgentSetup.exe or
.\AADConnectAuthAgentSetup.exe ENVIRONMENTNAME=<identifier>
Next steps
User sign-in with Azure Active Directory Pass-through Authentication
Manage and customize Active Directory Federation
Services by using Azure AD Connect
This article describes how to manage and customize Active Directory Federation Services (AD FS) by using Azure
Active Directory (Azure AD) Connect. It also includes other common AD FS tasks that you might need to do for a
complete configuration of an AD FS farm.
TO P IC W H AT IT C O VERS
Manage AD FS
Repair the trust How to repair the federation trust with Office 365.
Federate with Azure AD using alternate login ID Configure federation using alternate login ID
Add an AD FS server How to expand an AD FS farm with an additional AD FS

server.
Add an AD FS Web Application Proxy server How to expand an AD FS farm with an additional Web
Application Proxy (WAP) server.
Add a federated domain How to add a federated domain.
Update the TLS/SSL certificate How to update the TLS/SSL certificate for an AD FS farm.
Customize AD FS
Add a custom company logo or illustration How to customize an AD FS sign-in page with a company
logo and illustration.
Add a sign-in description How to add a sign-in page description.
Modify AD FS claim rules How to modify AD FS claims for various federation scenarios.
Manage AD FS
You can perform various AD FS-related tasks in Azure AD Connect with minimal user intervention by using the
Azure AD Connect wizard. After you've finished installing Azure AD Connect by running the wizard, you can run
the wizard again to perform additional tasks.
Repair the trust

You can use Azure AD Connect to check the current health of the AD FS and Azure AD trust and take appropriate
actions to repair the trust. Follow these steps to repair your Azure AD and AD FS trust.
1. Select Repair AAD and ADFS Trust from the list of additional tasks.
2. On the Connect to Azure AD page, provide your global administrator credentials for Azure AD, and click
Next .
3. On the Remote access credentials page, enter the credentials for the domain administrator.
After you click Next , Azure AD Connect checks for certificate health and shows any issues.
The Ready to configure page shows the list of actions that will be performed to repair the trust.
4. Click Install to repair the trust.
NOTE
Azure AD Connect can only repair or act on certificates that are self-signed. Azure AD Connect can't repair third-party
certificates.
Federate with Azure AD using AlternateID

It is recommended that the on-premises User Principal Name(UPN) and the cloud User Principal Name are kept
the same. If the on-premises UPN uses a non-routable domain (ex. Contoso.local) or cannot be changed due to
local application dependencies, we recommend setting up alternate login ID. Alternate login ID allows you to
configure a sign-in experience where users can sign in with an attribute other than their UPN, such as mail. The
choice for User Principal Name in Azure AD Connect defaults to the userPrincipalName attribute in Active
Directory. If you choose any other attribute for User Principal Name and are federating using AD FS, then Azure
AD Connect will configure AD FS for alternate login ID. An example of choosing a different attribute for User
Principal Name is shown below:
Configuring alternate login ID for AD FS consists of two main steps:
1. Configure the right set of issuance claims : The issuance claim rules in the Azure AD relying party
trust are modified to use the selected UserPrincipalName attribute as the alternate ID of the user.
2. Enable alternate login ID in the AD FS configuration : The AD FS configuration is updated so that AD
FS can look up users in the appropriate forests using the alternate ID. This configuration is supported for
AD FS on Windows Server 2012 R2 (with KB2919355) or later. If the AD FS servers are 2012 R2, Azure AD
Connect checks for the presence of the required KB. If the KB is not detected, a warning will be displayed
after configuration completes, as shown below:
To rectify the configuration in case of missing KB, install the required KB2919355 and then repair the trust
using Repair AAD and AD FS Trust.
NOTE
For more information on alternateID and steps to manually configure, read Configuring Alternate Login ID
Add an AD FS server
NOTE
To add an AD FS server, Azure AD Connect requires the PFX certificate. Therefore, you can perform this operation only if you
configured the AD FS farm by using Azure AD Connect.
1. Select Deploy an additional Federation Ser ver , and click Next .

2. On the Connect to Azure AD page, enter your global administrator credentials for Azure AD, and click
Next .
3. Provide the domain administrator credentials.

4. Azure AD Connect asks for the password of the PFX file that you provided while configuring your new AD
FS farm with Azure AD Connect. Click Enter Password to provide the password for the PFX file.
5. On the AD FS Ser vers page, enter the server name or IP address to be added to the AD FS farm.
6. Click Next , and go through the final Configure page. After Azure AD Connect has finished adding the
servers to the AD FS farm, you will be given the option to verify the connectivity.
Add an AD FS WAP server
NOTE
To add a WAP server, Azure AD Connect requires the PFX certificate. Therefore, you can only perform this operation if you
configured the AD FS farm by using Azure AD Connect.
1. Select Deploy Web Application Proxy from the list of available tasks.
2. Provide the Azure global administrator credentials.
3. On the Specify SSL cer tificate page, provide the password for the PFX file that you provided when you
configured the AD FS farm with Azure AD Connect.
4. Add the server to be added as a WAP server. Because the WAP server might not be joined to the domain,
the wizard asks for administrative credentials to the server being added.
5. On the Proxy trust credentials page, provide administrative credentials to configure the proxy trust and
access the primary server in the AD FS farm.
6. On the Ready to configure page, the wizard shows the list of actions that will be performed.
7. Click Install to finish the configuration. After the configuration is complete, the wizard gives you the option
to verify the connectivity to the servers. Click Verify to check connectivity.
Add a federated domain

It's easy to add a domain to be federated with Azure AD by using Azure AD Connect. Azure AD Connect adds the
domain for federation and modifies the claim rules to correctly reflect the issuer when you have multiple domains
federated with Azure AD.
1. To add a federated domain, select the task Add an additional Azure AD domain .
2. On the next page of the wizard, provide the global administrator credentials for Azure AD.
3. On the Remote access credentials page, provide the domain administrator credentials.
4. On the next page, the wizard provides a list of Azure AD domains that you can federate your on-premises
directory with. Choose the domain from the list.
After you choose the domain, the wizard provides you with appropriate information about further actions
that the wizard will take and the impact of the configuration. In some cases, if you select a domain that isn't
yet verified in Azure AD, the wizard provides you with information to help you verify the domain. See Add
your custom domain name to Azure Active Directory for more details.
5. Click Next . The Ready to configure page shows the list of actions that Azure AD Connect will perform.
Click Install to finish the configuration.
NOTE
Users from the added federated domain must be synchronized before they will be able to login to Azure AD.
AD FS customization
The following sections provide details about some of the common tasks that you might have to perform when
you customize your AD FS sign-in page.
Add a custom company logo or illustration

To change the logo of the company that's displayed on the Sign-in page, use the following Windows PowerShell
cmdlet and syntax.
NOTE
The recommended dimensions for the logo are 260 x 35 @ 96 dpi with a file size no greater than 10 KB.
Set-AdfsWebTheme -TargetName default -Logo @{path="c:\Contoso\logo.PNG"}
NOTE
The TargetName parameter is required. The default theme that's released with AD FS is named Default.
Add a sign-in description

To add a sign-in page description to the Sign-in page , use the following Windows PowerShell cmdlet and syntax.
Set-AdfsGlobalWebContent -SignInPageDescriptionText "<p>Sign-in to Contoso requires device registration.

Click <A href='http://fs1.contoso.com/deviceregistration/'>here</A> for more information.</p>"
Modify AD FS claim rules

AD FS supports a rich claim language that you can use to create custom claim rules. For more information, see
The Role of the Claim Rule Language.
The following sections describe how you can write custom rules for some scenarios that relate to Azure AD and
AD FS federation.
Immutable ID conditional on a value being present in the attribute
Azure AD Connect lets you specify an attribute to be used as a source anchor when objects are synced to Azure
AD. If the value in the custom attribute is not empty, you might want to issue an immutable ID claim.
For example, you might select ms-ds-consistencyguid as the attribute for the source anchor and issue
ImmutableID as ms-ds-consistencyguid in case the attribute has a value against it. If there's no value against
the attribute, issue objectGuid as the immutable ID. You can construct the set of custom claim rules as described
in the following section.
Rule 1: Quer y attributes
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> add(store = "Active Directory", types = ("http://contoso.com/ws/2016/02/identity/claims/objectguid",
"http://contoso.com/ws/2016/02/identity/claims/msdsconsistencyguid"), query = "; objectGuid,ms-ds-
consistencyguid;{0}", param = c.Value);
In this rule, you're querying the values of ms-ds-consistencyguid and objectGuid for the user from Active
Directory. Change the store name to an appropriate store name in your AD FS deployment. Also change the
claims type to a proper claims type for your federation, as defined for objectGuid and ms-ds-consistencyguid .
Also, by using add and not issue , you avoid adding an outgoing issue for the entity, and can use the values as
intermediate values. You will issue the claim in a later rule after you establish which value to use as the immutable
ID.
Rule 2: Check if ms-ds-consistencyguid exists for the user
NOT EXISTS([Type == "http://contoso.com/ws/2016/02/identity/claims/msdsconsistencyguid"])

=> add(Type = "urn:anandmsft:tmp/idflag", Value = "useguid");
This rule defines a temporary flag called idflag that is set to useguid if there's no ms-ds-consistencyguid
populated for the user. The logic behind this is the fact that AD FS doesn't allow empty claims. So when you add
claims http://contoso.com/ws/2016/02/identity/claims/objectguid and
http://contoso.com/ws/2016/02/identity/claims/msdsconsistencyguid in Rule 1, you end up with an
msdsconsistencyguid claim only if the value is populated for the user. If it isn't populated, AD FS sees that it will
have an empty value and drops it immediately. All objects will have objectGuid , so that claim will always be there
after Rule 1 is executed.
Rule 3: Issue ms-ds-consistencyguid as immutable ID if it's present
c:[Type == "http://contoso.com/ws/2016/02/identity/claims/msdsconsistencyguid"]
=> issue(Type = "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID", Value = c.Value);
This is an implicit Exist check. If the value for the claim exists, then issue that as the immutable ID. The previous
example uses the nameidentifier claim. You'll have to change this to the appropriate claim type for the
immutable ID in your environment.
Rule 4: Issue objectGuid as immutable ID if ms-ds-consistencyGuid is not present
c1:[Type == "urn:anandmsft:tmp/idflag", Value =~ "useguid"]

&& c2:[Type == "http://contoso.com/ws/2016/02/identity/claims/objectguid"]
=> issue(Type = "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID", Value = c2.Value);
In this rule, you're simply checking the temporary flag idflag . You decide whether to issue the claim based on its
value.
NOTE
The sequence of these rules is important.
SSO with a subdomain UPN

You can add more than one domain to be federated by using Azure AD Connect, as described in Add a new
federated domain. Azure AD Connect version 1.1.553.0 and latest creates the correct claim rule for issuerID
automatically. If you cannot use Azure AD Connect version 1.1.553.0 or latest, it is recommended that Azure AD
RPT Claim Rules tool is used to generate and set correct claim rules for the Azure AD relying party trust.
Next steps
Learn more about user sign-in options.
Multiple Domain Support for Federating with Azure
AD
The following documentation provides guidance on how to use multiple top-level domains and subdomains when
federating with Office 365 or Azure AD domains.
Multiple top-level domain support

Federating multiple, top-level domains with Azure AD requires some additional configuration that is not required
when federating with one top-level domain.
When a domain is federated with Azure AD, several properties are set on the domain in Azure. One important one
is IssuerUri. This property is a URI that is used by Azure AD to identify the domain that the token is associated
with. The URI doesn’t need to resolve to anything but it must be a valid URI. By default, Azure AD sets the URI to
the value of the federation service identifier in your on-premises AD FS configuration.
NOTE
The federation service identifier is a URI that uniquely identifies a federation service. The federation service is an instance of
AD FS that functions as the security token service.
You can view the IssuerUri by using the PowerShell command

Get-MsolDomainFederationSettings -DomainName <your domain> .
A problem arises when you add more than one top-level domain. For example, let's say you have set up federation
between Azure AD and your on-premises environment. For this document, the domain, bmcontoso.com is being
used. Now a second, top-level domain, bmfabrikam.com has been added.
When you attempt to convert the bmfabrikam.com domain to be federated, an error occurs. The reason is, Azure
AD has a constraint that does not allow the IssuerUri property to have the same value for more than one domain.
SupportMultipleDomain Parameter
To work around this constraint, you need to add a different IssuerUri, which can be done by using the
-SupportMultipleDomain parameter. This parameter is used with the following cmdlets:
New-MsolFederatedDomain
Convert-MsolDomaintoFederated
Update-MsolFederatedDomain
This parameter makes Azure AD configure the IssuerUri so that it is based on the name of the domain. The
IssuerUri will be unique across directories in Azure AD. Using the parameter allows the PowerShell command to
complete successfully.
Looking at the settings for the bmfabrikam.com domain you can see the following:
-SupportMultipleDomain does not change the other endpoints, which are still configured to point to the federation
service on adfs.bmcontoso.com.
Another thing that -SupportMultipleDomain does is that it ensures that the AD FS system includes the proper
Issuer value in tokens issued for Azure AD. This value is set by taking the domain portion of the users UPN and
setting it as the domain in the IssuerUri, i.e. https://{upn suffix}/adfs/services/trust.
Thus during authentication to Azure AD or Office 365, the IssuerUri element in the user’s token is used to locate
the domain in Azure AD. If, a match cannot be found, the authentication will fail.
For example, if a user’s UPN is bsimon@bmcontoso.com, the IssuerUri element in the token, AD FS issues, will be
set to http://bmcontoso.com/adfs/services/trust . This element will match the Azure AD configuration, and
authentication will succeed.
The following is the customized claim rule that implements this logic:
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"] => issue(Type =

"http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?
<domain>.+)", "http://${domain}/adfs/services/trust/"));
IMPORTANT
In order to use the -SupportMultipleDomain switch when attempting to add new or convert already existing domains, your
federated trust needs to have already been set up to support them.
How to update the trust between AD FS and Azure AD

If you did not set up the federated trust between AD FS and your instance of Azure AD, you may need to re-create
this trust. The reason is, when it is originally set up without the -SupportMultipleDomain parameter, the IssuerUri is
set with the default value. In the screenshot below, you can see the IssuerUri is set to
https://adfs.bmcontoso.com/adfs/services/trust .
If you have successfully added a new domain in the Azure AD portal and then attempt to convert it using
Convert-MsolDomaintoFederated -DomainName <your domain> , you will get the following error.
If you try to add the -SupportMultipleDomain switch, you will receive the following error:
Simply trying to run Update-MsolFederatedDomain -DomainName <your domain> -SupportMultipleDomain on the original
domain will also result in an error.
Use the steps below to add an additional top-level domain. If you have already added a domain, and did not use
the -SupportMultipleDomain parameter, start with the steps for removing and updating your original domain. If
you have not added a top-level domain yet, you can start with the steps for adding a domain using PowerShell of
Azure AD Connect.
Use the following steps to remove the Microsoft Online trust and update your original domain.
1. On your AD FS federation server open AD FS Management.
2. On the left, expand Trust Relationships and Relying Par ty Trusts
3. On the right, delete the Microsoft Office 365 Identity Platform entry.
4. On a machine that has Azure Active Directory Module for Windows PowerShell installed on it run the
following: $cred=Get-Credential .
5. Enter the username and password of a global administrator for the Azure AD domain you are federating with.
6. In PowerShell, enter Connect-MsolService -Credential $cred
7. In PowerShell, enter Update-MSOLFederatedDomain -DomainName <Federated Domain Name> -SupportMultipleDomain .
This update is for the original domain. So using the above domains it would be:
Update-MsolFederatedDomain -DomainName bmcontoso.com -SupportMultipleDomain
Use the following steps to add the new top-level domain using PowerShell
1. On a machine that has Azure Active Directory Module for Windows PowerShell installed on it run the
following: $cred=Get-Credential .
2. Enter the username and password of a global administrator for the Azure AD domain you are federating with
3. In PowerShell, enter Connect-MsolService -Credential $cred
4. In PowerShell, enter New-MsolFederatedDomain –SupportMultipleDomain –DomainName
Use the following steps to add the new top-level domain using Azure AD Connect.
1. Launch Azure AD Connect from the desktop or start menu
2. Choose “Add an additional Azure AD Domain”
3. Enter your Azure AD and Active Directory credentials
4. Select the second domain you wish to configure for federation.
5. Click Install
Verify the new top-level domain
By using the PowerShell command Get-MsolDomainFederationSettings -DomainName <your domain> you can view the
updated IssuerUri. The screenshot below shows the federation settings were updated on the original domain
http://bmcontoso.com/adfs/services/trust
And the IssuerUri on the new domain has been set to https://bmfabrikam.com/adfs/services/trust
Support for subdomains

When you add a subdomain, because of the way Azure AD handled domains, it will inherit the settings of the
parent. So, the IssuerUri, needs to match the parents.
So lets say, for example, that I have bmcontoso.com and then add corp.bmcontoso.com. The IssuerUri for a user
from corp.bmcontoso.com will need to be http://bmcontoso.com/adfs/services/trust . However the standard rule
implemented above for Azure AD, will generate a token with an issuer as
http://corp.bmcontoso.com/adfs/services/trust . which will not match the domain's required value and
authentication will fail.
How To enable support for subdomains
In order to work around this behavior, the AD FS relying party trust for Microsoft Online needs to be updated. To
do this, you must configure a custom claim rule so that it strips off any subdomains from the user’s UPN suffix
when constructing the custom Issuer value.
The following claim will do this:
"http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value,
"^.*@([^.]+\.)*?(?<domain>([^.]+\.?){2})$", "http://${domain}/adfs/services/trust/"));
[!NOTE] The last number in the regular expression set is how many parent domains there are in your root domain.
Here bmcontoso.com is used, so two parent domains are necessary. If three parent domains were to be kept (i.e.:
corp.bmcontoso.com), then the number would have been three. Eventually a range can be indicated, the match will
always be made to match the maximum of domains. "{2,3}" will match two to three domains (i.e.: bmfabrikam.com
and corp.bmcontoso.com).
Use the following steps to add a custom claim to support subdomains.
1. Open AD FS Management
2. Right-click the Microsoft Online RP trust and choose Edit Claim rules
3. Select the third claim rule, and replace
4. Replace the current claim:

".+@(?<domain>.+)","http://${domain}/adfs/services/trust/"));
with

"^.*@([^.]+\.)*?(?<domain>([^.]+\.?){2})$", "http://${domain}/adfs/services/trust/"));
5. Click Ok. Click Apply. Click Ok. Close AD FS Management.
Next steps
Learn more about these features, which were enabled with the installation: Automatic upgrade, Prevent accidental
deletes, and Azure AD Connect Health.
Federate multiple instances of Azure AD with single
instance of AD FS
A single high available AD FS farm can federate multiple forests if they have 2-way trust between them. These
multiple forests may or may not correspond to the same Azure Active Directory. This article provides instructions
on how to configure federation between a single AD FS deployment and more than one forests that sync to
different Azure AD.
NOTE
Device writeback and automatic device join are not supported in this scenario.
NOTE
Azure AD Connect cannot be used to configure federation in this scenario as Azure AD Connect can configure federation for
domains in a single Azure AD.
Steps for federating AD FS with multiple Azure AD

Consider a domain contoso.com in Azure Active Directory contoso.onmicrosoft.com is already federated with the
AD FS on-premises installed in contoso.com on-premises Active Directory environment. Fabrikam.com is a domain
in fabrikam.onmicrosoft.com Azure Active Directory.
Step 1: Establish a two-way trust

For AD FS in contoso.com to be able to authenticate users in fabrikam.com, a two-way trust is needed between
contoso.com and fabrikam.com. Follow the guideline in this article to create the two-way trust.
Step 2: Modify contoso.com federation settings
The default issuer set for a single domain federated to AD FS is "http://ADFSServiceFQDN/adfs/services/trust", for
example, http://fs.contoso.com/adfs/services/trust . Azure Active Directory requires unique issuer for each
federated domain. Since the same AD FS is going to federate two domains, the issuer value needs to be modified
so that it is unique for each domain AD FS federates with Azure Active Directory.
On the AD FS server, open Azure AD PowerShell (ensure that the MSOnline module is installed) and perform the
following steps:
Connect to the Azure Active Directory that contains the domain contoso.com Connect-MsolService Update the
federation settings for contoso.com Update-MsolFederatedDomain -DomainName contoso.com –
SupportMultipleDomain
Issuer in the domain federation setting will be changed to "http://contoso.com/adfs/services/trust" and an issuance
claim rule will be added for the Azure AD Relying Party Trust to issue the correct issuerId value based on the UPN
suffix.
Step 3: Federate fabrikam.com with AD FS

In Azure AD powershell session perform the following steps: Connect to Azure Active Directory that contains the
domain fabrikam.com
Connect-MsolService
Convert the fabrikam.com managed domain to federated:
Convert-MsolDomainToFederated -DomainName fabrikam.com -Verbose -SupportMultipleDomain
The above operation will federate the domain fabrikam.com with the same AD FS. You can verify the domain
settings by using Get-MsolDomainFederationSettings for both domains.
Next steps
Connect Active Directory with Azure Active Directory
Renew federation certificates for Office 365 and
Azure Active Directory
Overview
For successful federation between Azure Active Directory (Azure AD) and Active Directory Federation Services (AD
FS), the certificates used by AD FS to sign security tokens to Azure AD should match what is configured in Azure
AD. Any mismatch can lead to broken trust. Azure AD ensures that this information is kept in sync when you
deploy AD FS and Web Application Proxy (for extranet access).
This article provides you additional information to manage your token signing certificates and keep them in sync
with Azure AD, in the following cases:
You are not deploying the Web Application Proxy, and therefore the federation metadata is not available in the
extranet.
You are not using the default configuration of AD FS for token signing certificates.
You are using a third-party identity provider.
Default configuration of AD FS for token signing certificates

The token signing and token decrypting certificates are usually self-signed certificates, and are good for one year.
By default, AD FS includes an auto-renewal process called AutoCer tificateRollover . If you are using AD FS 2.0 or
later, Office 365 and Azure AD automatically update your certificate before it expires.
Renewal notification from the Microsoft 365 admin center or an email
NOTE
If you received an email or a portal notification asking you to renew your certificate for Office, see Managing changes to
token signing certificates to check if you need to take any action. Microsoft is aware of a possible issue that can lead to
notifications for certificate renewal being sent, even when no action is required.
Azure AD attempts to monitor the federation metadata, and update the token signing certificates as indicated by
this metadata. 30 days before the expiration of the token signing certificates, Azure AD checks if new certificates
are available by polling the federation metadata.
If it can successfully poll the federation metadata and retrieve the new certificates, no email notification or
warning in the Microsoft 365 admin center is issued to the user.
If it cannot retrieve the new token signing certificates, either because the federation metadata is not reachable
or automatic certificate rollover is not enabled, Azure AD issues an email notification and a warning in the
Microsoft 365 admin center.
IMPORTANT
If you are using AD FS, to ensure business continuity, please verify that your servers have the following updates so that
authentication failures for known issues do not occur. This mitigates known AD FS proxy server issues for this renewal and
future renewal periods:
Server 2012 R2 - Windows Server May 2014 rollup
Server 2008 R2 and 2012 - Authentication through proxy fails in Windows Server 2012 or Windows 2008 R2 SP1
Check if the certificates need to be updated

Step 1: Check the AutoCertificateRollover state
On your AD FS server, open PowerShell. Check that the AutoCertificateRollover value is set to True.
Get-Adfsproperties
NOTE
If you are using AD FS 2.0, first run Add-Pssnapin Microsoft.Adfs.Powershell.
Step 2: Confirm that AD FS and Azure AD are in sync

On your AD FS server, open the MSOnline PowerShell prompt, and connect to Azure AD.
NOTE
MSOL-Cmdlets are part of the MSOnline PowerShell module. You can download the MSOnline PowerShell Module directly
from the PowerShell Gallery.
Install-Module MSOnline
Connect to Azure AD using the MSOnline PowerShell-Module.
Import-Module MSOnline
Connect-MsolService
Check the certificates configured in AD FS and Azure AD trust properties for the specified domain.
Get-MsolFederationProperty -DomainName <domain.name> | FL Source, TokenSigningCertificate

If the thumbprints in both the outputs match, your certificates are in sync with Azure AD.
Step 3: Check if your certificate is about to expire
In the output of either Get-MsolFederationProperty or Get-AdfsCertificate, check for the date under "Not After." If
the date is less than 30 days away, you should take action.
F EDERAT IO N
C ERT IF IC AT ES IN M ETA DATA IS
A UTO C ERT IF IC AT ERO SY N C W IT H A Z URE P UB L IC LY
L LO VER AD A C C ESSIB L E VA L IDIT Y A C T IO N
Yes Yes Yes - No action needed.

See Renew token
signing certificate
automatically.
Yes No - Less than 15 days Renew immediately.

See Renew token
signing certificate
manually.
No - - Less than 30 days Renew immediately.

See Renew token
signing certificate
manually.
[-] Does not matter
Renew the token signing certificate automatically (recommended)

You don't need to perform any manual steps if both of the following are true:
You have deployed Web Application Proxy, which can enable access to the federation metadata from the
extranet.
You are using the AD FS default configuration (AutoCertificateRollover is enabled).
Check the following to confirm that the certificate can be automatically updated.
1. The AD FS proper ty AutoCer tificateRollover must be set to True. This indicates that AD FS will
automatically generate new token signing and token decryption certificates, before the old ones expire.
2. The AD FS federation metadata is publicly accessible. Check that your federation metadata is publicly
accessible by navigating to the following URL from a computer on the public internet (off of the corporate
network):
https://(your_FS_name)/federationmetadata/2007-06/federationmetadata.xml
where (your_FS_name) is replaced with the federation service host name your organization uses, such as
fs.contoso.com. If you are able to verify both of these settings successfully, you do not have to do anything else.
Example: https://fs.contoso.com/federationmetadata/2007-06/federationmetadata.xml
Renew the token signing certificate manually

You may choose to renew the token signing certificates manually. For example, the following scenarios might work
better for manual renewal:
Token signing certificates are not self-signed certificates. The most common reason for this is that your
organization manages AD FS certificates enrolled from an organizational certificate authority.
Network security does not allow the federation metadata to be publicly available.
In these scenarios, every time you update the token signing certificates, you must also update your Office 365
domain by using the PowerShell command, Update-MsolFederatedDomain.
Step 1: Ensure that AD FS has new token signing certificates
Non-default configuration
If you are using a non-default configuration of AD FS (where AutoCer tificateRollover is set to False ), you are
probably using custom certificates (not self-signed). For more information about how to renew the AD FS token
signing certificates, see Certificate requirements for ferderated servers.
Federation metadata is not publicly available
On the other hand, if AutoCer tificateRollover is set to True , but your federation metadata is not publicly
accessible, first make sure that new token signing certificates have been generated by AD FS. Confirm you have
new token signing certificates by taking the following steps:
1. Verify that you are logged on to the primary AD FS server.
2. Check the current signing certificates in AD FS by opening a PowerShell command window, and running
the following command:
PS C:>Get-ADFSCertificate –CertificateType token-signing
NOTE
If you are using AD FS 2.0, you should run Add-Pssnapin Microsoft.Adfs.Powershell first.
3. Look at the command output at any certificates listed. If AD FS has generated a new certificate, you should
see two certificates in the output: one for which the IsPrimar y value is True and the NotAfter date is
within 5 days, and one for which IsPrimar y is False and NotAfter is about a year in the future.
4. If you only see one certificate, and the NotAfter date is within 5 days, you need to generate a new
certificate.
5. To generate a new certificate, execute the following command at a PowerShell command prompt:
PS C:\>Update-ADFSCertificate –CertificateType token-signing .
6. Verify the update by running the following command again: PS C:>Get-ADFSCertificate –CertificateType
token-signing
Two certificates should be listed now, one of which has a NotAfter date of approximately one year in the future,
and for which the IsPrimar y value is False .
Step 2: Update the new token signing certificates for the Office 365 trust
Update Office 365 with the new token signing certificates to be used for the trust, as follows.
1. Open the Microsoft Azure Active Directory Module for Windows PowerShell.
2. Run $cred=Get-Credential. When this cmdlet prompts you for credentials, type your cloud service
administrator account credentials.
3. Run Connect-MsolService –Credential $cred. This cmdlet connects you to the cloud service. Creating a context
that connects you to the cloud service is required before running any of the additional cmdlets installed by the
tool.
4. If you are running these commands on a computer that is not the AD FS primary federation server, run Set-
MSOLAdfscontext -Computer <AD FS primary server>, where <AD FS primary server> is the internal FQDN
name of the primary AD FS server. This cmdlet creates a context that connects you to AD FS.
5. Run Update-MSOLFederatedDomain –DomainName <domain>. This cmdlet updates the settings from AD FS
into the cloud service, and configures the trust relationship between the two.
NOTE
If you need to support multiple top-level domains, such as contoso.com and fabrikam.com, you must use the
Suppor tMultipleDomain switch with any cmdlets. For more information, see Support for Multiple Top Level Domains.
Repair Azure AD trust by using Azure AD Connect

If you configured your AD FS farm and Azure AD trust by using Azure AD Connect, you can use Azure AD Connect
to detect if you need to take any action for your token signing certificates. If you need to renew the certificates,
you can use Azure AD Connect to do so.
For more information, see Repairing the trust.
AD FS and Azure AD certificate update steps

Token signing certificates are standard X509 certificates that are used to securely sign all tokens that the
federation server issues. Token decryption certificates are standard X509 certificates that are used to decrypt any
incoming tokens.
By default, AD FS is configured to generate token signing and token decryption certificates automatically, both at
the initial configuration time and when the certificates are approaching their expiration date.
Azure AD tries to retrieve a new certificate from your federation service metadata 30 days before the expiry of the
current certificate. In case a new certificate is not available at that time, Azure AD will continue to monitor the
metadata on regular daily intervals. As soon as the new certificate is available in the metadata, the federation
settings for the domain are updated with the new certificate information. You can use
Get-MsolDomainFederationSettings to verify if you see the new certificate in the NextSigningCertificate /
SigningCertificate.
For more information on Token Signing certificates in AD FS see Obtain and Configure Token Signing and Token
Decryption Certificates for AD FS
Update the TLS/SSL certificate for an Active
Directory Federation Services (AD FS) farm
Overview
This article describes how you can use Azure AD Connect to update the TLS/SSL certificate for an Active Directory
Federation Services (AD FS) farm. You can use the Azure AD Connect tool to easily update the TLS/SSL certificate
for the AD FS farm even if the user sign-in method selected is not AD FS.
You can perform the whole operation of updating TLS/SSL certificate for the AD FS farm across all federation and
Web Application Proxy (WAP) servers in three simple steps:
NOTE
To learn more about certificates that are used by AD FS, see Understanding certificates used by AD FS.
Prerequisites
AD FS Farm : Make sure that your AD FS farm is Windows Server 2012 R2-based or later.
Azure AD Connect : Ensure that the version of Azure AD Connect is 1.1.553.0 or higher. You'll use the task
Update AD FS SSL cer tificate .
Step 1: Provide AD FS farm information
Azure AD Connect attempts to obtain information about the AD FS farm automatically by:
1. Querying the farm information from AD FS (Windows Server 2016 or later).
2. Referencing the information from previous runs, which are stored locally with Azure AD Connect.
You can modify the list of servers that are displayed by adding or removing the servers to reflect the current
configuration of the AD FS farm. As soon as the server information is provided, Azure AD Connect displays the
connectivity and current TLS/SSL certificate status.
If the list contains a server that's no longer part of the AD FS farm, click Remove to delete the server from the list
of servers in your AD FS farm.
NOTE
Removing a server from the list of servers for an AD FS farm in Azure AD Connect is a local operation and updates the
information for the AD FS farm that Azure AD Connect maintains locally. Azure AD Connect doesn't modify the configuration
on AD FS to reflect the change.
Step 2: Provide a new TLS/SSL certificate

After you've confirmed the information about AD FS farm servers, Azure AD Connect asks for the new TLS/SSL
certificate. Provide a password-protected PFX certificate to continue the installation.
After you provide the certificate, Azure AD Connect goes through a series of prerequisites. Verify the certificate to
ensure that the certificate is correct for the AD FS farm:
The subject name/alternate subject name for the certificate is either the same as the federation service name,
or it's a wildcard certificate.
The certificate is valid for more than 30 days.
The certificate trust chain is valid.
The certificate is password protected.
Step 3: Select servers for the update

In the next step, select the servers that need to have the TLS/SSL certificate updated. Servers that are offline can't
be selected for the update.
After you complete the configuration, Azure AD Connect displays the message that indicates the status of the
update and provides an option to verify the AD FS sign-in.
FAQs
What should be the subject name of the cer tificate for the new AD FS TLS/SSL cer tificate?
Azure AD Connect checks if the subject name/alternate subject name of the certificate contains the
federation service name. For example, if your federation service name is fs.contoso.com, the subject
name/alternate subject name must be fs.contoso.com. Wildcard certificates are also accepted.
Why am I asked for credentials again on the WAP ser ver page?
If the credentials you provide for connecting to AD FS servers don't also have the privilege to manage the
WAP servers, then Azure AD Connect asks for credentials that have administrative privilege on the WAP
servers.
The ser ver is shown as offline. What should I do?
Azure AD Connect can't perform any operation if the server is offline. If the server is part of the AD FS farm,
then check the connectivity to the server. After you've resolved the issue, press the refresh icon to update
the status in the wizard. If the server was part of the farm earlier but now no longer exists, click Remove to
delete it from the list of servers that Azure AD Connect maintains. Removing the server from the list in
Azure AD Connect doesn't alter the AD FS configuration itself. If you're using AD FS in Windows Server
2016 or later, the server remains in the configuration settings and will be shown again the next time the
task is run.
Can I update a subset of my farm ser vers with the new TLS/SSL cer tificate?
Yes. You can always run the task Update SSL Cer tificate again to update the remaining servers. On the
Select ser vers for SSL cer tificate update page, you can sort the list of servers on SSL Expir y date to
easily access the servers that aren't updated yet.
I removed the ser ver in the previous run, but it's still being shown as offline and listed on the
AD FS Ser vers page. Why is the offline ser ver still there even after I removed it?
Removing the server from the list in Azure AD Connect doesn't remove it in the AD FS configuration. Azure
AD Connect references AD FS (Windows Server 2016 or higher) for any information about the farm. If the
server is still present in the AD FS configuration, it will be listed back in the list.
Next steps
Active Directory Federation Services management and customization with Azure AD Connect
Manage AD FS trust with Azure AD using Azure AD
Connect
Overview
Azure AD Connect can manage federation between on-premises Active Directory Federation Service (AD FS) and
Azure AD. This article provides an overview of:
The various settings configured on the trust by Azure AD Connect
The issuance transform rules (claim rules) set by Azure AD Connect
How to back-up and restore your claim rules between upgrades and configuration updates.
Settings controlled by Azure AD Connect

Azure AD Connect manages only settings related to Azure AD trust. Azure AD Connect does not modify any
settings on other relying party trusts in AD FS. The following table indicates settings that are controlled by Azure
AD Connect.
Token signing certificate Azure AD Connect can be used to reset and recreate the trust
with Azure AD. Azure AD Connect does a one-time immediate
rollover of token signing certificates for AD FS and updates
the Azure AD domain federation settings.
Token signing algorithm Microsoft recommends using SHA-256 as the token signing
algorithm. Azure AD Connect can detect if the token signing
algorithm is set to a value less secure than SHA-256. It will
update the setting to SHA-256 in the next possible
configuration operation. Other relying party trust must be
updated to use the new token signing certificate.
Azure AD trust identifier Azure AD Connect sets the correct identifier value for the
Azure AD trust. AD FS uniquely identifies the Azure AD trust
using the identifier value.
Azure AD endpoints Azure AD Connect makes sure that the endpoints configured
for the Azure AD trust are always as per the latest
recommended values for resiliency and performance.
Issuance transform rules There are numbers of claim rules which are needed for optimal
performance of features of Azure AD in a federated setting.
Azure AD Connect makes sure that the Azure AD trust is
always configured with the right set of recommended claim
rules.
Alternate-id If sync is configured to use alternate-id, Azure AD Connect

configures AD FS to perform authentication using alternate-id.
Automatic metadata update Trust with Azure AD is configured for automatic metadata
update. AD FS periodically checks the metadata of Azure AD
trust and keeps it up-to-date in case it changes on the Azure
AD side.
Integrated Windows Authentication (IWA) During Hybrid Azure AD join operation, IWA is enabled for
device registration to facilitate Hybrid Azure AD join for
downlevel devices
Execution flows and federation settings configured by Azure AD

Connect
Azure AD connect does not update all settings for Azure AD trust during configuration flows. The settings modified
depend on which task or execution flow is being executed. The following table lists the settings impacted in
different execution flows.
EXEC UT IO N F LO W SET T IN GS IM PA C T ED
First pass installation (express) None
First pass installation (new AD FS farm) A new AD FS farm is created and a trust with Azure AD is
created from scratch.
First pass installation (existing AD FS farm, existing Azure AD Azure AD trust identifier, Issuance transform rules, Azure AD
trust) endpoints, Alternate-id (if necessary), automatic metadata
update
Reset Azure AD trust Token signing certificate, Token signing algorithm, Azure AD
trust identifier, Issuance transform rules, Azure AD endpoints,
Alternate-id (if necessary), automatic metadata update
Add federation server None
Add WAP server None
Device options Issuance transform rules, IWA for device registration
Add federated domain If the domain is being added for the first time, that is, the
setup is changing from single domain federation to multi-
domain federation – Azure AD Connect will recreate the trust
from scratch. If the trust with Azure AD is already configured
for multiple domains, only Issuance transform rules are
modified
Update TLS None
During all operations, in which, any setting is modified, Azure AD Connect makes a backup of the current trust
settings at %ProgramData%\AADConnect\ADFS
NOTE
Prior to version 1.1.873.0, the backup consisted of only issuance transform rules and they were backed up in the wizard trace
log file.
Issuance transform rules set by Azure AD Connect

Azure AD Connect makes sure that the Azure AD trust is always configured with the right set of recommended
claim rules. Microsoft recommends using Azure AD connect for managing your Azure AD trust. This section lists the
issuance transform rules set and their description.
RUL E N A M E DESC RIP T IO N
Issue UPN This rule queries the value of userprincipalname as from the
attribute configured in sync settings for userprincipalname.
Query objectguid and msdsconsistencyguid for custom This rule adds a temporary value in the pipeline for objectguid
ImmutableId claim and msdsconsistencyguid value if it exists
Check for the existence of msdsconsistencyguid Based on whether the value for msdsconsistencyguid exists or
not, we set a temporary flag to direct what to use as
ImmutableId
Issue msdsconsistencyguid as Immutable ID if it exists Issue msdsconsistencyguid as ImmutableId if the value exists
Issue objectGuidRule if msdsConsistencyGuid rule does not If the value for msdsconsistencyguid does not exist, the value
exist of objectguid will be issued as ImmutableId
Issue nameidentifier This rule issues value for the nameidentifier claim.
RUL E N A M E DESC RIP T IO N
Issue accounttype for domain-joined computers If the entity being authenticated is a domain joined device, this
rule issues the account type as DJ signifying a domain joined
device
Issue AccountType with the value USER when it is not a If the entity being authenticated is a user, this rule issues the
computer account account type as User
Issue issuerid when it is not a computer account This rule issues the issuerId value when the authenticating
entity is not a device. The value is created via a regex, which is
configured by Azure AD Connect. The regex is created after
taking into consideration all the domains federated using
Azure AD Connect.
Issue issuerid for DJ computer auth This rule issues the issuerId value when the authenticating
entity is a device
Issue onpremobjectguid for domain-joined computers If the entity being authenticated is a domain joined device, this
rule issues the on-premises objectguid for the device
Pass through primary SID This rule issues the primary SID of the authenticating entity
Pass through claim - insideCorporateNetwork This rule issues a claim that helps Azure AD know if the
authentication is coming from inside corporate network or
externally
Pass Through Claim – Psso
Issue Password Expiry Claims This rule issues three claims for password expiration time,
number of days for the password to expire of the entity being
authenticated and URL where to route for changing the
password.
Pass through claim – authnmethodsreferences The value in the claim issued under this rule indicates what
type of authentication was performed for the entity
Pass through claim - multifactorauthenticationinstant The value of this claim specifies the time, in UTC, when the
user last performed multiple factor authentication.
Pass through claim - AlternateLoginID This rule issues the AlternateLoginID claim if the
authentication was performed using alternate login ID.
NOTE
The claim rules for Issue UPN and ImmutableId will differ if you use non-default choice during Azure AD Connect
configuration
Restore issuance transform rules

Azure AD Connect version 1.1.873.0 or later makes a backup of the Azure AD trust settings whenever an update is
made to the Azure AD trust settings. The Azure AD trust settings are backed up at
%ProgramData%\AADConnect\ADFS . The file name is in the following format AadTrust-<date>-<time>.txt, for
example - AadTrust-20180710-150216.txt
You can restore the issuance transform rules using the suggested steps below
1. Open the AD FS management UI in Server Manager
2. Open the Azure AD trust properties by going AD FS > Relying Par ty Trusts > Microsoft Office 365
Identity Platform > Edit Claims Issuance Policy
3. Click on Add rule
4. In the claim rule template, select Send Claims Using a Custom Rule and click Next
5. Copy the name of the claim rule from backup file and paste it in the field Claim rule name
6. Copy the claim rule from backup file into the text field for Custom rule and click Finish
NOTE
Make sure that your additional rules do not conflict with the rules configured by Azure AD Connect.
Next steps
Manage and customize Active Directory Federation Services using Azure AD Connect
Configure group claims for applications with Azure
Active Directory
Azure Active Directory can provide a users group membership information in tokens for use within applications.
Two main patterns are supported:
Groups identified by their Azure Active Directory object identifier (OID) attribute
Groups identified by sAMAccountName or GroupSID attributes for Active Directory (AD) synchronized groups
and users
IMPORTANT
There are a number of caveats to note for this functionality:
Support for use of sAMAccountName and security identifier (SID) attributes synced from on-premises is designed to
enable moving existing applications from AD FS and other identity providers. Groups managed in Azure AD do not
contain the attributes necessary to emit these claims.
In larger organizations the number of groups a user is a member of may exceed the limit that Azure Active Directory will
add to a token. 150 groups for a SAML token, and 200 for a JWT. This can lead to unpredictable results. If your users have
large numbers of group memberships, we recommend using the option to restrict the groups emitted in claims to the
relevant groups for the application.
For new application development, or in cases where the application can be configured for it, and where nested group
support isn't required, we recommend that in-app authorization is based on application roles rather than groups. This
limits the amount of information that needs to go into the token, is more secure, and separates user assignment from app
configuration.
Group claims for applications migrating from AD FS and other identity

providers
Many applications configured to authenticate with AD FS rely on group membership information in the form of
Windows AD group attributes. These attributes are the group sAMAccountName, which may be qualified by-
domain name, or the Windows Group Security Identifier (GroupSID). When the application is federated with AD FS,
AD FS uses the TokenGroups function to retrieve the group memberships for the user.
An app that has been moved from AD FS needs claims in the same format. Group and role claims may be emitted
from Azure Active Directory containing the domain qualified sAMAccountName or the GroupSID synced from
Active Directory rather than the group's Azure Active Directory objectID.
The supported formats for group claims are:
Azure Active Director y Group ObjectId (Available for all groups)
sAMAccountName (Available for groups synchronized from Active Directory)
NetbiosDomain\sAMAccountName (Available for groups synchronized from Active Directory)
DNSDomainName\sAMAccountName (Available for groups synchronized from Active Directory)
On Premises Group Security Identifier (Available for groups synchronized from Active Directory)
NOTE
sAMAccountName and On Premises Group SID attributes are only available on Group objects synced from Active Directory.
They aren't available on groups created in Azure Active Directory or Office365. Applications configured in Azure Active
Directory to get synced on-premises group attributes get them for synced groups only.
Options for applications to consume group information

Applications can call the MS Graph groups endpoint to obtain group information for the authenticated user. This
call ensures that all the groups a user is a member of are available even when there are a large number of groups
involved. Group enumeration is then independent of token size limitations.
However, if an existing application expects to consume group information via claims, Azure Active Directory can be
configured with a number of different claims formats. Consider the following options:
When using group membership for in-application authorization purposes it is preferable to use the Group
ObjectID. The Group ObjectID is immutable and unique in Azure Active Directory and available for all groups.
If using the on-premises group sAMAccountName for authorization, use domain qualified names; there’s less
chance of names clashing. sAMAccountName may be unique within an Active Directory domain, but if more
than one Active Directory domain is synchronized with an Azure Active Directory tenant there is a possibility for
more than one group to have the same name.
Consider using Application Roles to provide a layer of indirection between the group membership and the
application. The application then makes internal authorization decisions based on role clams in the token.
If the application is configured to get group attributes that are synced from Active Directory and a Group doesn't
contain those attributes, it won't be included in the claims.
Group claims in tokens include nested groups except when using the option to restrict the group claims to
groups assigned to the application. If a user is a member of GroupB and GroupB is a member of GroupA, then
the group claims for the user will contain both GroupA and GroupB. When an organization's users have large
numbers of group memberships, the number of groups listed in the token can grow the token size. Azure Active
Directory limits the number of groups it will emit in a token to 150 for SAML assertions, and 200 for JWT. If a
user is a member of a larger number of groups, the groups are omitted and a link to the Graph endpoint to
obtain group information is included instead.
Prerequisites for using Group attributes synchronized from Active

Directory
Group membership claims can be emitted in tokens for any group if you use the ObjectId format. To use group
claims in formats other than the group ObjectId, the groups must be synchronized from Active Directory using
Azure AD Connect.
There are two steps to configuring Azure Active Directory to emit group names for Active Directory Groups.
1. Synchronize group names from Active Director y Before Azure Active Directory can emit the group
names or on premises group SID in group or role claims, the required attributes need to be synchronized
from Active Directory. You must be running Azure AD Connect version 1.2.70 or later. Earlier versions of
Azure AD Connect than 1.2.70 will synchronize the group objects from Active Directory, but will not include
the required group name attributes. Upgrade to the current version.
2. Configure the application registration in Azure Active Director y to include group claims in
tokens Group claims can be configured in the Enterprise Applications section of the portal, or using the
Application Manifest in the Application Registrations section. To configure group claims in the application
manifest see “Configuring the Azure Active Directory Application Registration for group attributes” below.
Add group claims to tokens for SAML applications using SSO
configuration
To configure Group Claims for a Gallery or Non-Gallery SAML application, open Enterprise Applications , click on
the application in the list, select Single Sign On configuration , and then select User Attributes & Claims .
Click on Add a group claim
Use the radio buttons to select which groups should be included in the token
SEL EC T IO N DESC RIP T IO N
All groups Emits security groups and distribution lists and roles.
Security groups Emits security groups the user is a member of in the groups
claim
Director y roles If the user is assigned directory roles, they are emitted as a
'wids' claim (groups claim won't be emitted)
Groups assigned to the application Emits only the groups that are explicitly assigned to the
application and the user is a member of
For example, to emit all the Security Groups the user is a member of, select Security Groups
To emit groups using Active Directory attributes synced from Active Directory instead of Azure AD objectIDs select
the required format from the drop-down. Only groups synchronized from Active Directory will be included in the
claims.
To emit only groups assigned to the application, select Groups Assigned to the application
Groups assigned to the application will be included in the token. Other groups the user is a member of will be
omitted. With this option nested groups are not included and the user must be a direct member of the group
assigned to the application.
To change the groups assigned to the application, select the application from the Enterprise Applications list and
then click Users and Groups from the application’s left-hand navigation menu.
See the document Assign a user or group to an enterprise app for details of managing group assignment to
applications.
Advanced options
The way group claims are emitted can be modified by the settings under Advanced options
Customize the name of the group claim: If selected, a different claim type can be specified for group claims. Enter
the claim type in the Name field and the optional namespace for the claim in the namespace field.
Some applications require the group membership information to appear in the 'role' claim. You can optionally emit
the user's groups as roles by checking the 'Emit groups a role claims' box.
NOTE
If the option to emit group data as roles is used, only groups will appear in the role claim. Any Application Roles the user is
assigned will not appear in the role claim.
Edit the group claims configuration

Once a group claim configuration has been added to the User Attributes & Claims configuration, the option to add
a group claim will be greyed out. To change the group claim configuration click on the group claim in the
Additional claims list.
Configure the Azure AD Application Registration for group attributes

Group claims can also be configured in the Optional Claims section of the Application Manifest.
1. In the portal ->Azure Active Directory -> Application Registrations->Select Application->Manifest
2. Enable group membership claims by changing the groupMembershipClaim
Valid values are:
"All" Emits security groups, distribution lists and roles
"SecurityGroup" Emits security groups the user is a member of in the groups

claim
"Director yRole If the user is assigned directory roles, they are emitted as a
'wids' claim (groups claim won't be emitted)
"ApplicationGroup Emits only the groups that are explicitly assigned to the
application and the user is a member of
For example:
"groupMembershipClaims": "SecurityGroup"
By default Group ObjectIDs will be emitted in the group claim value. To modify the claim value to contain on
premises group attributes, or to change the claim type to role, use OptionalClaims configuration as follows:
3. Set group name configuration optional claims.
If you want the groups in the token to contain the on premises AD group attributes, specify which token type
optional claim should be applied to in the optional claims section. Multiple token types can be listed:
idToken for the OIDC ID token
accessToken for the OAuth/OIDC access token
Saml2Token for SAML tokens.
NOTE
The Saml2Token type applies to both SAML1.1 and SAML2.0 format tokens
For each relevant token type, modify the groups claim to use the OptionalClaims section in the manifest. The
OptionalClaims schema is as follows:
{
"name": "groups",
"source": null,
"essential": false,
"additionalProperties": []
}
O P T IO N A L C L A IM S SC H EM A VA L UE
name: Must be "groups"
source: Not used. Omit or specify null
essential: Not used. Omit or specify false

O P T IO N A L C L A IM S SC H EM A VA L UE
additionalProper ties: List of additional properties. Valid options are

"sam_account_name",
“dns_domain_and_sam_account_name”,
“netbios_domain_and_sam_account_name”, "emit_as_roles"
In additionalProperties only one of "sam_account_name", “dns_domain_and_sam_account_name”,

“netbios_domain_and_sam_account_name” are required. If more than one is present, the first is used and
any others ignored.
Some applications require group information about the user in the role claim. To change the claim type to
from a group claim to a role claim, add “emit_as_roles” to additional properties. The group values will be
emitted in the role claim.
NOTE
If "emit_as_roles" is used any Application Roles configured that the user is assigned will not appear in the role claim
Examples
Emit groups as group names in OAuth access tokens in dnsDomainName\SAMAccountName format
"optionalClaims": {
"accessToken": [{
"name": "groups",
"additionalProperties": ["dns_domain_and_sam_account_name"]
}]
}
To emit group names to be returned in netbiosDomain\samAccountName format as the roles claim in SAML and
OIDC ID Tokens:
"optionalClaims": {
"saml2Token": [{
"name": "groups",
"additionalProperties": ["netbios_name_and_sam_account_name", "emit_as_roles"]
}],
"idToken": [{
"name": "groups",
"additionalProperties": ["netbios_name_and_sam_account_name", "emit_as_roles"]
}]
}
Next steps
Add authorization using groups & groups claims to an ASP.NET Core web app (Code sample)
Assign a user or group to an enterprise app
Configure role claims
Change signature hash algorithm for Office 365
relying party trust
Overview
Active Directory Federation Services (AD FS) signs its tokens to Microsoft Azure Active Directory to ensure that
they cannot be tampered with. This signature can be based on SHA1 or SHA256. Azure Active Directory now
supports tokens signed with an SHA256 algorithm, and we recommend setting the token-signing algorithm to
SHA256 for the highest level of security. This article describes the steps needed to set the token-signing algorithm
to the more secure SHA256 level.
NOTE
Microsoft recommends usage of SHA256 as the algorithm for signing tokens as it is more secure than SHA1 but SHA1 still
remains a supported option.
Change the token-signing algorithm

After you have set the signature algorithm with one of the two processes below, AD FS signs the tokens for Office
365 relying party trust with SHA256. You don't need to make any extra configuration changes, and this change has
no impact on your ability to access Office 365 or other Azure AD applications.
AD FS management console
1. Open the AD FS management console on the primary AD FS server.
2. Expand the AD FS node and click Relying Par ty Trusts .
3. Right-click your Office 365/Azure relying party trust and select Proper ties .
4. Select the Advanced tab and select the secure hash algorithm SHA256.
5. Click OK .
AD FS PowerShell cmdlets
1. On any AD FS server, open PowerShell under administrator privileges.
2. Set the secure hash algorithm by using the Set-AdfsRelyingPar tyTrust cmdlet.
Set-AdfsRelyingPartyTrust -TargetName 'Microsoft Office 365 Identity Platform' -SignatureAlgorithm
'https://www.w3.org/2001/04/xmldsig-more#rsa-sha256'
Also read
Repair Office 365 trust with Azure AD Connect
Use a SAML 2.0 Identity Provider (IdP) for Single Sign
On
This document contains information on using a SAML 2.0 compliant SP-Lite profile-based Identity Provider as the
preferred Security Token Service (STS) / identity provider. This scenario is useful when you already have a user
directory and password store on-premises that can be accessed using SAML 2.0. This existing user directory can be
used for sign-on to Office 365 and other Azure AD-secured resources. The SAML 2.0 SP-Lite profile is based on the
widely used Security Assertion Markup Language (SAML) federated identity standard to provide a sign-on and
attribute exchange framework.
NOTE
For a list of 3rd party Idps that have been tested for use with Azure AD see the Azure AD federation compatibility list
Microsoft supports this sign-on experience as the integration of a Microsoft cloud service, such as Office 365, with
your properly configured SAML 2.0 profile-based IdP. SAML 2.0 identity providers are third-party products and
therefore Microsoft does not provide support for the deployment, configuration, troubleshooting best practices
regarding them. Once properly configured, the integration with the SAML 2.0 identity provider can be tested for
proper configuration by using the Microsoft Connectivity Analyzer Tool, which is described in more detail below.
For more information about your SAML 2.0 SP-Lite profile-based identity provider, ask the organization that
supplied it.
IMPORTANT
Only a limited set of clients are available in this sign-on scenario with SAML 2.0 identity providers, this includes:
Web-based clients such as Outlook Web Access and SharePoint Online
Email-rich clients that use basic authentication and a supported Exchange access method such as IMAP, POP, Active Sync,
MAPI, etc. (the Enhanced Client Protocol end point is required to be deployed), including:
Microsoft Outlook 2010/Outlook 2013/Outlook 2016, Apple iPhone (various iOS versions)
Various Google Android Devices
Windows Phone 7, Windows Phone 7.8, and Windows Phone 8.0
Windows 8 Mail Client and Windows 8.1 Mail Client
Windows 10 Mail Client
All other clients are not available in this sign-on scenario with your SAML 2.0 Identity Provider. For example, the
Lync 2010 desktop client is not able to sign in to the service with your SAML 2.0 Identity Provider configured for
single sign-on.
Azure AD SAML 2.0 protocol requirements

This document contains detailed requirements on the protocol and message formatting that your SAML 2.0 identity
provider must implement to federate with Azure AD to enable sign-on to one or more Microsoft cloud services
(such as Office 365). The SAML 2.0 relying party (SP-STS) for a Microsoft cloud service used in this scenario is
Azure AD.
It is recommended that you ensure your SAML 2.0 identity provider output messages be as similar to the provided
sample traces as possible. Also, use specific attribute values from the supplied Azure AD metadata where possible.
Once you are happy with your output messages, you can test with the Microsoft Connectivity Analyzer as described
below.
The Azure AD metadata can be downloaded from this URL: https://nexus.microsoftonline-
p.com/federationmetadata/saml20/federationmetadata.xml. For customers in China using the China-specific
instance of Office 365, the following federation endpoint should be used: https://nexus.partner.microsoftonline-
p.cn/federationmetadata/saml20/federationmetadata.xml.
SAML protocol requirements

This section details how the request and response message pairs are put together in order to help you to format
your messages correctly.
Azure AD can be configured to work with identity providers that use the SAML 2.0 SP Lite profile with some specific
requirements as listed below. Using the sample SAML request and response messages along with automated and
manual testing, you can work to achieve interoperability with Azure AD.
Signature block requirements

Within the SAML Response message, the Signature node contains information about the digital signature for the
message itself. The signature block has the following requirements:
1. The assertion node itself must be signed
2. The RSA-sha1 algorithm must be used as the DigestMethod. Other digital signature algorithms are not
accepted. <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/>
3. You may also sign the XML document.
4. The Transform Algorithm must match the values in the following sample:
<ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform
Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#"/>
5. The SignatureMethod Algorithm must match the following sample:
<ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
Supported bindings
Bindings are the transport-related communications parameters that are required. The following requirements apply
to the bindings
1. HTTPS is the required transport.
2. Azure AD will require HTTP POST for token submission during sign-in.
3. Azure AD will use HTTP POST for the authentication request to the identity provider and REDIRECT for the sign
out message to the identity provider.
Required attributes
This table shows requirements for specific attributes in the SAML 2.0 message.
AT T RIB UT E DESC RIP T IO N
NameID The value of this assertion must be the same as the Azure AD
user’s ImmutableID. It can be up to 64 alpha numeric
characters. Any non-html safe characters must be encoded, for
example a “+” character is shown as “.2B”.
AT T RIB UT E DESC RIP T IO N
IDPEmail The User Principal Name (UPN) is listed in the SAML response
as an element with the name IDPEmail The user’s
UserPrincipalName (UPN) in Azure AD/Office 365. The UPN is
in email address format. UPN value in Windows Office 365
(Azure Active Directory).
Issuer Required to be a URI of the identity provider. Do not reuse the

Issuer from the sample messages. If you have multiple top-
level domains in your Azure AD tenants the Issuer must match
the specified URI setting configured per domain.
IMPORTANT
Azure AD currently supports the following NameID Format URI for SAML 2.0:urn:oasis:names:tc:SAML:2.0:nameid-
format:persistent.
Sample SAML request and response messages

A request and response message pair is shown for the sign-on message exchange. The following is a sample
request message that is sent from Azure AD to a sample SAML 2.0 identity provider. The sample SAML 2.0 identity
provider is Active Directory Federation Services (AD FS) configured to use SAML-P protocol. Interoperability testing
has also been completed with other SAML 2.0 identity providers.
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_7171b0b2-19f2-4ba2-8f94-24b5e56b7f1e"
IssueInstant="2014-01-30T16:18:35Z"
Version="2.0"
AssertionConsumerServiceIndex="0" >
<saml:Issuer>urn:federation:MicrosoftOnline</saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
</samlp:AuthnRequest>
The following is a sample response message that is sent from the sample SAML 2.0 compliant identity provider to
Azure AD / Office 365.
<samlp:Response ID="_592c022f-e85e-4d23-b55b-9141c95cd2a5" Version="2.0" IssueInstant="2014-01-

31T15:36:31.357Z" Destination="https://login.microsoftonline.com/login.srf"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://WS2012R2-
0.contoso.com/adfs/services/trust</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="_7e3c1bcd-f180-4f78-83e1-7680920793aa" IssueInstant="2014-01-31T15:36:31.279Z" Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
<ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa">
<ds:Transforms>
<ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
</ds:Transforms>
<ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>CBn/5YqbheaJP425c0pHva9PhNY=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>TciWMyHW2ZODrh/2xrvp5ggmcHBFEd9vrp6DYXp+hZWJzmXMmzwmwS8KNRJKy8H7XqBsdELA1Msqi8I3TmWdnoIRfM/Z
AyUppo8suMu6Zw+boE32hoQRnX9EWN/f0vH6zA/YKTzrjca6JQ8gAV1ErwvRWDpyMcwdYCiWALv9ScbkAcebOE1s1JctZ5RBXggdZWrYi72X+I4
i6WgyZcIGai/rZ4v2otoWAEHS0y1yh1qT7NDPpl/McDaTGkNU6C+8VfjD78DrUXEcAfKvPgKlKrOMZnD1lCGsViimGY+LSuIdY45MLmyaa5UT4K
Wph6dA==</ds:SignatureValue>
<KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIC7jCCAdagAwIBAgIQRrjsbFPaXIlOG3GTv50fkjANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhBREZTIFNpZ25
pbmcgLSBXUzIwMTJSMi0wLnN3aW5mb3JtZXIuY29tMB4XDTE0MDEyMDE1MTY0MFoXDTE1MDEyMDE1MTY0MFowMzExMC8GA1UEAxMoQURGUyBTaW
duaW5nIC0gV1MyMDEyUjItMC5zd2luZm9ybWVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKe+rLVmXy1QwCwZwqgbbp1/+
3ZWxd9T/jV0hpLIIWr+LCOHqq8n8beJvlivgLmDJo8f+EITnAxWcsJUvVai/35AhHCUq9tc9sqMp5PWtabAEMb2AU72/QlX/72D2/NbGQq1BWYb
qUpgpCZ2nSgvlWDHlCiUo//UGsvfox01kjTFlmqQInsJVfRxF5AcCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAi8c6C4zaTEc7aQiUgvnGQgCbMZ
bhUXXLGRpjvFLKaQzkwa9eq7WLJibcSNyGXBa/SfT5wJgsm3TPKgSehGAOTirhcqHheZyvBObAScY7GOT+u9pVYp6raFrc7ez3c+CGHeV/tNvy1
hJNs12FYH4X+ZCNFIT9tprieR25NCdi5SWUbPZL0tVzJsHc1y92b2M2FxqRDohxQgJvyJOpcg2mSBzZZIkvDg7gfPSUXHVS1MQs0RHSbwq/XdQo
cUUhl9/e/YWCbNNxlM84BxFsBUok1dH/gzBySx+Fc8zYi7cOq9yaBT3RLT6cGmFGVYZJW4FyhPZOCLVNsLlnPQcX3dDg9A==
</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEG1234567890</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" NotOnOrAfter="2014-01-
31T15:41:31.357Z" Recipient="https://login.microsoftonline.com/login.srf" />
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2014-01-31T15:36:31.263Z" NotOnOrAfter="2014-01-31T16:36:31.263Z">
<AudienceRestriction>
<Audience>urn:federation:MicrosoftOnline</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="IDPEmail">
<AttributeValue>administrator@contoso.com</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2014-01-31T15:36:30.200Z" SessionIndex="_7e3c1bcd-f180-4f78-83e1-
7680920793aa">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
Configure your SAML 2.0 compliant identity provider

This section contains guidelines on how to configure your SAML 2.0 identity provider to federate with Azure AD to
enable single sign-on access to one or more Microsoft cloud services (such as Office 365) using the SAML 2.0
protocol. The SAML 2.0 relying party for a Microsoft cloud service used in this scenario is Azure AD.
Add Azure AD metadata

Your SAML 2.0 identity provider needs to adhere to information about the Azure AD relying party. Azure AD
publishes metadata at https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.
It is recommended that you always import the latest Azure AD metadata when configuring your SAML 2.0 identity
provider.
NOTE
Azure AD does not read metadata from the identity provider.
Add Azure AD as a relying party

You must enable communication between your SAML 2.0 identity provider and Azure AD. This configuration will be
dependent on your specific identity provider and you should refer to documentation for it. You would typically set
the relying party ID to the same as the entityID from the Azure AD metadata.
NOTE
Verify the clock on your SAML 2.0 identity provider server is synchronized to an accurate time source. An inaccurate clock
time can cause federated logins to fail.
Install Windows PowerShell for sign-on with SAML 2.0 identity provider
After you have configured your SAML 2.0 identity provider for use with Azure AD sign-on, the next step is to
download and install the Azure Active Directory Module for Windows PowerShell. Once installed, you will use these
cmdlets to configure your Azure AD domains as federated domains.
The Azure Active Directory Module for Windows PowerShell is a download for managing your organizations data
in Azure AD. This module installs a set of cmdlets to Windows PowerShell; you run those cmdlets to set up single
sign-on access to Azure AD and in turn to all of the cloud services you are subscribed to. For instructions about
how to download and install the cmdlets, see /previous-versions/azure/jj151815(v=azure.100)
Set up a trust between your SAML identity provider and Azure AD

Before configuring federation on an Azure AD domain, it must have a custom domain configured. You cannot
federate the default domain that is provided by Microsoft. The default domain from Microsoft ends with
“onmicrosoft.com”. You will run a series of cmdlets in the Windows PowerShell command-line interface to add or
convert domains for single sign-on.
Each Azure Active Directory domain that you want to federate using your SAML 2.0 identity provider must either be
added as a single sign-on domain or converted to be a single sign-on domain from a standard domain. Adding or
converting a domain sets up a trust between your SAML 2.0 identity provider and Azure AD.
The following procedure walks you through converting an existing standard domain to a federated domain using
SAML 2.0 SP-Lite.
NOTE
Your domain may experience an outage that impacts users up to 2 hours after you take this step.
Configuring a domain in your Azure AD Directory for federation

1. Connect to your Azure AD Directory as a tenant administrator:
Connect-MsolService
2. Configure your desired Office 365 domain to use federation with SAML 2.0:
$dom = "contoso.com"
$BrandName - "Sample SAML 2.0 IDP"
$LogOnUrl = "https://WS2012R2-0.contoso.com/passiveLogon"
$LogOffUrl = "https://WS2012R2-0.contoso.com/passiveLogOff"
$ecpUrl = "https://WS2012R2-0.contoso.com/PAOS"
$MyURI = "urn:uri:MySamlp2IDP"
$MySigningCert = "MIIC7jCCAdagAwIBAgIQRrjsbFPaXIlOG3GTv50fkjANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyh
BREZTIFNpZ25pbmcgLSBXUzIwMTJSMi0wLnN3aW5mb3JtZXIuY29tMB4XDTE0MDEyMDE1MTY0MFoXDT
E1MDEyMDE1MTY0MFowMzExMC8GA1UEAxMoQURGUyBTaWduaW5nIC0gV1MyMDEyUjItMC5zd2luZm9yb
WVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKe+rLVmXy1QwCwZwqgbbp1/kupQ
VcjKuKLitVDbssFyqbDTjP7WRjlVMWAHBI3kgNT7oE362Gf2WMJFf1b0HcrsgLin7daRXpq4Qi6OA57
sW1YFMj3sqyuTP0eZV3S4+ZbDVob6amsZIdIwxaLP9Zfywg2bLsGnVldB0+XKedZwDbCLCVg+3ZWxd9
T/jV0hpLIIWr+LCOHqq8n8beJvlivgLmDJo8f+EITnAxWcsJUvVai/35AhHCUq9tc9sqMp5PWtabAEM
b2AU72/QlX/72D2/NbGQq1BWYbqUpgpCZ2nSgvlWDHlCiUo//UGsvfox01kjTFlmqQInsJVfRxF5AcC
AwEAATANBgkqhkiG9w0BAQsFAAOCAQEAi8c6C4zaTEc7aQiUgvnGQgCbMZbhUXXLGRpjvFLKaQzkwa9
eq7WLJibcSNyGXBa/SfT5wJgsm3TPKgSehGAOTirhcqHheZyvBObAScY7GOT+u9pVYp6raFrc7ez3c+
CGHeV/tNvy1hJNs12FYH4X+ZCNFIT9tprieR25NCdi5SWUbPZL0tVzJsHc1y92b2M2FxqRDohxQgJvy
JOpcg2mSBzZZIkvDg7gfPSUXHVS1MQs0RHSbwq/XdQocUUhl9/e/YWCbNNxlM84BxFsBUok1dH/gzBy
Sx+Fc8zYi7cOq9yaBT3RLT6cGmFGVYZJW4FyhPZOCLVNsLlnPQcX3dDg9A=="
$uri = "http://WS2012R2-0.contoso.com/adfs/services/trust"
$Protocol = "SAMLP"
Set-MsolDomainAuthentication `
-DomainName $dom `
-FederationBrandName $BrandName `
-Authentication Federated `
-PassiveLogOnUri $LogOnUrl `
-ActiveLogOnUri $ecpUrl `
-SigningCertificate $MySigningCert `
-IssuerUri $MyURI `
-LogOffUri $LogOffUrl `
-PreferredAuthenticationProtocol $Protocol
3. You can obtain the signing certificate base64 encoded string from your IDP metadata file. An example of this
location has been provided but may differ slightly based on your implementation.
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>
MIIC5jCCAc6gAwIBAgIQLnaxUPzay6ZJsC8HVv/QfTANBgkqhkiG9w0BAQsFADAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBmcy50
ZWNobGFiY2VudHJhbC5vcmcwHhcNMTMxMTA0MTgxMzMyWhcNMTQxMTA0MTgxMzMyWjAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBm
cy50ZWNobGFiY2VudHJhbC5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwMdVLTr5YTSRp+ccbSpuuFeXMfABD9mVC
i2wtkRwC30TIyPdORz642MkurdxdPCWjwgJ0HW6TvXwcO9afH3OC5V//wEGDoNcI8PV4enCzTYFe/h//w51uqyv48Fbb3lEXs+aVl815
5OAj2sO9IX64OJWKey82GQWK3g7LfhWWpp17j5bKpSd9DBH5pvrV+Q1ESU3mx71TEOvikHGCZYitEPywNeVMLRKrevdWI3FAhFjcCSO6
nWDiMqCqiTDYOURXIcHVYTSof1YotkJ4tG6mP5Kpjzd4VQvnR7Pjb47nhIYG6iZ3mR1F85Ns9+hBWukQWNN2hcD/uGdPXhpdMVpBAgMB
AAEwDQYJKoZIhvcNAQELBQADggEBAK7h7jF7wPzhZ1dPl4e+XMAr8I7TNbhgEU3+oxKyW/IioQbvZVw1mYVCbGq9Rsw4KE06eSMybqHl
n3w5EeBbLS0MEkApqHY+p68iRpguqa+W7UHKXXQVgPMCpqxMFKonX6VlSQOR64FgpBme2uG+LJ8reTgypEKspQIN0WvtPWmiq4zAwBp0
8hAacgv868c0MM4WbOYU0rzMIR6Q+ceGVRImlCwZ5b7XKp4mJZ9hlaRjeuyVrDuzBkzROSurX1OXoci08yJvhbtiBJLf3uPOJHrhjKRw
It2TnzS9ElgFZlJiDIA26Athe73n43CT0af2IG6yC7e6sK4L3NEXJrwwUZk=</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
</IDPSSODescriptor>
For more information about “Set-MsolDomainAuthentication”, see: /previous-

versions/azure/dn194112(v=azure.100).
NOTE
You must use $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" only if you set up an ECP extension for your identity
provider. Exchange Online clients, excluding Outlook Web Application (OWA), rely on a POST based active end point. If your
SAML 2.0 STS implements an active end point similar to Shibboleth’s ECP implementation of an active end point it may be
possible for these rich clients to interact with the Exchange Online service.
Once federation has been configured you can switch back to “non-federated” (or “managed”), however this change
takes up to two hours to complete and it requires assigning new random passwords for cloud-based sign-in to
each user. Switching back to “managed” may be required in some scenarios to reset an error in your settings. For
more information on Domain conversion see: /previous-versions/azure/dn194122(v=azure.100).
Provision user principals to Azure AD / Office 365

Before you can authenticate your users to Office 365, you must provision Azure AD with user principals that
correspond to the assertion in the SAML 2.0 claim. If these user principals are not known to Azure AD in advance,
then they cannot be used for federated sign-in. Either Azure AD Connect or Windows PowerShell can be used to
provision user principals.
Azure AD Connect can be used to provision principals to your domains in your Azure AD Directory from the on-
premises Active Directory. For more detailed information, see Integrate your on-premises directories with Azure
Active Directory.
Windows PowerShell can also be used to automate adding new users to Azure AD and to synchronize changes
from the on-premises directory. To use the Windows PowerShell cmdlets, you must download the Azure Active
Directory Modules.
This procedure shows how to add a single user to Azure AD.
1. Connect to your Azure AD Directory as a tenant administrator: Connect-MsolService.
2. Create a new user principal:
New-MsolUser `
-UserPrincipalName elwoodf1@contoso.com `
-ImmutableId ABCDEFG1234567890 `
-DisplayName "Elwood Folk" `
-FirstName Elwood `
-LastName Folk `
-AlternateEmailAddresses "Elwood.Folk@contoso.com" `
-LicenseAssignment "samlp2test:ENTERPRISEPACK" `
-UsageLocation "US"
For more information about “New-MsolUser” checkout, /previous-versions/azure/dn194096(v=azure.100)
NOTE
The “UserPrinciplName” value must match the value that you will send for “IDPEmail” in your SAML 2.0 claim and the
“ImmutableID” value must match the value sent in your “NameID” assertion.
Verify single sign-on with your SAML 2.0 IDP

As the administrator, before you verify and manage single sign-on (also called identity federation), review the
information and perform the steps in the following articles to set up single sign-on with your SAML 2.0 SP-Lite
based identity provider:
1. You have reviewed the Azure AD SAML 2.0 Protocol Requirements
2. You have configured your SAML 2.0 identity provider
3. Install Windows PowerShell for single sign-on with SAML 2.0 identity provider
4. Set up a trust between SAML 2.0 identity provider and Azure AD
5. Provisioned a known test user principal to Azure Active Directory (Office 365) either through Windows
PowerShell or Azure AD Connect.
6. Configure directory synchronization using Azure AD Connect.
After setting up single sign-on with your SAML 2.0 SP-Lite based identity Provider, you should verify that it is
working correctly.
NOTE
If you converted a domain, rather than adding one, it may take up to 24 hours to set up single sign-on. Before you verify
single sign-on, you should finish setting up Active Directory synchronization, synchronize your directories, and activate your
synced users.
Use the tool to verify that single sign-on has been set up correctly
To verify that single sign-on has been set up correctly, you can perform the following procedure to confirm that you
are able to sign-in to the cloud service with your corporate credentials.
Microsoft has provided a tool that you can use to test your SAML 2.0 based identity provider. Before running the
test tool, you must have configured an Azure AD tenant to federate with your identity provider.
NOTE
The Connectivity Analyzer requires Internet Explorer 10 or later.
1. Download the Connectivity Analyzer from, https://testconnectivity.microsoft.com/?tabid=Client.

2. Click Install Now to begin downloading and installing the tool.
3. Select “I can’t set up federation with Office 365, Azure, or other services that use Azure Active Directory”.
4. Once the tool is downloaded and running, you will see the Connectivity Diagnostics window. The tool will step
you through testing your federation connection.
5. The Connectivity Analyzer will open your SAML 2.0 IDP for you to sign-in, enter the credentials for the user
principal you are testing:
6. At the Federation test sign-in window, you should enter an account name and password for the Azure AD tenant
that is configured to be federated with your SAML 2.0 identity provider. The tool will attempt to sign-in using
those credentials and detailed results of tests performed during the sign-in attempt will be provided as output.
7. This window shows a failed result of testing. Clicking on Review detailed results will show information about the
results for each test that was performed. You can also save the results to disk in order to share them.
NOTE
The Connectivity analyzer also tests Active Federation using the WS*-based and ECP/PAOS protocols. If you are not using
these you can disregard the following error: Testing the Active sign-in flow using your identity provider’s Active federation
endpoint.
Manually verify that single sign-on has been set up correctly

Manual verification provides additional steps that you can take to ensure that your SAML 2.0 identity Provider is
working properly in many scenarios. To verify that single sign-on has been set up correctly, complete the following
steps:
1. On a domain-joined computer, sign-in to your cloud service using the same sign-in name that you use for your
corporate credentials.
2. Click inside the password box. If single sign-on is set up, the password box will be shaded, and you will see the
following message: “You are now required to sign-in at <your company>.”
3. Click the Sign-in at <your company> link. If you are able to sign-in, then single sign-on has been set up.
Next Steps
Active Directory Federation Services management and customization with Azure AD Connect
Azure AD Connect Custom Installation
Post configuration tasks for Hybrid Azure AD join
After you have run Azure AD Connect to configure your organization for Hybrid Azure AD join, there are a few
additional steps that you must complete to finalize that setup. Carry out only the steps that apply for your devices.
1. Configure controlled rollout (Optional)

All domain-joined devices running Windows 10 and Windows Server 2016 automatically register with Azure AD
once all configuration steps are complete. If you prefer a controlled rollout rather than this auto-registration, you
can use group policy to selectively enable or disable automatic rollout. This group policy should be set before
starting the other configuration steps:
Create a group policy object in your Active Directory.
Name it (ex- Hybrid Azure AD join).
Edit and go to: Computer Configuration > Policies > Administrative Templates > Windows Components >
Device Registration.
NOTE
For 2012R2 the policy settings are at Computer Configuration > Policies > Administrative Templates > Windows
Components > Workplace Join > Automatically workplace join client computers
Enable this setting: Register domain-joined computers as devices.

Apply and click OK.
Link the GPO to the location of your choice (organizational unit, security group, or to the domain for all devices).
2. Configure network with device registration endpoints

Make sure that the following URLs are accessible from computers inside your organizational network for
registration to Azure AD:
https://enterpriseregistration.windows.net
https://device.login.microsoftonline.com
3. Implement WPAD for Windows 10 devices

If your organization accesses the Internet via an outbound proxy, implement Web Proxy Auto-Discovery (WPAD)to
enable Windows 10 computers to register to Azure AD.
4. Configure the SCP in any forests that were not configured by Azure
AD Connect
The service connection point (SCP) contains your Azure AD tenant information that will be used by your devices for
auto-registration. Run the PowerShell script, ConfigureSCP.ps1, that you downloaded from Azure AD Connect.
5. Configure any federation service that was not configured by Azure

AD Connect
If your organization uses a federation service to sign in to Azure AD, the claim rules in your Azure AD relying party
trust must allow device authentication. If you are using federation with AD FS, go to AD FS Help to generate the
claim rules. If you are using a non-Microsoft federation solution, contact that provider for guidance.
NOTE
If you have Windows down-level devices, the service must support issuing the authenticationmethod and wiaormultiauthn
claims when receiving requests to the Azure AD trust. In AD FS, you should add an issuance transform rule that passes-
through the authentication method.
6. Enable Azure AD Seamless SSO for Windows down-level devices

If your organization uses Password Hash Synchronization or Pass-through Authentication to sign in to Azure AD,
enable Azure AD Seamless SSO with that sign-in method to authenticate Windows down-level devices:
https://docs.microsoft.com/azure/active-directory/connect/active-directory-aadconnect-sso.
7. Set Azure AD policy for Windows down-level devices

To register Windows down-level devices, you need to make sure that the Azure AD policy allows users to register
devices.
Log-in to your account in the Azure portal.
Go to: Azure Active Directory > Devices > Device settings
Set "Users may register their devices with Azure AD" to ALL.
Click Save
8. Add Azure AD endpoint to Windows down-level devices

Add the Azure AD device authentication endpoint to the local Intranet zones on your Windows down-level devices
to avoid certificate prompts when authenticating the devices: https://device.login.microsoftonline.com
If you are using Seamless SSO, also enable “Allow status bar updates via script” on that zone and add the following
endpoint: https://autologon.microsoftazuread-sso.com
9. Install Microsoft Workplace Join on Windows down-level devices

This installer creates a scheduled task on the device system that runs in the user’s context. The task is triggered
when the user signs in to Windows. The task silently joins the device with Azure AD with the user credentials after
authenticating using Integrated Windows Authentication. The download center is at
https://www.microsoft.com/download/details.aspx?id=53554.
10. Configure group policy to allow device registration

For information about how to allow hybrid Azure AD join for individual devices, see Controlled validation of hybrid
Azure AD join.
Next steps
Configure device writeback
Quickstart
Deploy Seamless Single Sign-On

Azure Active Directory (Azure AD) Seamless Single Sign-On (Seamless SSO) automatically signs in users when
they are on their corporate desktops that are connected to your corporate network. Seamless SSO provides your
users with easy access to your cloud-based applications without needing any additional on-premises
components.
To deploy Seamless SSO, follow these steps.

Ensure that the following prerequisites are in place:
Set up your Azure AD Connect ser ver : If you use Pass-through Authentication as your sign-in method,
no additional prerequisite check is required. If you use password hash synchronization as your sign-in
method, and if there is a firewall between Azure AD Connect and Azure AD, ensure that:
You use version 1.1.644.0 or later of Azure AD Connect.
If your firewall or proxy allows, add the connections to the allowed list for *.msappproxy.net URLs
over port 443. If not, allow access to the Azure datacenter IP ranges, which are updated weekly. This
prerequisite is applicable only when you enable the feature. It is not required for actual user sign-
ins.
NOTE
Azure AD Connect versions 1.1.557.0, 1.1.558.0, 1.1.561.0, and 1.1.614.0 have a problem related to
password hash synchronization. If you don't intend to use password hash synchronization in conjunction
with Pass-through Authentication, read the Azure AD Connect release notes to learn more.
Use a suppor ted Azure AD Connect topology : Ensure that you are using one of Azure AD Connect's
supported topologies described here.
NOTE
Seamless SSO supports multiple AD forests, whether there are AD trusts between them or not.
Set up domain administrator credentials : You need to have domain administrator credentials for each
Active Directory forest that:
You synchronize to Azure AD through Azure AD Connect.
Contains users you want to enable for Seamless SSO.
Enable modern authentication : You need to enable modern authentication on your tenant for this
feature to work.
Use the latest versions of Office 365 clients : To get a silent sign-on experience with Office 365 clients
(Outlook, Word, Excel, and others), your users need to use versions 16.0.8730.xxxx or above.

Enable Seamless SSO through Azure AD Connect.
NOTE
You can also enable Seamless SSO using PowerShell if Azure AD Connect doesn't meet your requirements. Use this option if
you have more than one domain per Active Directory forest, and you want to be more targeted about the domain you
want to enable Seamless SSO for.
If you're doing a fresh installation of Azure AD Connect, choose the custom installation path. At the User sign-in
page, select the Enable single sign on option.
NOTE
The option will be available for selection only if the Sign On method is Password Hash Synchronization or Pass-
through Authentication .
If you already have an installation of Azure AD Connect, select the Change user sign-in page in Azure AD
Connect, and then select Next . If you are using Azure AD Connect versions 1.1.880.0 or above, the Enable single
sign on option will be selected by default. If you are using older versions of Azure AD Connect, select the Enable
single sign on option.
Continue through the wizard until you get to the Enable single sign on page. Provide domain administrator
credentials for each Active Directory forest that:
You synchronize to Azure AD through Azure AD Connect.
Contains users you want to enable for Seamless SSO.
After completion of the wizard, Seamless SSO is enabled on your tenant.
NOTE
The domain administrator credentials are not stored in Azure AD Connect or in Azure AD. They're used only to enable the
feature.
Follow these instructions to verify that you have enabled Seamless SSO correctly:
1. Sign in to the Azure Active Directory administrative center with the global administrator credentials for your
tenant.
4. Verify that the Seamless single sign-on feature appears as Enabled .
IMPORTANT
Seamless SSO creates a computer account named AZUREADSSOACC in your on-premises Active Directory (AD) in each AD
forest. The AZUREADSSOACC computer account needs to be strongly protected for security reasons. Only Domain Admins
should be able to manage the computer account. Ensure that Kerberos delegation on the computer account is disabled,
and that no other account in Active Directory has delegation permissions on the AZUREADSSOACC computer account. Store
the computer account in an Organization Unit (OU) where they are safe from accidental deletions and where only Domain
Admins have access.
NOTE
If you are using Pass-the-Hash and Credential Theft Mitigation architectures in your on-premises environment, make
appropriate changes to ensure that the AZUREADSSOACC computer account doesn't end up in the Quarantine container.
Step 3: Roll out the feature

You can gradually roll out Seamless SSO to your users using the instructions provided below. You start by adding
the following Azure AD URL to all or selected users' Intranet zone settings by using Group Policy in Active
Directory:
https://autologon.microsoftazuread-sso.com
In addition, you need to enable an Intranet zone policy setting called Allow updates to status bar via script
through Group Policy.
NOTE
The following instructions work only for Internet Explorer and Google Chrome on Windows (if it shares a set of trusted site
URLs with Internet Explorer). Read the next section for instructions on how to set up Mozilla Firefox and Google Chrome on
macOS.
Why do you need to modify users' Intranet zone settings?

By default, the browser automatically calculates the correct zone, either Internet or Intranet, from a specific URL.
For example, http://contoso/ maps to the Intranet zone, whereas http://intranet.contoso.com/ maps to the
Internet zone (because the URL contains a period). Browsers will not send Kerberos tickets to a cloud endpoint,
like the Azure AD URL, unless you explicitly add the URL to the browser's Intranet zone.
There are two ways to modify users' Intranet zone settings:
O P T IO N A DM IN C O N SIDERAT IO N USER EXP ERIEN C E
Group policy Admin locks down editing of Intranet Users cannot modify their own settings
zone settings
Group policy preference Admin allows editing on Intranet zone Users can modify their own settings
settings
"Group policy" option - Detailed steps

1. Open the Group Policy Management Editor tool.
2. Edit the group policy that's applied to some or all your users. This example uses Default Domain Policy .
3. Browse to User Configuration > Policy > Administrative Templates > Windows Components >
Internet Explorer > Internet Control Panel > Security Page . Then select Site to Zone Assignment
List .
4. Enable the policy, and then enter the following values in the dialog box:
Value name : The Azure AD URL where the Kerberos tickets are forwarded.
Value (Data): 1 indicates the Intranet zone.
The result looks like this:
Value name: https://autologon.microsoftazuread-sso.com
Value (Data): 1
NOTE
If you want to disallow some users from using Seamless SSO (for instance, if these users sign in on shared kiosks),
set the preceding values to 4 . This action adds the Azure AD URL to the Restricted zone, and fails Seamless SSO all
the time.
5. Select OK , and then select OK again.
6. Browse to User Configuration > Policy > Administrative Templates > Windows Components >
Internet Explorer > Internet Control Panel > Security Page > Intranet Zone . Then select Allow
updates to status bar via script .
7. Enable the policy setting, and then select OK .
"Group policy preference" option - Detailed steps

1. Open the Group Policy Management Editor tool.
2. Edit the group policy that's applied to some or all your users. This example uses Default Domain Policy .
3. Browse to User Configuration > Preferences > Windows Settings > Registr y > New > Registr y
item .
4. Enter the following values in appropriate fields and click OK .

Key Path : Software\Microsoft\Windows\CurrentVersion\Internet
Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon
Value name : https
Value type : REG_DWORD
Value data : 00000001
Browser considerations
Mozilla Firefox (all platforms )
Mozilla Firefox doesn't automatically use Kerberos authentication. Each user must manually add the Azure AD
URL to their Firefox settings by using the following steps:
1. Run Firefox and enter about:config in the address bar. Dismiss any notifications that you see.
2. Search for the network .negotiate-auth.trusted-uris preference. This preference lists Firefox's trusted sites
for Kerberos authentication.
3. Right-click and select Modify .
4. Enter https://autologon.microsoftazuread-sso.com in the field.
5. Select OK and then reopen the browser.
Safari (macOS)
Ensure that the machine running the macOS is joined to AD. Instructions for AD-joining your macOS device is
outside the scope of this article.
Microsoft Edge based on Chromium (all platforms )
If you have overridden the AuthNegotiateDelegateAllowlist or the AuthServerAllowlist policy settings in your
environment, ensure that you add Azure AD's URL ( https://autologon.microsoftazuread-sso.com ) to them as well.
Microsoft Edge based on Chromium (macOS and other non-Windows platforms )
For Microsoft Edge based on Chromium on macOS and other non-Windows platforms, refer to the Microsoft
Edge based on Chromium Policy List for information on how to add the Azure AD URL for integrated
authentication to your allow-list.
Google Chrome (all platforms )
If you have overridden the AuthNegotiateDelegateWhitelist or the AuthServerWhitelist policy settings in your
environment, ensure that you add Azure AD's URL ( https://autologon.microsoftazuread-sso.com ) to them as well.
Google Chrome (macOS and other non-Windows platforms )
For Google Chrome on macOS and other non-Windows platforms, refer to The Chromium Project Policy List for
information on how to control the allow list for the Azure AD URL for integrated authentication.
The use of third-party Active Directory Group Policy extensions to roll out the Azure AD URL to Firefox and
Google Chrome on Mac users is outside the scope of this article.
Known browser limitations
Seamless SSO doesn't work in private browsing mode on Firefox and Microsoft Edge browsers. It also doesn't
work on Internet Explorer if the browser is running in Enhanced Protected mode. For the next version of
Microsoft Edge based on Chromium, it will not work in InPrivate and Guest mode by design.

To test the feature for a specific user, ensure that all the following conditions are in place:
The user signs in on a corporate device.
The device is joined to your Active Directory domain. The device doesn't need to be Azure AD Joined.
The device has a direct connection to your domain controller (DC), either on the corporate wired or wireless
network or via a remote access connection, such as a VPN connection.
You have rolled out the feature to this user through Group Policy.
To test the scenario where the user enters only the username, but not the password:
Sign in to https://myapps.microsoft.com/ in a new private browser session.
To test the scenario where the user doesn't have to enter the username or the password, use one of these steps:
Sign in to https://myapps.microsoft.com/contoso.onmicrosoft.com in a new private browser session. Replace
contoso with your tenant's name.
Sign in to https://myapps.microsoft.com/contoso.com in a new private browser session. Replace contoso.com
with a verified domain (not a federated domain) on your tenant.
Step 5: Roll over keys

In Step 2, Azure AD Connect creates computer accounts (representing Azure AD) in all the Active Directory forests
on which you have enabled Seamless SSO. To learn more, see Azure Active Directory Seamless Single Sign-On:
Technical deep dive.
IMPORTANT
The Kerberos decryption key on a computer account, if leaked, can be used to generate Kerberos tickets for any user in its
AD forest. Malicious actors can then impersonate Azure AD sign-ins for compromised users. We highly recommend that
you periodically roll over these Kerberos decryption keys - at least once every 30 days.
For instructions on how to roll over keys, see Azure Active Directory Seamless Single Sign-On: Frequently asked
questions. We are working on a capability to introduce automated roll over of keys.
IMPORTANT
You don't need to do this step immediately after you have enabled the feature. Roll over the Kerberos decryption keys at
least once every 30 days.
Next steps
Technical deep dive: Understand how the Seamless Single Sign-On feature works.
Frequently asked questions: Get answers to frequently asked questions about Seamless Single Sign-On.
Troubleshoot: Learn how to resolve common problems with the Seamless Single Sign-On feature.
In this article, we address frequently asked questions about Azure Active Directory Seamless Single Sign-On
(Seamless SSO). Keep checking back for new content.
Q: What sign-in methods do Seamless SSO work with
Seamless SSO can be combined with either the Password Hash Synchronization or Pass-through Authentication
sign-in methods. However this feature cannot be used with Active Directory Federation Services (ADFS).
Q: Is Seamless SSO a free feature?
Seamless SSO is a free feature and you don't need any paid editions of Azure AD to use it.
Q: Is Seamless SSO available in the Microsoft Azure Germany cloud and the Microsoft Azure
Government cloud ?
Seamless SSO is available for the Azure Government cloud. For details, view Hybrid Identity Considerations for
Azure Government.
Q: What applications take advantage of domain_hint or login_hint parameter capability of Seamless
SSO?
Listed below is a non-exhaustive list of applications that can send these parameters to Azure AD, and therefore
provides users a silent sign-on experience using Seamless SSO (i.e., no need for your users to input their
usernames or passwords):
A P P L IC AT IO N N A M E A P P L IC AT IO N URL TO B E USED
Access panel https://myapps.microsoft.com/contoso.com
Outlook on Web https://outlook.office365.com/contoso.com
Office 365 portals https://portal.office.com?domain_hint=contoso.com,

https://www.office.com?domain_hint=contoso.com
In addition, users get a silent sign-on experience if an application sends sign-in requests to Azure AD's endpoints
set up as tenants - that is, https://login.microsoftonline.com/contoso.com/<..> or
https://login.microsoftonline.com/<tenant_ID>/<..> - instead of Azure AD's common endpoint - that is,
https://login.microsoftonline.com/common/<...>. Listed below is a non-exhaustive list of applications that make
these types of sign-in requests.
A P P L IC AT IO N N A M E A P P L IC AT IO N URL TO B E USED
SharePoint Online https://contoso.sharepoint.com
Azure portal https://portal.azure.com/contoso.com
In the above tables, replace "contoso.com" with your domain name to get to the right application URLs for your
tenant.
If you want other applications using our silent sign-on experience, let us know in the feedback section.
Q: Does Seamless SSO suppor t Alternate ID as the username, instead of userPrincipalName ?
Yes. Seamless SSO supports Alternate ID as the username when configured in Azure AD Connect as shown
here. Not all Office 365 applications support Alternate ID . Refer to the specific application's documentation for
the support statement.
Q: What is the difference between the single sign-on experience provided by Azure AD Join and
Seamless SSO?
Azure AD Join provides SSO to users if their devices are registered with Azure AD. These devices don't
necessarily have to be domain-joined. SSO is provided using primary refresh tokens or PRTs, and not Kerberos.
The user experience is most optimal on Windows 10 devices. SSO happens automatically on the Microsoft Edge
browser. It also works on Chrome with the use of a browser extension.
You can use both Azure AD Join and Seamless SSO on your tenant. These two features are complementary. If
both features are turned on, then SSO from Azure AD Join takes precedence over Seamless SSO.
Q: I want to register non-Windows 10 devices with Azure AD, without using AD FS. Can I use
Seamless SSO instead?
Yes, this scenario needs version 2.1 or later of the workplace-join client.
Q: How can I roll over the Kerberos decr yption key of the AZUREADSSO computer account?
It is important to frequently roll over the Kerberos decryption key of the AZUREADSSO computer account (which
represents Azure AD) created in your on-premises AD forest.
IMPORTANT
We highly recommend that you roll over the Kerberos decryption key at least every 30 days.
Follow these steps on the on-premises server where you are running Azure AD Connect:
Step 1. Get list of AD forests where Seamless SSO has been enabled
1. First, download, and install Azure AD PowerShell.
2. Navigate to the %programfiles%\Microsoft Azure Active Directory Connect folder.
3. Import the Seamless SSO PowerShell module using this command: Import-Module .\AzureADSSO.psd1 .
4. Run PowerShell as an Administrator. In PowerShell, call New-AzureADSSOAuthenticationContext . This command
should give you a popup to enter your tenant's Global Administrator credentials.
5. Call Get-AzureADSSOStatus | ConvertFrom-Json . This command provides you the list of AD forests (look at the
"Domains" list) on which this feature has been enabled.
Step 2. Update the Kerberos decr yption key on each AD forest that it was set it up on
1. Call $creds = Get-Credential . When prompted, enter the Domain Administrator credentials for the intended
AD forest.
NOTE
The domain administrator credentials username must be entered in the SAM account name format (contoso\johndoe or
contoso.com\johndoe). We use the domain portion of the username to locate the Domain Controller of the Domain
Administrator using DNS.
NOTE
The domain administrator account used must not be a member of the Protected Users group. If so, the operation will fail.
2. Call Update-AzureADSSOForest -OnPremCredentials $creds . This command updates the Kerberos decryption key
for the AZUREADSSO computer account in this specific AD forest and updates it in Azure AD.
NOTE
If you are not a domain admin and you were assigned permissions by the domain admin, you should call
Update-AzureADSSOForest -OnPremCredentials $creds -PreserveCustomPermissionsOnDesktopSsoAccount
3. Repeat the preceding steps for each AD forest that you’ve set up the feature on.
IMPORTANT
Ensure that you don't run the Update-AzureADSSOForest command more than once. Otherwise, the feature stops
working until the time your users' Kerberos tickets expire and are reissued by your on-premises Active Directory.
Q: How can I disable Seamless SSO?

Step 1. Disable the feature on your tenant
Option A: Disable using Azure AD Connect
1. Run Azure AD Connect, choose Change user sign-in page and click Next .
2. Uncheck the Enable single sign on option. Continue through the wizard.
After completing the wizard, Seamless SSO will be disabled on your tenant. However, you will see a message on
screen that reads as follows:
"Single sign-on is now disabled, but there are additional manual steps to perform in order to complete clean-up.
Learn more"
To complete the clean-up process, follow steps 2 and 3 on the on-premises server where you are running Azure
AD Connect.
Option B: Disable using PowerShell
Run the following steps on the on-premises server where you are running Azure AD Connect:
5. Call Enable-AzureADSSO -Enable $false .
At this point Seamless SSO is disabled but the domains will remain configured in case you would like to enable
Seamless SSO back. If you would like to remove the domains from Seamless SSO configuration completely, call
the following cmdlet after you completed step 5 above: Disable-AzureADSSOForest -DomainFqdn <fqdn> .
IMPORTANT
Disabling Seamless SSO using PowerShell will not change the state in Azure AD Connect. Seamless SSO will show as
enabled in the Change user sign-in page.
Step 2. Get list of AD forests where Seamless SSO has been enabled
Follow tasks 1 through 4 below if you have disabled Seamless SSO using Azure AD Connect. If you have disabled
Seamless SSO using PowerShell instead, jump ahead to task 5 below.
5. Call Get-AzureADSSOStatus | ConvertFrom-Json . This command provides you the list of AD forests (look at the
Step 3. Manually delete the AZUREADSSO computer account from each AD forest that you see listed.
Next steps
Quickstar t - Get up and running Azure AD Seamless SSO.
Azure Active Directory Connect Health operations
This topic describes the various operations you can perform by using Azure Active Directory (Azure AD) Connect
Health.
Enable email notifications

You can configure the Azure AD Connect Health service to send email notifications when alerts indicate that your
identity infrastructure is not healthy. This occurs when an alert is generated, and when it is resolved.
NOTE
Email notifications are enabled by default.
To enable Azure AD Connect Health email notifications

1. Open the Aler ts blade for the service for which you want to receive email notification.
2. From the action bar, click Notification Settings .
3. At the email notification switch, select ON .
4. Select the check box if you want all global administrators to receive email notifications.
5. If you want to receive email notifications at any other email addresses, specify them in the Additional Email
Recipients box. To remove an email address from this list, right-click the entry and select Delete .
6. To finalize the changes, click Save . Changes take effect only after you save.
NOTE
When there are issues processing synchronization requests in our backend service, this service sends a notification email
with the details of the error to the administrative contact email address(es) of your tenant. We heard feedback from
customers that in certain cases the volume of these messages is prohibitively large so we are changing the way we send
these messages.
Instead of sending a message for every sync error every time it occurs we will send out a daily digest of all errors the
backend service has returned. This enables customers to process these errors in a more efficient manner and reduces the
number of duplicate error messages.
We plan for this change to be implemented on January 15th, 2020.
Delete a server or service instance

NOTE
Azure AD premium license is required for the deletion steps.
In some instances, you might want to remove a server from being monitored. Here's what you need to know to
remove a server from the Azure AD Connect Health service.
When you're deleting a server, be aware of the following:
This action stops collecting any further data from that server. This server is removed from the monitoring
service. After this action, you are not able to view new alerts, monitoring, or usage analytics data for this server.
This action does not uninstall the Health Agent from your server. If you have not uninstalled the Health Agent
before performing this step, you might see errors related to the Health Agent on the server.
This action does not delete the data already collected from this server. That data is deleted in accordance with
the Azure data retention policy.
After performing this action, if you want to start monitoring the same server again, you must uninstall and
reinstall the Health Agent on this server.
Delete a server from the Azure AD Connect Health service
NOTE
Azure AD premium license is required for the deletion steps.
Azure AD Connect Health for Active Directory Federation Services (AD FS) and Azure AD Connect (Sync):
1. Open the Ser ver blade from the Ser ver List blade by selecting the server name to be removed.
2. On the Ser ver blade, from the action bar, click Delete .
3. Confirm by typing the server name in the confirmation box.
4. Click Delete .
Azure AD Connect Health for Azure Active Directory Domain Services:
1. Open the Domain Controllers dashboard.
2. Select the domain controller to be removed.
3. From the action bar, click Delete Selected .
4. Confirm the action to delete the server.
5. Click Delete .
Delete a service instance from Azure AD Connect Health service
In some instances, you might want to remove a service instance. Here's what you need to know to remove a
service instance from the Azure AD Connect Health service.
When you're deleting a service instance, be aware of the following:
This action removes the current service instance from the monitoring service.
This action does not uninstall or remove the Health Agent from any of the servers that were monitored as part
of this service instance. If you have not uninstalled the Health Agent before performing this step, you might see
errors related to the Health Agent on the servers.
All data from this service instance is deleted in accordance with the Azure data retention policy.
After performing this action, if you want to start monitoring the service, uninstall and reinstall the Health Agent
on all the servers. After performing this action, if you want to start monitoring the same server again, uninstall,
reinstall, and register the Health Agent on that server.
To delete a service instance from the Azure AD Connect Health service
1. Open the Ser vice blade from the Ser vice List blade by selecting the service identifier (farm name) that you
want to remove.
2. On the Ser vice blade, from the action bar, click Delete .
3. Confirm by typing the service name in the confirmation box (for example: sts.contoso.com).
4. Click Delete .
Manage access with Azure RBAC

Azure role-based access control (Azure RBAC) for Azure AD Connect Health provides access to users and groups
other than global administrators. Azure RBAC assigns roles to the intended users and groups, and provides a
mechanism to limit the global administrators within your directory.
Roles
Azure AD Connect Health supports the following built-in roles:
RO L E P ERM ISSIO N S
RO L E P ERM ISSIO N S
Owner Owners can manage access (for example, assign a role to a

user or group), view all information (for example, view alerts)
from the portal, and change settings (for example, email
notifications) within Azure AD Connect Health.
By default, Azure AD global administrators are assigned this
role, and this cannot be changed.
Contributor Contributors can view all information (for example, view

alerts) from the portal, and change settings (for example,
email notifications) within Azure AD Connect Health.
Reader Readers can view all information (for example, view alerts)
from the portal within Azure AD Connect Health.
All other roles (such as User Access Administrators or DevTest Labs Users) have no impact to access within Azure
AD Connect Health, even if the roles are available in the portal experience.
Access scope
Azure AD Connect Health supports managing access at two levels:
All ser vice instances : This is the recommended path in most cases. It controls access for all service instances
(for example, an AD FS farm) across all role types that are being monitored by Azure AD Connect Health.
Ser vice instance : In some cases, you might need to segregate access based on role types or by a service
instance. In this case, you can manage access at the service instance level.
Permission is granted if an end user has access either at the directory or service instance level.
Allow users or groups access to Azure AD Connect Health
The following steps show how to allow access.
Step 1: Select the appropriate access scope
To allow a user access at the all service instances level within Azure AD Connect Health, open the main blade in
Step 2: Add users and groups, and assign roles
1. From the Configure section, click Users .
2. Select Add .
3. In the Select a role pane, select a role (for example, Owner ).
4. Type the name or identifier of the targeted user or group. You can select one or more users or groups at the
same time. Click Select .
5. Select OK .
6. After the role assignment is complete, the users and groups appear in the list.
Now the listed users and groups have access, according to their assigned roles.
NOTE
Global administrators always have full access to all the operations, but global administrator accounts are not present in
the preceding list.
The Invite Users feature is not supported within Azure AD Connect Health.
Step 3: Share the blade location with users or groups

1. After you assign permissions, a user can access Azure AD Connect Health by going here.
2. On the blade, the user can pin the blade, or different parts of it, to the dashboard. Simply click the Pin to
dashboard icon.
NOTE
A user with the Reader role assigned is not able to get Azure AD Connect Health extension from the Azure Marketplace. The
user cannot perform the necessary "create" operation to do so. The user can still get to the blade by going to the preceding
link. For subsequent usage, the user can pin the blade to the dashboard.
Remove users or groups

You can remove a user or a group added to Azure AD Connect Health and Azure RBAC. Simply right-click the user
or group, and select Remove .
Next steps
Azure AD Connect Health Agent installation
Monitor AD FS using Azure AD Connect Health
The following documentation is specific to monitoring your AD FS infrastructure with Azure AD Connect Health.
For information on monitoring Azure AD Connect (Sync) with Azure AD Connect Health, see Using Azure AD
Connect Health for Sync. Additionally, for information on monitoring Active Directory Domain Services with
Azure AD Connect Health, see Using Azure AD Connect Health with AD DS.
Alerts for AD FS
The Azure AD Connect Health Alerts section provides you the list of active alerts. Each alert includes relevant
information, resolution steps, and links to related documentation.
You can double-click an active or resolved alert, to open a new blade with additional information, steps you can
take to resolve the alert, and links to relevant documentation. You can also view historical data on alerts that
were resolved in the past.
Usage Analytics for AD FS

Azure AD Connect Health Usage Analytics analyzes the authentication traffic of your federation servers. You can
double-click the usage analytics box, to open the usage analytics blade, which shows you several metrics and
groupings.
NOTE
To use Usage Analytics with AD FS, you must ensure that AD FS auditing is enabled. For more information, see Enable
Auditing for AD FS.
To select additional metrics, specify a time range, or to change the grouping, right-click on the usage analytics
chart and select Edit Chart. Then you can specify the time range, select a different metric, and change the
grouping. You can view the distribution of the authentication traffic based on different "metrics" and group each
metric using relevant "group by" parameters described in the following section:
Metric : Total Requests - Total number of requests processed by AD FS servers.
GRO UP B Y W H AT T H E GRO UP IN G M EA N S A N D W H Y IT 'S USEF UL?
All Shows the count of total number of requests processed by all

AD FS servers.
Application Groups the total requests based on the targeted relying

party. This grouping is useful to understand which
application is receiving how much percentage of the total
traffic.
Server Groups the total requests based on the server that

processed the request. This grouping is useful to understand
the load distribution of the total traffic.
Workplace Join Groups the total requests based on whether they are coming
from devices that are workplace joined (known). This
grouping is useful to understand if your resources are
accessed using devices that are unknown to the identity
infrastructure.
Authentication Method Groups the total requests based on the authentication

method used for authentication. This grouping is useful to
understand the common authentication method that gets
used for authentication. Following are the possible
authentication methods
1. Windows Integrated Authentication (Windows)
2. Forms Based Authentication (Forms)
3. SSO (Single Sign On)
4. X509 Certificate Authentication (Certificate)
If the federation servers receive the request with an SSO

Cookie, that request is counted as SSO (Single Sign On).
In such cases, if the cookie is valid, the user is not asked
to provide credentials and gets seamless access to the
application. This behavior is common if you have multiple
relying parties protected by the federation servers.
Network Location Groups the total requests based on the network location of
the user. It can be either intranet or extranet. This grouping is
useful to know what percentage of the traffic is coming from
the intranet versus extranet.
Metric: Total Failed Request - The total number failed requests processed by the federation service. (This
metric is only available on AD FS for Windows Server 2012 R2)
Error Type Shows the number of errors based on predefined error types.
This grouping is useful to understand the common types of
errors.
Incorrect Username or Password: Errors due to
incorrect username or password.
"Extranet Lockout": Failures due to the requests
received from a user that was locked out from
extranet
"Expired Password": Failures due to users logging in
with an expired password.
"Disabled Account": Failures due to users logging with
a disabled account.
"Device Authentication": Failures due to users failing
to authenticate using Device Authentication.
"User Certificate Authentication": Failures due to users
failing to authenticate because of an invalid certificate.
"MFA": Failures due to user failing to authenticate
using Multi-Factor Authentication.
"Other Credential": "Issuance Authorization": Failures
due to authorization failures.
"Issuance Delegation": Failures due to issuance
delegation errors.
"Token Acceptance": Failures due to ADFS rejecting the
token from a third-party Identity Provider.
"Protocol": Failure due to protocol errors.
"Unknown": Catch all. Any other failures that do not
fit into the defined categories.
Server Groups the errors based on the server. This grouping is

useful to understand the error distribution across servers.
Uneven distribution could be an indicator of a server in a
faulty state.
Network Location Groups the errors based on the network location of the
requests (intranet vs extranet). This grouping is useful to
understand the type of requests that are failing.
Application Groups the failures based on the targeted application (relying

party). This grouping is useful to understand which targeted
application is seeing most number of errors.
Metric : User Count - Average number of unique users actively authenticating using AD FS
All This metric provides a count of average number of users

using the federation service in the selected time slice. The
users are not grouped.
The average depends on the time slice selected.
Application Groups the average number of users based on the targeted

application (relying party). This grouping is useful to
understand how many users are using which application.
Performance Monitoring for AD FS

Azure AD Connect Health Performance Monitoring provides monitoring information on metrics. Selecting the
Monitoring box, opens a new blade with detailed information on the metrics.
By selecting the Filter option at the top of the blade, you can filter by server to see an individual server’s metrics.
To change metric, right-click on the monitoring chart under the monitoring blade and select Edit Chart (or select
the Edit Chart button). From the new blade that opens up, you can select additional metrics from the drop-down
and specify a time range for viewing the performance data.
Top 50 Users with failed Username/Password logins

One of the common reasons for a failed authentication request on an AD FS server is a request with invalid
credentials, that is, a wrong username or password. Usually happens to users due to complex passwords,
forgotten passwords, or typos.
But there are other reasons that can result in an unexpected number of requests being handled by your AD FS
servers, such as: An application that caches user credentials and the credentials expire or a malicious user
attempting to sign into an account with a series of well-known passwords. These two examples are valid reasons
that could lead to a surge in requests.
Azure AD Connect Health for ADFS provides a report about top 50 Users with failed login attempts due to invalid
username or password. This report is achieved by processing the audit events generated by all the AD FS servers
in the farms.
Within this report you have easy access to the following pieces of information:
Total # of failed requests with wrong username/password in the last 30 days
Average # of users that failed with a bad username/password login per day.
Clicking this part takes you to the main report blade that provides additional details. This blade includes a graph
with trending information to help establish a baseline about requests with wrong username or password.
Additionally, it provides the list of top 50 users with the number of failed attempts during the past week. Notice
top 50 users from the past week could help identify bad password spikes.
The graph provides the following information:
The total # of failed logins due to a bad username/password on a per-day basis.
The total # of unique users that failed logins on a per-day basis.
Client IP address of for last request
The report provides the following information:
REP O RT IT EM DESC RIP T IO N
User ID Shows the user ID that was used. This value is what the user
typed, which in some cases is the wrong user ID being used.
Failed Attempts Shows the total # of failed attempts for that specific user ID.
The table is sorted with the most number of failed attempts
in descending order.
Last Failure Shows the time stamp when the last failure occurred.
Last Failure IP Shows the Client IP address from the latest bad request. If
you see more than one IP addresses in this value, it may
include forward client IP together with user's last attempt
request IP.
NOTE
This report is automatically updated after every 12 hours with the new information collected within that time. As a result,
login attempts within the last 12 hours may not be included in the report.
Related links
Risky IP report
Risky IP report (public preview)
AD FS customers may expose password authentication endpoints to the internet to provide authentication services
for end users to access SaaS applications such as Office 365. In this case, it is possible for a bad actor to attempt
logins against your AD FS system to guess an end user’s password and get access to application resources. AD FS
provides the extranet account lockout functionality to prevent these types of attacks since AD FS in Windows
Server 2012 R2. If you are on a lower version, we strongly recommend that you upgrade your AD FS system to
Windows Server 2016.
Additionally, it is possible for a single IP address to attempt multiple logins against multiple users. In these cases,
the number of attempts per user may be under the threshold for account lockout protection in AD FS. Azure AD
Connect Health now provides the “Risky IP report” that detects this condition and notifies administrators when this
occurs. The following are the key benefits for this report:
Detection of IP addresses that exceed a threshold of failed password-based logins
Supports failed logins due to bad password or due to extranet lockout state
Email notification to alert administrators as soon as this occurs with customizable email settings
Customizable threshold settings that match with the security policy of an organization
Downloadable reports for offline analysis and integration with other systems via automation
NOTE
To use this report, you must ensure that AD FS auditing is enabled. For more information, see Enable Auditing for AD FS.
To access preview, Global Admin or Security Reader permission is required.
What is in the report?

The failed sign in activity client IP addresses are aggregated through Web Application Proxy servers. Each item in
the Risky IP report shows aggregated information about failed AD FS sign-in activities which exceed designated
threshold. It provides the following information:
Time Stamp Shows the time stamp based on Azure portal local time when
the detection time window starts.
All daily events are generated at mid-night UTC time.
Hourly events have the timestamp rounded to the beginning
of the hour. You can find first activity start time from
“firstAuditTimestamp” in the exported file.
Trigger Type Shows the type of detection time window. The aggregation
trigger types are per hour or per day. This is helpful to detect
versus a high frequency brute force attack versus a slow
attack where the number of attempts is distributed
throughout the day.
IP Address The single risky IP address that had either bad password or
extranet lockout sign-in activities. This could be an IPv4 or an
IPv6 address.
Bad Password Error Count The count of Bad Password error occurred from the IP address
during the detection time window. The Bad Password errors
can happen multiple times to certain users. Notice this does
not include failed attempts due to expired passwords.
Extranet Lock Out Error Count The count of Extranet Lockout error occurred from the IP
address during the detection time window. The Extranet
Lockout errors can happen multiple times to certain users.
This will only be seen if Extranet Lockout is configured in AD
FS (versions 2012R2 or higher). Note We strongly
recommend turning this feature on if you allow extranet
logins using passwords.
Unique Users Attempted The count of unique user accounts attempted from the IP
address during the detection time window. This provides a
mechanism to differentiate a single user attack pattern versus
multi-user attack pattern.
For example, the below report item indicates from the 6pm to 7pm hour window on 02/28/2018, IP address
104.2XX.2XX.9 had no bad password errors and 284 extranet lockout errors. 14 unique users were impacted within
the criteria. The activity event exceeded the designated report hourly threshold.
NOTE
Only activities exceeding designated threshold will be showing in the report list.
This report can be trace back at most 30 days.
This alert report does not show Exchange IP addresses or private IP addresses. They are still included in the export list.
Load balancer IP addresses in the list

Load balancer aggregate failed sign-in activities and hit the alert threshold. If you are seeing load balancer IP
addresses, it is highly likely that your external load balancer is not sending the client IP address when it passes the
request to the Web Application Proxy server. Please configure your load balancer correctly to pass forward client IP
address.
Download risky IP report
Using the Download functionality, the whole risky IP address list in the past 30 days can be exported from the
Connect Health Portal The export result will include all the failed AD FS sign-in activities in each detection time
window, so you can customize the filtering after the export. Besides the highlighted aggregations in the portal, the
export result also shows more details about failed sign-in activities per IP address:
firstAuditTimestamp Shows the first timestamp when the failed activities started
during the detection time window.
lastAuditTimestamp Shows the last timestamp when the failed activities ended
during the detection time window.
attemptCountThresholdIsExceeded The flag if the current activities are exceeding the alerting
threshold.
isWhitelistedIpAddress The flag if the IP address is filtered from alerting and

reporting. Private IP addresses (
10.x.x.x, 172.x.x.x & 192.168.x.x) and Exchange IP addresses
are filtered and marked as True. If you are seeing private IP
address ranges, it is highly likely that your external load
balancer is not sending the client IP address when it passes
the request to the Web Application Proxy server.
Configure notification settings

Admin contacts of the report can be updated through the Notification Settings . By default, the risky IP alert
email notification is in off state. You can enable the notification by toggle the button under “Get email notifications
for IP addresses exceeding failed activity threshold report” Like generic alert notification settings in Connect
Health, it allows you to customize designated notification recipient list about risky IP report from here. You can also
notify all global admins while making the change.
Configure threshold settings

Alerting threshold can be updated through Threshold Settings. To start with, system has threshold set by default.
There are four categories in the risk IP report threshold settings:
T H RESH O L D IT EM DESC RIP T IO N
(Bad U/P + Extranet Lockout) / Day Threshold setting to report the activity and trigger alert
notification when the count of Bad Password plus the count of
Extranet Lockout exceeds it per day .
(Bad U/P + Extranet Lockout) / Hour Threshold setting to report the activity and trigger alert
notification when the count of Bad Password plus the count of
Extranet Lockout exceeds it per hour .
Extranet Lockout / Day Threshold setting to report the activity and trigger alert
notification when the count of Extranet Lockout exceeds it per
day .
Extranet Lockout / Hour Threshold setting to report the activity and trigger alert
notification when the count of Extranet Lockout exceeds it per
hour .
NOTE
The change of report threshold will be applied after an hour of the setting change.
Existing reported items will not be affected by the threshold change.
We recommend that you analyze the number of events seen within your environment and adjust the threshold
appropriately.
FAQ
Why am I seeing private IP address ranges in the repor t?
Private IP addresses (10.x.x.x, 172.x.x.x & 192.168.x.x) and Exchange IP addresses are filtered and marked as True in
the IP approved list. If you are seeing private IP address ranges, it is highly likely that your external load balancer is
not sending the client IP address when it passes the request to the Web Application Proxy server.
Why am I seeing load balancer IP addresses in the repor t?
If you are seeing load balancer IP addresses, it is highly likely that your external load balancer is not sending the
client IP address when it passes the request to the Web Application Proxy server. Please configure your load
balancer correctly to pass forward client IP address.
What do I do to block the IP address?
You should add identified malicious IP address to the firewall or block in Exchange.
Why am I not seeing any items in this repor t?
Failed sign-in activities are not exceeding the threshold settings.
Ensure no “Health service is not up to date” alert active in your AD FS server list. Read more about how to
troubleshoot this alert.
Audits is not enabled in AD FS farms.
Why am I seeing no access to the repor t?
Global Admin or Security Reader permission is required. Please contact your global admin to get access.
Next steps
Monitor Azure AD Connect sync with Azure AD
Connect Health
The following documentation is specific to monitoring Azure AD Connect (Sync) with Azure AD Connect Health.
For information on monitoring AD FS with Azure AD Connect Health see Using Azure AD Connect Health with
AD FS. Additionally, for information on monitoring Active Directory Domain Services with Azure AD Connect
Health see Using Azure AD Connect Health with AD DS.
Alerts for Azure AD Connect Health for sync

The Azure AD Connect Health Alerts for sync section provides you the list of active alerts. Each alert includes
relevant information, resolution steps, and links to related documentation. By selecting an active or resolved
alert you will see a new blade with additional information, as well as steps you can take to resolve the alert, and
links to additional documentation. You can also view historical data on alerts that were resolved in the past.
By selecting an alert you will be provided with additional information as well as steps you can take to resolve
the alert and links to additional documentation.
Limited Evaluation of Alerts
If Azure AD Connect is NOT using the default configuration (for example, if Attribute Filtering is changed from
the default configuration to a custom configuration), then the Azure AD Connect Health agent will not upload
the error events related to Azure AD Connect.
This limits the evaluation of alerts by the service. You will see a banner that indicates this condition in the Azure
Portal under your service.
You can change this by clicking "Settings" and allowing Azure AD Connect Health agent to upload all error logs.
Sync Insight
Admins Frequently want to know about the time it takes to sync changes to Azure AD and the amount of
changes taking place. This feature provides an easy way to visualize this using the below graphs:
Latency of sync operations
Object Change trend
Sync Latency
This feature provides a graphical trend of latency of the sync operations (import, export, etc.) for connectors.
This provides a quick and easy way to understand not only the latency of your operations (larger if you have a
large set of changes occurring) but also a way to detect anomalies in the latency that may require further
investigation.
By default, only the latency of the 'Export' operation for the Azure AD connector is shown. To see more
operations on the connector or to view operations from other connectors, right-click on the chart, select Edit
Chart or click on the "Edit Latency Chart" button and choose the specific operation and connectors.
Sync Object Changes
This feature provides a graphical trend of the number of changes that are being evaluated and exported to
Azure AD. Today, trying to gather this information from the sync logs is difficult. The chart gives you, not only a
simpler way of monitoring the number of changes that are occurring in your environment, but also a visual
view of the failures that are occurring.
Object Level Synchronization Error Report
This feature provides a report about synchronization errors that can occur when identity data is synchronized
between Windows Server AD and Azure AD using Azure AD Connect.
The report covers errors recorded by the sync client (Azure AD Connect version 1.1.281.0 or higher)
It includes the errors that occurred in the last synchronization operation on the sync engine. ("Export" on
the Azure AD Connector.)
Azure AD Connect Health agent for sync must have outbound connectivity to the required end points for
the report to include the latest data.
The report is updated after ever y 30 minutes using the data uploaded by Azure AD Connect Health
agent for sync. It provides the following key capabilities
Categorization of errors
List of objects with error per category
All the data about the errors at one place
Side by side comparison of Objects with error due to a conflict
Download the error report as a CVS
Categorization of Errors
The report categorizes the existing synchronization errors in the following categories:
C AT EGO RY DESC RIP T IO N
Duplicate Attribute Errors when Azure AD Connect attempts create or update

objects with duplicated values of one or more attributes in
Azure AD that must be unique in a Tenant, such as
proxyAddresses, UserPrincipalName.
Data Mismatch Errors when the soft-match fails to match objects that result
in synchronization errors.
Data Validation Failure Errors due to invalid data, such as unsupported characters in
critical attributes such as UserPrincipalName, format errors
that fail validation before being written in Azure AD.
Federated Domain Change Errors when accounts use a different federated domain.
Large Attribute Errors when one or more attributes are larger than the
allowed size, length or count.
Other All other errors that don't fit in the above categories. Based
on feedback, this category will be split in sub categories.
List of objects with error per category
Drilling into each category will provide the list of objects having the error in that category.
Error Details
Following data is available in the detailed view for each error
Highlighted conflicting attribute
Identifiers for the AD Object involved
Identifiers for the Azure AD Object involved (as applicable)
Error description and how to fix
Download the error report as CSV
By selecting the "Export" button you can download a CSV file with all the details about all the errors.
Diagnose and remediate sync errors
For specific duplicated attribute sync error scenario involving user Source Anchor update, you can fix them
directly from the portal. Read more about Diagnose and remediate duplicated attribute sync errors
Related links
Troubleshooting Errors during synchronization
Duplicate Attribute Resiliency
The following documentation is specific to monitoring Active Directory Domain Services with Azure AD Connect
Health. The supported versions of AD DS are: Windows Server 2008 R2, Windows Server 2012, Windows Server
2012 R2, and Windows Server 2016.
For more information on monitoring AD FS with Azure AD Connect Health, see Using Azure AD Connect Health
with AD FS. Additionally, for information on monitoring Azure AD Connect (Sync) with Azure AD Connect Health
see Using Azure AD Connect Health for Sync.
Alerts for Azure AD Connect Health for AD DS

The Alerts section within Azure AD Connect Health for AD DS, provides you a list of active and resolved alerts,
related to your domain controllers. Selecting an active or resolved alert opens a new blade with additional
information, along with resolution steps, and links to supporting documentation. Each alert type can have one or
more instances, which correspond to each of the domain controllers affected by that particular alert. Near the
bottom of the alert blade, you can double-click an affected domain controller to open an additional blade with
more details about that alert instance.
Within this blade, you can enable email notifications for alerts and change the time range in view. Expanding the
time range allows you to see prior resolved alerts.
Domain Controllers Dashboard

This dashboard provides a topological view of your environment, along with key operational metrics and health
status of each of your monitored domain controllers. The presented metrics help to quickly identify, any domain
controllers that might require further investigation. By default, only a subset of the columns is displayed.
However, you can find the entire set of available columns, by double-clicking the columns command. Selecting
the columns that you most care about, turns this dashboard into a single and easy place to view the health of
your AD DS environment.
Domain controllers can be grouped by their respective domain or site, which is helpful for understanding the
environment topology. Lastly, if you double-click the blade header, the dashboard maximizes to utilize the
available screen real-estate. This larger view is helpful when multiple columns are displayed.
Replication Status Dashboard
This dashboard provides a view of the replication status and replication topology of your monitored domain
controllers. The status of the most recent replication attempt is listed, along with helpful documentation for any
error that is found. You can double-click a domain controller with an error, to open a new blade with information
such as: details about the error, recommended resolution steps, and links to troubleshooting documentation.
Monitoring
This feature provides graphical trends of different performance counters, which are continuously collected from
each of the monitored domain controllers. Performance of a domain controller can easily be compared across all
other monitored domain controllers in your forest. Additionally, you can see various performance counters side
by side, which is helpful when troubleshooting issues in your environment.
By default, we have preselected four performance counters; however, you can include others by clicking the filter
command and selecting or deselecting any desired performance counters. Additionally, you can double-click a
performance counter graph to open a new blade, which includes data points for each of the monitored domain
controllers.
Related links
Health service data is not up to date alert
Overview
The agents on the on-premises machines that Azure AD Connect Health monitors periodically upload data to the
Azure AD Connect Health Service. If the service does not receive data from an agent, the information the portal
presents will be stale. To highlight the issue, the service will raise the Health ser vice data is not up to date
alert. This alert is generated when the service has not received complete data in the past two hours.
The Warning status alert fires if the Health Service has received only par tial data types sent from the server in
the past two hours. The warning status alert does not trigger email notifications to configured recipients.
The Error status alert fires if the Health Service has not received any data types from the server in the past two
hours. The error status alert triggers email notifications to configured recipients.
The service gets the data from agents that are running on the on-premises machines, depending on the service
type. The following table lists the agents that run on the machine, what they do, and the data types that the service
generates. In some cases, there are multiple services involved in the process, so any of them could be the culprit.
Understanding the alert

The Aler t Details blade shows when the alert occurred and was last detected. A background process that runs
every two hours generates and re-evaluates the alert. In the following example, the initial alert occurred on 03/10
at 9:59 AM. The alert still existed on 03/12 at 10:00 AM when the alert was evaluated again. The blade also details
the time the Health Service last received a particular data type.
The following table maps service types to corresponding required data types:
A GEN T ( W IN DO W S SERVIC E
SERVIC E T Y P E N A M E) P URP O SE DATA T Y P E GEN ERAT ED
Azure AD Connect (Sync) Azure AD Connect Health Collect AAD Connect-specific - AadSyncService-
Sync Insights Service information (connectors, SynchronizationRules
synchronization rules, etc.) - AadSyncService-
Connectors
- AadSyncService-
GlobalConfigurations
- AadSyncService-
RunProfileResults
- AadSyncService-
ServiceConfigurations
- AadSyncService-
ServiceStatus
Azure AD Connect Health Collect AAD Connect-specific Performance counter

Sync Monitoring Service perf counters, ETW traces,
files
AD DS Azure AD Connect Health Perform synthetic tests, - Adds-TopologyInfo-Json

AD DS Insights Service collect topology information, - Common-TestData-Json
replication metadata (creates the test results)
Azure AD Connect Health Collect ADDS-specific perf - Performance counter

AD DS Monitoring Service counters, ETW traces, files - Common-TestData-Json
(uploads the test results)
AD FS Azure AD Connect Health Perform synthetic tests TestResult (creates the test
AD FS Diagnostics Service results)
Azure AD Connect Health Collect ADFS usage metrics Adfs-UsageMetrics

AD FS Insights Service
Azure AD Connect Health Collect ADFS-specific perf TestResult (uploads the test
AD FS Monitoring Service counters, ETW traces, files results)
Troubleshooting steps
The steps required to diagnose the issue is given below. The first is a set of basic checks that are common to all
Service Types.
IMPORTANT
This alert follows Connect Health data retention policy
Make sure the latest versions of the agents are installed. View release history.
Make sure that Azure AD Connect Health Agents services are running on the machine. For example,
Connect Health for AD FS should have three services.
Make sure to go over and meet the requirements section.
Use test connectivity tool to discover connectivity issues.
If you have an HTTP Proxy, follow these configuration steps.
Next steps
If any of the above steps identified an issue, fix it and wait for the alert to resolve. The alert background process
runs every 2 hours, so it will take up to 2 hours to resolve the alert.
Azure AD Connect Health data retention policy
Diagnose and remediate duplicated attribute sync
errors
Overview
Taking one step farther to highlight sync errors, Azure Active Directory (Azure AD) Connect Health introduces self-
service remediation. It troubleshoots duplicated attribute sync errors and fixes objects that are orphaned from
Azure AD. The diagnosis feature has these benefits:
It provides a diagnostic procedure that narrows down duplicated attribute sync errors. And it gives specific fixes.
It applies a fix for dedicated scenarios from Azure AD to resolve the error in a single step.
No upgrade or configuration is required to enable this feature. For more information about Azure AD, see
Identity synchronization and duplicate attribute resiliency.
Problems
A common scenario
When QuarantinedAttributeValueMustBeUnique and AttributeValueMustBeUnique sync errors happen, it's
common to see a UserPrincipalName or Proxy Addresses conflict in Azure AD. You might solve the sync errors
by updating the conflicting source object from the on-premises side. The sync error will be resolved after the next
sync. For example, this image indicates that two users have a conflict of their UserPrincipalName . Both are
Joe.J@contoso.com . The conflicting objects are quarantined in Azure AD.
Orphaned object scenario

Occasionally, you might find that an existing user loses the Source Anchor . The deletion of the source object
happened in on-premises Active Directory. But the change of deletion signal never got synchronized to Azure AD.
This loss happens for reasons like sync engine issues or domain migration. When the same object gets restored or
recreated, logically, an existing user should be the user to sync from the Source Anchor .
When an existing user is a cloud-only object, you can also see the conflicting user synchronized to Azure AD. The
user can't be matched in sync to the existing object. There's no direct way to remap the Source Anchor . See more
about the existing knowledge base.
As an example, the existing object in Azure AD preserves the license of Joe. A newly synchronized object with a
different Source Anchor occurs in a duplicated attribute state in Azure AD. Changes for Joe in on-premises Active
Directory won't be applied to Joe’s original user (existing object) in Azure AD.
Diagnostic and troubleshooting steps in Connect Health

The diagnose feature supports user objects with the following duplicated attributes:
AT T RIB UT E N A M E SY N C H RO N IZ AT IO N ERRO R T Y P ES
UserPrincipalName QuarantinedAttributeValueMustBeUnique or
AttributeValueMustBeUnique
ProxyAddresses QuarantinedAttributeValueMustBeUnique or
SipProxyAddress AttributeValueMustBeUnique
OnPremiseSecurityIdentifier AttributeValueMustBeUnique
IMPORTANT
To access this feature, Global Admin permission, or Contributor permission from Azure RBAC, is required.
Follow the steps from the Azure portal to narrow down the sync error details and provide more specific solutions:
From the Azure portal, take a few steps to identify specific fixable scenarios:
1. Check the Diagnose status column. The status shows if there's a possible way to fix a sync error directly from
Azure Active Directory. In other words, a troubleshooting flow exists that can narrow down the error case and
potentially fix it.
STAT US W H AT DO ES IT M EA N ?
Not Started You haven't visited this diagnosis process. Depending on the
diagnostic result, there's a potential way to fix the sync error
directly from the portal.
Manual Fix Required The error doesn't fit the criteria of available fixes from the
portal. Either conflicting object types aren't users, or you
already went through the diagnostic steps, and no fix
resolution was available from the portal. In the latter case, a fix
from the on-premises side is still one of the solutions. Read
more about on-premises fixes.
Pending Sync A fix was applied. The portal is waiting for the next sync cycle
to clear the error.
IMPORTANT
The diagnostic status column will reset after each sync cycle.
1. Select the Diagnose button under the error details. You'll answer a few questions and identify the sync error
details. Answers to the questions help identify an orphaned object case.
2. If a Close button appears at the end of the diagnostics, there's no quick fix available from the portal based
on your answers. Refer to the solution shown in the last step. Fixes from on-premises are still the solutions.
Select the Close button. The status of the current sync error switches to Manual fix required . The status
stays during the current sync cycle.
3. After an orphaned object case is identified, you can fix the duplicated attributes sync errors directly from the
portal. To trigger the process, select the Apply Fix button. The status of the current sync error updates to
Pending sync .
4. After the next sync cycle, the error should be removed from the list.
How to answer the diagnosis questions

Does the user exist in your on-premises Active Directory?
This question tries to identify the source object of the existing user from on-premises Active Directory.
1. Check if Azure Active Directory has an object with the provided UserPrincipalName . If not, answer No .
2. If it does, check whether the object is still in scope for syncing.
Search in the Azure AD connector space by using the DN.
If the object is found in the Pending Add state, answer No . Azure AD Connect can't connect the object to
the right Azure AD object.
If the object isn't found, answer Yes .
In these examples, the question tries to identify whether Joe Jackson still exists in on-premises Active Directory.
For the common scenario , both users Joe Johnson and Joe Jackson are present in on-premises Active
Directory. The quarantined objects are two different users.
For the orphaned object scenario , only the single user Joe Johnson is present in on-premises Active Directory:
Do both of these accounts belong to the same user?
This question checks an incoming conflicting user and the existing user object in Azure AD to see if they belong to
the same user.
1. The conflicting object is newly synced to Azure Active Directory. Compare the objects' attributes:
Display Name
User Principal Name
Object ID
2. If Azure AD fails to compare them, check whether Active Directory has objects with the provided
UserPrincipalNames . Answer No if you find both.
In the following example, the two objects belong to the same user Joe Johnson .
What happens after the fix is applied in the orphaned object scenario
Based on the answers to the preceding questions, you'll see the Apply Fix button when there's a fix available from
Azure AD. In this case, the on-premises object is syncing with an unexpected Azure AD object. The two objects are
mapped by using the Source Anchor . The Apply Fix change takes these or similar steps:
1. Updates the Source Anchor to the correct object in Azure AD.
2. Deletes the conflicting object in Azure AD if it's present.
IMPORTANT
The Apply Fix change applies only to orphaned object cases.
After the preceding steps, the user can access the original resource, which is a link to an existing object. The
Diagnose status value in the list view updates to Pending Sync . The sync error will be resolved after the next
sync. Connect Health will no longer show the resolved sync error in the list view.
Failures and error messages

User with conflicting attribute is soft deleted in the Azure Active Director y. Ensure the user is hard
deleted before retr y.
The user with conflicting attribute in Azure AD should be cleaned before you can apply fix. Check out how to delete
the user permanently in Azure AD before retrying the fix. The user will also be automatically deleted permanently
after 30 days in soft deleted state.
Updating source anchor to cloud-based user in your tenant is not suppor ted.
Cloud-based user in Azure AD should not have source anchor. Updating source anchor is not supported in this
case. Manual fix is required from on premises.
FAQ
Q. What happens if execution of the Apply Fix fails?
A. If execution fails, it's possible that Azure AD Connect is running an export error. Refresh the portal page and
retry after the next sync. The default sync cycle is 30 minutes.
Q. What if the existing object should be the object to be deleted?
A. If the existing object should be deleted, the process doesn't involve a change of Source Anchor . Usually, you
can fix it from on-premises Active Directory.
Q. What permission does a user need to apply the fix?
A. Global Admin , or Contributor from Azure RBAC, has permission to access the diagnostic and troubleshooting
process.
Q. Do I have to configure Azure AD Connect or update the Azure AD Connect Health agent for this feature?
A. No, the diagnosis process is a complete cloud-based feature.
Q. If the existing object is soft deleted, will the diagnosis process make the object active again?
A. No, the fix won't update object attributes other than Source Anchor .
Azure Active Directory Connect Health Alert Catalog
Azure AD Connect Health service send alerts indicate that your identity infrastructure is not healthy. This article includes alerts
titles, descriptions, and remediation steps for each alert.
Error, Warning, and Prewarning are three stages of alerts that are generated from Connect Health service. We highly recommend
you take immediate actions on triggered alerts.
Azure AD Connect Health alerts get resolved on a success condition. Azure AD Connect Health Agents detect and report the
success conditions to the service periodically. For a few alerts, the suppression is time-based. In other words, if the same error
condition is not observed within 72 hours from alert generation, the alert is automatically resolved.
General Alerts
A L ERT N A M E DESC RIP T IO N REM EDIAT IO N
Health service data is not up to date The Health Agent(s) running on one or more Ensure that the health agents have outbound
servers is not connected to the Health connectivity to the required service end
Service and the Health Service is not points. Read More
receiving the latest data from this server. The
last data processed by the Health Service is
older than 2 Hours.
Alerts for Azure AD Connect (Sync)

Azure AD Connect Sync Service is not Microsoft Azure AD Sync Windows service is Start Microsoft Azure Active Directory Sync
running not running or could not start. As a result, Services
objects will not synchronize with Azure Active 1. Click Star t , click Run , type
Directory. Ser vices.msc, and then click OK .
2. Locate the Microsoft Azure AD
Sync ser vice , and then check
whether the service is started. If the
service isn't started, right-click it, and
then click Star t .
Import from Azure Active Directory failed The import operation from Azure Active Investigate the event log errors of import
Directory Connector has failed. operation for further details.
Connection to Azure Active Directory failed Connection to Azure Active Directory failed Investigate the event log errors for further
due to authentication failure due to authentication failure. As a result details.
objects will not be synchronized with Azure
Active Directory.
Export to Active Directory failed The export operation to Active Directory Investigate the event log errors of export
Connector has failed. operation for further details.
Import from Active Directory failed Import from Active Directory failed. As a Verify DC connectivity
result, objects from some domains from this Rerun import manually
forest may not be imported. Investigate event log errors of the import
operation for further details.
Export to Azure Active Directory failed The export operation to Azure Active Investigate the event log errors of export
Directory Connector has failed. As a result, operation for further details.
some objects may not be exported
successfully to Azure Active Directory.
Password Hash Synchronization heartbeat Password Hash Synchronization has not Restart Microsoft Azure Active Directory Sync
was skipped in last 120 minutes connected with Azure Active Directory in the Services:
last 120 minutes. As a result, passwords will Any synchronization operations that are
not be synchronized with Azure Active currently running will be interrupted. You can
Directory. choose to perform below steps when no
synchronization operation is in progress.
1. Click Star t , click Run , type Ser vices.msc,
and then click OK .
2. Locate Microsoft Azure AD Sync, right-
click it, and then click Restar t .
High CPU Usage detected The percentage of CPU consumption crossed This could be a temporary spike in CPU
the recommended threshold on this server. consumption. Check the CPU usage trend
from the Monitoring section.
Inspect the top processes consuming the
highest CPU usage on the server.
1. You may use the Task Manager or
execute the following PowerShell
Command:
get-process | Sort-Object -
Descending CPU | Select-Object -First
10
2. If there are unexpected processes
consuming high CPU usage, stop the
processes using the following
PowerShell command:
stop-process -ProcessName [name of
the process]
If the processes seen in the above list are
the intended processes running on the server
and the CPU consumption is continuously
near the threshold please consider re-
evaluating the deployment requirements of
this server.
As a fail-safe option you may consider
restarting the server.
High Memory Consumption Detected The percentage of memory consumption of Inspect the top processes consuming the
the server is beyond the recommended highest memory on the server. You may use
threshold on this server. the Task Manager or execute the following
PowerShell Command:
get-process | Sort-Object -Descending WS |
Select-Object -First 10
If there are unexpected processes consuming
high memory, stop the processes using the
following PowerShell command:
stop-process -ProcessName [name of the
process]
If the processes seen in the above list are
the intended processes running on the
server, please consider re-evaluating the
deployment requirements of this server.
As a failsafe option, you may consider
restarting the server.
Password Hash Synchronization has stopped Password Hash Synchronization has stopped. Restart Microsoft Azure Active Directory Sync
working As a result passwords will not be Services:
synchronized with Azure Active Directory. Any synchronization operations that are
currently running will be interrupted. You can
choose to perform below steps when no
synchronization operation is in progress.
1. Click Star t , click Run , type
Ser vices.msc, and then click OK .
2. Locate the Microsoft Azure AD
Sync, right-click it, and then click
Restar t .
Export to Azure Active Directory was The export operation to Azure Active The number of objects are marked for
Stopped. Accidental delete threshold was Directory has failed. There were more objects deletion are greater than the set threshold.
reached to be deleted than the configured threshold. Ensure this outcome is desired.
As a result, no objects were exported. To allow the export to continue, perform
the following steps:
1. Disable Threshold by running Disable-
ADSyncExportDeletionThreshold
2. Start Synchronization Service
Manager
3. Run Export on Connector with type =
4. After successfully exporting the
objects, enable Threshold by running:
Enable-
ADSyncExportDeletionThreshold
Alerts for Active Directory Federation Services

Test Authentication Request (Synthetic The test authentication requests (Synthetic Ensure that the following steps are taken to
Transaction) failed to obtain a token Transactions) initiated from this server has validate the health of the server.
failed to obtain a token after 5 retries. This 1. Validate that there are no additional
may be caused due to transient network unresolved alerts for this or other AD
issues, AD DS Domain Controller availability FS servers in your farm.
or a mis-configured AD FS server. As a result, 2. Validate that this condition is not a
authentication requests processed by the transient failure by logging on with a
federation service may fail. The agent uses test user from the AD FS login page
the Local Computer Account context to available at
obtain a token from the Federation Service. https://{your_adfs_server_name}/adfs/l
s/idpinitiatedsignon.aspx
3. Go to
https://testconnectivity.microsoft.com
and choose the ‘Office 365’ tab.
Perform the ‘Office 365 Single Sign-
On Test’.
4. Verify if your AD FS service name can
be resolved from this server by
executing the following command
from a command prompt on this
server. nslookup
your_adfs_server_name
If the service name cannot be resolved,
refer to the FAQ section for instructions
of adding a HOST file entry of your AD
FS service with the IP address of this
server. This will allow the synthetic
transaction module running on this
server to request a token
The proxy server cannot reach the federation This AD FS proxy server is unable to contact Perform the following steps to validate the
server the AD FS service. As a result, authentication connectivity between this server and the AD
requests processed by this server will fail. FS service.
1. Ensure that the firewall between this
server and the AD FS service is
configured accurately.
2. Ensure that DNS resolution for the AD
FS service name appropriately points
to the AD FS service that resides
within the corporate network. This
can be achieved through a DNS
server that serves this server in the
perimeter network or through entries
in the HOSTS files for the AD FS
service name.
3. Validate the network connectivity by
opening up the browser on this
server and accessing the federation
metadata endpoint, which is at
https://<your-adfs-service-
name>/federationmetadata/2007-
06/federationmetadata.xml
The SSL Certificate is about to expire The TLS/SSL certificate used by the Update the TLS/SSL certificate on each AD FS
Federation servers is about to expire within server.
90 days. Once expired, any requests that 1. Obtain the TLS/SSL certificate with the
require a valid TLS connection will fail. For following requirements.
example, for Office 365 customers, mail a. Enhanced Key Usage is at least
clients will not be able to authenticate. Server Authentication.
b. Certificate Subject or Subject
Alternative Name (SAN)
contains the DNS name of the
Federation Service or
appropriate wild card. For
example: sso.contoso.com or
*.contoso.com
2. Install the new TLS/SSL certificate on
each server in the local machine
certificate store.
3. Ensure that the AD FS Service
Account has read access to the
certificate's Private Key
For AD FS 2.0 in Windows Ser ver
2008R2:
Bind the new TLS/SSL certificate to
the web site in IIS, which hosts the
Federation Service. Note that you
must perform this step on each
Federation Server and Federation
Server proxy.
For AD FS in Windows Ser ver 2012
R2 and later versions:
Refer to Managing SSL Certificates in AD
FS and WAP
AD FS service is not running on the server Active Directory Federation Service (Windows To start the Active Directory Federation
Service) is not running on this server. Any Service (Windows Service):
requests targeted to this server will fail. 1. Log on to the server as an
administrator.
2. Open services.msc
3. Find "Active Directory Federation
Services".
4. Right-click and select "Start".
DNS for the Federation Service may be The DNS server could be configured to use a Ensure that the DNS record type of the AD
misconfigured CNAME record for the AD FS farm name. It is FS farm <Farm Name> is not CNAME.
recommended to use A or AAAA record for Configure it to be an A or AAAA record.
AD FS in order for the Windows Integrated
Authentication to work seamlessly within
your corporate network.
AD FS Auditing is disabled AD FS Auditing is disabled for the server. AD If AD FS Audits are not enabled follow these
FS Usage section on the portal will not instructions:
include data from this server. 1. Grant the AD FS service account the
"Generate security audits" right on
the AD FS server.
2. Open the local security policy on the
server gpedit.msc.
3. Navigate to "Computer
Configuration\Windows Settings\Local
Policies\User Rights Assignment"
4. Add the AD FS Service Account to
have the "Generate security audits"
right.
5. Run the following command from the
command prompt:
auditpol.exe /set
/subcategory:"Application Generated"
/failure:enable /success:enable
6. Update Federation Service Properties
to include Success and Failure Audits.
7. In the AD FS console, choose "Edit
Federation Service Properties".
8. From "Federation Service Properties"
dialogue box choose the Events tab
and select "Success Audits" and
"Failure Audits".
After following these steps, AD FS Audit
Events should be visible from the Event
Viewer. To verify:
1. Go to Event Viewer/ Windows Logs
/Security.
2. Select Filter Current Logs and select
AD FS Auditing from the Event
sources drop down. For an active AD
FS server with AD FS auditing
enabled, events should be visible for
the above filtering.
If you have followed these instructions
before, but still seeing this alert, it is
possible that a Group Policy Object is
disabling AD FS auditing. The root cause
can be one of the following:
1. AD FS service account is being
removed from having the right to
Generate Security Audits.
2. A custom script in Group Policy
Object is disabling success and failure
audits based on "Application
Generated".
3. AD FS configuration is not enabled to
generate Success/Failure audits.
AD FS SSL certificate is self-signed You are currently using a self-signed Update the TLS/SSL certificate on each
certificate as the TLS/SSL certificate in your AD FS server.
AD FS farm. As a result, mail client
authentication for Office 365 will fail 1. Obtain a publicly trusted TLS/SSL
certificate with the following
requirements.
2. Certificate installation file contains its
private key.
3. Enhanced Key Usage is at least Server
Authentication.
4. Certificate Subject or Subject
Alternative Name (SAN) contains the
DNS name of the Federation Service
or appropriate wild card. For example:
sso.contoso.com or *.contoso.com
Install the new TLS/SSL certificate on
certificate store.
Ensure that the AD FS Service Account
has read access to the certificate's Private
Key.
2008R2:
1. Bind the new TLS/SSL certificate to
Server proxy.

R2 or later versions:
2. Refer to Managing SSL Certificates in
AD FS and WAP
The trust between the proxy server and The trust between the federation server Update the Proxy Trust Certificate on the
federation server is not valid proxy and the Federation Service could not proxy server. Re-Run the Proxy Configuration
be established or renewed. Wizard.
Extranet Lockout Protection Disabled for AD The Extranet Lockout Protection feature is Run the following command to enable AD FS
FS DISABLED on your AD FS farm. This feature Extranet Lockout Protection with default
protects your users from brute force values.
password attacks from the internet and Set-AdfsProperties -EnableExtranetLockout
prevents denial of service attacks against $true
your users when AD DS account lockout
policies are in effect. With this feature If you have AD lockout policies configured for
enabled, if the number of failed extranet login your users, ensure that the
attempts for a user (login attempts made via 'ExtranetLockoutThreshold' property is set to
WAP server and AD FS) exceed the a value below your AD DS lockout threshold.
'ExtranetLockoutThreshold' then AD FS This ensures that requests that have
servers will stop processing further login exceeded the threshold for AD FS are
attempts for ‘ExtranetObservationWindow' dropped and never validated against your AD
We highly recommend you enable this DS servers.
feature on your AD FS servers.
Invalid Service Principal Name (SPN) for the The Service Principal Name of the Federation Use [SETSPN -L Ser viceAccountName ] to
AD FS service account Service account is not registered or is not list the Service Principals.
unique. As a result, Windows Integrated Use [SETSPN -X ] to check for duplicate
Authentication from domain-joined clients Service Principal Names.
may not be seamless.
If SPN is duplicated for the AD FS service
account, remove the SPN from the
duplicated account using [SETSPN -d
ser vice/namehostname ]
If SPN is not set, use [SETSPN -s
{Desired-SPN} {domain_name}
{ser vice_account} ] to set the desired
SPN for the Federation Service Account.
The Primary AD FS Token Decrypting The Primary AD FS Token Decrypting If Auto-certificate roll-over is enabled, AD FS
certificate is about to expire certificate is about to expire in less than 90 manages the Token Decrypting Certificate.
days. AD FS cannot decrypt tokens from
trusted claims providers. AD FS cannot If you manage your certificate manually,
decrypt encrypted SSO cookies. The end please follow the below instructions.
users will not be able to authenticate to Obtain a new Token Decr ypting
access resources. Cer tificate.
1. Ensure that the Enhanced Key Usage
(EKU) includes "Key Encipherment".
2. Subject or Subject Alternative Name
(SAN) do not have any restrictions.
3. Note that your Federation Servers
and Claims Provider partners need to
be able to chain to a trusted root
certification authority when validating
your Token-Decrypting certificate.
Decide how your Claims Provider
par tners will trust the new Token-
Decr ypting cer tificate
1. Ask partners to pull the Federation
Metadata after updating the
certificate.
2. Share the public key of the new
certificate. (.cer file) with the partners.
On the Claims Provider partner's AD
FS server, launch AD FS Management
from the Administrative Tools menu.
Under Trust Relationships/Relying
Party Trusts, select the trust that was
created for you. Under
Properties/Encryption click "Browse"
to select the new Token-Decrypting
certificate and click OK.
Install the cer tificate in the local
cer tificate store on each of your
Federation Ser ver.
Ensure that the certificate installation
file has the Private Key of the
certificate on each server.
Ensure that the federation ser vice
account has access to the new
cer tificate's private key. Add the new
cer tificate to AD FS.
1. Launch AD FS Management from the
Administrative Tools menu
2. Expand Service and select Certificates
3. In the Actions pane, click Add Token-
Decrypting Certificate
4. You will be presented with a list of
certificates that are valid for Token-
Decrypting. If you find that your new
certificate is not being presented in
the list, you need to go back and
make sure that the certificate is in the
local computer personal store with a
private key associated and the
certificate has the Key Encipherment
as Extended Key Usage.
5. Select your new Token-Decrypting
certificate and click OK.
Set the new Token-Decr ypting
Cer tificate as Primar y.
1. With the Certificates node in AD FS
Management selected, you should
now see two certificates listed under
Token-Decrypting: existing and the
new certificate.
2. Select your new Token-Decrypting
certificate, right-click, and select Set as
primary.
3. Leave the old certificate as secondary
for roll-over purposes. You should
plan to remove the old certificate
once you are confident it is no longer
needed for roll-over, or when the
certificate has expired.
The Primary AD FS Token Signing certificate The AD FS token signing certificate is about Obtain a new Token Signing Cer tificate.
is about to expire to expire within 90 days. AD FS cannot issue 1. Ensure that the Enhanced Key Usage
signed tokens when this certificate is not (EKU) includes "Digital Signature".
valid. 2. Subject or Subject Alternative Name
(SAN) does not have any restrictions.
3. Note that your Federation Servers,
your Resource Partner Federation
Servers and Relying Party Application
servers need to be able to chain to a
trusted root certificate authority when
validating your Token-Signing
certificate.
Install the cer tificate in the local
cer tificate store on each Federation
Ser ver.
Ensure that the certificate installation
file has the Private Key of the
certificate on each server.
Ensure that the Federation Ser vice
Account has access to the new
cer tificate's private key. Add the new
cer tificate to AD FS.
1. Launch AD FS Management from the
Administrative Tools menu.
2. Expand Service and select Certificates
3. In the Actions pane, click Add Token-
Signing Certificate...
4. You will be presented with a list of
certificates that are valid for Token-
Signing. If you find that your new
certificate is not being presented in
the list, you need to go back and
make sure that the certificate is in the
local computer Personal store with
private key associated and the
certificate has the Digital Signature
KU.
5. Select your new Token-Signing
certificate and click OK
Inform all the Relying Par ties about the
change in Token Signing Cer tificate.
1. Relying Parties that consume AD FS
federation metadata, must pull the
new Federation Metadata to start
using the new certificate.
2. Relying Parties that do NOT consume
AD FS federation metadata must
manually update the public key of the
new Token Signing Certificate. Share
the .cer file with the Relying Parties.
Set the new Token-Signing
1. With the Certificates node in AD
FS Management selected, you
should now see two certificates
listed under Token-Signing:
existing and the new certificate.
2. Select your new Token-Signing
certificate, right-click, and select
Set as primar y
3. Leave the old certificate as
secondary for rollover purposes.
You should plan to remove the
old certificate once you are
confident it is no longer needed
for rollover, or when the
certificate has expired. Note that
current users' SSO sessions are
signed. Current AD FS Proxy Trust
relationships utilize tokens that
are signed and encrypted using
the old certificate.
AD FS SSL certificate is not found in the local The certificate with the thumbprint that is Install the certificate with the configured
certificate store configured as the TLS/SSL certificate in the thumbprint in the local certificate store.
AD FS database was not found in the local
certificate store. As a result, any
authentication request over the TLS will fail.
For example mail client authentication for
Office 365 will fail.
The SSL Certificate expired The TLS/SSL certificate for the AD FS service Update the TLS/SSL certificate on each AD FS
has expired. As a result, any authentication server.
requests that require a valid TLS connection 1. Obtain the TLS/SSL certificate with the
will fail. For example: mail client following requirements.
authentication will not be able to 2. Enhanced Key Usage is at least Server
authenticate for Office 365. Authentication.
3. Certificate Subject or Subject
Alternative Name (SAN) contains the
DNS name of the Federation Service
or appropriate wild card. For example:
sso.contoso.com or *.contoso.com
certificate store.
2008R2:
Server proxy.
R2 or later versions: Refer to:
Managing SSL Certificates in AD FS and
WAP
The Required end points for Azure Active The following set of end points required by Enable the required end points for the
Directory (for Office 365) are not enabled the Exchange Online Services, Azure AD, and Microsoft Cloud Services on your federation
Office 365 are not enabled for the federation service.
service: For AD FS in Windows Server 2012R2 or later
/adfs/services/trust/2005/usernamemixed versions
/adfs/ls/ Refer to: Managing SSL Certificates in AD
FS and WAP
The Federation server was unable to connect The AD FS service account is experiencing Ensure that the AD FS service account has
to the AD FS Configuration Database issues while connecting to the AD FS access to the configuration database.
configuration database. As a result, the AD FS Ensure that the AD FS Configuration
service on this computer may not function as Database service is available and reachable.
expected.
Required SSL bindings are missing or not The TLS bindings required for this federation For Windows Server 2012 R2
configured server to successfully perform authentication Open an elevated admin command prompt
are misconfigured. As a result, AD FS cannot and execute the following commands:
process any incoming requests. 1. To view the current TLS binding:
Get-AdfsSslCertificate
2. To add new bindings:
netsh http add sslcert hostnameport=<federation service
name>:443
certhash=0102030405060708090A0B0C0D0E0F10111213
appid={00112233-4455-6677-8899-AABBCCDDEEFF}
certstorename=MY
The Primary AD FS Token Signing certificate The AD FS Token Signing certificate has If Auto-certificate rollover is enabled, AD FS
has expired expired. AD FS cannot issue signed tokens will manage updating the Token Signing
when this certificate is not valid. Certificate.
If you manage your certificate manually,
follow the below instructions.
1. Obtain a new Token Signing
Cer tificate.
a. Ensure that the Enhanced Key
Usage (EKU) includes "Digital
Signature".
b. Subject or Subject Alternative
Name (SAN) does not have
any restrictions.
c. Remember that your
Federation Servers, your
Resource Partner Federation
Servers and Relying Party
Application servers need to be
able to chain to a trusted root
certificate authority when
validating your Token-Signing
certificate.
2. Install the cer tificate in the local
cer tificate store on each
Federation Ser ver.
Ensure that the certificate
installation file has the Private
Key of the certificate on each
server.
3. Ensure that the Federation
Ser vice Account has access to
the new cer tificate's private key.
4. Add the new cer tificate to AD
FS.
a. Launch AD FS Management
from the Administrative Tools
menu.
b. Expand Service and select
Certificates
c. In the Actions pane, click Add
Token-Signing Certificate...
d. You will be presented with a
list of certificates that are valid
for Token-Signing. If you find
that your new certificate is not
being presented in the list, you
need to go back and make
sure that the certificate is in
the local computer Personal
store with private key
associated and the certificate
has the Digital Signature KU.
e. Select your new Token-Signing
certificate and click OK
5. Inform all the Relying Par ties
about the change in Token
Signing Cer tificate.
a. Relying Parties that consume
AD FS federation metadata,
must pull the new Federation
Metadata to start using the
new certificate.
b. Relying Parties that do NOT
consume AD FS federation
metadata must manually
update the public key of the
new Token Signing Certificate.
Share the .cer file with the
Relying Parties.
6. Set the new Token-Signing
a. With the Certificates node in
AD FS Management selected,
you should now see two
certificates listed under Token-
Signing: existing and the new
certificate.
b. Select your new Token-Signing
certificate, right-click, and
select Set as primar y
c. Leave the old certificate as
secondary for rollover
purposes. You should plan to
remove the old certificate once
you are confident it is no
longer needed for rollover, or
when the certificate has
expired. Remember that
current users' SSO sessions are
signed. Current AD FS Proxy
Trust relationships utilize
tokens that are signed and
encrypted using the old
certificate.
Proxy server is dropping requests for This proxy server is currently dropping Verify if the network latency between the
congestion control requests from the extranet due to a higher Federation Proxy Server and the Federation
than normal latency between this proxy Servers falls within the acceptable range.
server and the federation server. As a result, Refer to the Monitoring Section for trending
certain portion of the authentication values of the "Token Request Latency". A
requests processed by the AD FS Proxy latency greater than [1500 ms] should be
server can fail. considered as high latency. If high latency is
observed, ensure the network between AD
FS and AD FS Proxy servers does not have
any connectivity issues.
Ensure Federation Servers are not
overloaded with authentication requests.
Monitoring Section provides trending views
for Token Requests per second, CPU
utilization and Memory consumption.
If the above items have been verified and
this issue is still seen, adjust the congestion
avoidance setting on each of the Federation
Proxy Servers as per the guidance from the
related links.
The AD FS service account is denied access to The AD FS service account does not have Ensure that the AD FS service account is
one of the certificate's private key. access to the private key of one of the AD FS provided access to the TLS, token signing,
certificates on this computer. and token decryption certificates stored in
the local computer certificate store.
1. From Command Line type MMC.
2. Go to File->Add/Remove Snap-In
3. Select Certificates and click Add. ->
Select Computer Account and click
Next. -> Select Local Computer and
click Finish. Click OK.
Open Certificates(Local
Computer)/Personal/Certificates.For all the
certificates that are used by AD FS:
1. Right-click the certificate.
2. Select All Tasks -> Manage Private
Keys.
3. On the Security Tab under Group or
user names ensure that the AD FS
service account is present. If not
select Add and add the AD FS service
account.
4. Select the AD FS service account and
under "Permissions for <AD FS
Service Account Name>" make sure
Read permission is allowed (check
mark).
The AD FS SSL certificate does not have a AD FS TLS/SSL certificate was installed Update the TLS/SSL certificate on each AD FS
private key without a private key. As a result any server.
authentication request over the SSL will fail. 1. Obtain a publicly trusted TLS/SSL
For example, mail client authentication for certificate with the following
Office 365 will fail. requirements.
a. Certificate installation file
contains its private key.
b. Enhanced Key Usage is at least
Server Authentication.
c. Certificate Subject or Subject
Alternative Name (SAN)
contains the DNS name of the
Federation Service or
appropriate wild card. For
example: sso.contoso.com or
*.contoso.com
certificate store.
2008R2:
the web site in IIS which hosts the
Server proxy.
R2 or later versions:
Refer to: Managing SSL Certificates in AD
FS and WAP
The Primary AD FS Token Decrypting The Primary AD FS Token Decrypting If Auto-certificate roll-over is enabled, AD
certificate has expired certificate has expired. AD FS cannot decrypt FS manages the Token Decrypting
tokens from trusted claims providers. AD FS Certificate.
cannot decrypt encrypted SSO cookies. The
end users will not be able to authenticate to If you manage your certificate manually,
access resources. follow the below instructions.
1. Obtain a new Token Decr ypting
Cer tificate.
Ensure that the Enhanced Key
Usage (EKU) includes "Key
Encipherment".
Subject or Subject Alternative
Name (SAN) do not have any
restrictions.
Note that your Federation
Servers and Claims Provider
partners need to be able to
chain to a trusted root
certification authority when
validating your Token-
Decrypting certificate.
2. Decide how your Claims Provider
par tners will trust the new
Token-Decr ypting cer tificate
Ask partners to pull the
Federation Metadata after
updating the certificate.
Share the public key of the
new certificate. (.cer file) with
the partners. On the Claims
Provider partner's AD FS
server, launch AD FS
Management from the
Administrative Tools menu.
Under Trust
Relationships/Relying Party
Trusts, select the trust that was
created for you. Under
Properties/Encryption click
"Browse" to select the new
Token-Decrypting certificate
and click OK.
3. Install the cer tificate in the local
cer tificate store on each of your
Federation Ser ver.
Ensure that the certificate
installation file has the Private
Key of the certificate on each
server.
4. Ensure that the federation
ser vice account has access to
the new cer tificate's private key.
5. Add the new cer tificate to AD
FS.
Launch AD FS Management
from the Administrative Tools
menu
Expand Service and select
Certificates
In the Actions pane, click Add
Token-Decrypting Certificate
You will be presented with a
list of certificates that are valid
for Token-Decrypting. If you
find that your new certificate is
not being presented in the list,
you need to go back and
make sure that the certificate
is in the local computer
personal store with a private
key associated and the
certificate has the Key
Encipherment as Extended Key
Usage.
Select your new Token-
Decrypting certificate and click
OK.
6. Set the new Token-Decr ypting
With the Certificates node in
AD FS Management selected,
you should now see two
certificates listed under Token-
Decrypting: existing and the
new certificate.
Select your new Token-
Decrypting certificate, right-
click, and select Set as primary.
Leave the old certificate as
secondary for roll-over
purposes. You should plan to
remove the old certificate once
you are confident it is no
longer needed for roll-over, or
when the certificate has
expired.
Alerts for Active Directory Domain Services

Domain controller is unreachable via LDAP Domain Controller is not reachable via LDAP Examine alerts list for related alerts, such
ping Ping. This can be caused due to Network as: Domain Controller is not advertising.
issues or machine issues. As a result, LDAP Ensure affected Domain Controller has
Pings will fail. sufficient disk space. Running out of space
will stop the DC from advertising itself as an
LDAP server.
Attempt to find the PDC: Run
netdom query fsmo
on the affected Domain Controller.
Ensure physical network is properly
configured/connected.
Active Directory replication error This domain controller is experiencing See additional details for the names of the
encountered replication issues, which can be found by affected source and destination DCs.
going to the Replication Status Dashboard. Navigate to Replication Status dashboard and
Replication errors may be due to improper look for the active errors on the affected DCs.
configuration or other related issues. Click on the error to open a blade with more
Untreated replication errors can lead to data details on how to remediate that particular
inconsistency. error.
Domain controller is unable to find a PDC A PDC is not reachable through this domain Examine alerts list for related alerts that
controller. This will lead to impacted user could be impacting your PDC, such as:
logons, unapplied group policy changes, and Domain Controller is not advertising.
system time synchronization failure. Attempt to find the PDC: Run
netdom query fsmo
Ensure network is working properly.
Domain controller is unable to find a Global A global catalog server is not reachable from Examine the alerts list for any Domain
Catalog server this domain controller. It will result in failed Controller is not adver tising alerts where
authentications attempted through this the impacted server might be a GC. If there
Domain Controller. are no advertising alerts, check the SRV
records for the GCs. You can check them by
running:
nltest /dnsgetdc: [ForestName] /gc
It should list the DCs advertising as GCs. If
the list is empty, check the DNS configuration
to ensure that the GC has registered the SRV
records. The DC is able to find them in DNS.
For troubleshooting Global Catalogs, see
Advertising as a Global Catalog Server.
Domain controller unable to reach local Sysvol contains important elements from See How to troubleshoot missing SYSVOL
SYSVOL share Group Policy Objects and scripts to be and Netlogon shares
distributed within DCs of a domain. The DC
will not advertise itself as DC and Group
Policies will not be applied.
Domain Controller time is out of sync The time on this Domain Controller is outside Restart Windows Time Service: Run
of the normal Time Skew range. As a result, net stop w32time
Kerberos authentications will fail. then
net start w32time
Resync Time: Run
w32tm /resync
Domain controller is not advertising This domain controller is not properly Examine alerts list for other related alerts
advertising the roles it's capable of such as: Replication is broken. Domain
performing. This can be caused by problems controller time is out of sync. Netlogon
with replication, DNS misconfiguration, critical service is not running. DFSR and/or NTFRS
services not running, or because of the services are not running. Identify and
server not being fully initialized. As a result, troubleshoot related DNS problems: Logon
domain controllers, domain members, and to affected Domain controller. Open System
other devices will not be able to locate this Event Log. If events 5774, 5775 or 5781 are
domain controller. Additionally, other domain present, see Troubleshooting Domain
controllers might not be able to replicate Controller Locator DNS Records Registration
from this domain controller. Failure Identify and troubleshoot related
Windows Time Service Issues: Ensure
Windows Time service is running: Run 'net
star t w32time ' on the affected Domain
Controller. Restart Windows Time Service:
Run 'net stop w32time ' then 'net star t
w32time ' on the affected Domain Controller.
GPSVC service is not running If the service is stopped or disabled, settings Run
configured by the admin will not be applied net start gpsvc
and applications and components will not be on the affected Domain Controller.
manageable through Group Policy. Any
components or applications that depend on
the Group Policy component might not be
functional if the service is disabled.
DFSR and/or NTFRS services are not running If both DFSR and NTFRS services are stopped, If using DFSR:
Domain Controllers will not be able to Run 'net star t dfsr ' on the affected
replicate SYSVOL data. SYSVOL Data will be Domain Controller.
out of consistency.
If using NTFRS:
Run 'net star t ntfrs ' on the affected
Domain Controller.
Netlogon service is not running Logon requests, registration, authentication, Run 'net star t netlogon ' on the affected
and locating of domain controllers will be Domain Controller
unavailable on this DC.
W32Time service is not running If Windows Time Service is stopped, date and Run 'net star t win32Time ' on the affected
time synchronization will be unavailable. If Domain Controller
this service is disabled, any services that
explicitly depend on it will fail to start.
ADWS service is not running If Active Directory Web Services service is Run 'net star t adws ' on the affected
stopped or disabled, client applications, such Domain Controller
as Active Directory PowerShell, will not be
able to access or manage any directory
service instances that are running locally on
this server.
Root PDC is not Syncing from NTP Server If you do not configure the PDC to On the affected Domain Controller, open a
synchronize time from an external or internal command prompt. Stop the Time service: net
time source, the PDC emulator uses its stop w32time
internal clock and is itself the reliable time Configure the external time source:
source for the forest. If time is not accurate w32tm /config /manualpeerlist:
on the PDC itself, all computers will have time.windows.com /syncfromflags:manual
incorrect time settings. /reliable:yes
Note: Replace time.windows.com with the

address of your desired external time source.
Start the Time service:
net start w32time
Domain controller is quarantined This Domain Controller is not connected to Enable inbound and outbound replication:
any of the other working Domain Controllers. Run 'repadmin /options Ser verName -
This may be caused due to improper DISABLE_INBOUND_REPL ' on the affected
configuration. As a result, this DC is not Domain Controller. Run 'repadmin /options
being used and will not replicate from/to Ser verName -
anyone. DISABLE_OUTBOUND_REPL ' on the
affected Domain Controller. Create a new
replication connection to another Domain
Controller:
1. Open Active Directory Sites and
Services: Start menu, point to
Administrative Tools, then click Active
Directory Sites and Services.
2. In the console tree, expand Sites, and
then expand the site, which this DC
belongs to.
3. Expand the Servers container to
display the list of servers.
4. Expand the server object for this DC.
5. Right-click the NTDS Settings object,
and click on New Active Directory
Domain Services Connection...
6. Select a Server from the list, and click
Ok.
How to remove orphaned domains from
Active Directory.
Outbound Replication is Disabled DCs with disabled Outbound Replication, will To enable outbound replication on the
not be able to distribute any changes affected Domain Controller, follow these
originating within itself. steps: Click Start, click Run, type cmd and
then click OK. Type the following text, and
then press ENTER:
repadmin /options -
DISABLE_OUTBOUND_REPL
Inbound Replication is Disabled DCs with disabled Inbound Replication, will To enable inbound replication on the affected
not have the latest information. This Domain Controller, follow these steps: Click
condition can lead to logon failures. Start, click Run, type cmd and then click OK.
Type the following text, and then press
ENTER:
repadmin /options -
DISABLE_INBOUND_REPL
LanmanServer service is not running If this service is disabled, any services that Run 'net star t LanManSer ver ' on the
explicitly depend on it will fail to start. affected Domain Controller.
Kerberos Key Distribution Center service is If KDC Service is stopped, users will not be Run 'net star t kdc' on the affected Domain
not running able to authentication through this DC using Controller.
the Kerberos v5 authentication protocol.
DNS service is not running If DNS Service is stopped, computers and Run 'net star t dns ' on the affected Domain
users using that server for DNS purposes will Controller.
fail to find resources.
DC had USN Rollback When USN rollbacks occur, modifications to There are two approaches to recover from a
objects and attributes are not inbound USN rollback:
replicated by destination domain controllers Remove the Domain Controller from the
that have previously seen the USN. Because domain, following these steps:
these destination domain controllers believe
they are up to date, no replication errors are 1. Remove Active Directory from the
reported in Directory Service event logs or domain controller to force it to be a
by monitoring and diagnostic tools. USN stand-alone server. For more
rollback may affect the replication of any information, click the following article
object or attribute in any partition. The most number to view the article in the
frequently observed side effect is that user Microsoft Knowledge Base:
accounts and computer accounts that are 332199 Domain controllers do not
created on the rollback domain controller do
created on the rollback domain controller do demote gracefully when you use the
A L ERT N A M E DESC RIP Ton
not exist IO None or more replication partners. REM EDIAT IO N
Active Directory Installation Wizard to
Or, the password updates that originated on force demotion in Windows Server
the rollback domain controller do not exist on 2003 and in Windows 2000 Server.
replication partners. 2. Shut down the demoted server.
3. On a healthy domain controller, clean
up the metadata of the demoted
domain controller. For more
information, click the following article
number to view the article in the
Microsoft Knowledge Base:
216498 How to remove data in Active
Directory after an unsuccessful
domain controller demotion
4. If the incorrectly restored domain
controller hosts operations master
roles, transfer these roles to a healthy
domain controller. For more
information, click the following article
number to view the article in the
Microsoft Knowledge Base:
255504 Using Ntdsutil.exe to transfer
or seize FSMO roles to a domain
controller
5. Restart the demoted server.
6. If you are required to, install Active
Directory on the stand-alone server
again.
7. If the domain controller was
previously a global catalog, configure
the domain controller to be a global
catalog. For more information, click
the following article number to view
the article in the Microsoft Knowledge
Base:
313994 How to create or move a
global catalog in Windows 2000
8. If the domain controller previously
hosted operations master roles,
transfer the operations master roles
back to the domain controller. For
more information, click the following
article number to view the article in
the Microsoft Knowledge Base:
255504 Using Ntdsutil.exe to transfer
or seize FSMO roles to a domain
controller Restore the system state of
a good backup.
Evaluate whether valid system state
backups exist for this domain controller. If
a valid system state backup was made
before the rolled-back domain controller
was incorrectly restored, and the backup
contains recent changes that were made
on the domain controller, restore the
system state from the most recent
backup.
You can also use the snapshot as a
source of a backup. Or you can set the
database to give itself a new invocation
ID using the procedure in the section "To
restore a previous version of a virtual
domain controller VHD without system
state data backup" in this article
Next steps
Azure AD Connect Health instructions for data
retrieval
This document describes how to use Azure AD Connect to retrieve data from Azure AD Connect Health.
NOTE
Retrieve all email addresses for users configured for health alerts.
To retrieve the email addresses for all of your users that are configured in Azure AD Connect Health to receive
alerts, use the following steps.
1. Start at the Azure Active Directory Connect health blade and select Sync Ser vices from the left-hand
navigation bar.
2. Click on the Aler ts tile.

3. Click on Notification Settings .
4. On the Notification Setting blade, you will find the list of email addresses that have been enabled as
recipients for health Alert notifications.
Retrieve accounts that were flagged with AD FS Bad Password attempts

To retrieve accounts that were flagged with AD FS Bad Password attempts, use the following steps.
1. Starting on the Azure Active Directory Health blade, select Sync Errors .
2. In the Sync Errors blade, click on Expor t . This will export a list of the recorded sync errors.
Next Steps
Azure AD Connect: Staging server and disaster
recovery
With a server in staging mode, you can make changes to the configuration and preview the changes before you
make the server active. It also allows you to run full import and full synchronization to verify that all changes
are expected before you make these changes into your production environment.
Staging mode
Staging mode can be used for several scenarios, including:
High availability.
Test and deploy new configuration changes.
Introduce a new server and decommission the old.
During installation, you can select the server to be in staging mode . This action makes the server active for
import and synchronization, but it does not run any exports. A server in staging mode is not running password
sync or password writeback, even if you selected these features during installation. When you disable staging
mode, the server starts exporting, enables password sync, and enables password writeback.
NOTE
Suppose you have an Azure AD Connect with Password Hash Synchronization feature enabled. When you enable staging
mode, the server stops synchronizing password changes from on-premises AD. When you disable staging mode, the
server resumes synchronizing password changes from where it last left off. If the server is left in staging mode for an
extended period of time, it can take a while for the server to synchronize all password changes that had occurred during
the time period.
You can still force an export by using the synchronization service manager.
A server in staging mode continues to receive changes from Active Directory and Azure AD and can quickly take
over the responsibilities of another server in the event of a failure. If you make configuration changes to your
primary server, it is your responsibility to make the same changes to the server in staging mode.
For those of you with knowledge of older sync technologies, the staging mode is different since the server has
its own SQL database. This architecture allows the staging mode server to be located in a different datacenter.
Verify the configuration of a server
To apply this method, follow these steps:
1. Prepare
2. Configuration
3. Import and Synchronize
4. Verify
5. Switch active server
Prepare
1. Install Azure AD Connect, select staging mode , and unselect star t synchronization on the last page in the
installation wizard. This mode allows you to run the sync engine manually.
2. Sign off/sign in and from the start menu select Synchronization Ser vice .
Configuration
If you have made custom changes to the primary server and want to compare the configuration with the
staging server, then use Azure AD Connect configuration documenter.
Import and Synchronize
1. Select Connectors , and select the first Connector with the type Active Director y Domain Ser vices . Click
Run , select Full impor t , and OK . Do these steps for all Connectors of this type.
2. Select the Connector with type Azure Active Director y (Microsoft) . Click Run , select Full impor t , and
OK .
3. Make sure the tab Connectors is still selected. For each Connector with type Active Director y Domain
Ser vices , click Run , select Delta Synchronization , and OK .
4. Select the Connector with type Azure Active Director y (Microsoft) . Click Run , select Delta
Synchronization , and OK .
You have now staged export changes to Azure AD and on-premises AD (if you are using Exchange hybrid
deployment). The next steps allow you to inspect what is about to change before you actually start the export to
the directories.
Verify
1. Start a cmd prompt and go to %ProgramFiles%\Microsoft Azure AD Sync\bin
2. Run: csexport "Name of Connector" %temp%\export.xml /f:x The name of the Connector can be found in
Synchronization Service. It has a name similar to "contoso.com – AAD" for Azure AD.
3. Run: CSExportAnalyzer %temp%\export.xml > %temp%\export.csv You have a file in %temp% named export.csv
that can be examined in Microsoft Excel. This file contains all changes that are about to be exported.
4. Make necessary changes to the data or configuration and run these steps again (Import and Synchronize
and Verify) until the changes that are about to be exported are expected.
Understanding the expor t.csv file Most of the file is self-explanatory. Some abbreviations to understand the
content:
OMODT – Object Modification Type. Indicates if the operation at an object level is an Add, Update, or Delete.
AMODT – Attribute Modification Type. Indicates if the operation at an attribute level is an Add, Update, or
delete.
Retrieve common identifiers The export.csv file contains all changes that are about to be exported. Each row
corresponds to a change for an object in the connector space and the object is identified by the DN attribute.
The DN attribute is a unique identifier assigned to an object in the connector space. When you have many
rows/changes in the export.csv to analyze, it may be difficult for you to figure out which objects the changes are
for based on the DN attribute alone. To simplify the process of analyzing the changes, use the csanalyzer.ps1
PowerShell script. The script retrieves common identifiers (for example, displayName, userPrincipalName) of the
objects. To use the script:
1. Copy the PowerShell script from the section CSAnalyzer to a file named csanalyzer.ps1 .
2. Open a PowerShell window and browse to the folder where you created the PowerShell script.
3. Run: .\csanalyzer.ps1 -xmltoimport %temp%\export.xml .
4. You now have a file named processedusers1.csv that can be examined in Microsoft Excel. Note that the file
provides a mapping from the DN attribute to common identifiers (for example, displayName and
userPrincipalName). It currently does not include the actual attribute changes that are about to be exported.
Switch active server
1. On the currently active server, either turn off the server (DirSync/FIM/Azure AD Sync) so it is not exporting to
Azure AD or set it in staging mode (Azure AD Connect).
2. Run the installation wizard on the server in staging mode and disable staging mode .
Disaster recovery
Part of the implementation design is to plan for what to do in case there is a disaster where you lose the sync
server. There are different models to use and which one to use depends on several factors including:
What is your tolerance for not being able make changes to objects in Azure AD during the downtime?
If you use password synchronization, do the users accept that they have to use the old password in Azure AD
in case they change it on-premises?
Do you have a dependency on real-time operations, such as password writeback?
Depending on the answers to these questions and your organization’s policy, one of the following strategies can
be implemented:
Rebuild when needed.
Have a spare standby server, known as staging mode .
Use virtual machines.
If you do not use the built-in SQL Express database, then you should also review the SQL High Availability
section.
Rebuild when needed
A viable strategy is to plan for a server rebuild when needed. Usually, installing the sync engine and do the
initial import and sync can be completed within a few hours. If there isn’t a spare server available, it is possible
to temporarily use a domain controller to host the sync engine.
The sync engine server does not store any state about the objects so the database can be rebuilt from the data
in Active Directory and Azure AD. The sourceAnchor attribute is used to join the objects from on-premises and
the cloud. If you rebuild the server with existing objects on-premises and the cloud, then the sync engine
matches those objects together again on reinstallation. The things you need to document and save are the
configuration changes made to the server, such as filtering and synchronization rules. These custom
configurations must be reapplied before you start synchronizing.
Have a spare standby server - staging mode
If you have a more complex environment, then having one or more standby servers is recommended. During
installation, you can enable a server to be in staging mode .
For more information, see staging mode.
Use virtual machines
A common and supported method is to run the sync engine in a virtual machine. In case the host has an issue,
the image with the sync engine server can be migrated to another server.
SQL High Availability
If you are not using the SQL Server Express that comes with Azure AD Connect, then high availability for SQL
Server should also be considered. The high availability solutions supported include SQL clustering and AOA
(Always On Availability Groups). Unsupported solutions include mirroring.
Support for SQL AOA was added to Azure AD Connect in version 1.1.524.0. You must enable SQL AOA before
installing Azure AD Connect. During installation, Azure AD Connect detects whether the SQL instance provided
is enabled for SQL AOA or not. If SQL AOA is enabled, Azure AD Connect further figures out if SQL AOA is
configured to use synchronous replication or asynchronous replication. When setting up the Availability Group
Listener, it is recommended that you set the RegisterAllProvidersIP property to 0. This is because Azure AD
Connect currently uses SQL Native Client to connect to SQL and SQL Native Client does not support the use of
MultiSubNetFailover property.
Appendix CSAnalyzer
See the section verify on how to use this script.
Param(
[Parameter(Mandatory=$true, HelpMessage="Must be a file generated using csexport 'Name of Connector'
export.xml /f:x)")]
[string]$xmltoimport="%temp%\exportedStage1a.xml",
[Parameter(Mandatory=$false, HelpMessage="Maximum number of users per output file")][int]$batchsize=1000,
[Parameter(Mandatory=$false, HelpMessage="Show console output")][bool]$showOutput=$false
[Parameter(Mandatory=$false, HelpMessage="Show console output")][bool]$showOutput=$false
)
#LINQ isn't loaded automatically, so force it

[Reflection.Assembly]::Load("System.Xml.Linq, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089") | Out-Null
[int]$count=1
[int]$outputfilecount=1
[array]$objOutputUsers=@()
#XML must be generated using "csexport "Name of Connector" export.xml /f:x"

write-host "Importing XML" -ForegroundColor Yellow
#XmlReader.Create won't properly resolve the file location,

#so expand and then resolve it
$resolvedXMLtoimport=Resolve-Path -Path ([Environment]::ExpandEnvironmentVariables($xmltoimport))
#use an XmlReader to deal with even large files

$result=$reader = [System.Xml.XmlReader]::Create($resolvedXMLtoimport)
$result=$reader.ReadToDescendant('cs-object')
do
{
#create the object placeholder
#adding them up here means we can enforce consistency
$objOutputUser=New-Object psobject
Add-Member -InputObject $objOutputUser -MemberType NoteProperty -Name ID -Value ""
Add-Member -InputObject $objOutputUser -MemberType NoteProperty -Name Type -Value ""
Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name DN -Value ""
Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name operation -Value ""
Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name UPN -Value ""
Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name displayName -Value ""
Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name sourceAnchor -Value ""
Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name alias -Value ""
Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name primarySMTP -Value ""
Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name onPremisesSamAccountName -Value ""
Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name mail -Value ""
$user = [System.Xml.Linq.XElement]::ReadFrom($reader)
if ($showOutput) {Write-Host Found an exported object... -ForegroundColor Green}
#object id
$outID=$user.Attribute('id').Value
if ($showOutput) {Write-Host ID: $outID}
$objOutputUser.ID=$outID
#object type
$outType=$user.Attribute('object-type').Value
if ($showOutput) {Write-Host Type: $outType}
$objOutputUser.Type=$outType
#dn
$outDN= $user.Element('unapplied-export').Element('delta').Attribute('dn').Value
if ($showOutput) {Write-Host DN: $outDN}
$objOutputUser.DN=$outDN
#operation
$outOperation= $user.Element('unapplied-export').Element('delta').Attribute('operation').Value
if ($showOutput) {Write-Host Operation: $outOperation}
$objOutputUser.operation=$outOperation
#now that we have the basics, go get the details
foreach ($attr in $user.Element('unapplied-export-hologram').Element('entry').Elements("attr"))

{
$attrvalue=$attr.Attribute('name').Value
$internalvalue= $attr.Element('value').Value
switch ($attrvalue)
{
{
"userPrincipalName"
{
if ($showOutput) {Write-Host UPN: $internalvalue}
$objOutputUser.UPN=$internalvalue
}
"displayName"
{
if ($showOutput) {Write-Host displayName: $internalvalue}
$objOutputUser.displayName=$internalvalue
}
"sourceAnchor"
{
if ($showOutput) {Write-Host sourceAnchor: $internalvalue}
$objOutputUser.sourceAnchor=$internalvalue
}
"alias"
{
if ($showOutput) {Write-Host alias: $internalvalue}
$objOutputUser.alias=$internalvalue
}
"proxyAddresses"
{
if ($showOutput) {Write-Host primarySMTP: ($internalvalue -replace "SMTP:","")}
$objOutputUser.primarySMTP=$internalvalue -replace "SMTP:",""
}
}
}
$objOutputUsers += $objOutputUser
Write-Progress -activity "Processing ${xmltoimport} in batches of ${batchsize}" -status "Batch

${outputfilecount}: " -percentComplete (($objOutputUsers.Count / $batchsize) * 100)
#every so often, dump the processed users in case we blow up somewhere

if ($count % $batchsize -eq 0)
{
Write-Host Hit the maximum users processed without completion... -ForegroundColor Yellow
#export the collection of users as a CSV

Write-Host Writing processedusers${outputfilecount}.csv -ForegroundColor Yellow
$objOutputUsers | Export-Csv -path processedusers${outputfilecount}.csv -NoTypeInformation
#increment the output file counter

$outputfilecount+=1
#reset the collection and the user counter

$objOutputUsers = $null
$count=0
}
$count+=1
#need to bail out of the loop if no more users to process

if ($reader.NodeType -eq [System.Xml.XmlNodeType]::EndElement)
{
break
}
} while ($reader.Read)
#need to write out any users that didn't get picked up in a batch of 1000
#export the collection of users as CSV
Write-Host Writing processedusers${outputfilecount}.csv -ForegroundColor Yellow
$objOutputUsers | Export-Csv -path processedusers${outputfilecount}.csv -NoTypeInformation
Next steps
Over view topics
Azure AD Connect sync: Best practices for changing
the default configuration
The purpose of this topic is to describe supported and unsupported changes to Azure AD Connect sync.
The configuration created by Azure AD Connect works “as is” for most environments that synchronize on-
premises Active Directory with Azure AD. However, in some cases, it is necessary to apply some changes to a
configuration to satisfy a particular need or requirement.
Changes to the service account

Azure AD Connect sync is running under a service account created by the installation wizard. This service account
holds the encryption keys to the database used by sync. It is created with a 127 characters long password and the
password is set to not expire.
It is unsuppor ted to change or reset the password of the service account. Doing so destroys the encryption
keys and the service is not able to access the database and is not able to start.
Changes to the scheduler

Starting with the releases from build 1.1 (February 2016) you can configure the scheduler to have a different sync
cycle than the default 30 minutes.
Changes to Synchronization Rules

The installation wizard provides a configuration that is supposed to work for the most common scenarios. In case
you need to make changes to the configuration, then you must follow these rules to still have a supported
configuration.
WARNING
If you make changes to the default sync rules then these changes will be overwritten the next time Azure AD Connect is
updated, resulting in unexpected and likely unwanted synchronization results.
You can change attribute flows if the default direct attribute flows are not suitable for your organization.
If you want to not flow an attribute and remove any existing attribute values in Azure AD, then you need to
create a rule for this scenario.
Disable an unwanted Sync Rule rather than deleting it. A deleted rule is recreated during an upgrade.
To change an out-of-box rule, you should make a copy of the original rule and disable the out-of-box rule. The
Sync Rule Editor prompts and helps you.
Export your custom synchronization rules using the Synchronization Rules Editor. The editor provides you with
a PowerShell script you can use to easily recreate them in a disaster recovery scenario.
WARNING
The out-of-box sync rules have a thumbprint. If you make a change to these rules, the thumbprint is no longer matching.
You might have problems in the future when you try to apply a new release of Azure AD Connect. Only make changes the
way it is described in this article.
Disable an unwanted Sync Rule

Do not delete an out-of-box sync rule. It is recreated during next upgrade.
In some cases, the installation wizard has produced a configuration that is not working for your topology. For
example, if you have an account-resource forest topology but you have extended the schema in the account forest
with the Exchange schema, then rules for Exchange are created for the account forest and the resource forest. In
this case, you need to disable the Sync Rule for Exchange.
In the picture above, the installation wizard has found an old Exchange 2003 schema in the account forest. This
schema extension was added before the resource forest was introduced in Fabrikam's environment. To ensure no
attributes from the old Exchange implementation are synchronized, the sync rule should be disabled as shown.
Change an out-of-box rule
The only time you should change an out-of-box rule is when you need to change the join rule. If you need to
change an attribute flow, then you should create a sync rule with higher precedence than the out-of-box rules. The
only rule you practically need to clone is the rule In from AD - User Join . You can override all other rules with a
higher precedence rule.
If you need to make changes to an out-of-box rule, then you should make a copy of the out-of-box rule and disable
the original rule. Then make the changes to the cloned rule. The Sync Rule Editor is helping you with those steps.
When you open an out-of-box rule, you are presented with this dialog box:
Select Yes to create a copy of the rule. The cloned rule is then opened.
On this cloned rule, make any necessary changes to scope, join, and transformations.
Next steps
Over view topics
Azure AD Connect sync: Make a change to the
default configuration
The purpose of this article is to walk you through how to make changes to the default configuration in Azure
Active Directory (Azure AD) Connect sync. It provides steps for some common scenarios. With this knowledge,
you should be able to make simple changes to your own configuration based on your own business rules.
WARNING
If you make changes to the default out-of-box sync rules then these changes will be overwritten the next time Azure AD
Connect is updated, resulting in unexpected and likely unwanted synchronization results.
The default out-of-box sync rules have a thumbprint. If you make a change to these rules, the thumbprint is no longer
matching. You might have problems in the future when you try to apply a new release of Azure AD Connect. Only make
changes the way it is described in this article.
Synchronization Rules Editor

The Synchronization Rules Editor is used to see and change the default configuration. You can find it on the Star t
menu under the Azure AD Connect group.
When you open the editor, you see the default out-of-box rules.
Navigating in the editor
Using the drop-downs at the top of the editor, you can quickly find a specific rule. For example, if you want to see
the rules where the attribute proxyAddresses is included, you can change the drop-downs to the following:
To reset filtering and load a fresh configuration, press F5 on the keyboard.

On the upper right is the Add new rule button. You use this button to create your own custom rule.
At the bottom are buttons for acting on a selected sync rule. Edit and Delete do what you expect them to. Expor t
produces a PowerShell script for re-creating the sync rule. With this procedure, you can move a sync rule from
one server to another.
Create your first custom rule

The most common changes are to the attribute flows. The data in your source directory might not be the same as
in Azure AD. In the example in this section, make sure the given name of a user is always in proper case.
Disable the scheduler
The scheduler runs every 30 minutes by default. Make sure it is not starting while you are making changes and
troubleshooting your new rules. To temporarily disable the scheduler, start PowerShell and run
Set-ADSyncScheduler -SyncCycleEnabled $false .
Create the rule
1. Click Add new rule .
2. On the Description page, enter the following:
Name : Give the rule a descriptive name.

Description : Give some clarification so someone else can understand what the rule is for.
Connected System : This is the system in which the object can be found. In this case, select Active
Director y Connector .
Connected System/Metaverse Object Type : Select User and Person , respectively.
Link Type : Change this value to Join .
Precedence : Provide a value that is unique in the system. A lower numeric value indicates higher
precedence.
Tag : Leave this empty. Only out-of-box rules from Microsoft should have this box populated with a
value.
3. On the Scoping filter page, enter givenName ISNOTNULL .
This section is used to define to which objects the rule should apply. If it's left empty, the rule would apply to all
user objects. However, that would include conference rooms, service accounts, and other non-people user
objects.
4. On the Join rules page, leave the field empty.
5. On the Transformations page, change FlowType to Expression . For Target Attribute , select givenName .
And for Source , enter PCase([givenName]) .
The sync engine is case-sensitive for both the function name and the name of the attribute. If you type
something wrong, you see a warning when you add the rule. You can save and continue, but you need to
reopen and correct the rule.
6. Click Add to save the rule.
Your new custom rule should be visible with the other sync rules in the system.
Verify the change
With this new change, you want to make sure it is working as expected and is not throwing any errors. Depending
on the number of objects you have, there are two ways to do this step:
Run a full sync on all objects.
Run a preview and full sync on a single object.
Open the Synchronization Ser vice from the Star t menu. The steps in this section are all in this tool.
Full sync on all objects
1. Select Connectors at the top. Identify the connector that you changed in the previous section (in this case,
Active Directory Domain Services), and select it.
2. For Actions , select Run .
3. Select Full Synchronization , and then select OK .
The objects are now updated in the metaverse. Verify your changes by looking at the object in the metaverse.
Preview and full sync on a single object
1. Select Connectors at the top. Identify the connector that you changed in the previous section (in this case,
Active Directory Domain Services), and select it.
2. Select Search Connector Space .
3. Use Scope to find an object that you want to use to test the change. Select the object and click Preview .
4. On the new screen, select Commit Preview .
The change is now committed to the metaverse.
View the object in the metaverse
1. Pick a few sample objects to make sure that the value is expected and that the rule applied.
2. Select Metaverse Search from the top. Add any filter that you need to find the relevant objects.
3. From the search result, open an object. Look at the attribute values, and also verify in the Sync Rules column
that the rule applied as expected.
Enable the scheduler

If everything is as expected, you can enable the scheduler again. From PowerShell, run
Set-ADSyncScheduler -SyncCycleEnabled $true .
Other common attribute flow changes

The previous section described how to make changes to an attribute flow. In this section, some additional
examples are provided. The steps for how to create the sync rule is abbreviated, but you can find the full steps in
the previous section.
Use an attribute other than the default
In this Fabrikam scenario, there is a forest where the local alphabet is used for given name, surname, and display
name. The Latin character representation of these attributes can be found in the extension attributes. For building
a global address list in Azure AD and Office 365, the organization wants to use these attributes instead.
With a default configuration, an object from the local forest looks like this:
To create a rule with other attribute flows, do the following:

1. Open the Synchronization Rules Editor from the Star t menu.
2. With Inbound still selected to the left, click the Add new rule button.
3. Give the rule a name and description. Select the on-premises Active Directory instance and the relevant object
types. In Link Type , select Join . For Precedence , pick a number that is not used by another rule. The out-of-
box rules start with 100, so the value 50 can be used in this example.
4. Leave Scoping filter empty. (That is, it should apply to all user objects in the forest.)
5. Leave Join rules empty. (That is, let the out-of-box rule handle any joins.)
6. In Transformations , create the following flows:
7. Click Add to save the rule.

8. Go to Synchronization Ser vice Manager . On Connectors , select the connector where you added the rule.
Select Run , and then select Full Synchronization . A full synchronization recalculates all objects by using the
current rules.
This is the result for the same object with this custom rule:
Length of attributes
String attributes are indexable by default, and the maximum length is 448 characters. If you are working with
string attributes that might contain more, make sure to include the following in the attribute flow:
attributeName <- Left([attributeName],448) .
Changing the userPrincipalSuffix

The userPrincipalName attribute in Active Directory is not always known by the users and might not be suitable
as the sign-in ID. With the Azure AD Connect sync installation wizard, you can choose a different attribute--for
example, mail. But in some cases, the attribute must be calculated.
For example, the company Contoso has two Azure AD directories, one for production and one for testing. They
want the users in their test tenant to use another suffix in the sign-in ID:
userPrincipalName <- Word([userPrincipalName],1,"@") & "@contosotest.com" .
In this expression, take everything left of the first @-sign (Word) and concatenate with a fixed string.
Convert a multi-value attribute to single value
Some attributes in Active Directory are multi-valued in the schema, even though they look single-valued in Active
Directory Users and Computers. An example is the description attribute:
description <- IIF(IsNullOrEmpty([description]),NULL,Left(Trim(Item([description],1)),448)) .
In this expression, if the attribute has a value, take the first item (Item) in the attribute, remove leading and trailing
spaces (Trim), and then keep the first 448 characters (Left) in the string.
Do not flow an attribute
For background on the scenario for this section, see Control the attribute flow process.
There are two ways to not flow an attribute. The first is by using the installation wizard to remove selected
attributes. This option works if you have never synchronized the attribute before. However, if you have started to
synchronize this attribute and later remove it with this feature, the sync engine stops managing the attribute and
the existing values are left in Azure AD.
If you want to remove the value of an attribute and make sure it does not flow in the future, you need create a
custom rule.
In this Fabrikam scenario, we have realized that some of the attributes we synchronize to the cloud should not be
there. We want to make sure these attributes are removed from Azure AD.
1. Create a new inbound synchronization rule and populate the description.
2. Create attribute flows with Expression for FlowType and with AuthoritativeNull for Source . The literal
AuthoritativeNull indicates that the value should be empty in the metaverse, even if a lower-precedence sync
rule tries to populate the value.
3. Save the sync rule. Start the Synchronization Ser vice , find the connector, select Run , and then select Full
Synchronization . This step recalculates all attribute flows.
4. Verify that the intended changes are about to be exported by searching the Connector Space.
Create rules with PowerShell
Using the sync rule editor works fine when you only have a few changes to make. If you need to make many
changes, PowerShell might be a better option. Some advanced features are only available with PowerShell.
Get the PowerShell script for an out-of-box rule
To see the PowerShell script that created an out-of-box rule, select the rule in the sync rules editor and click
Expor t . This action gives you the PowerShell script that created the rule.
Advanced precedence
The out-of-box sync rules start with a precedence value of 100. If you have many forests and you need to make
many custom changes, then 99 sync rules might not be enough.
You can instruct the sync engine that you want additional rules inserted before the out-of-box rules. To get this
behavior, follow these steps:
1. Mark the first out-of-box sync rule (In from AD-User Join ) in the sync rules editor and select Expor t . Copy
the SR Identifier value.
2. Create the new sync rule. You can use the sync rules editor to create it. Export the rule to a PowerShell script.
3. In the property PrecedenceBefore , insert the Identifier value from the out-of-box rule. Set the Precedence to
0 . Make sure the Identifier attribute is unique and that you are not reusing a GUID from another rule. Also
make sure that the ImmutableTag property is not set. This property should be set only for an out-of-box rule.
4. Save the PowerShell script and run it. The result is that your custom rule is assigned the precedence value of
100 and all other out-of-box rules are incremented.
You can have many custom sync rules by using the same PrecedenceBefore value when needed.
Enable synchronization of UserType

Azure AD Connect supports synchronization of the UserType attribute for User objects in version 1.1.524.0 and
later. More specifically, the following changes have been introduced:
The schema of the object type User in the Azure AD Connector is extended to include the UserType attribute,
which is of the type string and is single-valued.
The schema of the object type Person in the metaverse is extended to include the UserType attribute, which is
of the type string and is single-valued.
By default, the UserType attribute is not enabled for synchronization because there is no corresponding UserType
attribute in on-premises Active Directory. You must manually enable synchronization. Before doing this, you must
take note of the following behavior enforced by Azure AD:
Azure AD only accepts two values for the UserType attribute: Member and Guest .
If the UserType attribute is not enabled for synchronization in Azure AD Connect, Azure AD users created
through directory synchronization would have the UserType attribute set to Member .
Prior to version 1.5.30.0, Azure AD did not permit the UserType attribute on existing Azure AD users to be
changed by Azure AD Connect. In older versions, it could only be set during the creation of the Azure AD users
and changed via Powershell.
Before enabling synchronization of the UserType attribute, you must first decide how the attribute is derived from
on-premises Active Directory. The following are the most common approaches:
Designate an unused on-premises AD attribute (such as extensionAttribute1) to be used as the source
attribute. The designated on-premises AD attribute should be of the type string , be single-valued, and
contain the value Member or Guest .
If you choose this approach, you must ensure that the designated attribute is populated with the correct
value for all existing user objects in on-premises Active Directory that are synchronized to Azure AD before
enabling synchronization of the UserType attribute.
Alternatively, you can derive the value for the UserType attribute from other properties. For example, you
want to synchronize all users as Guest if their on-premises AD userPrincipalName attribute ends with
domain part @partners.fabrikam123.org.
As mentioned previously, older versions of Azure AD Connect do not permit the UserType attribute on
existing Azure AD users to be changed by Azure AD Connect. Therefore, you must ensure that the logic you
have decided is consistent with how the UserType attribute is already configured for all existing Azure AD
users in your tenant.
The steps to enable synchronization of the UserType attribute can be summarized as:
1. Disable the sync scheduler and verify there is no synchronization in progress.
2. Add the source attribute to the on-premises AD Connector schema.
3. Add the UserType to the Azure AD Connector schema.
4. Create an inbound synchronization rule to flow the attribute value from on-premises Active Directory.
5. Create an outbound synchronization rule to flow the attribute value to Azure AD.
6. Run a full synchronization cycle.
7. Enable the sync scheduler.
NOTE
The rest of this section covers these steps. They are described in the context of an Azure AD deployment with single-forest
topology and without custom synchronization rules. If you have multi-forest topology, custom synchronization rules
configured, or have a staging server, you need to adjust the steps accordingly.
Step 1: Disable the sync scheduler and verify there is no synchronization in progress
To avoid exporting unintended changes to Azure AD, ensure that no synchronization takes place while you are in
the middle of updating synchronization rules. To disable the built-in sync scheduler:
1. Start a PowerShell session on the Azure AD Connect server.
2. Disable scheduled synchronization by running the cmdlet Set-ADSyncScheduler -SyncCycleEnabled $false .
3. Open the Synchronization Service Manager by going to Star t > Synchronization Ser vice .
4. Go to the Operations tab and confirm there is no operation with a status of in progress.
Step 2: Add the source attribute to the on-premises AD Connector schema
Not all Azure AD attributes are imported into the on-premises AD Connector Space. To add the source attribute to
the list of the imported attributes:
1. Go to the Connectors tab in the Synchronization Service Manager.
2. Right-click the on-premises AD Connector and select Proper ties .
3. In the pop-up dialog box, go to the Select Attributes tab.
4. Make sure the source attribute is checked in the attribute list.
5. Click OK to save.
Step 3: Add the UserType attribute to the Azure AD Connector schema
By default, the UserType attribute is not imported into the Azure AD Connect Space. To add the UserType attribute
to the list of imported attributes:
2. Right-click the Azure AD Connector and select Proper ties .
4. Make sure the UserType attribute is checked in the attribute list.
5. Click OK to save.
Step 4: Create an inbound synchronization rule to flow the attribute value from on-premises Active Directory
The inbound synchronization rule permits the attribute value to flow from the source attribute from on-premises
Active Directory to the metaverse:
1. Open the Synchronization Rules Editor by going to Star t > Synchronization Rules Editor .
2. Set the search filter Direction to be Inbound .
3. Click the Add new rule button to create a new inbound rule.
4. Under the Description tab, provide the following configuration:
AT T RIB UT E VA L UE DETA IL S
Name Provide a name For example, In from AD – User

UserType
Description Provide a description
Connected System Pick the on-premises AD connector
Connected System Object Type User
Metaverse Object Type Person
Link Type Join

Precedence Choose a number between 1–99 1–99 is reserved for custom sync
rules. Do not pick a value that is
used by another synchronization
rule.
5. Go to the Scoping filter tab and add a single scoping filter group with the following clause:
AT T RIB UT E O P ERATO R VA L UE
adminDescription NOTSTARTWITH User_
The scoping filter determines to which on-premises AD objects this inbound synchronization rule is
applied. In this example, we use the same scoping filter used in the In from AD – User Common out-of-box
synchronization rule, which prevents the synchronization rule from being applied to User objects created
through the Azure AD User writeback feature. You might need to tweak the scoping filter according to your
Azure AD Connect deployment.
6. Go to the Transformation tab and implement the desired transformation rule. For example, if you have
designated an unused on-premises AD attribute (such as extensionAttribute1) as the source attribute for
the UserType, you can implement a direct attribute flow:
F LO W T Y P E TA RGET AT T RIB UT E SO URC E A P P LY O N C E M ERGE T Y P E
Direct UserType extensionAttribute1 Unchecked Update
In another example, you want to derive the value for the UserType attribute from other properties. For
example, you want to synchronize all users as Guest if their on-premises AD userPrincipalName attribute
ends with domain part @partners.fabrikam123.org. You can implement an expression like this:
Expression UserType IIF(IsPresent([userPri Unchecked Update

ncipalName]),IIF(CB
ool(InStr(LCase([user
PrincipalName]),"@p
artners.fabrikam123
.org")=0),"Member",
"Guest"),Error("User
PrincipalName is not
present to
determine
UserType"))
7. Click Add to create the inbound rule.

Step 5: Create an outbound synchronization rule to flow the attribute value to Azure AD
The outbound synchronization rule permits the attribute value to flow from the metaverse to the UserType
attribute in Azure AD:
1. Go to the Synchronization Rules Editor.
2. Set the search filter Direction to be Outbound .
3. Click the Add new rule button.
Name Provide a name For example, Out to AAD – User

UserType
Connected System Select the AAD connector

Link Type Join
rules. Do not pick a value that is
used by another synchronization
rule.
5. Go to the Scoping filter tab and add a single scoping filter group with two clauses:
sourceObjectType EQUAL User
cloudMastered NOTEQUAL True
The scoping filter determines to which Azure AD objects this outbound synchronization rule is applied. In
this example, we use the same scoping filter from the Out to AD – User Identity out-of-box synchronization
rule. It prevents the synchronization rule from being applied to User objects that are not synchronized from
on-premises Active Directory. You might need to tweak the scoping filter according to your Azure AD
Connect deployment.
6. Go to the Transformation tab and implement the following transformation rule:
Direct UserType UserType Unchecked Update
7. Click Add to create the outbound rule.

Step 6: Run a full synchronization cycle
In general, a full synchronization cycle is required because we have added new attributes to both the Active
Directory and Azure AD Connector schemas, and introduced custom synchronization rules. You want to verify the
changes before exporting them to Azure AD.
You can use the following steps to verify the changes while manually running the steps that make up a full
synchronization cycle.
1. Run a Full impor t on the on-premises AD Connector :
a. Go to the Connectors tab in the Synchronization Service Manager.
b. Right-click the on-premises AD Connector and select Run .
c. In the pop-up dialog box, select Full Impor t and then click OK .
d. Wait for the operation to finish.
NOTE
You can skip a full import on the on-premises AD Connector if the source attribute is already included in the
list of imported attributes. In other words, you did not have to make any changes during Step 2: Add the
source attribute to the on-premises AD Connector schema.
2. Run a Full impor t on the Azure AD Connector :

a. Right-click the Azure AD Connector and select Run .
b. In the pop-up dialog box, select Full Impor t and then click OK .
c. Wait for the operation to finish.
3. Verify the synchronization rule changes on an existing User object:
The source attribute from on-premises Active Directory and the UserType from Azure AD have been
imported into their respective Connector Spaces. Before proceeding with a full synchronization, do a
Preview on an existing User object in the on-premises AD Connector Space. The object you chose should
have the source attribute populated.
A successful Preview with the UserType populated in the metaverse is a good indicator that you have
configured the synchronization rules correctly. For information about how to do a Preview , refer to the
section Verify the change.
4. Run a Full Synchronization on the on-premises AD Connector :
a. Right-click the on-premises AD Connector and select Run .
b. In the pop-up dialog box, select Full Synchronization and then click OK .
c. Wait for the operation to finish.
5. Verify Pending Expor ts to Azure AD:
a. Right-click the Azure AD Connector and select Search Connector Space .
b. In the Search Connector Space pop-up dialog box:
Set Scope to Pending Expor t .
Select all three check boxes: Add , Modify , and Delete .
Click the Search button to get the list of objects with changes to be exported. To examine the
changes for a given object, double-click the object.
Verify that the changes are expected.
6. Run Expor t on the Azure AD Connector :
a. Right-click the Azure AD Connector and select Run .
b. In the Run Connector pop-up dialog box, select Expor t and then click OK .
c. Wait for the export to Azure AD to finish.
NOTE
These steps do not include the full synchronization and export steps on the Azure AD Connector. These steps are not
required because the attribute values are flowing from on-premises Active Directory to Azure AD only.
Step 7: Re -enable the sync scheduler

Re-enable the built-in sync scheduler:
1. Start a PowerShell session.
2. Re-enable scheduled synchronization by running the cmdlet Set-ADSyncScheduler -SyncCycleEnabled $true .
Next steps
Over view topics
Fix modified default rules in Azure AD Connect
Azure Active Directory (Azure AD) Connect uses default rules for synchronization. Unfortunately, these rules don't
apply universally to all organizations. Based on your requirements, you might need to modify them. This article
discusses two examples of the most common customizations, and explains the correct way to achieve these
customizations.
NOTE
Modifying existing default rules to achieve a needed customization isn't supported. If you do so, it prevents updating these
rules to the latest version in future releases. You won't get the bug fixes you need, or new features. This document explains
how to achieve the same result without modifying the existing default rules.
How to identify modified default rules

Starting with version 1.3.7.0 of Azure AD Connect, it's easy to identify the modified default rule. Go to Apps on
Desktop , and select Synchronization Rules Editor .
In the Editor, any modified default rules are shown with a warning icon in front of the name.
A disabled rule with same name next to it also appears (this is the standard default rule).
Common customizations
The following are common customizations to the default rules:
Change attribute flow
Change scoping filter
Change join condition
Before you change any rules:
Disable the sync scheduler. The scheduler runs every 30 minutes by default. Make sure it's not starting while
you're making changes and troubleshooting your new rules. To temporarily disable the scheduler, start
PowerShell, and run Set-ADSyncScheduler -SyncCycleEnabled $false .
The change in scoping filter can result in deletion of objects in the target directory. Be careful before making
any changes in the scoping of objects. We recommend that you make changes to a staging server before
making changes on the active server.
Run a preview on a single object, as mentioned in the Validate Sync Rule section, after adding any new rule.
Run a full sync after adding a new rule or modifying any custom sync rule. This sync applies new rules to all
the objects.
Change attribute flow

There are three different scenarios for changing the attribute flow:
Adding a new attribute.
Overriding the value of an existing attribute.
Choosing not to sync an existing attribute.
You can do these without altering standard default rules.
Add a new attribute
If you find that an attribute is not flowing from your source directory to the target directory, use the Azure AD
Connect sync: Directory extensions to fix this.
If the extensions don't work for you, try adding two new sync rules, described in the following sections.
Add an inbound sync rule
An inbound sync rule means the source for the attribute is a connector space, and the target is the metaverse. For
example, to have a new attribute flow from on-premises Active Directory to Azure Active Directory, create a new
inbound sync rule. Launch the Synchronization Rules Editor , select Inbound as the direction, and select Add
new rule .
Follow your own naming convention to name the rule. Here, we use Custom In from AD - User . This means that
the rule is a custom rule, and is an inbound rule from the Active Directory connector space to the metaverse.
Provide your own description of the rule, so that future maintenance of the rule is easy. For example, the
description can be based on what the objective of the rule is, and why it's needed.
Make your selections for the Connected System , Connected System Object Type , and Metaverse Object
Type fields.
Specify the precedence value from 0 through 99 (the lower the number, the higher the precedence). For the Tag ,
Enable Password Sync , and Disabled fields, use the default selections.
Keep Scoping filter empty. This means that the rule applies to all the objects joined between the Active Directory
Connected System and the metaverse.
Keep Join rules empty. This means this rule uses the join condition defined in the standard default rule. This is
another reason not to disable or delete the standard default rule. If there is no join condition, the attribute won't
flow.
Add appropriate transformations for your attribute. You can assign a constant, to make a constant value flow to
your target attribute. You can use direct mapping between the source or target attribute. Or, you can use an
expression for the attribute. Here are various expression functions you can use.
Add an outbound sync rule
To link the attribute to the target directory, you need to create an outbound rule. This means that the source is the
metaverse, and the target is the connected system. To create an outbound rule, launch the Synchronization Rules
Editor , change the Direction to Outbound , and select Add new rule .
As with the inbound rule, you can use your own naming convention to name the rule. Select the Connected
System as the Azure AD tenant, and select the connected system object to which you want to set the attribute
value. Set the precedence from 0 through 99.
Keep Scoping filter and Join rules empty. Fill in the transformation as constant, direct, or expression.
You now know how to make a new attribute for a user object flow from Active Directory to Azure Active Directory.
You can use these steps to map any attribute from any object to source and target. For more information, see
Creating custom sync rules and Prepare to provision users.
Override the value of an existing attribute
You might want to override the value of an attribute that has already been mapped. For example, if you always
want to set a null value to an attribute in Azure AD, simply create an inbound rule only. Make the constant value,
AuthoritativeNull , flow to the target attribute.
NOTE
Use AuthoritativeNull instead of Null in this case. This is because the non-null value replaces the null value, even if it
has lower precedence (a higher number value in the rule). AuthoritativeNull , on the other hand, isn't replaced with a non-
null value by other rules.
Don’t sync existing attribute

If you want to exclude an attribute from syncing, use the attribute filtering feature provided in Azure AD Connect.
Launch Azure AD Connect from the desktop icon, and then select Customize synchronization options .
Make sure Azure AD app and attribute filtering is selected, and select Next .
Clear the attributes that you want to exclude from syncing.

Change scoping filter
Azure AD Sync takes care of most of the objects. You can reduce the scope of objects, and reduce the number of
objects to be exported, without changing the standard default sync rules.
Use one of the following methods to reduce the scope of the objects you're syncing:
cloudFiltered attribute
Organization unit filtering
If you reduce the scope of the users being synced, the password hash syncing also stops for the filtered-out users. If
the objects are already syncing, after you reduce scope, the filtered-out objects are deleted from the target
directory. For this reason, ensure that you scope very carefully.
IMPORTANT
Increasing the scope of objects configured by Azure AD Connect isn't recommended. Doing so makes it difficult for the
Microsoft support team to understand the customizations. If you must increase the scope of objects, edit the existing rule,
clone it, and disable the original rule.
cloudFiltered attribute
You can't set this attribute in Active Directory. Set the value of this attribute by adding a new inbound rule. You can
then use Transformation and Expression to set this attribute in the metaverse. The following example shows that
you don’t want to sync all the users whose department name starts with HRD (case-insensitive):
cloudFiltered <= IIF(Left(LCase([department]), 3) = "hrd", True, NULL)
We first converted the department from source (Active Directory) to lowercase. Then, using the Left function, we
took only the first three characters and compared it with hrd . If it matched, the value is set to True , otherwise
NULL . In setting the value to null, some other rule with lower precedence (a higher number value) can write to it
with a different condition. Run preview on one object to validate sync rule, as mentioned in the Validate sync rule
section.
Organizational unit filtering

You can create one or more organizational units (OUs), and move the objects you don’t want to sync to these OUs.
Then, configure the OU filtering in Azure AD Connect. Launch Azure AD Connect from the desktop icon, and
select the following options. You can also configure the OU filtering at the time of installation of Azure AD Connect.
Follow the wizard, and clear the OUs you don’t want to sync.
Change join condition

Use the default join conditions configured by Azure AD Connect. Changing default join conditions makes it difficult
for Microsoft support to understand the customizations and support the product.
Validate sync rule

You can validate the newly added sync rule by using the preview feature, without running the full sync cycle. In
Azure AD Connect, select Synchronization Ser vice .
Select Metaverse Search . Select the scope object as person , select Add Clause , and mention your search
criteria. Next, select Search , and double-click the object in the search results. Make sure that your data in Azure AD
Connect is up-to-date for that object, by running import and sync on the forest before you run this step.
On Metaverse Object Proper ties , select Connectors , select the object in the corresponding connector (forest),
and select Proper ties… .
Select Preview…
In the Preview window, select Generate Preview and Impor t Attribute Flow in the left pane.
Here, notice that the newly added rule is run on the object, and has set the cloudFiltered attribute to true.
To compare the modified rule with the default rule, export both of the rules separately, as text files. These rules are
exported as a PowerShell script file. You can compare them by using any file comparison tool (for example, windiff)
to see the changes.
Notice that in the modified rule, the msExchMailboxGuid attribute is changed to the Expression type, instead of
Direct . Also, the value is changed to NULL and ExecuteOnce option. You can ignore Identified and Precedence
differences.
To fix your rules to change them back to default settings, delete the modified rule and enable the default rule.
Ensure that you don't lose the customization you're trying to achieve. When you're ready, run Full
Synchronization .
Next steps
Express settings
Customized settings
Azure AD Connect sync: Directory extensions
You can use directory extensions to extend the schema in Azure Active Directory (Azure AD) with your own
attributes from on-premises Active Directory. This feature enables you to build LOB apps by consuming attributes
that you continue to manage on-premises. These attributes can be consumed through extensions. You can see the
available attributes by using Microsoft Graph Explorer. You can also use this feature to create dynamic groups in
Azure AD.
At present, no Office 365 workload consumes these attributes.
Customize which attributes to synchronize with Azure AD

You configure which additional attributes you want to synchronize in the custom settings path in the installation
wizard.
NOTE
In Azure AD Connect versions earlier than 1.2.65.0, the search box for Available Attributes is case-sensitive.
The installation shows the following attributes, which are valid candidates:
User and Group object types
Single-valued attributes: String, Boolean, Integer, Binary
Multi-valued attributes: String, Binary
NOTE
Although Azure AD Connect supports synchronizing multi-valued Active Directory attributes to Azure AD as multi-valued
directory extensions, there is currently no way to retrieve/consume the data uploaded in multi-valued directory extension
attributes.
The list of attributes is read from the schema cache that's created during installation of Azure AD Connect. If you
have extended the Active Directory schema with additional attributes, you must refresh the schema before these
new attributes are visible.
An object in Azure AD can have up to 100 attributes for directory extensions. The maximum length is 250
characters. If an attribute value is longer, the sync engine truncates it.
Configuration changes in Azure AD made by the wizard

During installation of Azure AD Connect, an application is registered where these attributes are available. You can
see this application in the Azure portal. Its name is always Tenant Schema Extension App .
Make sure you select All applications to see this app.

The attributes are prefixed with extension _{ApplicationId}_ . ApplicationId has the same value for all attributes
in your Azure AD tenant. You will need this value for all other scenarios in this topic.
Viewing attributes using the Microsoft Graph API

These attributes are now available through the Microsoft Graph API, by using Microsoft Graph Explorer.
NOTE
In the Microsoft Graph API, you need to ask for the attributes to be returned. Explicitly select the attributes like this:
https://graph.microsoft.com/beta/users/abbie.spencer@fabrikamonline.com?
$select=extension_9d98ed114c4840d298fad781915f27e4_employeeID,extension_9d98ed114c4840d298fad781915f27e4_division
.
For more information, see Microsoft Graph: Use query parameters.
Use the attributes in dynamic groups

One of the more useful scenarios is to use these attributes in dynamic security or Office 365 groups.
1. Create a new group in Azure AD. Give it a good name and make sure the Membership type is Dynamic
User .
2. Select to Add dynamic quer y . If you look at the properties, then you will not see these extended
attributes. You need to add them first. Click Get custom extension proper ties , enter the Application ID,
and click Refresh proper ties .
3. Open the property drop-down and note that the attributes you added are now visible.
Complete the expression to suit your requirements. In our example, the rule is set to
(user.extension_9d98ed114c4840d298fad781915f27e4_division -eq "Sales and marketing") .
4. After the group has been created, give Azure AD some time to populate the members and then review the
members.
Next steps
Azure Active Directory Connect sync: Configure
preferred data location for Office 365 resources
The purpose of this topic is to walk you through how to configure the attribute for preferred data location in Azure
Active Directory (Azure AD) Connect sync. When someone uses Multi-Geo capabilities in Office 365, you use this
attribute to designate the geo-location of the user’s Office 365 data. (The terms region and geo are used
interchangeably.)
Enable synchronization of preferred data location

By default, Office 365 resources for your users are located in the same geo as your Azure AD tenant. For example,
if your tenant is located in North America, then the users' Exchange mailboxes are also located in North America.
For a multinational organization, this might not be optimal.
By setting the attribute preferredDataLocation , you can define a user's geo. You can have the user's Office 365
resources, such as the mailbox and OneDrive, in the same geo as the user, and still have one tenant for your entire
organization.
IMPORTANT
Multi-Geo is currently available to customers with an active Enterprise Agreement and a minimum of 250 Office 365 Services
subscriptions. Please talk to your Microsoft representative for details.
A list of all geos for Office 365 can be found in Where is your data located?.
The geos in Office 365 available for Multi-Geo are:
GEO P REF ERREDDATA LO C AT IO N VA L UE
Asia Pacific APC
Australia AUS
Canada CAN
European Union EUR
France FRA
India IND
Japan JPN
Korea KOR
South Africa ZAF
Switzerland CHE
GEO P REF ERREDDATA LO C AT IO N VA L UE
United Arab Emirates ARE
United Kingdom GBR
United States NAM
If a geo is not listed in this table (for example, South America), then it cannot be used for Multi-Geo.
Not all Office 365 workloads support the use of setting a user's geo.
Azure AD Connect support for synchronization
Azure AD Connect supports synchronization of the preferredDataLocation attribute for User objects in version
1.1.524.0 and later. Specifically:
The schema of the object type User in the Azure AD Connector is extended to include the
preferredDataLocation attribute. The attribute is of the type, single-valued string.
The schema of the object type Person in the metaverse is extended to include the preferredDataLocation
attribute. The attribute is of the type, single-valued string.
By default, preferredDataLocation is not enabled for synchronization. This feature is intended for larger
organizations. The Active Directory schema in Windows Server 2019 has an attribute msDS-
preferredDataLocation you should use for this purpose. If you have not updated the Active Directory schema
and cannot do so, then you must identify an attribute to hold the Office 365 geo for your users. This is going to be
different for each organization.
IMPORTANT
Azure AD allows the preferredDataLocation attribute on cloud User objects to be directly configured by using Azure
AD PowerShell. To configure this attribute on synchronized User objects , you must use Azure AD Connect.
Before enabling synchronization:

If you have not upgraded the Active Directory schema to 2019, then decide which on-premises Active
Directory attribute to be used as the source attribute. It should be of the type, single-valued string .
If you have previously configured the preferredDataLocation attribute on existing synchronized User
objects in Azure AD by using Azure AD PowerShell, you must backport the attribute values to the
corresponding User objects in on-premises Active Directory.
IMPORTANT
If you do not backport these values, Azure AD Connect removes the existing attribute values in Azure AD when
synchronization for the preferredDataLocation attribute is enabled.
Configure the source attribute on at least a couple of on-premises Active Directory User objects now. You
can use this for verification later.
The following sections provide the steps to enable synchronization of the preferredDataLocation attribute.
NOTE
The steps are described in the context of an Azure AD deployment with single-forest topology, and without custom
synchronization rules. If you have a multi-forest topology, custom synchronization rules configured, or have a staging server,
you should adjust the steps accordingly.
Step 1: Disable sync scheduler and verify there is no synchronization in

progress
To avoid unintended changes being exported to Azure AD, ensure that no synchronization takes place while you
are in the middle of updating synchronization rules. To disable the built-in sync scheduler:
1. Start a PowerShell session on the Azure AD Connect server.
2. Disable scheduled synchronization by running this cmdlet: Set-ADSyncScheduler -SyncCycleEnabled $false .
3. Start the Synchronization Ser vice Manager by going to START > Synchronization Ser vice .
4. Select the Operations tab, and confirm there is no operation with the status in progress.
Step 2: Refresh the schema for Active Directory

If you have updated the Active Directory schema to 2019 and Connect was installed before the schema extension,
then the Connect schema cache does not have the updated schema. You must then refresh the schema from the
wizard for it to appear in the UI.
1. Start the Azure AD Connect wizard from the desktop.
2. Select the option Refresh director y schema and click Next .
3. Enter your Azure AD credentials and click Next .
4. On the Refresh Director y Schema page, make sure all forests are selected and click Next .
5. When completed, close the wizard.
Step 3: Add the source attribute to the on-premises Active Directory
Connector schema
This step is only needed if you run Connect version 1.3.21 or older. If you are on 1.4.18 or newer,
then skip to step 5.
Not all Azure AD attributes are imported into the on-premises Active Directory connector space. If you have
selected to use an attribute that is not synchronized by default, then you need to import it. To add the source
attribute to the list of the imported attributes:
1. Select the Connectors tab in the Synchronization Service Manager.
2. Right-click the on-premises Active Directory Connector, and select Proper ties .
4. Make sure the source attribute you selected to use is checked in the attribute list. If you do not see your
attribute, select the Show All check box.
5. To save, select OK .
Step 4: Add preferredDataLocation to the Azure AD Connector
schema
This step is only needed if you run Connect version 1.3.21 or older. If you are on 1.4.18 or newer,
then skip to step 5.
By default, the preferredDataLocation attribute is not imported into the Azure AD Connector space. To add it to
the list of imported attributes:
1. Select the Connectors tab in the Synchronization Service Manager.
2. Right-click the Azure AD connector, and select Proper ties .
4. Select the preferredDataLocation attribute in the list.
5. To save, select OK .
Step 5: Create an inbound synchronization rule
The inbound synchronization rule permits the attribute value to flow from the source attribute in on-premises
Active Directory to the metaverse.
1. Start the Synchronization Rules Editor by going to START > Synchronization Rules Editor .
2. Set the search filter Direction to be Inbound .
3. To create a new inbound rule, select Add new rule .
Name Provide a name For example, “In from AD – User

preferredDataLocation”
Description Provide a custom description
Connected System Pick the on-premises Active

Directory Connector

Link Type Join
rules. Do not pick a value that is used
by another synchronization rule.
5. Keep the Scoping filter empty, to include all objects. You might need to tweak the scoping filter according
to your Azure AD Connect deployment.
6. Go to the Transformation tab , and implement the following transformation rule:
Direct preferredDataLocati Pick the source Unchecked Update

on attribute
7. To create the inbound rule, select Add .
Step 6: Create an outbound synchronization rule

The outbound synchronization rule permits the attribute value to flow from the metaverse to the
preferredDataLocation attribute in Azure AD:
1. Go to the Synchronization Rules Editor .
2. Set the search filter Direction to be Outbound .
3. Select Add new rule .
Name Provide a name For example, “Out to Azure AD –

User preferredDataLocation”
Connected System Select the Azure AD Connector
Link Type Join
rules. Do not pick a value that is used
by another synchronization rule.
5. Go to the Scoping filter tab, and add a single scoping filter group with two clauses:
Scoping filter determines which Azure AD objects this outbound synchronization rule is applied to. In this
example, we use the same scoping filter from “Out to Azure AD – User Identity” OOB (out-of-box)
synchronization rule. It prevents the synchronization rule from being applied to User objects that are not
synchronized from an on-premises Active Directory. You might need to tweak the scoping filter according to
your Azure AD Connect deployment.
6. Go to the Transformation tab, and implement the following transformation rule:
Direct preferredDataLocati preferredDataLocati Unchecked Update

on on
7. Close Add to create the outbound rule.

Step 7: Run full synchronization cycle
In general, full synchronization cycle is required. This is because you have added new attributes to both the Active
Directory and Azure AD Connector schema, and introduced custom synchronization rules. Verify the changes
before exporting them to Azure AD. You can use the following steps to verify the changes, while manually running
the steps that make up a full synchronization cycle.
1. Run Full impor t on the on-premises Active Directory Connector:
a. Go to the Operations tab in the Synchronization Service Manager.
b. Right-click the on-premises Active Director y Connector , and select Run .
c. In the dialog box, select Full Impor t , and select OK .
d. Wait for the operation to complete.
NOTE
You can skip full import on the on-premises Active Directory Connector if the source attribute is already
included in the list of imported attributes. In other words, you did not have to make any change during step
2 earlier in this article.
2. Run Full impor t on the Azure AD Connector:

a. Right-click the Azure AD Connector , and select Run .
b. In the dialog box, select Full Impor t , and select OK .
c. Wait for the operation to complete.
3. Verify the synchronization rule changes on an existing User object.
The source attribute from on-premises Active Directory, and preferredDataLocation from Azure AD, have
been imported into each respective connector space. Before proceeding with the full synchronization step,
do a preview on an existing User object in the on-premises Active Directory Connector space. The object
you picked should have the source attribute populated. A successful preview with preferredDataLocation
populated in the metaverse is a good indicator that you have configured the synchronization rules correctly.
For information about how to do a preview, see Verify the change.
4. Run Full Synchronization on the on-premises Active Directory Connector:
a. Right-click the on-premises Active Director y Connector , and select Run .
b. In the dialog box, select Full Synchronization , and select OK .
5. Verify Pending Expor ts to Azure AD:
a. Right-click the Azure AD Connector , and select Search Connector Space .
b. In the Search Connector Space dialog box:
a. Set Scope to Pending Expor t .
b. Select all three check boxes, including Add, Modify, and Delete .
c. To view the list of objects with changes to be exported, select Search . To examine the changes for a
given object, double-click the object.
d. Verify that the changes are expected.
6. Run Expor t on the Azure AD Connector
a. Right-click the Azure AD Connector , and select Run .
b. In the Run Connector dialog box, select Expor t , and select OK .
NOTE
You might notice that the steps do not include the full synchronization step on the Azure AD Connector, or the export step
on the Active Directory Connector. The steps are not required, because the attribute values are flowing from on-premises
Active Directory to Azure AD only.
Step 8: Re-enable sync scheduler

Re-enable the built-in sync scheduler:
1. Start a PowerShell session.
2. Re-enable scheduled synchronization by running this cmdlet: Set-ADSyncScheduler -SyncCycleEnabled $true
Step 9: Verify the result

It is now time to verify the configuration and enable it for your users.
1. Add the geo to the selected attribute on a user. The list of available geos can be found in this table.
2. Wait for the attribute to be synchronized to Azure AD.

3. Using Exchange Online PowerShell, verify that the mailbox region has been set correctly.
Assuming your tenant has been marked to be able to use this feature, the mailbox is moved to the correct geo.
This can be verified by looking at the server name where the mailbox is located.
Next steps
Learn more about Multi-Geo in Office 365:
Multi-Geo sessions at Ignite
Multi-Geo in OneDrive
Multi-Geo in SharePoint Online
Learn more about the configuration model in the sync engine:
Overview topics:
Azure AD Connect sync: Configure filtering
By using filtering, you can control which objects appear in Azure Active Directory (Azure AD) from your on-
premises directory. The default configuration takes all objects in all domains in the configured forests. In general,
this is the recommended configuration. Users using Office 365 workloads, such as Exchange Online and Skype
for Business, benefit from a complete Global Address List so they can send email and call everyone. With the
default configuration, they would have the same experience that they would have with an on-premises
implementation of Exchange or Lync.
In some cases however, you're required make some changes to the default configuration. Here are some
examples:
You plan to use the multi-Azure AD directory topology. Then you need to apply a filter to control which
objects are synchronized to a particular Azure AD directory.
You run a pilot for Azure or Office 365 and you only want a subset of users in Azure AD. In the small pilot, it's
not important to have a complete Global Address List to demonstrate the functionality.
You have many service accounts and other nonpersonal accounts that you don't want in Azure AD.
For compliance reasons, you don't delete any user accounts on-premises. You only disable them. But in Azure
AD, you only want active accounts to be present.
This article covers how to configure the different filtering methods.
IMPORTANT
Microsoft doesn't support modifying or operating Azure AD Connect sync outside of the actions that are formally
documented. Any of these actions might result in an inconsistent or unsupported state of Azure AD Connect sync. As a
result, Microsoft can't provide technical support for such deployments.
Basics and important notes

In Azure AD Connect sync, you can enable filtering at any time. If you start with a default configuration of
directory synchronization and then configure filtering, the objects that are filtered out are no longer
synchronized to Azure AD. Because of this change, any objects in Azure AD that were previously synchronized
but were then filtered are deleted in Azure AD.
Before you start making changes to filtering, make sure that you disable the scheduled task so you don't
accidentally export changes that you haven't yet verified to be correct.
Because filtering can remove many objects at the same time, you want to make sure that your new filters are
correct before you start exporting any changes to Azure AD. After you've completed the configuration steps, we
strongly recommend that you follow the verification steps before you export and make changes to Azure AD.
To protect you from deleting many objects by accident, the feature "prevent accidental deletes" is on by default. If
you delete many objects due to filtering (500 by default), you need to follow the steps in this article to allow the
deletes to go through to Azure AD.
If you use a build before November 2015 (1.0.9125), make a change to a filter configuration, and use password
hash synchronization, then you need to trigger a full sync of all passwords after you've completed the
configuration. For steps on how to trigger a password full sync, see Trigger a full sync of all passwords. If you're
on build 1.0.9125 or later, then the regular full synchronization action also calculates whether passwords
should be synchronized and if this extra step is no longer required.
If user objects were inadvertently deleted in Azure AD because of a filtering error, you can recreate the user
objects in Azure AD by removing your filtering configurations. Then you can synchronize your directories again.
This action restores the users from the recycle bin in Azure AD. However, you can't undelete other object types.
For example, if you accidentally delete a security group and it was used to ACL a resource, the group and its ACLs
can't be recovered.
Azure AD Connect only deletes objects that it has once considered to be in scope. If there are objects in Azure AD
that were created by another sync engine and these objects aren't in scope, adding filtering doesn't remove them.
For example, if you start with a DirSync server that created a complete copy of your entire directory in Azure AD,
and you install a new Azure AD Connect sync server in parallel with filtering enabled from the beginning, Azure
AD Connect doesn't remove the extra objects that are created by DirSync.
The filtering configuration is retained when you install or upgrade to a newer version of Azure AD Connect. It's
always a best practice to verify that the configuration wasn't inadvertently changed after an upgrade to a newer
version before running the first synchronization cycle.
If you have more than one forest, then you must apply the filtering configurations that are described in this topic
to every forest (assuming that you want the same configuration for all of them).
Disable the scheduled task
To disable the built-in scheduler that triggers a synchronization cycle every 30 minutes, follow these steps:
1. Go to a PowerShell prompt.
2. Run Set-ADSyncScheduler -SyncCycleEnabled $False to disable the scheduler.
3. Make the changes that are documented in this article.
4. Run Set-ADSyncScheduler -SyncCycleEnabled $True to enable the scheduler again.
If you use an Azure AD Connect build before 1.1.105.0
To disable the scheduled task that triggers a synchronization cycle every three hours, follow these steps:
1. Start Task Scheduler from the Star t menu.
2. Directly under Task Scheduler Librar y , find the task named Azure AD Sync Scheduler , right-click, and
select Disable .
3. You can now make configuration changes and run the sync engine manually from the Synchronization
Ser vice Manager console.
After you've completed all your filtering changes, don't forget to come back and Enable the task again.
Filtering options
You can apply the following filtering configuration types to the directory synchronization tool:
Group-based : Filtering based on a single group can only be configured on initial installation by using the
Domain-based : By using this option, you can select which domains synchronize to Azure AD. You can also
add and remove domains from the sync engine configuration when you make changes to your on-premises
infrastructure after you install Azure AD Connect sync.
Organizational unit (OU)–based : By using this option, you can select which OUs synchronize to Azure AD.
This option is for all object types in selected OUs.
Attribute-based : By using this option, you can filter objects based on attribute values on the objects. You can
also have different filters for different object types.
You can use multiple filtering options at the same time. For example, you can use OU-based filtering to only
include objects in one OU. At the same time, you can use attribute-based filtering to filter the objects further.
When you use multiple filtering methods, the filters use a logical "AND" between the filters.
Domain-based filtering
This section provides you with the steps to configure your domain filter. If you added or removed domains in
your forest after you installed Azure AD Connect, you also have to update the filtering configuration.
The preferred way to change domain-based filtering is by running the installation wizard and changing domain
and OU filtering. The installation wizard automates all the tasks that are documented in this topic.
You should only follow these steps if you're unable to run the installation wizard for some reason.
Domain-based filtering configuration consists of these steps:
1. Select the domains that you want to include in the synchronization.
2. For each added and removed domain, adjust the run profiles.
3. Apply and verify changes.
Select the domains to be synchronized
There are two ways to select the domains to be synchronized: - Using the Synchronization Service - Using the
Azure AD Connect wizard.
Select the domains to be synchronized using the Synchronization Service
To set the domain filter, do the following steps:
1. Sign in to the server that is running Azure AD Connect sync by using an account that is a member of the
ADSyncAdmins security group.
2. Start Synchronization Ser vice from the Star t menu.
3. Select Connectors , and in the Connectors list, select the Connector with the type Active Director y
Domain Ser vices . In Actions , select Proper ties .
4. Click Configure Director y Par titions .

5. In the Select director y par titions list, select and unselect domains as needed. Verify that only the partitions
that you want to synchronize are selected.
If you've changed your on-premises Active Directory infrastructure and added or removed domains from the
forest, then click the Refresh button to get an updated list. When you refresh, you're asked for credentials.
Provide any credentials with read access to Windows Server Active Directory. It doesn't have to be the user
that is prepopulated in the dialog box.
6. When you're done, close the Proper ties dialog by clicking OK . If you removed domains from the forest, a
message pop-up says that a domain was removed and that configuration will be cleaned up.
7. Continue to adjust the run profiles.
Select the domains to be synchronized using the Azure AD Connect wizard
To set the domain filter, do the following steps:
1. Start the Azure AD Connect wizard
3. Select Customize Synchronization Options and click Next .
4. Enter your Azure AD credentials
5. On the Connected Directories screen click Next .
6. On the Domain and OU filtering page click Refresh . New domains ill now appear and deleted domains
will disappear.
Update the run profiles
If you've updated your domain filter, you also need to update the run profiles.
1. In the Connectors list, make sure that the Connector that you changed in the previous step is selected. In
Actions , select Configure Run Profiles .
2. Find and identify the following profiles:
Full Import
Full Synchronization
Delta Import
Delta Synchronization
Export
3. For each profile, adjust the added and removed domains.
a. For each of the five profiles, do the following steps for each added domain:
a. Select the run profile and click New Step .
b. On the Configure Step page, in the Type drop-down menu, select the step type with the same
name as the profile that you're configuring. Then click Next .
c. On the Connector Configuration page, in the Par tition drop-down menu, select the name of
the domain that you've added to your domain filter.
d. To close the Configure Run Profile dialog, click Finish .

b. For each of the five profiles, do the following steps for each removed domain:
a. Select the run profile.
b. If the Value of the Par tition attribute is a GUID, select the run step and click Delete Step .
c. Verify your change. Each domain that you want to synchronize should be listed as a step in each run
profile.
4. To close the Configure Run Profiles dialog, click OK .
5. To complete the configuration, you need to run a Full impor t and a Delta sync . Continue reading the
section Apply and verify changes.
Organizational unit–based filtering

The preferred way to change OU-based filtering is by running the installation wizard and changing domain and
OU filtering. The installation wizard automates all the tasks that are documented in this topic.
You should only follow these steps if you're unable to run the installation wizard for some reason.
To configure organizational unit–based filtering, do the following steps:
3. Select Connectors , and in the Connectors list, select the Connector with the type Active Director y
Domain Ser vices . In Actions , select Proper ties .
4. Click Configure Director y Par titions , select the domain that you want to configure, and then click
Containers .
5. When you're prompted, provide any credentials with read access to your on-premises Active Directory. It
doesn't have to be the user that is prepopulated in the dialog box.
6. In the Select Containers dialog box, clear the OUs that you don’t want to synchronize with the cloud
directory, and then click OK .
The Computers container should be selected for your Windows 10 computers to be successfully
synchronized to Azure AD. If your domain-joined computers are located in other OUs, make sure those
are selected.
The ForeignSecurityPrincipals container should be selected if you have multiple forests with trusts.
This container allows cross-forest security group membership to be resolved.
The RegisteredDevices OU should be selected if you enabled the device writeback feature. If you use
another writeback feature, such as group writeback, make sure these locations are selected.
Select any other OU where Users, iNetOrgPersons, Groups, Contacts, and Computers are located. In the
picture, all these OUs are located in the ManagedObjects OU.
If you use group-based filtering, then the OU where the group is located must be included.
Note that you can configure whether new OUs that are added after the filtering configuration finishes
are synchronized or not synchronized. See the next section for details.
7. When you're done, close the Proper ties dialog by clicking OK .
8. To complete the configuration, you need to run a Full impor t and a Delta sync . Continue reading the
section Apply and verify changes.
Synchronize new OUs
New OUs that are created after filtering has been configured are synchronized by default. This state is indicated
by a selected check box. You can also unselect some sub-OUs. To get this behavior, click the box until it becomes
white with a blue check mark (its default state). Then unselect any sub-OUs that you don't want to synchronize.
If all sub-OUs are synchronized, then the box is white with a blue check mark.
If some sub-OUs have been unselected, then the box is gray with a white check mark.
With this configuration, a new OU that was created under ManagedObjects is synchronized.
The Azure AD Connect installation wizard always creates this configuration.
Don't synchronize new OUs
You can configure the sync engine to not synchronize new OUs after the filtering configuration has finished. This
state is indicated in the UI by the box appearing solid gray with no check mark. To get this behavior, click the box
until it becomes white with no check mark. Then select the sub-OUs that you want to synchronize.
With this configuration, a new OU that was created under ManagedObjects isn't synchronized.
Attribute-based filtering
Make sure that you're using the November 2015 (1.0.9125) or later build for these steps to work.
IMPORTANT
Microsoft recommends to not modify the default rules created by Azure AD Connect . If you want to modify the rule,
then clone it, and disable the original rule. Make any changes to the cloned rule. Please note that by doing so (disabling
original rule) you will miss any bug fixes or features enabled through that rule.
Attribute-based filtering is the most flexible way to filter objects. You can use the power of declarative
provisioning to control almost every aspect of when an object is synchronized to Azure AD.
You can apply inbound filtering from Active Directory to the metaverse, and outbound filtering from the
metaverse to Azure AD. We recommend that you apply inbound filtering because that is the easiest to maintain.
You should only use outbound filtering if it's required to join objects from more than one forest before the
evaluation can take place.
Inbound filtering
Inbound filtering uses the default configuration, where objects going to Azure AD must have the metaverse
attribute cloudFiltered not set to a value to be synchronized. If this attribute's value is set to True , then the object
isn't synchronized. It shouldn't be set to False , by design. To make sure other rules have the ability to contribute a
value, this attribute is only supposed to have the values True or NULL (absent).
In inbound filtering, you use the power of scope to determine which objects to synchronize or not synchronize.
This is where you make adjustments to fit your own organization's requirements. The scope module has a group
and a clause to determine when a sync rule is in scope. A group contains one or many clauses. There is a logical
"AND" between multiple clauses, and a logical "OR" between multiple groups.
Let us look at an example:
This should be read as (depar tment = IT) OR (depar tment = Sales AND c = US) .
In the following samples and steps, you use the user object as an example, but you can use this for all object
types.
In the following samples, the precedence value starts with 50. This can be any number not used, but should be
lower than 100.
Negative filtering: "do not sync these"
In the following example, you filter out (not synchronize) all users where extensionAttribute15 has the value
NoSync .
2. Start Synchronization Rules Editor from the Star t menu.
3. Make sure Inbound is selected, and click Add New Rule .
4. Give the rule a descriptive name, such as "In from AD – User DoNotSyncFilter". Select the correct forest, select
User as the CS object type , and select Person as the MV object type . In Link Type , select Join . In
Precedence , type a value that isn't currently used by another synchronization rule (for example 50), and then
click Next .
5. In Scoping filter , click Add Group , and click Add Clause . In Attribute , select ExtensionAttribute15 .
Make sure that Operator is set to EQUAL , and type the value NoSync in the Value box. Click Next .
6. Leave the Join rules empty, and then click Next .

7. Click Add Transformation , select the FlowType as Constant , and select cloudFiltered as the Target
Attribute . In the Source text box, type True . Click Add to save the rule.
8. To complete the configuration, you need to run a Full sync . Continue reading the section Apply and verify
changes.
Positive filtering: "only sync these"
Expressing positive filtering can be more challenging because you also have to consider objects that aren't
obvious to be synchronized, such as conference rooms. You are also going to override the default filter in the out-
of-box rule In from AD - User Join . When you create your custom filter, make sure to not include critical
system objects, replication conflict objects, special mailboxes, and the service accounts for Azure AD Connect.
The positive filtering option requires two sync rules. You need one rule (or several) with the correct scope of
objects to synchronize. You also need a second catch-all sync rule that filters out all objects that haven't yet been
identified as an object that should be synchronized.
In the following example, you only synchronize user objects where the department attribute has the value Sales .
3. Make sure Inbound is selected, and click Add New Rule .
4. Give the rule a descriptive name, such as "In from AD – User Sales sync". Select the correct forest, select User
as the CS object type , and select Person as the MV object type . In Link Type , select Join . In Precedence ,
type a value that isn't currently used by another synchronization rule (for example 51), and then click Next .
5. In Scoping filter , click Add Group , and click Add Clause . In Attribute , select depar tment . Make sure that
Operator is set to EQUAL , and type the value Sales in the Value box. Click Next .

7. Click Add Transformation , select Constant as the FlowType , and select the cloudFiltered as the Target
Attribute . In the Source box, type False . Click Add to save the rule.
This is a special case where you explicitly set cloudFiltered to False .

8. We now have to create the catch-all sync rule. Give the rule a descriptive name, such as "In from AD – User
Catch-all filter". Select the correct forest, select User as the CS object type , and select Person as the MV
object type . In Link Type , select Join . In Precedence , type a value that isn't currently used by another
Synchronization Rule (for example 99). You've selected a precedence value that is higher (lower precedence)
than the previous sync rule. But you've also left some room so that you can add more filtering sync rules later
when you want to start synchronizing additional departments. Click Next .
9. Leave Scoping filter empty, and click Next . An empty filter indicates that the rule is to be applied to all
objects.
11. Click Add Transformation , select Constant as the FlowType , and select cloudFiltered as the Target
Attribute . In the Source box, type True . Click Add to save the rule.
changes.
If you need to, you can create more rules of the first type where you include more objects in the synchronization.
Outbound filtering
In some cases, it's necessary to do the filtering only after the objects have joined in the metaverse. For example, it
might be necessary to look at the mail attribute from the resource forest, and the userPrincipalName attribute
from the account forest, to determine if an object should be synchronized. In these cases, you create the filtering
on the outbound rule.
In this example, you change the filtering so that only users that have both their mail and userPrincipalName
ending in @contoso.com are synchronized:
3. Under Rules Type , click Outbound .
4. Depending on the version of Connect you use, either find the rule named Out to AAD – User Join or Out
to AAD - User Join SOAInAD , and click Edit .
5. In the pop-up, answer Yes to create a copy of the rule.
6. On the Description page, change Precedence to an unused value, such as 50.
7. Click Scoping filter on the left-hand navigation, and then click Add clause . In Attribute , select mail . In
Operator , select ENDSWITH . In Value , type @contoso.com , and then click Add clause . In Attribute ,
select userPrincipalName . In Operator , select ENDSWITH . In Value , type @contoso.com .
8. Click Save .
changes.
Apply and verify changes

After you've made your configuration changes, you must apply them to the objects that are already present in
the system. It might also be that the objects that aren't currently in the sync engine should be processed (and the
sync engine needs to read the source system again to verify its content).
If you changed the configuration by using domain or organizational-unit filtering, then you need to do a Full
impor t , followed by Delta synchronization .
If you changed the configuration by using attribute filtering, then you need to do a Full synchronization .
Do the following steps:
2. Select Connectors . In the Connectors list, select the Connector where you made a configuration change
earlier. In Actions , select Run .
3. In Run profiles , select the operation that was mentioned in the previous section. If you need to run two
actions, run the second after the first one has finished. (The State column is Idle for the selected connector.)
After the synchronization, all changes are staged to be exported. Before you actually make the changes in Azure
AD, you want to verify that all these changes are correct.
1. Start a command prompt, and go to %ProgramFiles%\Microsoft Azure AD Sync\bin .
2. Run csexport "Name of Connector" %temp%\export.xml /f:x .
The name of the Connector is in Synchronization Service. It has a name similar to "contoso.com – AAD" for
Azure AD.
3. Run CSExportAnalyzer %temp%\export.xml > %temp%\export.csv .
4. You now have a file in %temp% named export.csv that can be examined in Microsoft Excel. This file contains
all the changes that are about to be exported.
5. Make the necessary changes to the data or configuration, and run these steps again (Import, Synchronize, and
Verify) until the changes that are about to be exported are what you expect.
When you're satisfied, export the changes to Azure AD.
1. Select Connectors . In the Connectors list, select the Azure AD Connector. In Actions , select Run .
2. In Run profiles , select Expor t .
3. If your configuration changes delete many objects, then you see an error in the export when the number is
more than the configured threshold (by default 500). If you see this error, then you need to temporarily
disable the "prevent accidental deletes" feature.
Now it's time to enable the scheduler again.
1. Start Task Scheduler from the Star t menu.
2. Directly under Task Scheduler Librar y , find the task named Azure AD Sync Scheduler , right-click, and
select Enable .
Group-based filtering
You can configure group-based filtering the first time that you install Azure AD Connect by using custom
installation. It's intended for a pilot deployment where you want only a small set of objects to be synchronized.
When you disable group-based filtering, it can't be enabled again. It's not supported to use group-based filtering
in a custom configuration. It's only supported to configure this feature by using the installation wizard. When
you've completed your pilot, then use one of the other filtering options in this topic. When using OU-based
filtering in conjunction with group-based filtering, the OU(s) where the group and its members are located must
be included.
When synchronizing multiple AD forests, you can configure group-based filtering by specifying a different group
for each AD connector. If you wish to synchronize a user in one AD forest and the same user has one or more
corresponding objects in other AD forests, you must ensure that the user object and all its corresponding objects
are within group-based filtering scope. For examples:
You have a user in one forest that has a corresponding FSP (Foreign Security Principal) object in another
forest. Both objects must be within group-based filtering scope. Otherwise, the user will not be
synchronized to Azure AD.
You have a user in one forest that has a corresponding resource account (e.g., linked mailbox) in another
forest. Further, you have configured Azure AD Connect to link the user with the resource account. Both
objects must be within group-based filtering scope. Otherwise, the user will not be synchronized to Azure
AD.
You have a user in one forest that has a corresponding mail contact in another forest. Further, you have
configured Azure AD Connect to link the user with the mail contact. Both objects must be within group-
based filtering scope. Otherwise, the user will not be synchronized to Azure AD.
Next steps
Learn more about Azure AD Connect sync configuration.
Learn more about integrating your on-premises identities with Azure AD.
Azure AD Connect sync: Scheduler
This topic describes the built-in scheduler in Azure AD Connect sync (sync engine).
This feature was introduced with build 1.1.105.0 (released February 2016).
Overview
Azure AD Connect sync synchronize changes occurring in your on-premises directory using a scheduler. There
are two scheduler processes, one for password sync and another for object/attribute sync and maintenance
tasks. This topic covers the latter.
In earlier releases, the scheduler for objects and attributes was external to the sync engine. It used Windows task
scheduler or a separate Windows service to trigger the synchronization process. The scheduler is with the 1.1
releases built-in to the sync engine and do allow some customization. The new default synchronization
frequency is 30 minutes.
The scheduler is responsible for two tasks:
Synchronization cycle . The process to import, sync, and export changes.
Maintenance tasks . Renew keys and certificates for Password reset and Device Registration Service (DRS).
Purge old entries in the operations log.
The scheduler itself is always running, but it can be configured to only run one or none of these tasks. For
example, if you need to have your own synchronization cycle process, you can disable this task in the scheduler
but still run the maintenance task.
IMPORTANT
By default every 30 minutes a synchronization cycle is run. If you have modified the synchronization cycley you will need
to make sure that a synchronization cycle is run at least once every 7 days.
A delta sync needs to happen within 7 days from the last delta sync.
A delta sync (following a full sync) needs to happen within 7 days from the time the last full sync completed.
Failure to do so may cause synchronization issues which will require you to run a full synchronization to resolve. This also
applies to servers in Staging mode.
Scheduler configuration
To see your current configuration settings, go to PowerShell and run Get-ADSyncScheduler . It shows you
something like this picture:
If you see The sync command or cmdlet is not available when you run this cmdlet, then the PowerShell
module is not loaded. This problem could happen if you run Azure AD Connect on a domain controller or on a
server with higher PowerShell restriction levels than the default settings. If you see this error, then run
Import-Module ADSync to make the cmdlet available.
AllowedSyncCycleInter val . The shortest time interval between synchronization cycles allowed by Azure
AD. You cannot synchronize more frequently than this setting and still be supported.
CurrentlyEffectiveSyncCycleInter val . The schedule currently in effect. It has the same value as
CustomizedSyncInterval (if set) if it is not more frequent than AllowedSyncInterval. If you use a build before
1.1.281 and you change CustomizedSyncCycleInterval, this change takes effect after next synchronization
cycle. From build 1.1.281 the change takes effect immediately.
CustomizedSyncCycleInter val . If you want the scheduler to run at any other frequency than the default
30 minutes, then you configure this setting. In the picture above, the scheduler has been set to run every
hour instead. If you set this setting to a value lower than AllowedSyncInterval, then the latter is used.
NextSyncCyclePolicyType . Either Delta or Initial. Defines if the next run should only process delta changes,
or if the next run should do a full import and sync. The latter would also reprocess any new or changed rules.
NextSyncCycleStar tTimeInUTC . Next time the scheduler starts the next sync cycle.
PurgeRunHistor yInter val . The time operation logs should be kept. These logs can be reviewed in the
synchronization service manager. The default is to keep these logs for 7 days.
SyncCycleEnabled . Indicates if the scheduler is running the import, sync, and export processes as part of
its operation.
MaintenanceEnabled . Shows if the maintenance process is enabled. It updates the certificates/keys and
purges the operations log.
StagingModeEnabled . Shows if staging mode is enabled. If this setting is enabled, then it suppresses the
exports from running but still run import and synchronization.
SchedulerSuspended . Set by Connect during an upgrade to temporarily block the scheduler from running.
You can change some of these settings with Set-ADSyncScheduler . The following parameters can be modified:
CustomizedSyncCycleInterval
NextSyncCyclePolicyType
PurgeRunHistoryInterval
SyncCycleEnabled
MaintenanceEnabled
In earlier builds of Azure AD Connect, isStagingModeEnabled was exposed in Set-ADSyncScheduler. It is
unsuppor ted to set this property. The property SchedulerSuspended should only be modified by Connect. It
is unsuppor ted to set this with PowerShell directly.
The scheduler configuration is stored in Azure AD. If you have a staging server, any change on the primary
server also affects the staging server (except IsStagingModeEnabled).
CustomizedSyncCycleInterval
Syntax: Set-ADSyncScheduler -CustomizedSyncCycleInterval d.HH:mm:ss
d - days, HH - hours, mm - minutes, ss - seconds
Example: Set-ADSyncScheduler -CustomizedSyncCycleInterval 03:00:00
Changes the scheduler to run every 3 hours.
Example: Set-ADSyncScheduler -CustomizedSyncCycleInterval 1.0:0:0
Changes change the scheduler to run daily.
Disable the scheduler
If you need to make configuration changes, then you want to disable the scheduler. For example, when you
configure filtering or make changes to synchronization rules.
To disable the scheduler, run Set-ADSyncScheduler -SyncCycleEnabled $false .
When you've made your changes, do not forget to enable the scheduler again with
Set-ADSyncScheduler -SyncCycleEnabled $true .
Start the scheduler

The scheduler is by default run every 30 minutes. In some cases, you might want to run a sync cycle in between
the scheduled cycles or you need to run a different type.
Delta sync cycle
A delta sync cycle includes the following steps:
Delta import on all Connectors
Delta sync on all Connectors
Export on all Connectors
Full sync cycle
A full sync cycle includes the following steps:
Full Import on all Connectors
Full Sync on all Connectors
Export on all Connectors
It could be that you have an urgent change that must be synchronized immediately, which is why you need to
manually run a cycle.
If you need to manually run a sync cycle, then from PowerShell run Start-ADSyncSyncCycle -PolicyType Delta .
To initiate a full sync cycle, run Start-ADSyncSyncCycle -PolicyType Initial from a PowerShell prompt.
Running a full sync cycle can be very time consuming, read the next section to read how to optimize this
process.
Sync steps required for different configuration changes
Different configuration changes require different sync steps to ensure the changes are correctly applied to all
objects.
Added more objects or attributes to be imported from a source directory (by adding/modifying the sync
rules)
A Full Import is required on the Connector for that source directory
Made changes to the Synchronization rules
A Full Sync is required on the Connector for the changed Synchronization rules
Changed filtering so a different number of objects should be included
A Full Import is required on the Connector for each AD Connector UNLESS you are using Attribute-
based filtering based on attributes that are already being imported into the sync engine
Customizing a sync cycle run the right mix of Delta and Full sync steps
To avoid running a full sync cycle you can mark specific Connectors to run a Full step using the following
cmdlets.
Set-ADSyncSchedulerConnectorOverride -Connector <ConnectorGuid> -FullImportRequired $true
Set-ADSyncSchedulerConnectorOverride -Connector <ConnectorGuid> -FullSyncRequired $true
Get-ADSyncSchedulerConnectorOverride -Connector <ConnectorGuid>
Example: If you made changes to the synchronization rules for Connector “AD Forest A” that don’t require any
new attributes to be imported you would run the following cmdlets to run a delta sync cycle which also did a
Full Sync step for that Connector.
Set-ADSyncSchedulerConnectorOverride -ConnectorName “AD Forest A” -FullSyncRequired $true
Start-ADSyncSyncCycle -PolicyType Delta
Example: If you made changes to the synchronization rules for Connector “AD Forest A” so that they now require
a new attribute to be imported you would run the following cmdlets to run a delta sync cycle which also did a
Full Import, Full Sync step for that Connector.
Set-ADSyncSchedulerConnectorOverride -ConnectorName “AD Forest A” -FullImportRequired $true
Set-ADSyncSchedulerConnectorOverride -ConnectorName “AD Forest A” -FullSyncRequired $true
Start-ADSyncSyncCycle -PolicyType Delta
Stop the scheduler

If the scheduler is currently running a synchronization cycle, you might need to stop it. For example if you start
the installation wizard and you get this error:
When a sync cycle is running, you cannot make configuration changes. You could wait until the scheduler has
finished the process, but you can also stop it so you can make your changes immediately. Stopping the current
cycle is not harmful and pending changes are processed with next run.
1. Start by telling the scheduler to stop its current cycle with the PowerShell cmdlet Stop-ADSyncSyncCycle .
2. If you use a build before 1.1.281, then stopping the scheduler does not stop the current Connector from its
current task. To force the Connector to stop, take the following actions:
Start Synchronization Ser vice from the start menu. Go to Connectors , highlight the Connector
with the state Running , and select Stop from the Actions.
The scheduler is still active and starts again on next opportunity.
Custom scheduler
The cmdlets documented in this section are only available in build 1.1.130.0 and later.
If the built-in scheduler does not satisfy your requirements, then you can schedule the Connectors using
PowerShell.
Invoke -ADSyncRunProfile
You can start a profile for a Connector in this way:
Invoke-ADSyncRunProfile -ConnectorName "name of connector" -RunProfileName "name of profile"
The names to use for Connector names and Run Profile Names can be found in the Synchronization Service
Manager UI.
The Invoke-ADSyncRunProfile cmdlet is synchronous, that is, it does not return control until the Connector has
completed the operation, either successfully or with an error.
When you schedule your Connectors, the recommendation is to schedule them in the following order:
1. (Full/Delta) Import from on-premises directories, such as Active Directory
2. (Full/Delta) Import from Azure AD
3. (Full/Delta) Synchronization from on-premises directories, such as Active Directory
4. (Full/Delta) Synchronization from Azure AD
5. Export to Azure AD
6. Export to on-premises directories, such as Active Directory
This order is how the built-in scheduler runs the Connectors.
Get-ADSyncConnectorRunStatus
You can also monitor the sync engine to see if it is busy or idle. This cmdlet returns an empty result if the sync
engine is idle and is not running a Connector. If a Connector is running, it returns the name of the Connector.
Get-ADSyncConnectorRunStatus
In the picture above, the first line is from a state where the sync engine is idle. The second line from when the
Azure AD Connector is running.
Scheduler and installation wizard

If you start the installation wizard, then the scheduler is temporarily suspended. This behavior is because it is
assumed you make configuration changes and these settings cannot be applied if the sync engine is actively
running. For this reason, do not leave the installation wizard open since it stops the sync engine from
performing any synchronization actions.
Next steps
How to customize a synchronization rule
Recommended Steps
You can use the synchronization rule editor to edit or create a new synchronization rule. You need to be an
advanced user to make changes to synchronization rules. Any wrong changes may result in deletion of objects
from your target directory. Please read Recommended Documents to gain expertise in synchronization rules. To
modify a synchronization rule go through following steps:
Launch the synchronization editor from the application menu in desktop as shown below:
In order to customize a default synchronization rule, clone the existing rule by clicking the “Edit” button on
the Synchronization Rules Editor, which will create a copy of the standard default rule and disable it. Save the
cloned rule with a precedence less than 100. Precedence determines what rule wins(lower numeric value) a
conflict resolution if there is an attribute flow conflict.
When modifying a specific attribute, ideally you should only keep the modifying attribute in the cloned rule.
Then enable the default rule so that modified attribute comes from cloned rule and other attributes are
picked from default standard rule.
Please note that in the case where the calculated value of the modified attribute is NULL in your cloned rule
and is not NULL in the default standard rule then, the not NULL value will win and will replace the NULL
value. If you don’t want a NULL value to be replace with a not NULL value then assign AuthoritativeNull in
your cloned rule.
To modify an Outbound rule, change filter from the synchronization rule editor.
Recommended Documents
Azure AD Connect sync: Understanding the architecture
Azure AD Connect sync: Understanding Declarative Provisioning
Azure AD Connect sync: Understanding Declarative Provisioning Expressions
Azure AD Connect sync: Understanding the default configuration
Azure AD Connect sync: Understanding Users, Groups, and Contacts
Azure AD Connect sync: Shadow attributes
Next Steps
Azure AD Connect sync.
What is hybrid identity?.
Azure AD Connect sync V2 endpoint API (public
preview)
Microsoft has deployed a new endpoint (API) for Azure AD Connect that improves the performance of the
synchronization service operations to Azure Active Directory. By utilizing the new V2 endpoint, you will experience
noticeable performance gains on export and import to Azure AD. This new endpoint supports the following:
syncing groups with up to 250k members
performance gains on export and import to Azure AD
NOTE
Currently, the new endpoint does not have a configured group size limit for O365 groups that are written back. This may
have an effect on your Active Directory and sync cycle latencies. It is recommended to increase your group sizes
incrementally.
Pre-requisites
In order to use the new V2 endpoint, you will need to use Azure AD Connect version 1.5.30.0 or later and follow the
deployment steps provided below to enable the V2 endpoint for your Azure AD Connect server.
NOTE
Currently, this public preview is only available in the Azure global cloud and not available for national clouds.
Public preview limitations

While this release has undergone extensive testing, you may still encounter issues. One of the goals of this public
preview release is to find and fix any such issues.
IMPORTANT
While support is provided for this public preview release, Microsoft may not always be able to fix all issues you may
encounter immediately. For this reason, it is recommended that you use your best judgement before deploying this release in
your production environment.
Deployment guidance
You will need to deploy Azure AD Connect version 1.5.30.0 or later to use the V2 endpoint. Use the link provided to
download.
It is recommended that you follow the swing migration method for rolling out the new endpoint in your
environment. This will provide a clear contingency plan in the event, that a major rollback is necessary. The
following example illustrates how a swing migration can be used in this scenario. For more information on the
swing migration deployment method, refer to the link provided.
Swing migration for deploying V2 endpoint
The following steps will guide you through deploying the v2 endpoint using the swing method.
1. Deploy the V2 endpoint on the current staging server. This server will be known as the V2 ser ver in the steps
below. The current active server will continue to process the production workload using the V1 endpoint, which
will be called the V1 ser ver below.
2. Validate that the V2 ser ver is still processing imports as expected. At this stage, large groups will not be
provisioned to Azure AD or on-prem AD, but you will be able to verify that the upgrade did not result in any
other unexpected impact to the existing synchronization process.
3. Once validation is complete, switch the V2 ser ver to be the active server and the V1 ser ver to be the staging
server. At this time, large groups that are in scope to be synced will be provisioned to Azure AD, as well as large
O365 unified groups will be provisioned to AD, if group writeback is enabled.
4. Validate that the V2 ser ver is performing and processing large groups successfully. You may choose to stay at
this step and monitor the synchronization process for a period.
NOTE
If you need to transition back to your previous configuration, you can perform a swing migration from the V2 ser ver back
to the V1 ser ver . Since the V1 endpoint does not support groups with over 50k members, any large group that was
provisioned by Azure AD Connect, in either Azure AD or on-prem AD, will be subsequently deleted. 4. Once you are
confident in using the V2 endpoint, upgrade the V1 ser ver to begin using the V2 endpoint.
Expectations of performance impact

When using the V2 endpoint, performance gains are a function of the number of synced groups, size of those
groups, and their group churn (the activity resulting from adding and removing users as members of the group).
Using the new endpoint, without increasing the number, size, or churn of the synced groups, should result in
shorter times for export and import to Azure AD.
However, the performance gains can be negated by the additional processing required when syncing large groups.
You could end up increasing the overall sync time by adding a too many large groups to the sync process.
To gain a better understanding of how the addition of the new groups will impact your sync performance, it is
recommended that you start by syncing only a few large groups with less than 100k members. You can then
increase the number and size of groups by bringing more of them in scope, through OU, attribute, or max group
size filtering. The performance improvements will be realized on the export and import tasks for the Azure AD
connector, not the on-premises AD connector.
Deployment step by step

The following three phases are an in-depth example of deploying the new V2 endpoint. Use the phases as a
guideline for your deployment.
Phase 1 – install and validate Azure AD Connect
It is recommended that you first perform the steps to install or upgrade to Azure AD Connect version 1.5.30.0 or
later and validate the sync process before you go to the second phase where you will enable the V2 endpoint. On
the Azure AD Connect server:
1. [Optional] Take database backup
2. Install or upgrade to Azure AD Connect version 1.5.30.0 or later.
3. Validate the installation
Phase 2 – enable the V2 endpoint
The next step is to enable the V2 endpoint.
NOTE
After you have enabled the V2 endpoint for your server you will be able to see some performance improvements for your
existing workload. You will not yet be able to sync groups with more that 50K members though.
To switch to the V2 endpoint, use the following steps:

1. Open a PowerShell prompt as administrator.
2. Disable the sync scheduler after verifying that no synchronization operations are running:
Set-ADSyncScheduler -SyncCycleEnabled $false
3. Import the new module:

Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Extensions\AADConnector.psm1'
4. Switch to the v2 endpoint:

Set-ADSyncAADConnectorExportApiVersion 2
Set-ADSyncAADConnectorImportApiVersion 2
You have now enabled the V2 endpoint for your server. Take some time to verify that there are no unexpected
results after enabling the V2 endpoint before you move to the next phase where you will increase the group size
limit.
NOTE
The file / module paths may use a different drive letter, depending on the installation path provided when installing Azure AD
Connect.
Phase 3 – increase the group membership limit

After you have verified that the service is running without unexpected results, you can proceed to raising the group
membership limit. It is recommended to first raise the membership limit to a slightly higher value, e g. 75K
members, to see the larger groups syncing to Azure AD. Once you are satisfied with the results you can further
raise the member limit.
The maximum limit is 250K members per group.
The following steps can be used to increase the membership limit:
1. Open Azure AD Synchronization Rules Editor
2. In the editor, choose Outbound for Direction
3. Click on the Out to AAD – Group Join sync rule
4. Click the Edit button
5. Click the Yes button to disable the default rule and create an editable copy.
6. In the pop-up window on the Description page, set the precedence to an available value between 1 and 99
7. On the Transformations page, update the Source value for the member transformation, replacing
‘50000’ with a value between 50001 and 250000. This replacement will increase the maximum membership
size of groups that will sync to Azure AD. We suggest starting with a number of 100k, to understand the
impact that syncing large groups will have on your sync performance.
Example
IIF((ValueCount("member")> 75000),Error("Maximum Group member count exceeded"),IgnoreThisFlow)
9. Click Save
10. Open admin PowerShell prompt
11. Re-enable the Sync Scheduler
Set-ADSyncScheduler -SyncCycleEnabled $true
NOTE
If Azure AD Connect Health is not enabled, change the windows application event log settings to archive the logs, instead of
overwriting them. The logs may be used to assist in future troubleshooting efforts.
NOTE
After enabling the new endpoint, you may see additional export errors on the AAD connector with name ‘dn-attributes-
failure’. There will be a corresponding event log entry for each error with id 6949, . The errors are informational and do not
indicate a problem with your installation, but rather that the sync process could not add certain members to a group in
Azure AD because the member object itself was not synced to Azure AD.
The new V2 endpoint code handles some types of export errors slightly different from how the V1 code did. You
may see more of the informational error messages when you use the V2 endpoint.
NOTE
When upgrading Azure AD Connect, ensure that the steps in Phase 2 are rerun, as the changes are not preserved through
the upgrade process.
During subsequent increases to the group member limit in the Out to AAD – Group Join sync rule, a full sync is
not necessary, so you can elect to suppress the full sync by running the following command in PowerShell.
Set-ADSyncSchedulerConnectorOverride -FullSyncRequired $false -ConnectorName "<AAD Connector Name>"
NOTE
If you have O365 unified groups that have more than 50k members, the groups will be read into Azure AD Connect, and if
group writeback is enabled, they will be written to your on-premises AD.
Rollback
If you have enabled the v2 endpoint and need to rollback, follow these steps:
1. On the Azure AD Connect server: a. [Optional] Take database backup
2. Open an admin PowerShell prompt:
3. Disable the sync scheduler after verifying that no synchronization operations are running
Set-ADSyncScheduler -SyncCycleEnabled $false
4. Switch to the V1 endpoint *

Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Extensions\AADConnector.psm1'
Set-ADSyncAADConnectorExportApiVersion 1
Set-ADSyncAADConnectorImportApiVersion 1
5. Open Azure AD Synchronization Rules Editor

6. Delete the editable copy of the Out to AAD – Group Join sync rule
7. Enable the default copy of the Out to AAD – Group Join sync rule
8. Open an admin PowerShell prompt
9. Re-enable the Sync Scheduler
Set-ADSyncScheduler -SyncCycleEnabled $true
NOTE
When switching back from the V2 to V1 endpoints, groups synced with more than 50k members will be deleted after a full
sync is run, for both AD groups provisioned to Azure AD and O365 unified groups provisioned to AD.

Q: Can a customer use this feature in production?
Yes, this can be used in production environments, with the caveat as mentioned before.
Q: Who can the customer contact when things go wrong?
If you need support when using this feature you should open a support case.
Q: Can I expect frequent updates to the public preview?
There is a limited degree of ongoing changes during a Public Preview.Youshould assess this risk when deploying
Public Preview featuresinproduction.
Q: Time to next milestone?
Public Preview capabilities may be withdrawn and possibly redesigned before reaching further milestones.
Next steps
Using the Sync Service Manager Operations tab
The operations tab shows the results from the most recent operations. This tab is key to understand and
troubleshoot issues.
Understand the information visible in the operations tab

The top half shows all runs in chronological order. By default, the operations log keeps information about the last
seven days, but this setting can be changed with the scheduler. You want to look for any run that does not show a
success status. You can change the sorting by clicking the headers.
The Status column is the most important information and shows the most severe problem for a run. Here is a
quick summary of the most common statuses in order of priority to investigate (where * indicate several possible
error strings).
STAT US C O M M EN T
stopped-* The run could not complete. For example, if the remote
system is down and cannot be contacted.
stopped-error-limit There are more than 5,000 errors. The run was automatically
stopped due to the large number of errors.
completed-*-errors The run completed, but there are errors (fewer than 5,000)
that should be investigated.
completed-*-warnings The run completed, but some data is not in the expected
state. If you have errors, then this message is usually only a
symptom. Until you have addressed errors, you should not
investigate warnings.
success No issues.
When you select a row, the bottom updates to show the details of that run. To the far left of the bottom, you might
have a list saying Step # . This list only appears if you have multiple domains in your forest where each domain is
represented by a step. The domain name can be found under the heading Par tition . Under Synchronization
Statistics , you can find more information about the number of changes that were processed. You can click the
links to get a list of the changed objects. If you have objects with errors, those errors show up under
Synchronization Errors .
For more information, see troubleshoot an object that is not synchronizing
Next steps
Using connectors with the Azure AD Connect Sync
Service Manager
The Connectors tab is used to manage all systems the sync engine is connected to.
Connector actions
A C T IO N C O M M EN T
Create Do not use. For connecting to additional AD forests, use the

Properties Used for domain and OU filtering.
Delete Used to either delete the data in the connector space or to

delete connection to a forest.
Configure Run Profiles Except for domain filtering, nothing to configure here. You can
use this action to see already configured run profiles.
Run Used to start a one-off run of a profile.
Stop Stops a Connector currently running a profile.
Export Connector Do not use.

A C T IO N C O M M EN T
Import Connector Do not use.
Update Connector Do not use.
Refresh Schema Refreshes the cached schema. It is preferred to use the option
in the installation wizard instead, since that also updates sync
rules.
Search Connector Space Used to find objects and to Follow an object and its data
through the system.
Delete
The delete action is used for two different things.
The option Delete connector space only removes all data, but keep the configuration.
The option Delete Connector and connector space removes the data and the configuration. This option is
used when you do not want to connect to a forest anymore.
Both options sync all objects and update the metaverse objects. This action is a long running operation.
Configure Run Profiles
This option allows you to see the run profiles configured for a Connector.
Search Connector Space
The search connector space action is useful to find objects and troubleshoot data issues.
Start by selecting a scope . You can search based on data (RDN, DN, Anchor, Sub-Tree), or state of the object (all
other options).
If you for example do a Sub-Tree search, you get all objects in one OU.
From this grid you can select an object, select proper ties , and follow it from the source connector space, through
the metaverse, and to the target connector space.
Changing the AD DS account password
If you change the account password, the Synchronization Service will no longer be able to import/export changes
to on-premises AD. You may see the following:
The import/export step for the AD connector fails with "no-start-credentials" error.
Under Windows Event Viewer, the application event log contains an error with Event ID 6000 and message
“The management agent “contoso.com” failed to run because the credentials were invalid.”
To resolve the issue, update the AD DS user account using the following:

3. Select the AD Connector which is configured to use the AD DS account.
4. Under Actions, select Proper ties .
5. In the pop-up dialog, select Connect to Active Directory Forest:
6. The Forest name indicates the corresponding on premises AD.
7. The User name indicates the AD DS account used for synchronization.
8. Enter the new password of the AD DS account in the Password textbox
9. Click OK to save the new password and restart the Synchronization Service to remove the old password from
memory cache.
Next steps
Sync Service Manager Metaverse Designer
For most customers, there is nothing to configure here.
Next steps
Sync Service Manager Metaverse Search
The metaverse search tab is useful for troubleshooting data-related problems. In the top half, you can create a
query based on a combination of attributes. When you are satisfied with your query, click Search . The result is
visible in the bottom grid. You can select which columns should be visible with Column Settings .
In the search results, select an object and Proper ties to see the metaverse object properties.
Next steps
What is the Azure AD Connect Admin Agent?
The Azure AD Connect Administration Agent is a new component of Azure Active Directory Connect that can be
installed on an Azure Active Directory Connect server. It is used to collect specific data from your Active Directory
environment that helps a Microsoft support engineer to troubleshoot issues when you open a support case.
NOTE
The admin agent is not installed and enabled by default. You must install the agent in order to collect data to assist with
support cases.
When installed, the Azure AD Connect Administration Agent waits for specific requests for data from Azure Active
Directory, gets the requested data from the sync environment and sends it to Azure Active Directory, where it is
presented to the Microsoft support engineer.
The information that the Azure AD Connect Administration Agent retrieves from your environment is not stored in
any way - it is only displayed to the Microsoft support engineer to assist them in investigating and troubleshooting
the Azure Active Directory Connect related support case that you opened The Azure AD Connect Administration
Agent is not installed on the Azure AD Connect Server by default.
Install the Azure AD Connect Administration Agent on the Azure AD

Connect server
Prerequisites:
1. Azure AD Connect is installed on the server
2. Azure AD Connect Health is installed on the server
The Azure AD Connect Administration Agent binaries are placed in the AAD Connect server. To install the agent, do
the following:
1. Open powershell in admin mode
2. Navigate to the directory where the application is located cd "C:\Program Files\Microsoft Azure Active Directory
Connect\Tools"
3. Run ConfigureAdminAgent.ps1
When prompted, please enter your Azure AD global admin credentials. This should be the same credentials entered
during Azure AD Connect installation.
After the agent is installed, you'll see the following two new programs in the "Add/Remove Programs" list in the
Control Panel of your server:
What data in my Sync service is shown to the Microsoft service
engineer?
When you open a support case the Microsoft Support Engineer can see, for a given user, the relevant data in Active
Directory, the Active Directory connector space in the Azure Active Directory Connect server, the Azure Active
Directory connector space in the Azure Active Directory Connect server and the Metaverse in the Azure Active
Directory Connect server.
The Microsoft Support Engineer cannot change any data in your system and cannot see any passwords.
What if I don't want the Microsoft support engineer to access my data?

Once the agent is installed, If you do not want the Microsoft service engineer to access your data for a support call,
you can disable the functionality by modifying the service config file as described below:
1. Open C:\Program Files\Microsoft Azure AD Connect Administration
Agent\AzureADConnectAdministrationAgentSer vice.exe.config in notepad.
2. Disable UserDataEnabled setting as shown below. If UserDataEnabled setting exists and is set to true,
then set it to false. If the setting does not exist, then add the setting as shown below.
<appSettings>
<add key="TraceFilename" value="ADAdministrationAgent.log" />
<add key="UserDataEnabled" value="false" />
</appSettings>
3. Save the config file.

4. Restart Azure AD Connect Administration Agent service as shown below
Next steps
Troubleshoot Azure AD connectivity with the
ADConnectivityTool PowerShell module
The ADConnectivity tool is a PowerShell module that is used in one of the following:
During installation when a network connectivity problem prevents the successful validation of the Active
Directory credentials the user provided in the Wizard.
Post installation by a user who calls the functions from a PowerShell session.
The tool is located in: C:\Program Files\Microsoft Azure Active Director y Connect\Tools\
ADConnectivityTool.psm1
ADConnectivityTool during installation

On the Connect your directories page, in the Azure AD Connect Wizard, if a network issue occurs, the
ADConnectivityTool will automatically use one of its functions to determine what is going on. Any of the following
can be considered network issues:
The name of the Forest the user provided was typed wrongly, or said Forest doesn’t exist
UDP port 389 is closed in the Domain Controllers associated with the Forest the user provided
The credentials provided in the ‘AD forest account’ window doesn’t have privileges to retrieve the Domain
Controllers associated with the target Forest
Any of the TCP ports 53, 88 or 389 are closed in the Domain Controllers associated with the Forest the user
provided
Both UDP 389 and a TCP port (or ports) are closed
DNS could not be resolved for the provided Forest and\or its associated Domain Controllers
Whenever any of these issues are found, a related error message is displayed in the AADConnect Wizard:
For example, when we are attempting to add a directory on the Connect your directories screen, Azure AD
Connect needs to verify this and expects to be able to communicate with a domain controller over port 389. If it
cannot, we will see the error that is shown in the screenshot above.
What is actually happening behind the scenes, is that Azure AD Connect is calling the
Start-NetworkConnectivityDiagnosisTools function. This function is called when the validation of credentials fails
due to a network connectivity issue.
Finally, a detailed log file is generated whenever the tool is called from the wizard. The log is located in
C:\ProgramData\AADConnect\ADConnectivityTool-<date>-<time>.log
ADConnectivityTools post installation

After Azure AD Connect has been installed, any of the functions in the ADConnectivityTools PowerShell module can
be used.
You can find reference information on the functions in the ADConnectivityTools Reference
Start-ConnectivityValidation
We are going to call out this function because it can only be called manually once the ADConnectivityTool.psm1
has been imported into PowerShell.
This function executes the same logic that the Azure AD Connect Wizard runs to validate the provided AD
Credentials. However it provides a much more verbose explanation about the problem and a suggested solution.
The connectivity validation consists of the following steps:
Get Domain FQDN (fully qualified domain name) object
Validate that, if the user selected ‘Create new AD account’, these credentials belong to the Enterprise
Administrators group
Get Forest FQDN object
Confirm that at least one domain associated with the previously obtained Forest FQDN object is reachable
Verify that the functional level of the forest is Windows Server 2003 or greater.
The user will be able to add a Directory if all these actions were executed successfully.
If the user runs this function after a problem is solved (or if no problem exists at all) the output will indicate for the
user to go back to the Azure AD Connect Wizard and try inserting the credentials again.
Next Steps
Custom Installation
ADConnectivityTools Reference
Troubleshoot Azure AD connectivity
This article explains how connectivity between Azure AD Connect and Azure AD works and how to troubleshoot
connectivity issues. These issues are most likely to be seen in an environment with a proxy server.
Troubleshoot connectivity issues in the installation wizard

Azure AD Connect is using Modern Authentication (using the ADAL library) for authentication. The installation
wizard and the sync engine proper require machine.config to be properly configured since these two are .NET
applications.
In this article, we show how Fabrikam connects to Azure AD through its proxy. The proxy server is named
fabrikamproxy and is using port 8080.
First we need to make sure machine.config is correctly configured and Microsoft Azure AD Sync ser vice has
been restarted once after the machine.config file update.
NOTE
In some non-Microsoft blogs, it is documented that changes should be made to miiserver.exe.config instead. However, this
file is overwritten on every upgrade so even if it works during initial install, the system stops working on first upgrade. For
that reason, the recommendation is to update machine.config instead.
The proxy server must also have the required URLs opened. The official list is documented in Office 365 URLs and
IP address ranges.
Of these URLs, the following table is the absolute bare minimum to be able to connect to Azure AD at all. This list
does not include any optional features, such as password writeback, or Azure AD Connect Health. It is documented
here to help in troubleshooting for the initial configuration.
URL P O RT DESC RIP T IO N
mscrl.microsoft.com HTTP/80 Used to download CRL lists.
*.verisign.com HTTP/80 Used to download CRL lists.
*.entrust.net HTTP/80 Used to download CRL lists for MFA.
*.windows.net HTTPS/443 Used to sign in to Azure AD.

URL P O RT DESC RIP T IO N
secure.aadcdn.microsoftonline-p.com HTTPS/443 Used for MFA.
*.microsoftonline.com HTTPS/443 Used to configure your Azure AD

directory and import/export data.
Errors in the wizard

The installation wizard is using two different security contexts. On the page Connect to Azure AD , it is using the
currently signed in user. On the page Configure , it is changing to the account running the service for the sync
engine. If there is an issue, it appears most likely already at the Connect to Azure AD page in the wizard since
the proxy configuration is global.
The following issues are the most common errors you encounter in the installation wizard.
The installation wizard has not been correctly configured
This error appears when the wizard itself cannot reach the proxy.
If you see this error, verify the machine.config has been correctly configured.
If that looks correct, follow the steps in Verify proxy connectivity to see if the issue is present outside the wizard
as well.
A Microsoft account is used
If you use a Microsoft account rather than a school or organization account, you see a generic error.
The MFA endpoint cannot be reached

This error appears if the endpoint https://secure.aadcdn.microsoftonline-p.com cannot be reached and your
global admin has MFA enabled.

If you see this error, verify that the endpoint secure.aadcdn.microsoftonline-p.com has been added to the
proxy.
The password cannot be verified
If the installation wizard is successful in connecting to Azure AD, but the password itself cannot be verified you see
this error:
Is the password a temporary password and must be changed? Is it actually the correct password? Try to sign in
to https://login.microsoftonline.com (on another computer than the Azure AD Connect server) and verify the
account is usable.
Verify proxy connectivity
To verify if the Azure AD Connect server has actual connectivity with the Proxy and Internet, use some PowerShell
to see if the proxy is allowing web requests or not. In a PowerShell prompt, run
Invoke-WebRequest -Uri https://adminwebservice.microsoftonline.com/ProvisioningService.svc . (Technically the first
call is to https://login.microsoftonline.com and this URI works as well, but the other URI is faster to respond.)
PowerShell uses the configuration in machine.config to contact the proxy. The settings in winhttp/netsh should not
impact these cmdlets.
If the proxy is correctly configured, you should get a success status:
If you receive Unable to connect to the remote ser ver , then PowerShell is trying to make a direct call without
using the proxy or DNS is not correctly configured. Make sure the machine.config file is correctly configured.
If the proxy is not correctly configured, you get an error:
ERRO R ERRO R T EXT C O M M EN T
403 Forbidden The proxy has not been opened for the
requested URL. Revisit the proxy
configuration and make sure the URLs
have been opened.
407 Proxy Authentication Required The proxy server required a sign-in and
none was provided. If your proxy server
requires authentication, make sure to
have this setting configured in the
machine.config. Also make sure you are
using domain accounts for the user
running the wizard and for the service
account.
Proxy idle timeout setting

When Azure AD Connect sends an export request to Azure AD, Azure AD can take up to 5 minutes to process the
request before generating a response. This can happen especially if there are a number of group objects with
large group memberships included in the same export request. Ensure the Proxy idle timeout is configured to be
greater than 5 minutes. Otherwise, intermittent connectivity issue with Azure AD may be observed on the Azure
AD Connect server.
The communication pattern between Azure AD Connect and Azure AD

If you have followed all these preceding steps and still cannot connect, you might at this point start looking at
network logs. This section is documenting a normal and successful connectivity pattern. It is also listing common
red herrings that can be ignored when you are reading the network logs.
There are calls to https://dc.services.visualstudio.com . It is not required to have this URL open in the proxy
for the installation to succeed and these calls can be ignored.
You see that dns resolution lists the actual hosts to be in the DNS name space nsatc.net and other namespaces
not under microsoftonline.com. However, there are not any web service requests on the actual server names
and you do not have to add these URLs to the proxy.
The endpoints adminwebservice and provisioningapi are discovery endpoints and used to find the actual
endpoint to use. These endpoints are different depending on your region.
Reference proxy logs
Here is a dump from an actual proxy log and the installation wizard page from where it was taken (duplicate
entries to the same endpoint have been removed). This section can be used as a reference for your own proxy and
network logs. The actual endpoints might be different in your environment (in particular those URLs in italic).
Connect to Azure AD
T IM E URL
1/11/2016 8:31 connect://login.microsoftonline.com:443
1/11/2016 8:31 connect://adminwebservice.microsoftonline.com:443
1/11/2016 8:32 connect://bba800-anchor.microsoftonline.com:443
1/11/2016 8:33 connect://provisioningapi.microsoftonline.com:443
1/11/2016 8:33 connect://bwsc02-relay.microsoftonline.com:443
Configure
T IM E URL
1/11/2016 8:46 connect://provisioningapi.microsoftonline.com:443
1/11/2016 8:46 connect://bwsc02-relay.microsoftonline.com:443
Initial Sync
T IM E URL
1/11/2016 8:48 connect://login.windows.net:443
Authentication errors
This section covers errors that can be returned from ADAL (the authentication library used by Azure AD Connect)
and PowerShell. The error explained should help you in understand your next steps.
Invalid Grant
Invalid username or password. For more information, see The password cannot be verified.
Unknown User Type
Your Azure AD directory cannot be found or resolved. Maybe you try to login with a username in an unverified
domain?
User Realm Discovery Failed
Network or proxy configuration issues. The network cannot be reached. See Troubleshoot connectivity issues in
the installation wizard.
User Password Expired
Your credentials have expired. Change your password.
Authorization Failure
Failed to authorize user to perform action in Azure AD.
Authentication Canceled
The multi-factor authentication (MFA) challenge was canceled.
Connect To MS Online Failed
Authentication was successful, but Azure AD PowerShell has an authentication problem.
Azure AD Global Admin Role Needed
User was authenticated successfully. However user is not assigned global admin role. This is how you can assign
global admin role to the user.
Privileged Identity Management Enabled
Authentication was successful. Privileged identity management has been enabled and you are currently not a
global administrator. For more information, see Privileged Identity Management.
Company Information Unavailable
Authentication was successful. Could not retrieve company information from Azure AD.
Domain Information Unavailable
Authentication was successful. Could not retrieve domain information from Azure AD.
Unspecified Authentication Failure
Shown as Unexpected error in the installation wizard. Can happen if you try to use a Microsoft Account rather
than a school or organization account .
Troubleshooting steps for previous releases.

With releases starting with build number 1.1.105.0 (released February 2016), the sign-in assistant was retired.
This section and the configuration should no longer be required, but is kept as reference.
For the single-sign in assistant to work, winhttp must be configured. This configuration can be done with netsh .
The Sign-in assistant has not been correctly configured

This error appears when the Sign-in assistant cannot reach the proxy or the proxy is not allowing the request.
If you see this error, look at the proxy configuration in netsh and verify it is correct.
If that looks correct, follow the steps in Verify proxy connectivity to see if the issue is present outside the wizard
as well.
Next steps
Troubleshooting Errors during synchronization
Errors could occur when identity data is synchronized from Windows Server Active Directory (AD DS) to Azure
Active Directory (Azure AD). This article provides an overview of different types of sync errors, some of the
possible scenarios that cause those errors and potential ways to fix the errors. This article includes the common
error types and may not cover all the possible errors.
This article assumes the reader is familiar with the underlying design concepts of Azure AD and Azure AD Connect.
With the latest version of Azure AD Connect (August 2016 or higher), a report of Synchronization Errors is
available in the Azure portal as part of Azure AD Connect Health for sync.
Starting September 1, 2016 Azure Active Directory Duplicate Attribute Resiliency feature will be enabled by default
for all the new Azure Active Directory Tenants. This feature will be automatically enabled for existing tenants in the
upcoming months.
Azure AD Connect performs three types of operations from the directories it keeps in sync: Import,
Synchronization, and Export. Errors can take place in all the operations. This article mainly focuses on errors during
Export to Azure AD.
Errors during Export to Azure AD

Following section describes different types of synchronization errors that can occur during the export operation to
Azure AD using the Azure AD connector. This connector can be identified by the name format being
"contoso.onmicrosoft.com". Errors during Export to Azure AD indicate that the operation (add, update, delete etc.)
attempted by Azure AD Connect (Sync Engine) on Azure Active Directory failed.
Data Mismatch Errors

InvalidSoftMatch
Description
When Azure AD Connect (sync engine) instructs Azure Active Directory to add or update objects, Azure AD
matches the incoming object using the sourceAnchor attribute to the immutableId attribute of objects in
Azure AD. This match is called a Hard Match .
When Azure AD does not find any object that matches the immutableId attribute with the sourceAnchor
attribute of the incoming object, before provisioning a new object, it falls back to use the ProxyAddresses and
UserPrincipalName attributes to find a match. This match is called a Soft Match . The Soft Match is designed to
match objects already present in Azure AD (that are sourced in Azure AD) with the new objects being
added/updated during synchronization that represent the same entity (users, groups) on premises.
InvalidSoftMatch error occurs when the hard match does not find any matching object AND soft match finds
a matching object but that object has a different value of immutableId than the incoming object's
SourceAnchor, suggesting that the matching object was synchronized with another object from on premises
Active Directory.
In other words, in order for the soft match to work, the object to be soft-matched with should not have any value
for the immutableId. If any object with immutableId set with a value is failing the hard-match but satisfying the
soft-match criteria, the operation would result in an InvalidSoftMatch synchronization error.
Azure Active Directory schema does not allow two or more objects to have the same value of the following
attributes. (This is not an exhaustive list.)
ProxyAddresses
UserPrincipalName
onPremisesSecurityIdentifier
ObjectId
NOTE
Azure AD Attribute Duplicate Attribute Resiliency feature is also being rolled out as the default behavior of Azure Active
Directory. This will reduce the number of synchronization errors seen by Azure AD Connect (as well as other sync clients) by
making Azure AD more resilient in the way it handles duplicated ProxyAddresses and UserPrincipalName attributes present
in on premises AD environments. This feature does not fix the duplication errors. So the data still needs to be fixed. But it
allows provisioning of new objects which are otherwise blocked from being provisioned due to duplicated values in Azure
AD. This will also reduce the number of synchronization errors returned to the synchronization client. If this feature is
enabled for your Tenant, you will not see the InvalidSoftMatch synchronization errors seen during provisioning of new
objects.
Example Scenarios for InvalidSoftMatch

1. Two or more objects with the same value for the ProxyAddresses attribute exist in on-premises Active Directory.
Only one is getting provisioned in Azure AD.
2. Two or more objects with the same value for the userPrincipalName attribute exists in on-premises Active
Directory. Only one is getting provisioned in Azure AD.
3. An object was added in the on premises Active Directory with the same value of ProxyAddresses attribute as
that of an existing object in Azure Active Directory. The object added on premises is not getting provisioned in
4. An object was added in on premises Active Directory with the same value of userPrincipalName attribute as
that of an account in Azure Active Directory. The object is not getting provisioned in Azure Active Directory.
5. A synced account was moved from Forest A to Forest B. Azure AD Connect (sync engine) was using ObjectGUID
attribute to compute the SourceAnchor. After the forest move, the value of the SourceAnchor is different. The
new object (from Forest B) is failing to sync with the existing object in Azure AD.
6. A synced object got accidentally deleted from on premises Active Directory and a new object was created in
Active Directory for the same entity (such as user) without deleting the account in Azure Active Directory. The
new account fails to sync with the existing Azure AD object.
7. Azure AD Connect was uninstalled and reinstalled. During the reinstallation, a different attribute was chosen as
the SourceAnchor. All the objects that had previously synced stopped syncing with InvalidSoftMatch error.
Example case:
1. Bob Smith is a synced user in Azure Active Directory from on premises Active Directory of contoso.com
2. Bob Smith's UserPrincipalName is set as bobs@contoso.com .
3. "abcdefghijklmnopqrstuv==" is the SourceAnchor calculated by Azure AD Connect using Bob Smith's
objectGUID from on premises Active Directory, which is the immutableId for Bob Smith in Azure Active
Directory.
4. Bob also has following values for the proxyAddresses attribute:
smtp: bobs@contoso.com
smtp: bob.smith@contoso.com
smtp: bob@contoso.com
5. A new user, Bob Taylor , is added to the on premises Active Directory.
6. Bob Taylor's UserPrincipalName is set as bobt@contoso.com .
7. "abcdefghijkl0123456789=="" is the sourceAnchor calculated by Azure AD Connect using Bob Taylor's
objectGUID from on premises Active Directory. Bob Taylor's object has NOT synced to Azure Active Directory
yet.
8. Bob Taylor has the following values for the proxyAddresses attribute
smtp: bobt@contoso.com
smtp: bob.taylor@contoso.com
9. During sync, Azure AD Connect will recognize the addition of Bob Taylor in on premises Active Directory and
ask Azure AD to make the same change.
10. Azure AD will first perform hard match. That is, it will search if there is any object with the immutableId equal to
"abcdefghijkl0123456789==". Hard Match will fail as no other object in Azure AD will have that immutableId.
11. Azure AD will then attempt to soft-match Bob Taylor. That is, it will search if there is any object with
proxyAddresses equal to the three values, including smtp: bob@contoso.com
12. Azure AD will find Bob Smith's object to match the soft-match criteria. But this object has the value of
immutableId = "abcdefghijklmnopqrstuv==". which indicates this object was synced from another object from
on premises Active Directory. Thus, Azure AD cannot soft-match these objects and results in an
InvalidSoftMatch sync error.
How to fix InvalidSoftMatch error
The most common reason for the InvalidSoftMatch error is two objects with different SourceAnchor (immutableId)
have the same value for the ProxyAddresses and/or UserPrincipalName attributes, which are used during the soft-
match process on Azure AD. In order to fix the Invalid Soft Match
1. Identify the duplicated proxyAddresses, userPrincipalName, or other attribute value that's causing the error.
Also identify which two (or more) objects are involved in the conflict. The report generated by Azure AD
Connect Health for sync can help you identify the two objects.
2. Identify which object should continue to have the duplicated value and which object should not.
3. Remove the duplicated value from the object that should NOT have that value. You should make the change in
the directory where the object is sourced from. In some cases, you may need to delete one of the objects in
conflict.
4. If you made the change in the on premises AD, let Azure AD Connect sync the change.
Sync error reports within Azure AD Connect Health for sync are updated every 30 minutes and include the errors
from the latest synchronization attempt.
NOTE
ImmutableId, by definition, should not change in the lifetime of the object. If Azure AD Connect was not configured with
some of the scenarios in mind from the above list, you could end up in a situation where Azure AD Connect calculates a
different value of the SourceAnchor for the AD object that represents the same entity (same user/group/contact etc) that
has an existing Azure AD Object that you wish to continue using.
Related Articles
Duplicate or invalid attributes prevent directory synchronization in Office 365
ObjectTypeMismatch
Description
When Azure AD attempts to soft match two objects, it is possible that two objects of different "object type" (such as
User, Group, Contact etc.) have the same values for the attributes used to perform the soft match. As duplication of
these attributes is not permitted in Azure AD, the operation can result in "ObjectTypeMismatch" synchronization
error.
Example Scenarios for ObjectTypeMismatch error
A mail enabled security group is created in Office 365. Admin adds a new user or contact in on premises AD
(that's not synchronized to Azure AD yet) with the same value for the ProxyAddresses attribute as that of the
Office 365 group.
Example case
1. Admin creates a new mail enabled security group in Office 365 for the Tax department and provides an email
address as tax@contoso.com. This group is assigned the ProxyAddresses attribute value of smtp:
tax@contoso.com
2. A new user joins Contoso.com and an account is created for the user on premises with the proxyAddress as
smtp: tax@contoso.com
3. When Azure AD Connect will sync the new user account, it will get the "ObjectTypeMismatch" error.
How to fix ObjectTypeMismatch error
The most common reason for the ObjectTypeMismatch error is two objects of different type (User, Group, Contact
etc.) have the same value for the ProxyAddresses attribute. In order to fix the ObjectTypeMismatch:
1. Identify the duplicated proxyAddresses (or other attribute) value that's causing the error. Also identify which
two (or more) objects are involved in the conflict. The report generated by Azure AD Connect Health for sync
can help you identify the two objects.
3. Remove the duplicated value from the object that should NOT have that value. Note that you should make the
change in the directory where the object is sourced from. In some cases, you may need to delete one of the
objects in conflict.
4. If you made the change in the on premises AD, let Azure AD Connect sync the change. Sync error report within
Azure AD Connect Health for sync gets updated every 30 minutes and includes the errors from the latest
synchronization attempt.
Duplicate Attributes
Description
Azure Active Directory schema does not allow two or more objects to have the same value of the following
attributes. That is each object in Azure AD is forced to have a unique value of these attributes at a given instance.
ProxyAddresses
UserPrincipalName
If Azure AD Connect attempts to add a new object or update an existing object with a value for the above attributes
that is already assigned to another object in Azure Active Directory, the operation results in the
"AttributeValueMustBeUnique" sync error.
Possible Scenarios:
1. Duplicate value is assigned to an already synced object, which conflicts with another synced object.
Example case:
1. Bob Smith is a synced user in Azure Active Directory from on premises Active Directory of contoso.com
2. Bob Smith's UserPrincipalName on premises is set as bobs@contoso.com .
3. Bob also has following values for the proxyAddresses attribute:
smtp: bobs@contoso.com
smtp: bob.smith@contoso.com
4. A new user, Bob Taylor , is added to the on premises Active Directory.
5. Bob Taylor's UserPrincipalName is set as bobt@contoso.com .
6. Bob Taylor has the following values for the ProxyAddresses attribute i. smtp: bobt@contoso.com ii. smtp:
bob.taylor@contoso.com
7. Bob Taylor's object is synchronized with Azure AD successfully.
8. Admin decided to update Bob Taylor's ProxyAddresses attribute with the following value: i. smtp:
bob@contoso.com
9. Azure AD will attempt to update Bob Taylor's object in Azure AD with the above value, but that operation will
fail as that ProxyAddresses value is already assigned to Bob Smith, resulting in "AttributeValueMustBeUnique"
error.
How to fix AttributeValueMustBeUnique error
The most common reason for the AttributeValueMustBeUnique error is two objects with different SourceAnchor
(immutableId) have the same value for the ProxyAddresses and/or UserPrincipalName attributes. In order to fix
AttributeValueMustBeUnique error
1. Identify the duplicated proxyAddresses, userPrincipalName or other attribute value that's causing the error. Also
identify which two (or more) objects are involved in the conflict. The report generated by Azure AD Connect
Health for sync can help you identify the two objects.
3. Remove the duplicated value from the object that should NOT have that value. Note that you should make the
change in the directory where the object is sourced from. In some cases, you may need to delete one of the
objects in conflict.
4. If you made the change in the on premises AD, let Azure AD Connect sync the change for the error to get fixed.
Related Articles
-Duplicate or invalid attributes prevent directory synchronization in Office 365
Data Validation Failures

IdentityDataValidationFailed
Description
Azure Active Directory enforces various restrictions on the data itself before allowing that data to be written into
the directory. These restrictions are to ensure that end users get the best possible experiences while using the
applications that depend on this data.
Scenarios
a. The UserPrincipalName attribute value has invalid/unsupported characters. b. The UserPrincipalName attribute
does not follow the required format.
How to fix IdentityDataValidationFailed error
a. Ensure that the userPrincipalName attribute has supported characters and required format.
Related Articles
Prepare to provision users through directory synchronization to Office 365
FederatedDomainChangeError
Description
This case results in a "FederatedDomainChangeError" sync error when the suffix of a user's UserPrincipalName
is changed from one federated domain to another federated domain.
Scenarios
For a synchronized user, the UserPrincipalName suffix was changed from one federated domain to another
federated domain on premises. For example, UserPrincipalName = bob@contoso.com was changed to
UserPrincipalName = bob@fabrikam.com.
Example
1. Bob Smith, an account for Contoso.com, gets added as a new user in Active Directory with the
UserPrincipalName bob@contoso.com
2. Bob moves to a different division of Contoso.com called Fabrikam.com and their UserPrincipalName is changed
to bob@fabrikam.com
3. Both contoso.com and fabrikam.com domains are federated domains with Azure Active Directory.
4. Bob's userPrincipalName does not get updated and results in a "FederatedDomainChangeError" sync error.
How to fix
If a user's UserPrincipalName suffix was updated from bob@contoso.com to bob@fabrikam.com , where both
contoso.com and fabrikam.com are federated domains , then follow these steps to fix the sync error
1. Update the user's UserPrincipalName in Azure AD from bob@contoso.com to bob@contoso.onmicrosoft.com.
You can use the following PowerShell command with the Azure AD PowerShell Module:
Set-MsolUserPrincipalName -UserPrincipalName bob@contoso.com -NewUserPrincipalName
bob@contoso.onmicrosoft.com
2. Allow the next sync cycle to attempt synchronization. This time synchronization will be successful and it will
update the UserPrincipalName of Bob to bob@fabrikam.com as expected.
Related Articles
Changes aren't synced by the Azure Active Directory Sync tool after you change the UPN of a user account to
use a different federated domain
LargeObject
Description
When an attribute exceeds the allowed size limit, length limit or count limit set by Azure Active Directory schema,
the synchronization operation results in the LargeObject or ExceededAllowedLength sync error. Typically this
error occurs for the following attributes
userCertificate
userSMIMECertificate
thumbnailPhoto
proxyAddresses
Possible Scenarios
1. Bob's userCertificate attribute is storing too many certificates assigned to Bob. These may include older, expired
certificates. The hard limit is 15 certificates. For more information on how to handle LargeObject errors with
userCertificate attribute, please refer to article Handling LargeObject errors caused by userCertificate attribute.
2. Bob's userSMIMECertificate attribute is storing too many certificates assigned to Bob. These may include older,
expired certificates. The hard limit is 15 certificates.
3. Bob's thumbnailPhoto set in Active Directory is too large to be synced in Azure AD.
4. During automatic population of the ProxyAddresses attribute in Active Directory, an object has too many
ProxyAddresses assigned.
How to fix
1. Ensure that the attribute causing the error is within the allowed limitation.
Existing Admin Role Conflict

Description
An Existing Admin Role Conflict will occur on a user object during synchronization when that user object has:
administrative permissions and
the same UserPrincipalName as an existing Azure AD object
Azure AD Connect is not allowed to soft match a user object from on-premises AD with a user object in Azure AD
that has an administrative role assigned to it. For more information see Azure AD UserPrincipalName population
How to fix
To resolve this issue do the following:
1. Remove the Azure AD account (owner) from all admin roles.
2. Hard Delete the Quarantined object in the cloud.
3. The next sync cycle will take care of soft-matching the on-premises user to the cloud account (since the cloud
user is now no longer a global GA).
4. Restore the role memberships for the owner.
NOTE
You can assign the administrative role to the existing user object again after the soft match between the on-premises user
object and the Azure AD user object has completed.
Related links
Locate Active Directory Objects in Active Directory Administrative Center
How to query Azure Active Directory for an object using Azure Active Directory PowerShell
Troubleshoot an object that is not synchronizing with
If an object is not syncing as expected with Microsoft Azure Active Directory (Azure AD), it can be because of
several reasons. If you have received an error email from Azure AD or you see the error in Azure AD Connect
Health, read Troubleshooting errors during synchronization instead. But if you are troubleshooting a problem
where the object is not in Azure AD, this article is for you. It describes how to find errors in the on-premises
component Azure AD Connect synchronization.
IMPORTANT
For Azure AD Connect deployment with version 1.1.749.0 or higher, use the troubleshooting task in the wizard to
troubleshoot object syncing issues.
Synchronization process
Before we investigate syncing issues, let’s understand the Azure AD Connect syncing process:
Terminology
CS: Connector space, a table in a database
MV: Metaverse, a table in a database
Synchronization steps
The syncing process involves following steps:
1. Impor t from AD: Active Directory objects are brought into the Active Directory CS.
2. Impor t from Azure AD: Azure AD objects are brought into the Azure AD CS.
3. Synchronization: Inbound synchronization rules and outbound synchronization rules are run in the order
of precedence number, from lower to higher. To view the synchronization rules, go to the Synchronization
Rules Editor from the desktop applications. The inbound synchronization rules bring in data from CS to MV.
The outbound synchronization rules move data from MV to CS.
4. Expor t to AD: After syncing, objects are exported from the Active Directory CS to Active Directory.
5. Expor t to Azure AD: After syncing, objects are exported from the Azure AD CS to Azure AD.
Troubleshooting
To find the errors, look at a few different places, in the following order:
1. The operation logs to find errors identified by the synchronization engine during import and synchronization.
2. The connector space to find missing objects and synchronization errors.
3. The metaverse to find data-related problems.
Start Synchronization Service Manager before you begin these steps.
Operations
The Operations tab in Synchronization Service Manager is where you should start your troubleshooting. This tab
shows the results from the most recent operations.
The top half of the Operations tab shows all runs in chronological order. By default, the operations log keeps
information about the last seven days, but this setting can be changed with the scheduler. Look for any run that
does not show a success status. You can change the sorting by clicking the headers.
The Status column contains the most important information and shows the most severe problem for a run. Here's
a quick summary of the most common statuses in order of investigation priority (where * indicates several
possible error strings).
stopped-* The run could not finish. This might happen, for example, if
the remote system is down and cannot be contacted.
stopped-error-limit There are more than 5,000 errors. The run was automatically
stopped due to the large number of errors.
completed-*-errors The run finished, but there are errors (fewer than 5,000) that
should be investigated.
completed-*-warnings The run finished, but some data is not in the expected state. If
you have errors, this message is usually only a symptom.
Don't investigate warnings until you have addressed errors.
success No issues.
When you select a row, the bottom of the Operations tab is updated to show the details of that run. On the far-left
side of this area, you might have a list titled Step # . This list appears only if you have multiple domains in your
forest and each domain is represented by a step. The domain name can be found under the heading Par tition .
Under the Synchronization Statistics heading, you can find more information about the number of changes
that were processed. Select the links to get a list of the changed objects. If you have objects with errors, those
errors show up under the Synchronization Errors heading.
Errors on the Operations tab
When you have errors, Synchronization Service Manager shows both the object in error and the error itself as
links that provide more information.
Start by selecting the error string. (In the preceding figure, the error string is sync-rule-error-function-
triggered .) You are first presented with an overview of the object. To see the actual error, select Stack Trace . This
trace provides debug-level information for the error.
Right-click the Call Stack Information box, click Select All , and then select Copy . Then copy the stack and look
at the error in your favorite editor, such as Notepad.
If the error is from SyncRulesEngine , the call stack information first lists all attributes on the object. Scroll down
until you see the heading InnerException => .
The line after the heading shows the error. In the preceding figure, the error is from a custom synchronization rule
that Fabrikam created.
If the error does not give enough information, it's time to look at the data itself. Select the link with the object
identifier and continue troubleshooting the connector space imported object.
Connector space object properties

If the Operations tab shows no errors, follow the connector space object from Active Directory to the metaverse
to Azure AD. In this path, you should find where the problem is.
Searching for an object in the CS
In Synchronization Service Manager, select Connectors , select the Active Directory Connector, and select Search
Connector Space .
In the Scope box, select RDN when you want to search on the CN attribute, or select DN or anchor when you
want to search on the distinguishedName attribute. Enter a value and select Search .
If you don't find the object you're looking for, it might have been filtered with domain-based filtering or OU-based
filtering. To verify that the filtering is configured as expected, read Azure AD Connect sync: Configure filtering.
You can perform another useful search by selecting the Azure AD Connector. In the Scope box, select Pending
Impor t , and then select the Add check box. This search gives you all synced objects in Azure AD that cannot be
associated with an on-premises object.
Those objects were created by another synchronization engine or a synchronization engine with a different
filtering configuration. These orphan objects are no longer managed. Review this list and consider removing these
objects by using the Azure AD PowerShell cmdlets.
CS import
When you open a CS object, there are several tabs at the top. The Impor t tab shows the data that is staged after
an import.
The Old Value column shows what currently is stored in Connect, and the New Value column shows what has
been received from the source system and has not been applied yet. If there is an error on the object, changes are
not processed.
The Synchronization Error tab is visible in the Connector Space Object Proper ties window only if there is a
problem with the object. For more information, review how to troubleshoot sync errors on the Operations tab.
CS lineage
The Lineage tab in the Connector Space Object Proper ties window shows how the connector space object is
related to the metaverse object. You can see when the connector last imported a change from the connected
system and which rules applied to populate data in the metaverse.
In the preceding figure, the Action column shows an inbound synchronization rule with the action Provision .
That indicates that as long as this connector space object is present, the metaverse object remains. If the list of
synchronization rules instead shows an outbound synchronization rule with a Provision action, this object is
deleted when the metaverse object is deleted.
In the preceding figure, you can also see in the PasswordSync column that the inbound connector space can
contribute changes to the password since one synchronization rule has the value True . This password is sent to
Azure AD through the outbound rule.
From the Lineage tab, you can get to the metaverse by selecting Metaverse Object Proper ties .
Preview
In the lower-left corner of the Connector Space Object Proper ties window is the Preview button. Select this
button to open the Preview page, where you can sync a single object. This page is useful if you are
troubleshooting some custom synchronization rules and want to see the effect of a change on a single object. You
can select a Full sync or a Delta sync . You can also select Generate Preview , which only keeps the change in
memory. Or select Commit Preview , which updates the metaverse and stages all changes to target connector
spaces.
In the preview you can inspect the object and see which rule applied for a particular attribute flow.
Log
Next to the Preview button, select the Log button to open the Log page. Here you can see the password sync
status and history. For more information, see Troubleshoot password hash synchronization with Azure AD Connect
sync.
Metaverse object properties

It's usually better to start searching from the source Active Directory connector space. But you can also start
searching from the metaverse.
Searching for an object in the MV
In Synchronization Service Manager, select Metaverse Search , as in the following figure. Create a query that you
know finds the user. Search for common attributes, such as accountName (sAMAccountName ) and
userPrincipalName . For more information, see Sync Service Manager Metaverse search.
In the Search Results window, click the object.

If you did not find the object, it has not yet reached the metaverse. Continue to search for the object in the Active
Directory connector space. If you find the object in the Active Directory connector space, there could be a sync
error that is blocking the object from coming to the metaverse, or a synchronization rule scoping filter might be
applied.
Object not found in the MV
If the object is in the Active Directory CS but not present in the MV, a scoping filter is applied. To look at the scoping
filter, go to the desktop application menu and select Synchronization Rules Editor . Filter the rules applicable to
the object by adjusting the filter below.
View each rule in the list from above and check the Scoping filter . In the following scoping filter, if the
isCriticalSystemObject value is null or FALSE or empty, it's in scope.
Go to the CS Import attribute list and check which filter is blocking the object from moving to the MV. The
Connector Space attribute list will show only non-null and non-empty attributes. For example, if
isCriticalSystemObject doesn't show up in the list, the value of this attribute is null or empty.
Object not found in the Azure AD CS
If the object is not present in the connector space of Azure AD but is present in the MV, look at the scoping filter of
the outbound rules of the corresponding connector space, and find out if the object is filtered out because the MV
attributes don't meet the criteria.
To look at the outbound scoping filter, select the applicable rules for the object by adjusting the filter below. View
each rule and look at the corresponding MV attribute value.
MV Attributes
On the Attributes tab, you can see the values and which connectors contributed them.
If an object is not syncing, ask the following questions about attribute states in the metaverse:
Is the attribute cloudFiltered present and set to True ? If it is, it has been filtered according to the steps in
attribute-based filtering.
Is the attribute sourceAnchor present? If not, do you have an account-resource forest topology? If an object is
identified as a linked mailbox (the attribute msExchRecipientTypeDetails has the value 2 ), the
sourceAnchor is contributed by the forest with an enabled Active Directory account. Make sure the master
account has been imported and synced correctly. The master account must be listed among the connectors for
the object.
MV connectors
The Connectors tab shows all connector spaces that have a representation of the object.
You should have a connector to:

Each Active Directory forest the user is represented in. This representation can include
foreignSecurityPrincipals and Contact objects.
A connector in Azure AD.
If you're missing the connector to Azure AD, review the section on MV attributes to verify the criteria for
provisioning to Azure AD.
From the Connectors tab you can also go to the connector space object. Select a row and click Proper ties .
Next steps
Learn more about Azure AD Connect sync.
Learn more about hybrid identity.
Troubleshooting Source Anchor Issues during
Installation
This article explains the different source anchor related issues that may occur during installation and offers ways to
resolve these issues.
Invalid Source Anchor in Azure Active Directory

Custom Installation
During custom installation, Azure AD Connect reads the source anchor policy from Azure Active Directory. If the
policy exists in Azure Active Directory, Azure AD Connect applies the same policy unless it is overridden by the
customer. The wizard informs you which attribute has been read. Additionally, the wizard warns if you try to
override the source anchor policy.
During this read operation, it is possible that the source anchor policy in Azure Active Directory is unexpected. In
this case, Azure AD Connect does not know what the source anchor to use and needs manual override.
To resolve this issue, you can manually override the source anchor by selecting a specific attribute. Proceed with
this option if and only if you are certain of which attribute to select. If you are not certain, contact Microsoft support
for guidance. If you change the source anchor policy, it can break the association between your on-premises users
and their associated Azure resources.
During express installation, Azure AD Connect reads the source anchor policy from Azure Active Directory. If the
policy exists in Azure Active Directory, Azure AD Connect applies the same policy. There is no option to do manual
override.
During this read operation, it is possible that the source anchor policy in Azure Active Directory is unexpected. In
this case, Azure AD Connect does not know what the source anchor should be.
To resolve this issue, you need to re-install using the custom mode and manually override the source anchor by
selecting a specific attribute. Proceed with this option if and only if you are certain of which attribute to select. If you
are not certain, contact Microsoft support for guidance. If you change the source anchor policy, it can break the
association between your on-premises users and their associated Azure resources.
Invalid Source Anchor in Sync Engine
During installation, it is possible Azure AD Connect attempts to configure the sync engine using an invalid source
anchor. This operation is most likely a product issue and the installation of Azure AD Connect will fail. Contact
Microsoft support if you run in to this issue.
Next steps
Troubleshoot object synchronization with Azure AD
Connect sync
This article provides steps for troubleshooting issues with object synchronization by using the troubleshooting
task. To see how troubleshooting works in Azure Active Directory (Azure AD) Connect, watch this short video.
Troubleshooting task
For Azure AD Connect deployment with version 1.1.749.0 or higher, use the troubleshooting task in the wizard to
troubleshoot object synchronization issues. For earlier versions, please troubleshoot manually as described here.
Run the troubleshooting task in the wizard
To run the troubleshooting task in the wizard, perform the following steps:
1. Open a new Windows PowerShell session on your Azure AD Connect server with the Run as Administrator
option.
4. Navigate to the Additional Tasks page, select Troubleshoot, and click Next.
5. On the Troubleshooting page, click Launch to start the troubleshooting menu in PowerShell.
6. In the main menu, select Troubleshoot Object Synchronization.
Troubleshooting Input Parameters

The following input parameters are needed by the troubleshooting task:
1. Object Distinguished Name – This is the distinguished name of the object that needs troubleshooting
2. AD Connector Name – This is the name of the AD forest where the above object resides.
3. Azure AD tenant global administrator credentials
Understand the results of the troubleshooting task

The troubleshooting task performs the following checks:
1. Detect UPN mismatch if the object is synced to Azure Active Directory
2. Check if object is filtered due to domain filtering
3. Check if object is filtered due to OU filtering
4. Check if object synchronization is blocked due to a linked mailbox
5. Check if object is dynamic distribution group which is not supposed to be synchronized
The rest of this section describes specific results that are returned by the task. In each case, the task provides an
analysis followed by recommended actions to resolve the issue.
Detect UPN mismatch if object is synced to Azure Active Directory

UPN Suffix is NOT verified with Azure AD Tenant
When UserPrincipalName (UPN)/Alternate Login ID suffix is not verified with the Azure AD Tenant, then Azure
Active Directory replaces the UPN suffixes with the default domain name "onmicrosoft.com".
Azure AD Tenant DirSync Feature ‘SynchronizeUpnForManagedUsers’ is disabled

When the Azure AD Tenant DirSync Feature ‘SynchronizeUpnForManagedUsers’ is disabled, Azure Active Directory
does not allow synchronization updates to UserPrincipalName/Alternate Login ID for licensed user accounts with
managed authentication.
Object is filtered due to domain filtering

Domain is not configured to sync
Object is out of scope due to domain not being configured. In the example below, the object is out of sync scope as
the domain that it belongs to is filtered from synchronization.
Domain is configured to sync but is missing run profiles/run steps

Object is out of scope as the domain is missing run profiles/run steps. In the example below, the object is out of
sync scope as the domain that it belongs to is missing run steps for the Full Import run profile.
Object is filtered due to OU filtering

The object is out of sync scope due to OU filtering configuration. In the example below, the object belongs to
OU=NoSync,DC=bvtadwbackdc,DC=com. This OU is not included in sync scope.
Linked Mailbox issue

A linked mailbox is supposed to be associated with an external master account located in another trusted account
forest. If there is no such external master account, then Azure AD Connect will not synchronize the user account
corresponds to the linked mailbox in the Exchange forest to the Azure AD tenant.
Dynamic Distribution Group issue

Due to various differences between on-premises Active Directory and Azure Active Directory, Azure AD Connect
does not synchronize dynamic distribution groups to the Azure AD tenant.
HTML Report
In addition to analyzing the object, the troubleshooting task also generates an HTML report that has everything
known about the object. This HTML report can be shared with support team to do further troubleshooting, if
needed.
Next steps
Troubleshoot password hash synchronization with
This topic provides steps for how to troubleshoot issues with password hash synchronization. If passwords are
not synchronizing as expected, it can be either for a subset of users or for all users.
For Azure Active Directory (Azure AD) Connect deployment with version 1.1.614.0 or after, use the
troubleshooting task in the wizard to troubleshoot password hash synchronization issues:
If you have an issue where no passwords are synchronized, refer to the No passwords are synchronized:
troubleshoot by using the troubleshooting task section.
If you have an issue with individual objects, refer to the One object is not synchronizing passwords:
troubleshoot by using the troubleshooting task section.
For deployment with version 1.1.524.0 or later, there is a diagnostic cmdlet that you can use to troubleshoot
password hash synchronization issues:
troubleshoot by using the diagnostic cmdlet section.
If you have an issue with individual objects, refer to the One object is not synchronizing passwords:
troubleshoot by using the diagnostic cmdlet section.
For older versions of Azure AD Connect deployment:
manual troubleshooting steps section.
If you have an issue with individual objects, refer to the One object is not synchronizing passwords: manual
troubleshooting steps section.
No passwords are synchronized: troubleshoot by using the

troubleshooting task
You can use the troubleshooting task to figure out why no passwords are synchronized.
NOTE
The troubleshooting task is available only for Azure AD Connect version 1.1.614.0 or later.
Run the troubleshooting task

To troubleshoot issues where no passwords are synchronized:
1. Open a new Windows PowerShell session on your Azure AD Connect server with the Run as
Administrator option.
4. Navigate to the Additional Tasks page, select Troubleshoot , and click Next .
6. In the main menu, select Troubleshoot password hash synchronization .
7. In the sub menu, select Password hash synchronization does not work at all .
Validates that the password hash synchronization feature is enabled for your Azure AD tenant.
Validates that the Azure AD Connect server is not in staging mode.
For each existing on-premises Active Directory connector (which corresponds to an existing Active
Directory forest):
Validates that the password hash synchronization feature is enabled.
Searches for password hash synchronization heartbeat events in the Windows Application Event
logs.
For each Active Directory domain under the on-premises Active Directory connector:
Validates that the domain is reachable from the Azure AD Connect server.
Validates that the Active Directory Domain Services (AD DS) accounts used by the on-
premises Active Directory connector has the correct username, password, and permissions
required for password hash synchronization.
The following diagram illustrates the results of the cmdlet for a single-domain, on-premises Active Directory
topology:
The rest of this section describes specific results that are returned by the task and corresponding issues.
password hash synchronization feature isn't enabled
If you haven't enabled password hash synchronization by using the Azure AD Connect wizard, the following error
is returned:
Azure AD Connect server is in staging mode

If the Azure AD Connect server is in staging mode, password hash synchronization is temporarily disabled, and
the following error is returned:
No password hash synchronization heartbeat events
Each on-premises Active Directory connector has its own password hash synchronization channel. When the
password hash synchronization channel is established and there aren't any password changes to be synchronized,
a heartbeat event (EventId 654) is generated once every 30 minutes under the Windows Application Event Log.
For each on-premises Active Directory connector, the cmdlet searches for corresponding heartbeat events in the
past three hours. If no heartbeat event is found, the following error is returned:
AD DS account does not have correct permissions

If the AD DS account that's used by the on-premises Active Directory connector to synchronize password hashes
does not have the appropriate permissions, the following error is returned:
Incorrect AD DS account username or password

If the AD DS account used by the on-premises Active Directory connector to synchronize password hashes has an
incorrect username or password, the following error is returned:
One object is not synchronizing passwords: troubleshoot by using the

troubleshooting task
You can use the troubleshooting task to determine why one object is not synchronizing passwords.
NOTE
The troubleshooting task is available only for Azure AD Connect version 1.1.614.0 or later.
Run the diagnostics cmdlet

To troubleshoot issues for a specific user object:
4. Navigate to the Additional Tasks page, select Troubleshoot , and click Next .
6. In the main menu, select Troubleshoot password hash synchronization .
7. In the sub menu, select Password is not synchronized for a specific user account .
Examines the state of the Active Directory object in the Active Directory connector space, Metaverse, and
Azure AD connector space.
Validates that there are synchronization rules with password hash synchronization enabled and applied to
the Active Directory object.
Attempts to retrieve and display the results of the last attempt to synchronize the password for the object.
The following diagram illustrates the results of the cmdlet when troubleshooting password hash synchronization
for a single object:
The rest of this section describes specific results returned by the cmdlet and corresponding issues.
The Active Directory object isn't exported to Azure AD
password hash synchronization for this on-premises Active Directory account fails because there is no
corresponding object in the Azure AD tenant. The following error is returned:
User has a temporary password

Currently, Azure AD Connect does not support synchronizing temporary passwords with Azure AD. A password is
considered to be temporary if the Change password at next logon option is set on the on-premises Active
Directory user. The following error is returned:
Results of last attempt to synchronize password aren't available

By default, Azure AD Connect stores the results of password hash synchronization attempts for seven days. If
there are no results available for the selected Active Directory object, the following warning is returned:
No passwords are synchronized: troubleshoot by using the diagnostic

cmdlet
You can use the Invoke-ADSyncDiagnostics cmdlet to figure out why no passwords are synchronized.
NOTE
The Invoke-ADSyncDiagnostics cmdlet is available only for Azure AD Connect version 1.1.524.0 or later.

To troubleshoot issues where no passwords are synchronized:
3. Run Import-Module ADSyncDiagnostics .
4. Run Invoke-ADSyncDiagnostics -PasswordSync .
One object is not synchronizing passwords: troubleshoot by using the

diagnostic cmdlet
You can use the Invoke-ADSyncDiagnostics cmdlet to determine why one object is not synchronizing passwords.
NOTE
The Invoke-ADSyncDiagnostics cmdlet is available only for Azure AD Connect version 1.1.524.0 or later.

To troubleshoot issues where no passwords are synchronized for a user:
3. Run Import-Module ADSyncDiagnostics .
4. Run the following cmdlet:
Invoke-ADSyncDiagnostics -PasswordSync -ADConnectorName <Name-of-AD-Connector> -DistinguishedName

<DistinguishedName-of-AD-object>
For example:
Invoke-ADSyncDiagnostics -PasswordSync -ADConnectorName "contoso.com" -DistinguishedName

"CN=TestUserCN=Users,DC=contoso,DC=com"
No passwords are synchronized: manual troubleshooting steps

Follow these steps to determine why no passwords are synchronized:
1. Is the Connect server in staging mode? A server in staging mode does not synchronize any passwords.
2. Run the script in the Get the status of password sync settings section. It gives you an overview of the
password sync configuration.
3. If the feature is not enabled in Azure AD or if the sync channel status is not enabled, run the Connect
installation wizard. Select Customize synchronization options , and unselect password sync. This
change temporarily disables the feature. Then run the wizard again and re-enable password sync. Run the
script again to verify that the configuration is correct.
4. Look in the event log for errors. Look for the following events, which would indicate a problem:
Source: "Directory synchronization" ID: 0, 611, 652, 655 If you see these events, you have a connectivity
problem. The event log message contains forest information where you have a problem. For more
information, see [Connectivity problem](#connectivity problem).
5. If you see no heartbeat or if nothing else worked, run Trigger a full sync of all passwords. Run the script
only once.
6. See the Troubleshoot one object that is not synchronizing passwords section.
Connectivity problems
Do you have connectivity with Azure AD?
Does the account have required permissions to read the password hashes in all domains? If you installed Connect
by using Express settings, the permissions should already be correct.
If you used custom installation, set the permissions manually by doing the following:
1. To find the account used by the Active Directory connector, start Synchronization Ser vice Manager .
2. Go to Connectors , and then search for the on-premises Active Directory forest you are troubleshooting.
3. Select the connector, and then click Proper ties .
4. Go to Connect to Active Director y Forest .
Note the username and the domain where the account is located.
5. Start Active Director y Users and Computers , and then verify that the account you found earlier has
the follow permissions set at the root of all domains in your forest:
Replicate Directory Changes
6. Are the domain controllers reachable by Azure AD Connect? If the Connect server cannot connect to all
domain controllers, configure Only use preferred domain controller .
7. Go back to Synchronization Ser vice Manager and Configure Director y Par tition .
8. Select your domain in Select director y par titions , select the Only use preferred domain controllers
check box, and then click Configure .
9. In the list, enter the domain controllers that Connect should use for password sync. The same list is used
for import and export as well. Do these steps for all your domains.
NOTE
To apply these changes, restart the Microsoft Azure AD Sync (ADSync) service.
10. If the script shows that there is no heartbeat, run the script in Trigger a full sync of all passwords.
One object is not synchronizing passwords: manual troubleshooting

steps
You can easily troubleshoot password hash synchronization issues by reviewing the status of an object.
1. In Active Director y Users and Computers , search for the user, and then verify that the User must
change password at next logon check box is cleared.
If the check box is selected, ask the user to sign in and change the password. Temporary passwords are not
synchronized with Azure AD.
2. If the password looks correct in Active Directory, follow the user in the sync engine. By following the user
from on-premises Active Directory to Azure AD, you can see whether there is a descriptive error on the
object.
a. Start the Synchronization Service Manager.
b. Click Connectors .
c. Select the Active Director y Connector where the user is located.
d. Select Search Connector Space .
e. In the Scope box, select DN or Anchor , and then enter the full DN of the user you are troubleshooting.
f. Locate the user you are looking for, and then click Proper ties to see all the attributes. If the user is not in
the search result, verify your filtering rules and make sure that you run Apply and verify changes for the
user to appear in Connect.
g. To see the password sync details of the object for the past week, click Log .
If the object log is empty, Azure AD Connect has been unable to read the password hash from Active
Directory. Continue your troubleshooting with Connectivity Errors. If you see any other value than success ,
refer to the table in Password sync log.
h. Select the lineage tab, and make sure that at least one sync rule in the PasswordSync column is True .
In the default configuration, the name of the sync rule is In from AD - User AccountEnabled .
i. Click Metaverse Object Proper ties to display a list of user attributes.
Verify that there is no cloudFiltered attribute present. Make sure that the domain attributes
(domainFQDN and domainNetBios) have the expected values.
j. Click the Connectors tab. Make sure that you see connectors to both on-premises Active Directory and
Azure AD.
k. Select the row that represents Azure AD, click Proper ties , and then click the Lineage tab. The connector
space object should have an outbound rule in the PasswordSync column set to True . In the default
configuration, the name of the sync rule is Out to AAD - User Join .
Password sync log

The status column can have the following values:
STAT US DESC RIP T IO N
Success Password has been successfully synchronized.
FilteredByTarget Password is set to User must change password at next

logon . Password has not been synchronized.
NoTargetConnection No object in the metaverse or in the Azure AD connector

space.
SourceConnectorNotPresent No object found in the on-premises Active Directory

connector space.
STAT US DESC RIP T IO N
TargetNotExportedToDirectory The object in the Azure AD connector space has not yet been
exported.
MigratedCheckDetailsForMoreInfo Log entry was created before build 1.0.9125.0 and is shown
in its legacy state.
Error Service returned an unknown error.
Unknown An error occurred while trying to process a batch of password

hashes.
MissingAttribute Specific attributes (for example, Kerberos hash) required by

Azure AD Domain Services are not available.
RetryRequestedByTarget Specific attributes (for example, Kerberos hash) required by

Azure AD Domain Services were not available previously. An
attempt to resynchronize the user's password hash is made.
Scripts to help troubleshooting

Get the status of password sync settings
Import-Module ADSync
$connectors = Get-ADSyncConnector
$aadConnectors = $connectors | Where-Object {$_.SubType -eq "Windows Azure Active Directory (Microsoft)"}
$adConnectors = $connectors | Where-Object {$_.ConnectorTypeName -eq "AD"}
if ($aadConnectors -ne $null -and $adConnectors -ne $null)
{
if ($aadConnectors.Count -eq 1)
{
$features = Get-ADSyncAADCompanyFeature -ConnectorName $aadConnectors[0].Name
Write-Host
Write-Host "Password sync feature enabled in your Azure AD directory: " $features.PasswordHashSync
foreach ($adConnector in $adConnectors)
{
Write-Host
Write-Host "Password sync channel status BEGIN --------------------------------------------------
----- "
Write-Host
Get-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector.Name
Write-Host
$pingEvents =
Get-EventLog -LogName "Application" -Source "Directory Synchronization" -InstanceId 654 -
After (Get-Date).AddHours(-3) |
Where-Object {
$_.Message.ToUpperInvariant().Contains($adConnector.Identifier.ToString("D").ToUpperInvariant()) } |
Sort-Object { $_.Time } -Descending
if ($pingEvents -ne $null)
{
Write-Host "Latest heart beat event (within last 3 hours). Time " $pingEvents[0].TimeWritten
}
else
{
Write-Warning "No ping event found within last 3 hours."
}
Write-Host
Write-Host "Password sync channel status END ----------------------------------------------------
--- "
Write-Host
}
}
else
{
Write-Warning "More than one Azure AD Connectors found. Please update the script to use the
appropriate Connector."
}
}
Write-Host
if ($aadConnectors -eq $null)
{
Write-Warning "No Azure AD Connector was found."
}
if ($adConnectors -eq $null)
{
Write-Warning "No AD DS Connector was found."
}
Write-Host
Trigger a full sync of all passwords
NOTE
Run this script only once. If you need to run it more than once, something else is the problem. To troubleshoot the problem,
contact Microsoft support.
You can trigger a full sync of all passwords by using the following script:
$adConnector = "<CASE SENSITIVE AD CONNECTOR NAME>"
$aadConnector = "<CASE SENSITIVE AAD CONNECTOR NAME>"
Import-Module adsync
$c = Get-ADSyncConnector -Name $adConnector
$p = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ConfigurationParameter
"Microsoft.Synchronize.ForceFullPasswordSync", String, ConnectorGlobal, $null, $null, $null
$p.Value = 1
$c.GlobalParameters.Remove($p.Name)
$c.GlobalParameters.Add($p)
$c = Add-ADSyncConnector -Connector $c
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable
$false
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable
$true
Next steps
Implementing password hash synchronization with Azure AD Connect sync
Azure AD Connect Sync: Customizing synchronization options
Troubleshoot Azure Active Directory Pass-through
Authentication
This article helps you find troubleshooting information about common issues regarding Azure AD Pass-through
Authentication.
IMPORTANT
If you are facing user sign-in issues with Pass-through Authentication, don't disable the feature or uninstall Pass-through
Authentication Agents without having a cloud-only Global Administrator account to fall back on. Learn about adding a
cloud-only Global Administrator account. Doing this step is critical and ensures that you don't get locked out of your
tenant.
General issues
Check status of the feature and Authentication Agents
Ensure that the Pass-through Authentication feature is still Enabled on your tenant and the status of
Authentication Agents shows Active , and not Inactive . You can check status by going to the Azure AD
Connect blade on the Azure Active Directory admin center.
User-facing sign-in error messages
If the user is unable to sign into using Pass-through Authentication, they may see one of the following user-
facing errors on the Azure AD sign-in screen:
ERRO R DESC RIP T IO N RESO L UT IO N
AADSTS80001 Unable to connect to Active Directory Ensure that agent servers are
members of the same AD forest as the
users whose passwords need to be
validated and they are able to connect
to Active Directory.
AADSTS8002 A timeout occurred connecting to Check to ensure that Active Directory

Active Directory is available and is responding to
requests from the agents.
AADSTS80004 The username passed to the agent Ensure the user is attempting to sign
was not valid in with the right username.
AADSTS80005 Validation encountered unpredictable A transient error. Retry the request. If

WebException it continues to fail, contact Microsoft
support.
AADSTS80007 An error occurred communicating with Check the agent logs for more
Active Directory information and verify that Active
Directory is operating as expected.
Users get invalid username/password error

This can happen when a user’s on-premises UserPrincipalName (UPN) is different than the user's cloud UPN.
To confirm that this is the issue, first test that the Pass-through Authentication agent is working correctly:
1. Create a test account.
2. Import the PowerShell module on the agent machine:
Import-Module "C:\Program Files\Microsoft Azure AD Connect Authentication

Agent\Modules\PassthroughAuthPSModule\PassthroughAuthPSModule.psd1"
3. Run the Invoke PowerShell command:
Invoke-PassthroughAuthOnPremLogonTroubleshooter
4. When you are prompted to enter credentials, enter the same username and password that are used to sign
in to (https://login.microsoftonline.com).
If you get the same username/password error, this means that the Pass-through Authentication agent is
working correctly and the issue may be that the on-premises UPN is non-routable. To learn more, see
Configuring Alternate Login ID.
IMPORTANT
If the Azure AD Connect server isn't domain joined, a requirement mentioned in Azure AD Connect: Prerequisites, the
invalid username/password issue occurs.
Sign-in failure reasons on the Azure Active Directory admin center (needs Premium license )
If your tenant has an Azure AD Premium license associated with it, you can also look at the sign-in activity
report on the Azure Active Directory admin center.
Navigate to Azure Active Director y -> Sign-ins on the Azure Active Directory admin center and click a
specific user's sign-in activity. Look for the SIGN-IN ERROR CODE field. Map the value of that field to a failure
reason and resolution using the following table:
SIGN - IN ERRO R C O DE SIGN - IN FA IL URE REA SO N RESO L UT IO N
50144 User's Active Directory password has Reset the user's password in your on-
expired. premises Active Directory.
80001 No Authentication Agent available. Install and register an Authentication

Agent.
80002 Authentication Agent's password Check if your Active Directory is

validation request timed out. reachable from the Authentication
Agent.
80003 Invalid response received by If the problem is consistently

Authentication Agent. reproducible across multiple users,
check your Active Directory
configuration.
80004 Incorrect User Principal Name (UPN) Ask the user to sign in with the correct
used in sign-in request. username.
80005 Authentication Agent: Error occurred. Transient error. Try again later.
80007 Authentication Agent unable to Check if your Active Directory is

connect to Active Directory. reachable from the Authentication
Agent.
80010 Authentication Agent unable to If the problem is consistently

decrypt password. reproducible, install and register a new
Authentication Agent. And uninstall
the current one.
80011 Authentication Agent unable to If the problem is consistently

retrieve decryption key. reproducible, install and register a new
Authentication Agent. And uninstall
the current one.
IMPORTANT
Pass-through Authentication Agents authenticate Azure AD users by validating their usernames and passwords against
Active Directory by calling the Win32 LogonUser API. As a result, if you have set the "Logon To" setting in Active
Directory to limit workstation logon access, you will have to add servers hosting Pass-through Authentication Agents to
the list of "Logon To" servers as well. Failing to do this will block your users from signing into Azure AD.
Authentication Agent installation issues

An unexpected error occurred
Collect agent logs from the server and contact Microsoft Support with your issue.
Authentication Agent registration issues

Registration of the Authentication Agent failed due to blocked ports
Ensure that the server on which the Authentication Agent has been installed can communicate with our service
URLs and ports listed here.
Registration of the Authentication Agent failed due to token or account authorization errors
Ensure that you use a cloud-only Global Administrator account for all Azure AD Connect or standalone
Authentication Agent installation and registration operations. There is a known issue with MFA-enabled Global
Administrator accounts; turn off MFA temporarily (only to complete the operations) as a workaround.
An unexpected error occurred
Collect agent logs from the server and contact Microsoft Support with your issue.
Authentication Agent uninstallation issues

Warning message when uninstalling Azure AD Connect
If you have Pass-through Authentication enabled on your tenant and you try to uninstall Azure AD Connect, it
shows you the following warning message: "Users will not be able to sign-in to Azure AD unless you have other
Pass-through Authentication agents installed on other servers."
Ensure that your setup is highly available before you uninstall Azure AD Connect to avoid breaking user sign-in.
Issues with enabling the feature

Enabling the feature failed because there were no Authentication Agents available
You need to have at least one active Authentication Agent to enable Pass-through Authentication on your tenant.
You can install an Authentication Agent by either installing Azure AD Connect or a standalone Authentication
Agent.
Enabling the feature failed due to blocked ports
Ensure that the server on which Azure AD Connect is installed can communicate with our service URLs and
ports listed here.
Enabling the feature failed due to token or account authorization errors
Ensure that you use a cloud-only Global Administrator account when enabling the feature. There is a known
issue with multi-factor authentication (MFA)-enabled Global Administrator accounts; turn off MFA temporarily
(only to complete the operation) as a workaround.
Collecting Pass-through Authentication Agent logs

Depending on the type of issue you may have, you need to look in different places for Pass-through
Authentication Agent logs.
Azure AD Connect logs
For errors related to installation, check the Azure AD Connect logs at %ProgramData%\AADConnect\trace-
*.log .
Authentication Agent event logs
For errors related to the Authentication Agent, open up the Event Viewer application on the server and check
under Application and Ser vice Logs\Microsoft\AzureAdConnect\AuthenticationAgent\Admin .
For detailed analytics, enable the "Session" log (right-click inside the Event Viewer application to find this
option). Don't run the Authentication Agent with this log enabled during normal operations; use only for
troubleshooting. The log contents are only visible after the log is disabled again.
Detailed trace logs
To troubleshoot user sign-in failures, look for trace logs at %ProgramData%\Microsoft\Azure AD Connect
Authentication Agent\Trace\ . These logs include reasons why a specific user sign-in failed using the Pass-
through Authentication feature. These errors are also mapped to the sign-in failure reasons shown in the
preceding sign-in failure reasons table. Following is an example log entry:
AzureADConnectAuthenticationAgentService.exe Error: 0 : Passthrough Authentication request failed.

RequestId: 'df63f4a4-68b9-44ae-8d81-6ad2d844d84e'. Reason: '1328'.
ThreadId=5
DateTime=xxxx-xx-xxTxx:xx:xx.xxxxxxZ
You can get descriptive details of the error ('1328' in the preceding example) by opening up the command
prompt and running the following command (Note: Replace '1328' with the actual error number that you see in
your logs):
Net helpmsg 1328
Domain Controller logs

If audit logging is enabled, additional information can be found in the security logs of your Domain Controllers.
A simple way to query sign-in requests sent by Pass-through Authentication Agents is as follows:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[EventData[Data[@Name='ProcessName'] and (Data='C:\Program Files\Microsoft
Azure AD Connect Authentication Agent\AzureADConnectAuthenticationAgentService.exe')]]</Select>
</Query>
</QueryList>
Performance Monitor counters

Another way to monitor Authentication Agents is to track specific Performance Monitor counters on each server
where the Authentication Agent is installed. Use the following Global counters (# PTA authentications , #PTA
failed authentications and #PTA successful authentications ) and Error counters (# PTA authentication
errors ):
IMPORTANT
Pass-through Authentication provides high availability using multiple Authentication Agents, and not load balancing.
Depending on your configuration, not all your Authentication Agents receive roughly equal number of requests. It is
possible that a specific Authentication Agent receives no traffic at all.
Troubleshoot Azure Active Directory Seamless Single
Sign-On
This article helps you find troubleshooting information about common problems regarding Azure Active
Directory (Azure AD) Seamless Single Sign-On (Seamless SSO).
Known issues
In a few cases, enabling Seamless SSO can take up to 30 minutes.
If you disable and re-enable Seamless SSO on your tenant, users will not get the single sign-on experience till
their cached Kerberos tickets, typically valid for 10 hours, have expired.
If Seamless SSO succeeds, the user does not have the opportunity to select Keep me signed in . Due to this
behavior, SharePoint and OneDrive mapping scenarios don't work.
Office 365 Win32 clients (Outlook, Word, Excel, and others) with versions 16.0.8730.xxxx and above are
supported using a non-interactive flow. Other versions are not supported; on those versions, users will enter
their usernames, but not passwords, to sign-in. For OneDrive, you will have to activate the OneDrive silent
config feature for a silent sign-on experience.
Seamless SSO doesn't work in private browsing mode on Firefox.
Seamless SSO doesn't work in Internet Explorer when Enhanced Protected mode is turned on.
Seamless SSO doesn't work on mobile browsers on iOS and Android.
If a user is part of too many groups in Active Directory, the user's Kerberos ticket will likely be too large to
process, and this will cause Seamless SSO to fail. Azure AD HTTPS requests can have headers with a maximum
size of 50 KB; Kerberos tickets need to be smaller than that limit to accommodate other Azure AD artifacts
(typically, 2 - 5 KB) such as cookies. Our recommendation is to reduce user's group memberships and try
again.
If you're synchronizing 30 or more Active Directory forests, you can't enable Seamless SSO through Azure AD
Connect. As a workaround, you can manually enable the feature on your tenant.
Adding the Azure AD service URL ( https://autologon.microsoftazuread-sso.com ) to the Trusted sites zone
instead of the Local intranet zone blocks users from signing in.
Seamless SSO supports the AES256_HMAC_SHA1, AES128_HMAC_SHA1 and RC4_HMAC_MD5 encryption
types for Kerberos. It is recommended that the encryption type for the AzureADSSOAcc$ account is set to
AES256_HMAC_SHA1, or one of the AES types vs. RC4 for added security. The encryption type is stored on the
msDS-SupportedEncryptionTypes attribute of the account in your Active Directory. If the AzureADSSOAcc$
account encryption type is set to RC4_HMAC_MD5, and you want to change it to one of the AES encryption
types, please make sure that you first roll over the Kerberos decryption key of the AzureADSSOAcc$ account
as explained in the FAQ document under the relevant question, otherwise Seamless SSO will not happen.
Check status of feature

Ensure that the Seamless SSO feature is still Enabled on your tenant. You can check the status by going to the
Azure AD Connect pane in the Azure Active Directory admin center.
Click through to see all the AD forests that have been enabled for Seamless SSO.
Sign-in failure reasons in the Azure Active Directory admin center

(needs a Premium license)
If your tenant has an Azure AD Premium license associated with it, you can also look at the sign-in activity report
in the Azure Active Directory admin center.
Browse to Azure Active Director y > Sign-ins in the Azure Active Directory admin center, and then select a
specific user's sign-in activity. Look for the SIGN-IN ERROR CODE field. Map the value of that field to a failure
reason and resolution by using the following table:
81001 User's Kerberos ticket is too large. Reduce the user's group memberships
and try again.
81002 Unable to validate the user's Kerberos See the troubleshooting checklist.
ticket.
ticket.
81004 Kerberos authentication attempt failed. See the troubleshooting checklist.
ticket.
ticket.
81010 Seamless SSO failed because the user's The user needs to sign in from a
Kerberos ticket has expired or is invalid. domain-joined device inside your
corporate network.
81011 Unable to find the user object based on Use Azure AD Connect to synchronize
the information in the user's Kerberos the user's information into Azure AD.
ticket.
81012 The user trying to sign in to Azure AD The user needs to sign in from a
is different from the user that is signed different device.
in to the device.
81013 Unable to find the user object based on Use Azure AD Connect to synchronize
the information in the user's Kerberos the user's information into Azure AD.
ticket.
Troubleshooting checklist
Use the following checklist to troubleshoot Seamless SSO problems:
Ensure that the Seamless SSO feature is enabled in Azure AD Connect. If you can't enable the feature (for
example, due to a blocked port), ensure that you have all the prerequisites in place.
If you have enabled both Azure AD Join and Seamless SSO on your tenant, ensure that the issue is not with
Azure AD Join. SSO from Azure AD Join takes precedence over Seamless SSO if the device is both registered
with Azure AD and domain-joined. With SSO from Azure AD Join the user sees a sign-in tile that says
"Connected to Windows".
Ensure that the Azure AD URL ( https://autologon.microsoftazuread-sso.com ) is part of the user's Intranet zone
settings.
Ensure that the corporate device is joined to the Active Directory domain. The device doesn't need to be Azure
AD Joined for Seamless SSO to work.
Ensure that the user is logged on to the device through an Active Directory domain account.
Ensure that the user's account is from an Active Directory forest where Seamless SSO has been set up.
Ensure that the device is connected to the corporate network.
Ensure that the device's time is synchronized with the time in both Active Directory and the domain controllers,
and that they are within five minutes of each other.
Ensure that the AZUREADSSOACC computer account is present and enabled in each AD forest that you want
Seamless SSO enabled. If the computer account has been deleted or is missing, you can use PowerShell
cmdlets to re-create them.
List the existing Kerberos tickets on the device by using the klist command from a command prompt.
Ensure that the tickets issued for the AZUREADSSOACC computer account are present. Users' Kerberos tickets are
typically valid for 10 hours. You might have different settings in Active Directory.
If you disabled and re-enabled Seamless SSO on your tenant, users will not get the single sign-on experience
till their cached Kerberos tickets have expired.
Purge existing Kerberos tickets from the device by using the klist purge command, and try again.
To determine if there are JavaScript-related problems, review the console logs of the browser (under
Developer Tools ).
Review the domain controller logs.
Domain controller logs
If you enable success auditing on your domain controller, then every time a user signs in through Seamless SSO, a
security entry is recorded in the event log. You can find these security events by using the following query. (Look
for event 4769 associated with the computer account AzureADSSOAcc$ .)
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[EventData[Data[@Name='ServiceName'] and (Data='AZUREADSSOACC$')]]</Select>
</Query>
</QueryList>
Manual reset of the feature

If troubleshooting didn't help, you can manually reset the feature on your tenant. Follow these steps on the on-
premises server where you're running Azure AD Connect.
Step 1: Import the Seamless SSO PowerShell module
2. Browse to the %programfiles%\Microsoft Azure Active Directory Connect folder.
3. Import the Seamless SSO PowerShell module by using this command: Import-Module .\AzureADSSO.psd1 .
Step 2: Get the list of Active Directory forests on which Seamless SSO has been enabled
1. Run PowerShell as an administrator. In PowerShell, call New-AzureADSSOAuthenticationContext . When prompted,
enter your tenant's global administrator credentials.
2. Call Get-AzureADSSOStatus . This command provides you with the list of Active Directory forests (look at the
Step 3: Disable Seamless SSO for each Active Directory forest where you've set up the feature
1. Call $creds = Get-Credential . When prompted, enter the domain administrator credentials for the
intended Active Directory forest.
NOTE
The domain administrator credentials username must be entered in the SAM account name format
(contoso\johndoe or contoso.com\johndoe). We use the domain portion of the username to locate the Domain
Controller of the Domain Administrator using DNS.
NOTE
The domain administrator account used must not be a member of the Protected Users group. If so, the operation
will fail.
2. Call Disable-AzureADSSOForest -OnPremCredentials $creds . This command removes the AZUREADSSOACC

computer account from the on-premises domain controller for this specific Active Directory forest.
3. Repeat the preceding steps for each Active Directory forest where you’ve set up the feature.
Step 4: Enable Seamless SSO for each Active Directory forest
1. Call Enable-AzureADSSOForest . When prompted, enter the domain administrator credentials for the
intended Active Directory forest.
NOTE
The domain administrator credentials username must be entered in the SAM account name format
(contoso\johndoe or contoso.com\johndoe). We use the domain portion of the username to locate the Domain
Controller of the Domain Administrator using DNS.
NOTE
The domain administrator account used must not be a member of the Protected Users group. If so, the operation
will fail.
2. Repeat the preceding step for each Active Directory forest where you want to set up the feature.
Step 5. Enable the feature on your tenant
To turn on the feature on your tenant, call Enable-AzureADSSO -Enable $true .
Azure AD Connect sync: Handling LargeObject errors
caused by userCertificate attribute
Azure AD enforces a maximum limit of 15 certificate values on the userCer tificate attribute. If Azure AD Connect
exports an object with more than 15 values to Azure AD, Azure AD returns a LargeObject error with message:
"The provisioned object is too large. Trim the number of attribute values on this object. The operation will be
retried in the next synchronization cycle..."
The LargeObject error may be caused by other AD attributes. To confirm it is indeed caused by the userCertificate
attribute, you need to verify against the object either in on-premises AD or in the Synchronization Service Manager
Metaverse Search.
To obtain the list of objects in your tenant with LargeObject errors, use one of the following methods:
If your tenant is enabled for Azure AD Connect Health for sync, you can refer to the Synchronization Error
Report provided.
The notification email for directory synchronization errors that is sent at the end of each sync cycle has the
list of objects with LargeObject errors.
The Synchronization Service Manager Operations tab displays the list of objects with LargeObject errors if
you click the latest Export to Azure AD operation.
Mitigation options
Until the LargeObject error is resolved, other attribute changes to the same object cannot be exported to Azure AD.
To resolve the error, you can consider the following options:
Upgrade Azure AD Connect to build 1.1.524.0 or after. In Azure AD Connect build 1.1.524.0, the out-of-box
synchronization rules have been updated to not export attributes userCertificate and userSMIMECertificate
if the attributes have more than 15 values. For details on how to upgrade Azure AD Connect, refer to article
Azure AD Connect: Upgrade from a previous version to the latest.
Implement an outbound sync rule in Azure AD Connect that exports a null value instead of the actual
values for objects with more than 15 cer tificate values . This option is suitable if you do not require
any of the certificate values to be exported to Azure AD for objects with more than 15 values. For details on
how to implement this sync rule, refer to next section Implementing sync rule to limit export of
userCertificate attribute.
Reduce the number of certificate values on the on-premises AD object (15 or less) by removing values that
are no longer in use by your organization. This is suitable if the attribute bloat is caused by expired or
unused certificates. You can use the PowerShell script available here to help find, backup, and delete expired
certificates in your on-premises AD. Before deleting the certificates, it is recommended that you verify with
the Public-Key-Infrastructure administrators in your organization.
Configure Azure AD Connect to exclude the userCertificate attribute from being exported to Azure AD. In
general, we do not recommend this option since the attribute may be used by Microsoft Online Services to
enable specific scenarios. In particular:
The userCertificate attribute on the User object is used by Exchange Online and Outlook clients for
message signing and encryption. To learn more about this feature, refer to article S/MIME for
message signing and encryption.
The userCertificate attribute on the Computer object is used by Azure AD to allow Windows 10 on-
premises domain-joined devices to connect to Azure AD. To learn more about this feature, please
refer to article Connect domain-joined devices to Azure AD for Windows 10 experiences.
Implementing sync rule to limit export of userCertificate attribute

To resolve the LargeObject error caused by the userCertificate attribute, you can implement an outbound sync rule
in Azure AD Connect that exports a null value instead of the actual values for objects with more than 15
cer tificate values . This section describes the steps required to implement the sync rule for User objects. The
steps can be adapted for Contact and Computer objects.
IMPORTANT
Exporting null value removes certificate values previously exported successfully to Azure AD.
The steps can be summarized as:

1. Disable sync scheduler and verify there is no synchronization in progress.
2. Find the existing outbound sync rule for userCertificate attribute.
3. Create the outbound sync rule required.
4. Verify the new sync rule on an existing object with LargeObject error.
5. Apply the new sync rule to remaining objects with LargeObject error.
6. Verify there are no unexpected changes waiting to be exported to Azure AD.
7. Export the changes to Azure AD.
8. Re-enable sync scheduler.
Step 1. Disable sync scheduler and verify there is no synchronization in progress
Ensure no synchronization takes place while you are in the middle of implementing a new sync rule to avoid
unintended changes being exported to Azure AD. To disable the built-in sync scheduler:
1. Start PowerShell session on the Azure AD Connect server.
2. Disable scheduled synchronization by running cmdlet: Set-ADSyncScheduler -SyncCycleEnabled $false
NOTE
The preceding steps are only applicable to newer versions (1.1.xxx.x) of Azure AD Connect with the built-in scheduler. If you
are using older versions (1.0.xxx.x) of Azure AD Connect that uses Windows Task Scheduler, or you are using your own
custom scheduler (not common) to trigger periodic synchronization, you need to disable them accordingly.
1. Start the Synchronization Ser vice Manager by going to START → Synchronization Service.
2. Go to the Operations tab and confirm there is no operation whose status is “in progress.”
Step 2. Find the existing outbound sync rule for userCertificate attribute
There should be an existing sync rule that is enabled and configured to export userCertificate attribute for User
objects to Azure AD. Locate this sync rule to find out its precedence and scoping filter configuration:
1. Start the Synchronization Rules Editor by going to START → Synchronization Rules Editor.
2. Configure the search filters with the following values:
Direction Outbound
MV Object Type Person
Connector name of your Azure AD connector
Connector Object Type user
MV attribute userCer tificate
3. If you are using OOB (out-of-box) sync rules to Azure AD connector to export userCertficiate attribute for
User objects, you should get back the “Out to AAD – User ExchangeOnline” rule.
4. Note down the precedence value of this sync rule.
5. Select the sync rule and click Edit .
6. In the “Edit Reserved Rule Confirmation” pop-up dialog, click No . (Don’t worry, we are not going to make
any change to this sync rule).
7. In the edit screen, select the Scoping filter tab.
8. Note down the scoping filter configuration. If you are using the OOB sync rule, there should exactly be one
scoping filter group containing two clauses , including:
Step 3. Create the outbound sync rule required

The new sync rule must have the same scoping filter and higher precedence than the existing sync rule. This
ensures that the new sync rule applies to the same set of objects as the existing sync rule and overrides the existing
sync rule for the userCertificate attribute. To create the sync rule:
1. In the Synchronization Rules Editor, click the Add new rule button.
2. Under the Description tab , provide the following configuration:
Name Provide a name E.g., “Out to AAD – Custom override

for userCertificate”
Description Provide a description E.g., “If userCertificate attribute has

more than 15 values, export NULL.”
Connected System Select the Azure AD Connector
Connected System Object Type user
Metaverse Object Type person

Link Type Join
Precedence Chose a number between 1 - 99 The number chosen must not be

used by any existing sync rule and
has a lower value (and therefore,
higher precedence) than the existing
sync rule.
3. Go to the Scoping filter tab and implement the same scoping filter the existing sync rule is using.
4. Skip the Join rules tab.
5. Go to the Transformations tab to add a new transformation using following configuration:
Flow Type Expression
Target Attribute userCer tificate
Source Attribute Use the following expression:

IIF(IsNullOrEmpty([userCertificate]), NULL,
IIF((Count([userCertificate])>
15),AuthoritativeNull,[userCertificate]))
6. Click the Add button to create the sync rule.

Step 4. Verify the new sync rule on an existing object with LargeObject error
This is to verify that the sync rule created is working correctly on an existing AD object with LargeObject error
before you apply it to other objects:
1. Go to the Operations tab in the Synchronization Service Manager.
2. Select the most recent Export to Azure AD operation and click on one of the objects with LargeObject errors.
3. In the Connector Space Object Properties pop-up screen, click on the Preview button.
4. In the Preview pop-up screen, select Full synchronization and click Commit Preview .
5. Close the Preview screen and the Connector Space Object Properties screen.
7. Right-click on the Azure AD Connector and select Run...
8. In the Run Connector pop-up, select Expor t step and click OK .
9. Wait for Export to Azure AD to complete and confirm there is no more LargeObject error on this specific object.
Step 5. Apply the new sync rule to remaining objects with LargeObject error
Once the sync rule has been added, you need to run a full synchronization step on the AD Connector:
2. Right-click on the AD Connector and select Run...
3. In the Run Connector pop-up, select Full Synchronization step and click OK .
4. Wait for the Full Synchronization step to complete.
5. Repeat the above steps for the remaining AD Connectors if you have more than one AD Connectors. Usually,
multiple connectors are required if you have multiple on-premises directories.
Step 6. Verify there are no unexpected changes waiting to be exported to Azure AD
2. Right-click on the Azure AD Connector and select Search Connector Space .
3. In the Search Connector Space pop-up:
a. Set Scope to Pending Expor t .
b. Check all 3 checkboxes, including Add , Modify and Delete .
c. Click Search button to return all objects with changes waiting to be exported to Azure AD.
d. Verify there are no unexpected changes. To examine the changes for a given object, double-click on the
object.
Step 7. Export the changes to Azure AD
To export the changes to Azure AD:
2. Right-click on the Azure AD Connector and select Run...
3. In the Run Connector pop-up, select Expor t step and click OK .
4. Wait for Export to Azure AD to complete and confirm there are no more LargeObject errors.
Step 8. Re -enable sync scheduler
Now that the issue is resolved, re-enable the built-in sync scheduler:
1. Start PowerShell session.
2. Re-enable scheduled synchronization by running cmdlet: Set-ADSyncScheduler -SyncCycleEnabled $true
NOTE
The preceding steps are only applicable to newer versions (1.1.xxx.x) of Azure AD Connect with the built-in scheduler. If you
are using older versions (1.0.xxx.x) of Azure AD Connect that uses Windows Task Scheduler, or you are using your own
custom scheduler (not common) to trigger periodic synchronization, you need to disable them accordingly.
Next steps
Azure AD Connect: How to recover from LocalDB 10-
GB limit
Azure AD Connect requires a SQL Server database to store identity data. You can either use the default SQL Server
2012 Express LocalDB installed with Azure AD Connect or use your own full SQL. SQL Server Express imposes a
10-GB size limit. When using LocalDB and this limit is reached, Azure AD Connect Synchronization Service can no
longer start or synchronize properly. This article provides the recovery steps.
Symptoms
There are two common symptoms:
Azure AD Connect Synchronization Service is running but fails to synchronize with “stopped-database-
disk-full” error.
Azure AD Connect Synchronization Service is unable to star t . When you attempt to start the service, it
fails with event 6323 and error message "The server encountered an error because SQL Server is out of disk
space."
Short-term recovery steps

This section provides the steps to reclaim DB space required for Azure AD Connect Synchronization Service to
resume operation. The steps include:
1. Determine the Synchronization Service status
2. Shrink the database
3. Delete run history data
4. Shorten retention period for run history data
Determine the Synchronization Service status
First, determine whether the Synchronization Service is still running or not:
1. Log in to your Azure AD Connect server as administrator.
2. Go to Ser vice Control Manager .
3. Check the status of Microsoft Azure AD Sync .
4. If it is running, do not stop or restart the service. Skip Shrink the database step and go to Delete run history
data step.
5. If it is not running, try to start the service. If the service starts successfully, skip Shrink the database step and
go to Delete run history data step. Otherwise, continue with Shrink the database step.
Shrink the database
Use the Shrink operation to free up enough DB space to start the Synchronization Service. It frees up DB space by
removing whitespaces in the database. This step is best-effort as it is not guaranteed that you can always recover
space. To learn more about Shrink operation, read this article Shrink a database.
IMPORTANT
Skip this step if you can get the Synchronization Service to run. It is not recommended to shrink the SQL DB as it can lead to
poor performance due to increased fragmentation.
The name of the database created for Azure AD Connect is ADSync . To perform a Shrink operation, you must log in
either as the sysadmin or DBO of the database. During Azure AD Connect installation, the following accounts are
granted sysadmin rights:
Local Administrators
The user account that was used to run Azure AD Connect installation.
The Sync Service account that is used as the operating context of Azure AD Connect Synchronization Service.
The local group ADSyncAdmins that was created during installation.
1. Back up the database by copying ADSync.mdf and ADSync_log.ldf files located under
%ProgramFiles%\Microsoft Azure AD Sync\Data to a safe location.
2. Start a new PowerShell session.

3. Navigate to folder %ProgramFiles%\Microsoft SQL Server\110\Tools\Binn .
4. Start sqlcmd utility by running the command
./SQLCMD.EXE -S "(localdb)\.\ADSync" -U <Username> -P <Password> , using the credential of a sysadmin or the
database DBO.
5. To shrink the database, at the sqlcmd prompt (1>), enter DBCC Shrinkdatabase(ADSync,1); , followed by GO in
the next line.
6. If the operation is successful, try to start the Synchronization Service again. If you can start the
Synchronization Service, go to Delete run history data step. If not, contact Support.
Delete run history data
By default, Azure AD Connect retains up to seven days’ worth of run history data. In this step, we delete the run
history data to reclaim DB space so that Azure AD Connect Synchronization Service can start syncing again.
1. Start Synchronization Ser vice Manager by going to START → Synchronization Service.
2. Go to the Operations tab.
3. Under Actions , select Clear Runs …
4. You can either choose Clear all runs or Clear runs before… <date> option. It is recommended that you
start by clearing run history data that are older than two days. If you continue to run into DB size issue, then
choose the Clear all runs option.
Shorten retention period for run history data
This step is to reduce the likelihood of running into the 10-GB limit issue after multiple sync cycles.
1. Open a new PowerShell session.
2. Run Get-ADSyncScheduler and take note of the PurgeRunHistoryInterval property, which specifies the
current retention period.
3. Run Set-ADSyncScheduler -PurgeRunHistoryInterval 2.00:00:00 to set the retention period to two days. Adjust
the retention period as appropriate.
Long-term solution – Migrate to full SQL

In general, the issue is indicative that 10-GB database size is no longer sufficient for Azure AD Connect to
synchronize your on-premises Active Directory to Azure AD. It is recommended that you switch to using the full
version of SQL server. You cannot directly replace the LocalDB of an existing Azure AD Connect deployment with
the database of the full version of SQL. Instead, you must deploy a new Azure AD Connect server with the full
version of SQL. It is recommended that you do a swing migration where the new Azure AD Connect server (with
SQL DB) is deployed as a staging server, next to the existing Azure AD Connect server (with LocalDB).
For instruction on how to configure remote SQL with Azure AD Connect, refer to article Custom installation of
Azure AD Connect.
For instructions on swing migration for Azure AD Connect upgrade, refer to article Azure AD Connect: Upgrade
from a previous version to the latest.
Next steps
Troubleshoot SQL connectivity issues with Azure AD
Connect
This article explains how to troubleshoot connectivity issues between Azure AD Connect and SQL Server.
The following screenshot shows a typical error, if the SQL Server cannot be found.
Troubleshooting steps
Open a powershell window and Import the ADSyncTools Powershell module
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\Tools\AdSyncTools.psm1"
NOTE
Install-Module requires updating to PowerShell 5.0 (WMF 5.0) or later;
Or install PackageManagement PowerShell Modules Preview - March 2016 for PowerShell 3.0/4.0
Show all commands : Get-Command -Module AdSyncTools

Execute the powershell function : Connect-ADSyncDatabase with the following parameters
Server. The SQL Server name.
Instance. (Optional) The SQL Server Instance name and optionally Port number, that you would like to
use. Do not specify this parameter to use the default instance.
UserName. (Optional) The user account to connect with. If left blank the currently logged in user will be
used. If you are connecting to a remote SQL Server this should be the custom service account you have
created for Azure ADConnect SQL Connectivity. Azure AD Connect uses the Azure AD Connect sync
service account as to authenticate to a remote SQL server.
Password. (Optional) Password for the UserName provided.
This powershell function will attempt to bind to the specified SQL Server and Instance using the credentials passed
in OR use the credentials of the current user. If the SQL Server cannot be found the script will attempt to connect to
the SQL Browser service to determine enabled protocols and ports.
Example using just a Server name:
PS C:\Program Files\Microsoft Azure Active Directory Connect\Tools> import-module .\AdSyncTools.psm1
PS C:\Program Files\Microsoft Azure Active Directory Connect\Tools> Connect-AdSyncDatabase -Server SQL1

Resolving server address : SQL1
InterNetworkV6 : fe80::6c90:a995:3e70:ef74%17
InterNetworkV6 : 2001:4898:e0:66:6c90:a995:3e70:ef74
InterNetwork : 10.91.26.143
Attempting to connect to SQL1 using a TCP binding for the default instance.
Data Source=tcp:SQL1\;Integrated Security=True.ConnectionString
Successfully connected.
StatisticsEnabled : False
AccessToken :
ConnectionString : Data Source=tcp:SQL1\;Integrated Security=True
ConnectionTimeout : 15
Database : master
DataSource : tcp:SQL1\
PacketSize : 8000
ClientConnectionId : 23e06ef2-0a38-4f5f-9291-da931de40375
ServerVersion : 13.00.4474
State : Open
WorkstationId : SQL1
Credential :
FireInfoMessageEventOnUserErrors : False
Site :
Container :
PS C:\Program Files\Microsoft Azure Active Directory Connect\Tools>
Example using an Instance and Port number that don’t exist:
PS C:\Program Files\Microsoft Azure Active Directory Connect\tools> Connect-AdSyncDatabase -Server SQL1 -

Instance "INSTANCE1"
Attempting to connect to SQL1\INSTANCE1 using a TCP binding.

Data Source=tcp:SQL1\INSTANCE1;Integrated Security=True.ConnectionString
Connect-AdSyncDatabase : Unable to connect using a TCP binding. A network-related or instance-specific error
occurred while establishing a connection
to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and
that SQL Server is configured to allow
remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)
At line:1 char:1
+ Connect-AdSyncDatabase -Server SQL1 -Instance "INSTANCE1"
+ Connect-AdSyncDatabase -Server SQL1 -Instance "INSTANCE1"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ConnectionError: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Connect-AdSyncDatabase
TROUBLESHOOTING: Attempting to query the SQL Server Browser service configuration on SQL1.
Get-ADSyncSQLBrowserInstances : Unable to read the SQL Server Browser configuration. An existing connection was
forcibly closed by the remote host.
Ensure port 1434 (UDP) is open on SQL1 and the SQL Server Browser service is running.
At C:\Program Files\Microsoft Azure Active Directory Connect\tools\AdSyncTools.psm1:1717 char:18
+ $instances = Get-ADSyncSQLBrowserInstances $Server
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-ADSyncSQLBrowserInstances
WHAT TO TRY NEXT:
Each SQL instance must be bound to an explicit static TCP port and paired with an inbound firewall rule on SQL1
to allow connection. Enable the SQL Se
rver Browser service temporarily on the SQL server and run this cmdLet again to further troubleshoot the issue.
Alternatively use the SQL Server Configur
ation Manager on SQL1 to verify the instance name and TCP/IP port assignment manually.
You must specify both the instance name and the port to connect when the SQL Server Browser service is not
running. An inbound firewall rule on SQL1 is required for the associated port.
Example: 'MySQLInstance,1234' where 1234 has a matching firewall rule.
PS C:\Program Files\Microsoft Azure Active Directory Connect\tools>

PS C:\Program Files\Microsoft Azure Active Directory Connect\tools> Connect-AdSyncDatabase -Server SQL1 -
Instance "INSTANCE1,99"
Attempting to connect to SQL1\INSTANCE1,99 using a TCP binding.

Data Source=tcp:SQL1\INSTANCE1,99;Integrated Security=True.ConnectionString
Connect-AdSyncDatabase : Unable to connect using a TCP binding. A network-related or instance-specific error
occurred while establishing a connection
to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and
that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - The remote
computer refused the network connection.)
At line:1 char:1
+ Connect-AdSyncDatabase -Server SQL1 -Instance "INSTANCE1,99"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Connect-AdSyncDatabase
TROUBLESHOOTING: Attempting to query the SQL Server Browser service configuration on SQL1.
SQL browser response contained 2 instances.
Verifying protocol bindings and port connectivity.
MSSQLSERVER : Enabled - port 1433 is assigned and reachable through the firewall
INSTANCE1 : Blocked - the inbound firewall rule for port 58379 is missing or disabled
WHAT TO TRY NEXT:
Each SQL instance must be bound to an explicit static TCP port and paired with an
inbound firewall rule on SQL1 to allow connection. Review the TcpStatus field
for each instance and take corrective action.
InstanceName : MSSQLSERVER
tcp : 1433
TcpStatus : Enabled - port 1433 is assigned and reachable through the firewall
InstanceName : INSTANCE1
tcp : 58379
TcpStatus : Blocked - the inbound firewall rule for port 58379 is missing or disabled
PS C:\Program Files\Microsoft Azure Active Directory Connect\tools>
Next Steps
Azure AD connectivity with Azure AD Connect
Troubleshoot an attribute not synchronizing in Azure
AD Connect
Recommended Steps
Before investigating attribute syncing issues, let’s understand the Azure AD Connect syncing process:
Terminology
CS: Connector Space, a table in database.
MV: Metaverse, a table in database.
AD: Active Directory
AAD: Azure Active Directory
Synchronization Steps
Import from AD: Active Directory objects are brought into AD CS.
Import from AAD: Azure Active Directory objects are brought into AAD CS.
Synchronization: Inbound Synchronization Rules and Outbound Synchronization Rules are run in
the order of precedence number from lower to higher. To view the Synchronization Rules, you can go to
Synchronization Rules Editor from the desktop applications. The Inbound Synchronization Rules
brings in data from CS to MV. The Outbound Synchronization Rules moves data from MV to CS.
Export to AD: After running Synchronization, objects are exported from AD CS to Active Director y .
Export to AAD: After running Synchronization, objects are exported from AAD CS to Azure Active
Director y .
Step by Step Investigation
We will start our search from the Metaverse and look at the attribute mapping from source to target.
Launch Synchronization Ser vice Manager from the desktop applications, as shown below:
On the Synchronization Ser vice Manager , select the Metaverse Search , select Scope by Object
Type , select the object using an attribute, and click Search button.
Double click the object found in the Metaverse search to view all its attributes. You can click on the
Connectors tab to look at corresponding object in all the Connector Spaces .
Double click on the Active Director y Connector to view the Connector Space attributes. Click on the
Preview button, on the following dialog click on the Generate Preview button.
Now click on the Impor t Attribute Flow , this shows flow of attributes from Active Director y Connector
Space to the Metaverse . Sync Rule column shows which Synchronization Rule contributed to that
attribute. Data Source column shows you the attributes from the Connector Space . Metaverse
Attribute column shows you the attributes in the Metaverse . You can look for the attribute not syncing
here. If you don't find the attribute here, then this is not mapped and you have to create new custom
Synchronization Rule to map the attribute.
Click on the Expor t Attribute Flow in the left pane to view the attribute flow from Metaverse back to
Active Director y Connector Space using Outbound Synchronization Rules .
Similarly, you can view the Azure Active Director y Connector Space object and can generate the
Preview to view attribute flow from Metaverse to the Connector Space and vice versa, this way you can
investigate why an attribute is not syncing.
Azure AD Connect sync: Understanding the architecture
Azure AD Connect sync: Understanding Declarative Provisioning
Azure AD Connect sync: Understanding Declarative Provisioning Expressions
Azure AD Connect sync: Understanding the default configuration
Azure AD Connect sync: Understanding Users, Groups, and Contacts
Azure AD Connect sync: Shadow attributes
Next Steps
What is hybrid identity?.
Troubleshoot: Azure AD Connect install issues
Recommended Steps
Please check which Azure AD Connect installation type is suitable for you. If you meet the criteria of express
installation, then we highly recommend you to go with the express installation. The express installation gives you
minimal options needed to finish the installation, therefore there is less likelihood of any issues.
However, if you don’t meet the express installation criteria and must do the custom installation then here are some
best practices you can follow to avoid common issues. For the sake of simplicity only selective options are
mentioned here:
Ensure you are an administrator on the machine on which you are installing AAD Connect. Log in on to the
machine with same administrator credentials.
Let all the options to be default on the following page, except for “Use an existing SQL Server”, if you want to
use existing SQL Server. Here are more details about how to use custom installation options.
On the following page, pick option “Create new AD account", to avoid any permission issues with existing
account.
Common Issues
Connectivity issues with on-premises Active Directory.
Connectivity issues with online Azure Active Directory.
Permission issues with on-premises Active Directory.
Prerequisites for Azure AD Connect
Select which installation type to use for Azure AD Connect
Getting started with Azure AD Connect using express settings
Azure AD Connect: Upgrade from a previous version to the latest
Azure AD Connect: What is staging server?
What is the ADConnectivityTool PowerShell Module?
Next steps
Plan and troubleshoot User Principal Name changes
in Azure Active Directory
A User Principal Name (UPN) is an attribute that is an internet communication standard for user accounts. A UPN
consists of a UPN prefix (the user account name) and a UPN suffix (a DNS domain name). The prefix joins the suffix
using the "@" symbol. For example, someone@example.com. A UPN must be unique among all security principal
objects within a directory forest.
This ar ticle assumes you're using UPN as the user identifier. It addresses planning for UPN changes,
and recovering from issues that may result from UPN changes.
NOTE
For developers, we recommend that you use the user objectID as the immutable identifier, rather than UPN or email
addresses as their values can change.
Learn about UPNs and UPN changes

Sign-in pages often prompt users to enter their email address when the required value is actually their UPN.
Therefore, you should be sure to change users' UPN anytime their primary email address changes.
Users' primary email addresses might change for many reasons:
company rebranding
employees moving to different company divisions
mergers and acquisitions
employee name changes
Types of UPN changes
You can change a UPN by changing the prefix, suffix, or both.
Changing the prefix .
For example, if a person's name changed, you might change their account name:
BSimon@contoso.com to BJohnson@contoso.com
You might also change the corporate standard for prefixes:
Bsimon@contoso.com to Britta.Simon@contoso.com
Changing the suffix .
For example, if a person changed divisions, you might change their domain:
Britta.Simon@contoso.com to Britta.Simon@contosolabs.com
Or
Britta.Simon@corp.contoso.com to Britta.Simon@labs.contoso.com
We recommend to change users' UPN every time their primary email address is updated.
During the initial synchronization from Active Directory to Azure AD, ensure the users' emails are identical to their
UPNs.
UPNs in Active Directory
In Active Directory, the default UPN suffix is the DNS name of the domain where you created the user account. In
most cases, this is the domain name that you register as the enterprise domain on the internet. If you create the
user account in the contoso.com domain, the default UPN is
username@contoso.com
However, you can add more UPN suffixes by using Active Directory domains and trusts.
For example, you may want to add labs.contoso.com and have the users' UPNs and email reflect that. They would
then become
username@labs.contoso.com.
IMPORTANT
If you are changing the suffix in Active Directory, you must ensure that a matching custom domain name has been added
and verified on Azure AD.
UPNs in Azure Active Directory

Users sign in to Azure AD with the value in their userPrincipalName attribute.
When you use Azure AD in conjunction with your on-premises Active Directory, user accounts are synchronized by
using the Azure AD Connect service. By default the Azure AD Connect wizard uses the userPrincipalName attribute
from the on-premises Active Directory as the UPN in Azure AD. You can change it to a different attribute in a
custom installation.
It's important that you have a defined process when you update a User Principal Name (UPN) of a single user, or for
your entire organization.
See the Known issues and workarounds in this document.
When you're synchronizing user accounts from Active Directory to Azure AD, ensure that the UPNs in Active
Directory map to verified domains in Azure AD.
If the value of the userPrincipalName attribute doesn't correspond to a verified domain in Azure AD, the
synchronization process replaces the suffix with a default .onmicrosoft.com value.
Roll-out bulk UPN changes
Follow the best practices for a pilot for bulk UPN changes. Also have a tested rollback plan for reverting UPNs if
you find issues that can't be quickly resolved. Once your pilot is running, you can start targeting small sets of users
with various organizational roles and their specific sets of apps or devices.
Going through this first subset of users will give you a good idea of what users should expect as part of the change.
Include this information on your user communications.
Create a defined procedure for changing UPNs on individual users as part of normal operations. We recommend
having a tested procedure that includes documentation about known issues and workarounds.
The following sections detail potential known issues and workarounds when UPNs are changed.
Apps known issues and workarounds

Software as a service (SaaS) and Line of Business (LoB) applications often rely on UPNs to find users and store user
profile information, including roles. Applications that use Just in Time provisioning to create a user profile when
users sign in to the app for the first time can be affected by UPN changes.
Known issue
Changing a user's UPN could break the relationship between the Azure AD user and the user profile created on the
application. If the application uses Just in Time provisioning, it might create a brand-new user profile. This will
require the application administrator to make manual changes to fix this relationship.
Workaround
Azure AD Automated User Provisioning lets you automatically create, maintain, and remove your user identities in
supported cloud applications. Configuring automated user provisioning on your applications automatically updates
UPNs on the applications. Test the applications as part of the progressive rollout to validate that they are not
impacted by UPN changes. If you are a developer, consider adding SCIM support to your application to enable
automatic user provisioning from Azure Active Directory.
Managed devices known issues and workarounds

By bringing your devices to Azure AD, you maximize your users' productivity through single sign-on (SSO) across
your cloud and on-premises resources.
Azure AD joined devices
Azure AD joined devices are joined directly to Azure AD and allow users to sign in to the device using their
organization's identity.
Known issues
Users may experience single sign-on issues with applications that depend on Azure AD for authentication.
Resolution
The issues mentioned on this section have been fixed on the Windows 10 May 2020 update (2004).
Workaround
Allow enough time for the UPN change to sync to Azure AD. Once you verify that the new UPN is reflected on the
Azure AD Portal, ask the user to select the "Other user" tile to sign in with their new UPN. You can also verify
through PowerShell. After signing in with their new UPN, references to the old UPN might still appear on the
"Access work or school" Windows setting.
Hybrid Azure AD joined devices

Hybrid Azure AD joined devices are joined to Active Directory and Azure AD. You can implement Hybrid Azure AD
join if your environment has an on-premises Active Directory footprint and you also want to benefit from the
capabilities provided by Azure AD.
Known issues
Windows 10 Hybrid Azure AD joined devices are likely to experience unexpected restarts and access issues.
If users sign in to Windows before the new UPN has been synchronized to Azure AD, or continue to use an existing
Windows session, they may experience single sign-on issues with applications that use Azure AD for authentication
if Conditional Access has been configured to enforce the use of Hybrid Joined devices to access resources.
Additionally, the following message will appear, forcing a restart after one minute.
"Your PC will automatically restart in one minute. Windows ran into a problem and needs to restart. You should
close this message now and save your work".
Resolution
The issues mentioned on this section have been fixed on the Windows 10 May 2020 update (2004).
Workaround
The device must be unjoined from Azure AD and restarted. After restart, the device will automatically join Azure AD
again and the user must sign in using the new UPN by selecting the "Other user" tile. To unjoin a device from Azure
AD, run the following command at a command prompt:
dsregcmd /leave
The user will need to re-enroll for Windows Hello for Business if it's being used. Windows 7 and 8.1 devices are not
affected by this issue after UPN changes.
Microsoft Authenticator known issues and workarounds

Your organization might require the use of the Microsoft Authenticator app to sign in and access organizational
applications and data. Although a username might appear in the app, the account isn't set up to function as a
verification method until the user completes the registration process.
The Microsoft Authenticator app has four main functions:
Multi-factor authentication via a push notification or verification code
Act as an Authentication Broker on iOS and Android devices to provide single sign-on for applications that
use Brokered authentication
Device registration (also known as Workplace Join) to Azure AD, which is a requirement for other features
like Intune App Protection and Device Enrolment/Management,
Phone sign in, which requires MFA and device registration.
Multi-Factor Authentication with Android devices
The Microsoft Authenticator app offers an out-of-band verification option. Instead of placing an automated phone
call or SMS to the user during sign-in, Multi-Factor Authentication (MFA) pushes a notification to the Microsoft
Authenticator app on the user's smartphone or tablet. The user simply taps Approve (or enters a PIN or biometric
and taps "Authenticate") in the app to complete their sign-in.
Known issues
When you change a user's UPN, the old UPN still displays on the user account and a notification might not be
received. Verification codes continue to work.
Workaround
If a notification is received, instruct the user to dismiss the notification, open the Authenticator app, tap the "Check
for notifications" option and approve the MFA prompt. After this, the UPN displayed on the account will be updated.
Note the updated UPN might be displayed as a new account, this is due to other Authenticator functionality being
used. For more information refer to the additional known issues in this article.
Brokered authentication
On Android and iOS brokers like Microsoft Authenticator enable:
Single sign-on (SSO) - Your users won't need to sign in to each application.
Device identification - The broker accesses the device certificate created on the device when it was workplace
joined.
Application identification verification - When an application calls the broker, it passes its redirect URL, and
the broker verifies it.
Additionally, it allows applications to participate in more advanced features such as Conditional Access, and
supports Microsoft Intune scenarios.
Known issues
User is presented with more interactive authentication prompts on new applications that use broker-assisted sign-
in due to a mismatch between the login_hint passed by the application and the UPN stored on the broker.
Workaround
The user needs to manually remove the account from Microsoft Authenticator and start a new sign-in from a
broker-assisted application. The account will be automatically added after the initial authentication.
Device registration
The Microsoft Authenticator app is responsible for registering the device to Azure AD. Device registration allows the
device to authenticate to Azure AD and is a requirement for the following scenarios:
Intune App Protection
Intune Device Enrollment
Phone Sign In
Known issues
When you change the UPN, a new account with the new UPN appears listed on the Microsoft Authenticator app,
while the account with the old UPN is still listed. Additionally, the old UPN displays on the Device Registration
section on the app settings. There is no change in the normal functionality of Device Registration or the dependant
scenarios.
Workaround
To remove all references to the old UPN on the Microsoft Authenticator app, instruct the user to manually remove
both the old and new accounts from Microsoft Authenticator, re-register for MFA and rejoin the device.
Phone sign-in
Phone sign-in allows users to sign in to Azure AD without a password. To enable phone sign-in, the user needs to
register for MFA using the Authenticator app and then enable phone sign-in directly on Authenticator. As part of the
configuration, the device registers with Azure AD.
Known issues
Users are not able to use Phone sign-in because they do not receive any notification. If the user taps on Check for
Notifications, they get an error.
Workaround
The user needs to select the drop-down menu on the account enabled for Phone sign-in and select Disable phone
sign-in. If desired, Phone sign-in can be enabled again.
Security Key (FIDO2) known issues and workarounds

Known issues
When multiple users are registered on the same key, the sign in screen shows an account selection page where the
old UPN is displayed. Sign ins using Security Keys are not affected by UPN changes.
Workaround
To remove references to old UPNs, users must reset the security key and re-register.
OneDrive known issues and workarounds

OneDrive users are known to experience issues after UPN changes. For more information, see How UPN changes
affect the OneDrive URL and OneDrive features.
Next steps
See these resources:
Azure AD Connect: Design concepts
Microsoft identity platform ID tokens
Hybrid Identity Required Ports and Protocols
The following document is a technical reference on the required ports and protocols for implementing a hybrid
identity solution. Use the following illustration and refer to the corresponding table.
Table 1 - Azure AD Connect and On-premises AD

This table describes the ports and protocols that are required for communication between the Azure AD Connect
server and on-premises AD.
P ROTO C O L P O RT S DESC RIP T IO N
DNS 53 (TCP/UDP) DNS lookups on the destination forest.
Kerberos 88 (TCP/UDP) Kerberos authentication to the AD

forest.
MS-RPC 135 (TCP) Used during the initial configuration of

the Azure AD Connect wizard when it
binds to the AD forest, and also during
Password synchronization.
LDAP 389 (TCP/UDP) Used for data import from AD. Data is
encrypted with Kerberos Sign & Seal.
SMB 445 (TCP) Used by Seamless SSO to create a

computer account in the AD forest.
LDAP/SSL 636 (TCP/UDP) Used for data import from AD. The data
transfer is signed and encrypted. Only
used if you are using TLS.
RPC 49152- 65535 (Random high RPC Port) Used during the initial configuration of
(TCP) Azure AD Connect when it binds to the
AD forests, and during Password
synchronization. See KB929851,
KB832017, and KB224196 for more
information.
WinRM 5985 (TCP) Only used if you are installing AD FS

with gMSA by Azure AD Connect
Wizard
AD DS Web Services 9389 (TCP) Only used if you are installing AD FS

with gMSA by Azure AD Connect
Wizard
Table 2 - Azure AD Connect and Azure AD

server and Azure AD.
HTTP 80 (TCP) Used to download CRLs (Certificate

Revocation Lists) to verify TLS/SSL
certificates.
HTTPS 443(TCP) Used to synchronize with Azure AD.
For a list of URLs and IP addresses you need to open in your firewall, see Office 365 URLs and IP address ranges
and Troubleshooting Azure AD Connect connectivity.
Table 3 - Azure AD Connect and AD FS Federation Servers/WAP

server and AD FS Federation/WAP servers.
HTTP 80 (TCP) Used to download CRLs (Certificate

Revocation Lists) to verify TLS/SSL
certificates.
HTTPS 443(TCP) Used to synchronize with Azure AD.
WinRM 5985 WinRM Listener
Table 4 - WAP and Federation Servers

This table describes the ports and protocols that are required for communication between the Federation servers
and WAP servers.
HTTPS 443(TCP) Used for authentication.
Table 5 - WAP and Users

This table describes the ports and protocols that are required for communication between users and the WAP
servers.
HTTPS 443(TCP) Used for device authentication.
TCP 49443 (TCP) Used for certificate authentication.
Table 6a & 6b - Pass-through Authentication with Single Sign On (SSO)

and Password Hash Sync with Single Sign On (SSO)
The following tables describes the ports and protocols that are required for communication between the Azure AD
Connect and Azure AD.
Table 6a - Pass-through Authentication with SSO
P ROTO C O L P O RT N UM B ER DESC RIP T IO N
HTTP 80 Enable outbound HTTP traffic for

security validation such as SSL. Also
needed for the connector auto-update
capability to function properly.
HTTPS 443 Enable outbound HTTPS traffic for

operations such as enabling and
disabling of the feature, registering
connectors, downloading connector
updates, and handling all user sign-in
requests.
In addition, Azure AD Connect needs to be able to make direct IP connections to the Azure data center IP ranges.
Table 6b - Password Hash Sync with SSO
P ROTO C O L P O RT N UM B ER DESC RIP T IO N
HTTPS 443 Enable SSO registration (required only

for the SSO registration process).
In addition, Azure AD Connect needs to be able to make direct IP connections to the Azure data center IP ranges.
Again, this is only required for the SSO registration process.
Table 7a & 7b - Azure AD Connect Health agent for (AD FS/Sync) and
Azure AD
The following tables describe the endpoints, ports, and protocols that are required for communication between
Azure AD Connect Health agents and Azure AD
Table 7a - Ports and Protocols for Azure AD Connect Health agent for (AD FS/Sync) and Azure AD
This table describes the following outbound ports and protocols that are required for communication between the
Azure AD Connect Health agents and Azure AD.
HTTPS 443(TCP) Outbound
Azure Service Bus 5671 (TCP) Outbound
Azure Service Bus port 5671 is no longer required for the latest version of agent. The latest Azure AD Connect
Health agent version only required port 443.
7b - Endpoints for Azure AD Connect Health agent for (AD FS/Sync) and Azure AD
For a list of endpoints, see the Requirements section for the Azure AD Connect Health agent.
Azure AD Connect: Version release history
The Azure Active Directory (Azure AD) team regularly updates Azure AD Connect with new features and
functionality. Not all additions are applicable to all audiences.
This article is designed to help you keep track of the versions that have been released, and to understand what
the changes are in the latest version.
This table is a list of related topics:
TO P IC DETA IL S
Steps to upgrade from Azure AD Connect Different methods to upgrade from a previous version to the
latest Azure AD Connect release.
Required permissions For permissions required to apply an update, see accounts

and permissions.
Download Download Azure AD Connect.
NOTE
Releasing a new version of Azure AD Connect is a process that requires several quality control step to ensure the
operation functionality of the service, and while we go through this process the version number of a new release as well as
the release status will be updated to reflect the most recent state. While we go through this process, the version number
of the release will be shown with an "X" in the minor release number position, as in "1.3.X.0" - this indicates that the
release notes in this document are valid for all versions beginning with "1.3.". As soon as we have finalized the release
process the release version number will be updated to the most recently released version and the release status will be
updated to "Released for download and auto upgrade". Not all releases of Azure AD Connect will be made available for
auto upgrade. The release status will indicate whether a release is made available for auto upgrade or for download only. If
auto upgrade was enabled on your Azure AD Connect server then that server will automatically upgrade to the latest
version of Azure AD Connect that is released for auto upgrade. Note that not all Azure AD Connect configurations are
eligible for auto upgrade. Please follow this link to read more about auto upgrade
IMPORTANT
Starting on November 1st, 2020, we will begin implementing a deprecation process whereby versions of Azure AD
Connect that were released more than 18 months ago will be deprecated. At that time we will begin this process by
deprecating all releases of Azure AD Connect with version 1.3.20.0 (which was released on 4/24/2019) and older, and we
will proceed to evaluate the deprecation of older versions of Azure AD Connect every time a new version releases.
You need to make sure you are running a recent version of Azure AD Connect to receive an optimal support experience.
If you run a deprecated version of Azure AD Connect you may not have the latest security fixes, performance
improvements, troubleshooting and diagnostic tools and service enhancements, and if you require support we may not be
able to provide you with the level of service your organization needs.
If you have enabled Azure AD Connect for sync you will soon automatically begin receiving Health notifications that warn
you about upcoming deprecations when you are running one of the older versions.
Please refer to this article to learn more about how to upgrade Azure AD Connect to the latest version.
For version history information on deprecated versions, see Azure AD Connect version release history archive
1.5.45.0
Release status
07/29/2020: Released for download
Functional changes
This is a bug fix release. There are no functional changes in this release.
Fixed issues
Fixed an issue where admin can’t enable “Seamless Single Sign On” if AZUREADSSOACC computer account is
already present in the “Active Directory”.
Fixed an issue that caused a staging error during V2 API delta import for a conflicting object that was repaired
via the health portal.
Fixed an issue in the import/export configuration where disabled custom rule was imported as enabled.
1.5.42.0
Release status
Functional changes
This release includes a public preview of the functionality to export the configuration of an existing Azure AD
Connect server into a .JSON file which can then be used when installing a new Azure AD Connect server to
create a copy of the original server.
A detailed description of this new feature can be found in this article
Fixed issues
Fixed a bug where there would be a false warning about the local DB size on the localized builds during
upgrade.
Fixed a bug where there would be a false error in the app events for the account name/domain name swap.
Fixed an error where Azure AD Connect would fail to install on a DC, giving error "member not found".
1.5.30.0
Release status
Fixed issues
This hotfix build fixes an issue where unselected domains were getting incorrectly selected from the wizard UI if
only grandchild containers were selected.
NOTE
This version includes the new Azure AD Connect sync V2 endpoint API. This new V2 endpoint is currently in public
preview. This version or later is required to use the new V2 endpoint API. However, simply installing this version does not
enable the V2 endpoint. You will continue to use the V1 endpoint unless you enable the V2 endpoint. You need to follow
the steps under Azure AD Connect sync V2 endpoint API (public preview) in order to enable it and opt-in to the public
preview.
1.5.29.0
Release status
Fixed issues
This hotfix build fixes an issue introduced in build 1.5.20.0 where a tenant administrator with MFA was not able
to enable DSSO.
1.5.22.0
Release status
Fixed issues
This hotfix build fixes an issue in build 1.5.20.0 if you have cloned the In from AD - Group Join rule and have
not cloned the In from AD - Group Common rule.
1.5.20.0
Release status
Fixed issues
This hotfix build fixes an issue with build 1.5.18.0 if you have the Group Filtering feature enabled and use mS-
DS-ConsistencyGuid as the source anchor.
Fixed an issue in the ADSyncConfig PowerShell module, where invoking DSACLS command used in all the
Set-ADSync* Permissions cmdlets would cause one of the following errors:
GrantAclsNoInheritance : The parameter is incorrect. The command failed to complete successfully.
GrantAcls : No GUID Found for computer …
IMPORTANT
If you have cloned the In from AD - Group Join sync rule and have not cloned the In from AD - Group Common
sync rule and plan to upgrade, complete the following steps as part of the upgrade:
1. During Upgrade, uncheck the option Star t the synchronization process when configuration completes .
2. Edit the cloned join sync rule and add the following two transformations:
Set direct flow objectGUID to sourceAnchorBinary .
Set expression flow ConvertToBase64([objectGUID]) to sourceAnchor .
3. Enable the scheduler using Set-ADSyncScheduler -SyncCycleEnabled $true .
1.5.18.0
Release status
Functional changes ADSyncAutoUpgrade
Added support for the mS-DS-ConsistencyGuid feature for group objects. This allows you to move groups
between forests or reconnect groups in AD to Azure AD where the AD group objectID has changed, e.g. when
an AD server is rebuilt after a calamity. For more information see Moving groups between forests.
The mS-DS-ConsistencyGuid attribute is automatically set on all synced groups and you do not have to do
anything to enable this feature.
Removed the Get-ADSyncRunProfile because it is no longer in use.
Changed the warning you see when attempting to use an Enterprise Admin or Domain Admin account for the
AD DS connector account to provide more context.
Added a new cmdlet to remove objects from the connector space the old CSDelete.exe tool is removed, and it
is replaced with the new Remove-ADSyncCSObject cmdlet. The Remove-ADSyncCSObject cmdlet takes a
CsObject as input. This object can be retrieved by using the Get-ADSyncCSObject cmdlet.
NOTE
The old CSDelete.exe tool has been removed and replaced with the new Remove-ADSyncCSObject cmdlet
Fixed issues
Fixed a bug in the group writeback forest/OU selector on rerunning the Azure AD Connect wizard after
disabling the feature.
Introduced a new error page that will be displayed if the required DCOM registry values are missing with a
new help link. Information is also written to log files.
Fixed an issue with the creation of the Azure Active Directory synchronization account where enabling
Directory Extensions or PHS may fail because the account has not propagated across all service replicas
before attempted use.
Fixed a bug in the sync errors compression utility that was not handling surrogate characters correctly.
Fixed a bug in the auto upgrade which left the server in the scheduler suspended state.
1.4.38.0
Release status
12/9/2019: Release for download. Not available through auto-upgrade.
New features and improvements
We updated Password Hash Sync for Azure AD Domain Services to properly account for padding in Kerberos
hashes. This will provide a performance improvement during password synchronization from Azue AD to
Azure AD Domain Services.
We added support for reliable sessions between the authentication agent and service bus.
This release enforces TLS 1.2 for communication between authentication agent and cloud services.
We added a DNS cache for websocket connections between authentication agent and cloud services.
We added the ability to target specific agent from cloud to test for agent connectivity.
Fixed issues
Release 1.4.18.0 had a bug where the PowerShell cmdlet for DSSO was using the login windows credentials
instead of the admin credentials provided while running ps. As a result of which it was not possible to enable
DSSO in multiple forest through the Azure AD Connect user interface.
A fix was made to enable DSSO simultaneously in all forest through the Azure AD Connect user interface
1.4.32.0
Release status
11/08/2019: Released for download. Not available through auto-upgrade.
IMPORTANT
Due to an internal schema change in this release of Azure AD Connect, if you manage AD FS trust relationship
configuration settings using MSOnline PowerShell then you must update your MSOnline PowerShell module to version
1.1.183.57 or higher
Fixed issues
This version fixes an issue with existing Hybrid Azure AD joined devices. This release contains a new device sync
rule that corrects this issue. Note that this rule change may cause deletion of obsolete devices from Azure AD.
This is not a cause for concern, as these device objects are not used by Azure AD during Conditional Access
authorization. For some customers, the number of devices that will be deleted through this rule change can
exceed the deletion threshold. If you see the deletion of device objects in Azure AD exceeding the Export Deletion
Threshold, it is advised to allow the deletions to go through. How to allow deletes to flow when they exceed the
deletion threshold
1.4.25.0
Release status
9/28/2019: Released for auto-upgrade to select tenants. Not available for download.
This version fixes a bug where some servers that were auto-upgraded from a previous version to 1.4.18.0 and
experienced issues with Self-service password reset (SSPR) and Password Writeback.
Fixed issues
Under certain circumstances, servers that were auto upgraded to version 1.4.18.0 did not re-enable Self-service
password reset and Password Writeback after the upgrade was completed. This auto upgrade release fixes that
issue and re-enables Self-service password reset and Password Writeback.
We fixed a bug in the sync errors compression utility that was not handling surrogate characters correctly.
1.4.18.0
WARNING
We are investigating an incident where some customers are experiencing an issue with existing Hybrid Azure AD joined
devices after upgrading to this version of Azure AD Connect. We advise customers who have deployed Hybrid Azure AD
join to postpone upgrading to this version until the root cause of these issues are fully understood and mitigated. More
information will be provided as soon as possible.
IMPORTANT
With this version of Azure AD Connect some customers may see some or all of their Windows devices disappear from
Azure AD. This is not a cause for concern, as these device identities are not used by Azure AD during Conditional Access
authorization. For more information see Understanding Azure AD Connect 1.4.xx.x device disappearnce
Release status
9/25/2019: Released for auto-upgrade only.
New troubleshooting tooling helps troubleshoot "user not syncing", "group not syncing" or "group member
not syncing" scenarios.
Add support for national clouds in Azure AD Connect troubleshooting script
Customers should be informed that the deprecated WMI endpoints for MIIS_Service have now been
removed. Any WMI operations should now be done via PS cmdlets.
Security improvement by resetting constrained delegation on AZUREADSSOACC object
When adding/editing a sync rule, if there are any attributes used in the rule that are in the connector schema
but not added to the connector, the attributes automatically added to the connector. The same is true for the
object type the rule affects. If anything is added to the connector, the connector will be marked for full import
on the next sync cycle.
Using an Enterprise or Domain admin as the connector account is no longer supported in new Azure AD
Connect Deployments. Current Azure AD Connect deployments using an Enterprise or Domain admin as the
connector account will not be affected by this release.
In the Synchronization Manager a full sync is run on rule creation/edit/deletion. A popup will appear on any
rule change notifying the user if full import or full sync is going to be run.
Added mitigation steps for password errors to 'connectors > properties > connectivity' page
Added a deprecation warning for the sync service manager on the connector properties page. This warning
notifies the user that changes should be made through the Azure AD Connect wizard.
Added new error for issues with a user's password policy.
Prevent misconfiguration of group filtering by domain and OU filters. Group filtering will show an error when
the domain/OU of the entered group is already filtered out and keep the user from moving forward until the
issue is resolved.
Users can no longer create a connector for Active Directory Domain Services or Windows Azure Active
Directory in the Synchronization Service Manager UI.
Fixed accessibility of custom UI controls in the Synchronization Service Manager.
Enabled six federation management tasks for all sign-in methods in Azure AD Connect. (Previously, only the
“Update AD FS TLS/SSL certificate” task was available for all sign-ins.)
Added a warning when changing the sign-in method from federation to PHS or PTA that all Azure AD
domains and users will be converted to managed authentication.
Removed token-signing certificates from the “Reset Azure AD and AD FS trust” task and added a separate
sub-task to update these certificates.
Added a new federation management task called “Manage certificates” which has sub-tasks to update the TLS
or token-signing certificates for the AD FS farm.
Added a new federation management sub-task called “Specify primary server” which allows administrators
to specify a new primary server for the AD FS farm.
Added a new federation management task called “Manage servers” which has sub-tasks to deploy an AD FS
server, deploy a Web Application Proxy server, and specify primary server.
Added a new federation management task called “View federation configuration” that displays the current AD
FS settings. (Because of this addition, AD FS settings have been removed from the “Review your solution”
page.)
Fixed issues
Resolved sync error issue for the scenario where a user object taking over its corresponding contact object
has a self-reference (e.g. user is their own manager).
Help popups now show on keyboard focus.
For Auto upgrade, if any conflicting app is running from 6 hours, kill it and continue with upgrade.
Limit the number of attributes a customer can select to 100 per object when selecting directory extensions.
This will prevent the error from occurring during export as Azure has a maximum of 100 extension attributes
per object.
Fixed a bug to make the AD Connectivity script more robust
Fixed a bug to make Azure AD Connect install on a machine using an existing Named Pipes WCF service
more robust.
Improved diagnostics and troubleshooting around group policies that do not allow the ADSync service to
start when initially installed.
Fixed a bug where display name for a Windows computer was written incorrectly.
Fix a bug where OS type for a Windows computer was written incorrectly.
Fixed a bug where non-Windows 10 computers were syncing unexpectedly. Note that the effect of this
change is that non-Windows-10 computers that were previously synced will now be deleted. This does not
affect any features as the sync of Windows computers is only used for Hybrid Azure AD domain join, which
only works for Windows-10 devices.
Added several new (internal) cmdlets to the ADSync PowerShell module.
1.3.21.0
IMPORTANT
There is a known issue with upgrading Azure AD Connect from an earlier version to 1.3.21.0 where the O365 portal does
not reflect the updated version even though Azure AD Connect upgraded successfully.
To resolve this you need to import the AdSync module and then run the Set-ADSyncDirSyncConfiguration PowerShell
cmdlet on the Azure AD Connect server. You can use the following steps:
1. Open PowerShell in administator mode.
2. Run Import-Module "ADSync" .
3. Run Set-ADSyncDirSyncConfiguration -AnchorAttribute "" .
Release status
Fixed issues
Fixed an elevation of privilege vulnerability that exists in Microsoft Azure Active Directory Connect build
1.3.20.0. This vulnerability, under certain conditions, may allow an attacker to execute two PowerShell cmdlets
in the context of a privileged account, and perform privileged actions. This security update addresses the issue
by disabling these cmdlets. For more information see security update.
Next steps
Azure AD Connect Health: Version Release History
The Azure Active Directory team regularly updates Azure AD Connect Health with new features and functionality.
This article lists the versions and features that have been released.
NOTE
Connect Health agents are updated automatically when new version is released. Please ensure the auto-upgrade settings is
enabled from Azure portal.
Azure AD Connect Health for Sync is integrated with Azure AD Connect installation. Read more about Azure AD
Connect release history For feature feedback, vote at Connect Health User Voice channel
April 2020
Agent Update
Azure AD Connect Health agent for AD FS (version 3.1.77.0)
1. Bug fix for “Invalid Service Principal Name (SPN) for AD FS service” alert, for which the alert was
reporting incorrectly.
July 2019
Agent Update
1. Text change in TestWindowsTransport
2. Changes for AD FS RP upload
1. Add TestWindowsTransport test and remove WsTrust endpoints checks in CheckOffice365Endpoints test
2. Log OS and .NET information
3. Increase RP configuration message upload size to 1MB.
4. Bug fixes
Azure AD Connect Health agent for AD DS (version 3.1.56.0)
1. Log OS and .NET information
2. Bug fixes
May 2019
Agent Update:
1. Bug fix to distinguish between multiple sign ins that share the same client-request-id.
2. Bug fix to parse bad username/password errors on language localized servers.
April 2019
Agent Update:
1. Fix Check Duplicate SPN alert process for ADFS
March 2019
Agent Update:
1. .NET version collection
2. Improvement of performance counter collection when missing certain categories
3. Bug fix on preventing spawning of multiple Monitoring Agent instances
1. Integrate and upgrade of AD FS test scripts using ADFSToolBox
2. Implement .NET version collection
3. Improvement of performance counter collection when missing certain categories
4. Bug fix on preventing spawning of multiple Monitoring Agent instances
November 2018
New GA features:
Azure AD Connect Health for Sync - Diagnose and remediate duplicated attribute sync errors from the portal
Agent Update:
1. Transport Layer Security (TLS) protocol version 1.2 compliance and enforcement
2. Reduce Global Catalog alert noise
3. Health agent registration bug fixes
1. Transport Layer Security (TLS) protocol version 1.2 compliance and enforcement
2. Support of Test-ADFSRequestToken for localized operating system
3. Solved diagnostic agent EventHandler locking issue
4. Health agent registration bug fixes
August 2018
Azure AD Connect Health agent for Sync (version 3.1.7.0) released with Azure AD Connect version 1.1.880.0
1. Hotfix for high CPU issue of monitoring agent with .NET Framework KB releases
June 2018
New preview features:
Azure AD Connect Health for Sync - Diagnose and remediate duplicated attribute sync errors from the portal
Agent Update:
2. Test results fixes on ADFS Server 2016 secondary server
1. Hotfix for agent memory management and related alerts specifically for version 3.0.244.0
May 2018
Agent Update:
1. Agent privacy improvement
2. Bug fixes and general improvements
1. Agent Diagnostics Service and related PowerShell module improvements
Azure AD Connect Health agent for Sync (version 3.0.164.0) released with Azure AD Connect version
1.1.819.0
March 2018
Azure AD Connect Health for AD FS - Risky IP report and alert.
Agent Update:
1. Agent availability improvements
December 2017
Agent Update:
2. Added new agent troubleshooting commands
1. Added new agent troubleshooting commands
October 2017
Agent Update:
Fixed a version compatibility issue between Azure AD Connect and Azure AD Connect Health Agent for Sync.
This issue affects customers who are performing Azure AD Connect in-place upgrade to version 1.1.647.0, but
currently has Health Agent version 3.0.127.0. After the upgrade, the Health Agent can no longer send health
data about Azure AD Connect Synchronization Service to Azure AD Health Service. With this fix, Health Agent
version 3.0.129.0 is installed during Azure AD Connect in-place upgrade. Health Agent version 3.0.129.0 does
not have compatibility issue with Azure AD Connect version 1.1.649.0.
July 2017
Agent Update:
2. Sovereign cloud support
2. Sovereign cloud support
1. Support for Microsoft Azure Government Cloud and Microsoft Cloud Germany
April 2017
Agent Update:
1. Performance counters upload improvements
October 2016
Agent Update:
Improvements in detecting client IP addresses in authentication requests
Bug Fixes related to Alerts
Bug fixes related to Alerts.
Provide the required data for the Synchronization Error Reports
Bug fixes related to Alerts
Synchronization Error Reports for Azure AD Connect
New features:
Azure AD Connect Health for AD FS - IP address field is available in the report about top 50 users with bad
username/password.
July 2016
Azure AD Connect Health for AD DS.
January 2016
Agent Update:
New features:
Test Connectivity Tool for Azure AD Connect Health Agents
November 2015
New features:
Support for Azure role-based access control (Azure RBAC)
Azure AD Connect Health for sync.
Fixed issues:
Bug fixes for errors seen during agent registrations.
September 2015
New features:
Wrong Username password report for AD FS
Support to configure Unauthenticated HTTP Proxy
Support to configure agent on Server core
Improvements to Alerts for AD FS
Improvements in Azure AD Connect Health Agent for AD FS for connectivity and data upload.
Fixed issues:
Bug fixes in Usage Insights for AD FS Error types.
June 2015
Initial release of Azure AD Connect Health for AD FS and AD FS Proxy.
New features:
Alerts for monitoring AD FS and AD FS Proxy servers with email notifications.
Easy access to AD FS topology and patterns in AD FS Performance Counters.
Trend in successful token requests on AD FS servers grouped by Applications, Authentication Methods,
Request Network Location etc.
Trends in failed request on AD FS servers grouped by Applications, Error Types etc.
Simpler Agent Deployment using Azure AD Global Admin credentials.
Next steps
Learn more about Monitor your on-premises identity infrastructure and synchronization services in the cloud.
Azure AD Pass-through Authentication agent: Version
release history
The agents installed on-premises that enable Pass-through Authentication are updated regularly to provide new
capabilities. This article lists the versions and features that are added when new functionality is introduced. Pass-
through authentication agents are updated automatically when a new version is released.
Here are related topics:
User sign-in with Azure AD Pass-through Authentication
Azure AD Pass-through Authentication agent installation
1.5.1742.0
Release Status:
Added support for targeting cloud environments upon installation. The bundle can be pinned to a given cloud
environment.
1.5.1007.0
Release status
Added support for Service Bus reliable channels to add another layer of connection resiliency for outbound
connections
Enforce TLS 1.2 during agent registration
1.5.643.0
Release status
Web socket connection support
Set TLS 1.2 as the default protocol for the agent
1.5.405.0
Release status
Fixed issues
Fixed a bug that caused some memory leaks in the agent.
Updated the Azure Service Bus version, which includes a bug fix for connector timeout issues.
1.5.405.0
Release status
Added support for websocket based connections between the agent and Azure AD services to improve
connection resiliency
1.5.402.0
Release status
Fixed issues
Fixed bugs related to the DNS cache for default proxy scenarios
1.5.389.0
Release status
Added DNS cache functionality for outbound connections to add resiliency from DNS failures
1.5.261.0
Release status
GA version of the Azure AD Pass-through authentication agent
Next steps
User sign-in with Azure Active Directory Pass-through Authentication
Accounts used for Azure AD Connect
Azure AD Connect uses 3 accounts in order to synchronize information from on-premises or Windows Server
Active Directory to Azure Active Directory. These accounts are:
AD DS Connector account : used to read/write information to Windows Server Active Directory
ADSync ser vice account : used to run the synchronization service and access the SQL database
Azure AD Connector account : used to write information to Azure AD
In addition to these three accounts used to run Azure AD Connect, you will also need the following additional
accounts to install Azure AD Connect. These are:
Local Administrator account : The administrator who is installing Azure AD Connect and who has local
Administrator permissions on the machine.
AD DS Enterprise Administrator account : Optionally used to create the “AD DS Connector account”
above.
Azure AD Global Administrator account : used to create the Azure AD Connector account and
configure Azure AD.
SQL SA account (optional) : used to create the ADSync database when using the full version of SQL
Server. This SQL Server may be local or remote to the Azure AD Connect installation. This account may be
the same account as the Enterprise Administrator. 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 information on this see Install Azure AD Connect using SQL delegated administrator
permissions
IMPORTANT
As of build 1.4.###.# it is no longer supported to use an enterprise admin or a domain admin account as the AD DS
Connector account. If you attempt to enter an account that is an enterprise admin or domain admin when specifying use
existing account , you will receive an error.
NOTE
It is supported to manage the administrative accounts used in Azure AD Connect from an ESAE Administrative Forest (also
know as "Red forest"). Dedicated administrative forests allow organizations to host administrative accounts, workstations,
and groups in an environment that has stronger security controls than the production environment. To learn more about
dedicated administrative forests please refer to ESAE Administrative Forest Design Approach.
NOTE
The Global Administrator role is not required after the initial setup and the only required account will be the Director y
Synchronization Accounts role account. That does not necessarily mean that you will want to just remove the account
with the Global Administrator role. It is better to change the role to a less powerful role, as totally removing the account
may introduce issues if you ever need to re-run the wizard again. By reducing the privilege of the role you can always re-
elevate the privileges if you have to utilize the Azure AD Connect wizard again.
Installing Azure AD Connect

The Azure AD Connect installation wizard offers two different paths:
In Express Settings, the wizard requires more privileges. This is so that it can set up your configuration easily,
without requiring you to create users or configure permissions.
In Custom Settings, the wizard offers you more choices and options. However, there are some situations in
which you need to ensure you have the correct permissions yourself.
Express settings installation

In Express settings, the installation wizard asks for the following:
AD DS Enterprise Administrator credentials
Azure AD Global Administrator credentials
AD DS Enterprise Admin credentials
The AD DS Enterprise Admin account is used to configure your on-premises Active Directory. These credentials
are only used during the installation and are not used after the installation has completed. The Enterprise Admin,
not the Domain Admin should make sure the permissions in Active Directory can be set in all domains.
If you are upgrading from DirSync, the AD DS Enterprise Admins credentials are used to reset the password for
the account used by DirSync. You also need Azure AD Global Administrator credentials.
Azure AD Global Admin credentials
These credentials are only used during the installation and are not used after the installation has completed. It is
used to create the Azure AD Connector account used for synchronizing changes to Azure AD. The account also
enables sync as a feature in Azure AD.
AD DS Connector account required permissions for express settings
The AD DS Connector account is created for reading and writing to Windows Server AD and has the following
permissions when created by express settings:
P ERM ISSIO N USED F O R
Replicate Directory Changes Password hash sync

Read/Write all properties User Import and Exchange hybrid
Read/Write all properties iNetOrgPerson Import and Exchange hybrid
Read/Write all properties Group Import and Exchange hybrid
Read/Write all properties Contact Import and Exchange hybrid
Reset password Preparation for enabling password writeback
Express installation wizard summary
The following is a summary of the express installation wizard pages, the credentials collected, and what they are
used for.
W IZ A RD PA GE C REDEN T IA L S C O L L EC T ED P ERM ISSIO N S REQ UIRED USED F O R
N/A User running the installation Administrator of the local Creates the ADSync
wizard server service account that is used
as to run the
synchronization service.
Connect to Azure AD Azure AD directory Global administrator role in Enabling sync in the
credentials Azure AD Azure AD directory.
Creation of the Azure AD
Connector account that is
used for on-going sync
operations in Azure AD.
Connect to AD DS On-premises Active Member of the Enterprise Creates the AD DS

Directory credentials Admins (EA) group in Active Connector account in Active
Directory Directory and grants
permissions to it. This
created account is used to
read and write directory
information during
synchronization.
Custom installation settings

With the custom settings installation, the wizard offers you more choices and options.
Custom installation wizard summary
The following is a summary of the custom installation wizard pages, the credentials collected, and what they are
used for.

N/A User running the installation Administrator of the local By default, creates the local
wizard server account that is used as the
If using a full SQL Server, sync engine service account.
the user must be System The account is only created
Administrator (SA) in SQL when the admin does not
specify a particular account.
Install synchronization AD or local user account User, permissions are If the admin specifies an
services, Service account credentials granted by the installation account, this account is used
option wizard as the service account for
the sync service.
Connect to Azure AD Azure AD directory Global administrator role in Enabling sync in the
credentials Azure AD Azure AD directory.
Creation of the Azure AD
Connector account that is
used for on-going sync
operations in Azure AD.
Connect your directories On-premises Active The permissions depend on This account is used to read
Directory credentials for which features you enable and write directory
each forest that is and can be found in Create information during
connected to Azure AD the AD DS Connector synchronization.
account
AD FS Servers For each server in the list, Domain Administrator Installation and
the wizard collects configuration of the AD FS
credentials when the sign-in server role.
credentials of the user
running the wizard are
insufficient to connect
Web application proxy For each server in the list, Local admin on the target Installation and
servers the wizard collects machine configuration of WAP server
credentials when the sign-in role.
credentials of the user
running the wizard are
insufficient to connect
Proxy trust credentials Federation service trust Domain account that is a Initial enrollment of FS-WAP
credentials (the credentials local administrator of the trust certificate.
the proxy uses to enroll for AD FS server
a trust certificate from the
FS
AD FS Service Account AD user account credentials Domain user The Azure AD user account
page, "Use a domain user whose credentials are
account option" provided is used as the
sign-in account of the AD FS
service.
Create the AD DS Connector account

IMPORTANT
A new PowerShell Module named ADSyncConfig.psm1 was introduced with build 1.1.880.0 (released in August 2018) that
includes a collection of cmdlets to help you configure the correct Active Directory permissions for the Azure AD DS
Connector account.
For more information see Azure AD Connect: Configure AD DS Connector Account Permission
The account you specify on the Connect your directories page must be present in Active Directory prior to
installation. Azure AD Connect version 1.1.524.0 and later has the option to let the Azure AD Connect wizard
create the AD DS Connector account used to connect to Active Directory.
It must also have the required permissions granted. The installation wizard does not verify the permissions and
any issues are only found during synchronization.
Which permissions you require depends on the optional features you enable. If you have multiple domains, the
permissions must be granted for all domains in the forest. If you do not enable any of these features, the default
Domain User permissions are sufficient.
F EAT URE P ERM ISSIO N S
ms-DS-ConsistencyGuid feature Write permissions to the ms-DS-ConsistencyGuid attribute

documented in Design Concepts - Using ms-DS-
Password hash sync Replicate Directory Changes

Exchange hybrid deployment Write permissions to the attributes documented in Exchange

hybrid writeback for users, groups, and contacts.
Exchange Mail Public Folder Read permissions to the attributes documented in Exchange
Mail Public Folder for public folders.
Password writeback Write permissions to the attributes documented in Getting

started with password management for users.
Device writeback Permissions granted with a PowerShell script as described in

device writeback.
Group writeback Allows you to writeback Office 365 Groups to a forest with
Exchange installed.
Upgrade
When you upgrade from one version of Azure AD Connect to a new release, you need the following permissions:
IMPORTANT
Starting with build 1.1.484, Azure AD Connect introduced a regression bug which requires sysadmin permissions to
upgrade the SQL database. This bug is corrected in build 1.1.647. If you are upgrading to this build, you will need sysadmin
permissions. Dbo permissions are not sufficient. If you attempt to upgrade Azure AD Connect without having sysadmin
permissions, the upgrade will fail and Azure AD Connect will no longer function correctly afterwards. Microsoft is aware of
this and is working to correct this.
P RIN C IPA L P ERM ISSIO N S REQ UIRED USED F O R
User running the installation wizard Administrator of the local server Update binaries.
User running the installation wizard Member of ADSyncAdmins Make changes to Sync Rules and other
configuration.
User running the installation wizard If you use a full SQL server: DBO (or Make database level changes, such as
similar) of the sync engine database updating tables with new columns.
More about the created accounts

AD DS Connector account
If you use express settings, then an account is created in Active Directory that is used for synchronization. The
created account is located in the forest root domain in the Users container and has its name prefixed with
MSOL_ . The account is created with a long complex password that does not expire. If you have a password policy
in your domain, make sure long and complex passwords would be allowed for this account.
If you use custom settings, then you are responsible for creating the account before you start the installation. See
Create the AD DS Connector account.
ADSync service account
The sync service can run under different accounts. It can run under a Vir tual Ser vice Account (VSA), a Group
Managed Ser vice Account (gMSA/sMSA), or a regular user account. The supported options were changed with
the 2017 April release of Connect when you do a fresh installation. If you upgrade from an earlier release of
Azure AD Connect, these additional options are not available.
T Y P E O F A C C O UN T IN STA L L AT IO N O P T IO N DESC RIP T IO N
Virtual Service Account Express and custom, 2017 April and This is the option used for all express
later installations, except for installations on
a Domain Controller. For custom, it is
the default option unless another
option is used.
Group Managed Service Account Custom, 2017 April and later If you use a remote SQL server, then
we recommend to use a group
managed service account.
User account Express and custom, 2017 April and A user account prefixed with AAD_ is
later only created during installation when
installed on Windows Server 2008 and
when installed on a Domain Controller.
User account Express and custom, 2017 March and A local account prefixed with AAD_ is
earlier created during installation. When using
custom installation, another account
can be specified.
If you use Connect with a build from 2017 March or earlier, then you should not reset the password on the
service account since Windows destroys the encryption keys for security reasons. You cannot change the account
to any other account without reinstalling Azure AD Connect. If you upgrade to a build from 2017 April or later,
then it is supported to change the password on the service account but you cannot change the account used.
IMPORTANT
You can only set the service account on first installation. It is not supported to change the service account after the
installation has completed.
This is a table of the default, recommended, and supported options for the sync service account.
Legend:
Bold indicates the default option and in most cases the recommended option.
Italic indicates the recommended option when it is not the default option.
2008 - Default option when installed on Windows Server 2008
Non-bold - Supported option
Local account - Local user account on the server
Domain account - Domain user account
sMSA - standalone Managed Service account
gMSA - group Managed Service account
LO C A L DB LO C A L DB / LO C A L SQ L REM OT E SQ L
EXP RESS C USTO M C USTO M
domain-joined machine VSA VSA gMSA

Local account (2008) Local account (2008) Domain account
Local account
Domain account
sMSA,gMSA
Domain Controller Domain account gMSA gMSA

Domain account Domain account
sMSA
Virtual service account

A virtual service account is a special type of account that does not have a password and is managed by Windows.
The VSA is intended to be used with scenarios where the sync engine and SQL are on the same server. If you use
remote SQL, then we recommend to use a Group Managed Service Account instead.
This feature requires Windows Server 2008 R2 or later. If you install Azure AD Connect on Windows Server 2008,
then the installation falls back to using a user account instead.
Group managed service account
If you use a remote SQL server, then we recommend to using a group managed ser vice account . For more
information on how to prepare your Active Directory for Group Managed Service account, see Group Managed
Service Accounts Overview.
To use this option, on the Install required components page, select Use an existing ser vice account , and select
Managed Ser vice Account .
It is also supported to use a standalone managed service account. However, these can only be used on the local
machine and there is no benefit to use them over the default virtual service account.
This feature requires Windows Server 2012 or later. If you need to use an older operating system and use remote
SQL, then you must use a user account.
User account
A local service account is created by the installation wizard (unless you specify the account to use in custom
settings). The account is prefixed AAD_ and used for the actual sync service to run as. If you install Azure AD
Connect on a Domain Controller, the account is created in the domain. The AAD_ service account must be located
in the domain if:
you use a remote server running SQL server
you use a proxy that requires authentication
The account is created with a long complex password that does not expire.
This account is used to store the passwords for the other accounts in a secure way. These other accounts
passwords are stored encrypted in the database. The private keys for the encryption keys are protected with the
cryptographic services secret-key encryption using Windows Data Protection API (DPAPI).
If you use a full SQL Server, then the service account is the DBO of the created database for the sync engine. The
service will not function as intended with any other permissions. A SQL login is also created.
The account is also granted permissions to files, registry keys, and other objects related to the Sync Engine.
Azure AD Connector account
An account in Azure AD is created for the sync service's use. This account can be identified by its display name.
The name of the server the account is used on can be identified in the second part of the user name. In the
picture, the server name is DC1. If you have staging servers, each server has its own account.
The account is created with a long complex password that does not expire. It is granted a special role Director y
Synchronization Accounts that has only permissions to perform directory synchronization tasks. This special
built-in role cannot be granted outside of the Azure AD Connect wizard. The Azure portal shows this account with
the role User .
There is a limit of 20 sync service accounts in Azure AD. To get the list of existing Azure AD service accounts in
your Azure AD, run the following Azure AD PowerShell cmdlet:
Get-AzureADDirectoryRole | where {$_.DisplayName -eq "Directory Synchronization Accounts"} | Get-
AzureADDirectoryRoleMember
To remove unused Azure AD service accounts, run the following Azure AD PowerShell cmdlet:
Remove-AzureADUser -ObjectId <ObjectId-of-the-account-you-wish-to-remove>
NOTE
Before you can use the above PowerShell commands you will need to install the Azure Active Directory PowerShell for
Graph module and connect to your instance of Azure AD using Connect-AzureAD
For additional information on how to manage or reset the password for the Azure AD Connector account see
Manage the Azure AD Connect account
Related documentation
If you did not read the documentation on Integrating your on-premises identities with Azure Active Directory, the
following table provides links to related topics.
TO P IC L IN K
Download Azure AD Connect Download Azure AD Connect
Install using Express settings Express installation of Azure AD Connect
Install using Customized settings Custom installation of Azure AD Connect
After installation Verify the installation and assign licenses
Next steps
Azure Active Directory Connect FAQ
General installation
Q: How can I harden my Azure AD Connect ser ver to decrease the security attack surface?
Microsoft recommends hardening your Azure AD Connect server to decrease the security attack surface for this
critical component of your IT environment. Following the recommendations below will decrease the security risks
to your organization.
Deploy Azure AD Connect on a domain joined server and restrict administrative access to domain
administrators or other tightly controlled security groups
To learn more, see:
Securing administrators groups
Securing built-in administrator accounts
Security improvement and sustainment by reducing attack surfaces
Reducing the Active Directory attack surface
Q: Will installation work if the Azure Active Director y (Azure AD) Global Admin has two-factor
authentication (2FA) enabled?
As of the February 2016 builds, this scenario is supported.
Q: Is there a way to install Azure AD Connect unattended?
Azure AD Connect installation is supported only when you use the installation wizard. An unattended, silent
installation is not supported.
Q: I have a forest where one domain cannot be contacted. How do I install Azure AD Connect?
As of the February 2016 builds, this scenario is supported.
Q: Does the Azure Active Director y Domain Ser vices (Azure AD DS) health agent work on ser ver
core?
Yes. After you install the agent, you can complete the registration process by using the following PowerShell cmdlet:
Register-AzureADConnectHealthADDSAgent -Credentials $cred
Q: Does Azure AD Connect suppor t syncing from two domains to an Azure AD?
Yes, this scenario is supported. Refer to Multiple Domains.
Q: Can you have multiple connectors for the same Active Director y domain in Azure AD Connect?
No, multiple connectors for the same AD domain are not supported.
Q: Can I move the Azure AD Connect database from the local database to a remote SQL Ser ver
instance?
Yes, the following steps provide general guidance on how to do this. We are currently working on a more detailed
document.
1. Back up the LocalDB ADSync database. The simplest way to do this is to use SQL Server Management Studio
installed on the same machine as Azure AD Connect. Connect to (LocalDb).\ADSync, and then back up the
ADSync database.
2. Restore the ADSync database to your remote SQL Server instance.
3. Install Azure AD Connect against the existing remote SQL database. The article demonstrates how to migrate
to using a local SQL database. If you are migrating to using a remote SQL database, in step 5 of the process
you must also enter an existing service account that the Windows Sync service will run as. This sync engine
service account is described here:
Use an existing ser vice account : By default, Azure AD Connect uses a virtual service account for the
synchronization services to use. If you use a remote SQL Server instance or use a proxy that requires
authentication, use a managed service account or a service account in the domain, and know the password.
In those cases, enter the account to use. Make sure that users who are running the installation are system
administrators in SQL so that login credentials for the service account can be created. For more information,
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 by using SQL delegated administrator permissions.
To keep things simple, we recommend that users who install Azure AD Connect be system administrators in SQL.
However, with recent builds you can now use delegated SQL administrators, as described in Install Azure AD
Connect using SQL delegated administrator permissions.
Q: What are some of the best practices from the field?
The following is an informational document that presents some of the best practices that engineering, support and
our consultants have developed over the years. This is presented in a bullet list that can be quickly referenced.
Although this list attempts to be comprehensive, there may be additional best practices that might not have made it
on the list yet.
If using Full SQL then it should remain local vs. remote
Fewer hops
Easier to troubleshoot
Less complexity
Need to designate resources to SQL and allow overhead for Azure AD Connect and OS
Bypass Proxy if at all possible, if you are unable to bypass the proxy then you need to ensure that the timeout
value is greater than 5 minutes.
If proxy is required then you must add the proxy to the machine.config file
Be aware of local SQL jobs and maintenance and how they will impact Azure AD Connect - particularly re-
indexing
Ensure than DNS can resolve externally
Ensure that server specifications are per recommendation whether you are using physical or virtual servers
Ensure that if you are using a virtual server that resources required are dedicated
Ensure that you have the disk and disk configuration meet Best Practices for SQL Server
Install and configure Azure AD Connect Health for monitoring
Use the Delete Threshold that is built into Azure AD Connect.
Carefully review release updates to be prepared for all changes and new attributes that may be added
Backup everything
Backup Keys
Backup Synchronization Rules
Backup Server Configuration
Backup SQL Database
Ensure that there are no 3rd party backup agents that are backing up SQL without the SQL VSS Writer
(common in virtual servers with 3rd party snapshots)
Limit the amount of custom synchronization rules that are used as they add complexity
Treat Azure AD Connect Servers as Tier 0 Servers
Be leery of modifying cloud synchronization rules without great understanding of the impact and the right
business drivers
Make sure that the correct URL's and Firewall ports are open for support of Azure AD Connect and Azure AD
Connect Health
Leverage the cloud filtered attribute to troubleshoot and prevent phantom objects
With the Staging Server ensure that you are using the Azure AD Connect Configuration Documenter for
consistency between servers
Staging Servers should be in separate datacenters (Physical Locations
Staging servers are not meant to be a High Availability solution, but you can have multiple staging servers
Introducing a "Lag" Staging Servers could mitigate some potential downtime in case of error
Test and Validate all upgrades on the Staging Server first
Always validate exports before switching over to the staging server. Leverage the staging server for Full Imports
and Full Synchronizations to reduce business impact
Keep version consistency between Azure AD Connect Servers as much as possible
Q: Can I allow Azure AD Connect to create the Azure AD Connector account on Workgroup machine?
No. In order to allow Azure AD Connect to auto-create the Azure AD Connector account, the machine must be
domain-joined.
Network
Q: I have a firewall, network device, or something else that limits the time that connections can stay
open on my network . What should my client-side timeout threshold be when I use Azure AD
Connect?
All networking software, physical devices, or anything else that limits the maximum time that connections can
remain open should use a threshold of at least five minutes (300 seconds) for connectivity between the server
where the Azure AD Connect client is installed and Azure Active Directory. This recommendation also applies to all
previously released Microsoft Identity synchronization tools.
Q: Are single label domains (SLDs) suppor ted?
While we strongly recommend against this network configuration (see article), using Azure AD Connect sync with a
single label domain is supported, as long as the network configuration for the single level domain is functioning
correctly.
Q: Are Forests with disjoint AD domains suppor ted?
No, Azure AD Connect does not support on-premises forests that contain disjoint namespaces.
Q: Are "dotted" NetBIOS names suppor ted?
No, Azure AD Connect does not support on-premises forests or domains where the NetBIOS name contains a dot
(.).
Q: Is pure IPv6 environment suppor ted?
No, Azure AD Connect does not support a pure IPv6 environment.
Q:I have a multi-forest environment and the network between the two forests is using NAT (Network
Address Translation). Is using Azure AD Connect between these two forests suppor ted?
No, using Azure AD Connect over NAT is not supported.
Federation
Q: What do I do if I receive an email that asks me to renew my Office 365 cer tificate?
For guidance about renewing the certificate, see renew certificates.
Q: I have "Automatically update relying par ty" set for the Office 365 relying par ty. Do I have to take
any action when my token signing cer tificate automatically rolls over?
Use the guidance that's outlined in the article renew certificates.
Environment
Q: Is it suppor ted to rename the ser ver after Azure AD Connect has been installed?
No. Changing the server name renders the sync engine unable to connect to the SQL database instance, and the
service cannot start.
Q: Are Next Generation Cr yptographic (NGC) sync rules suppor ted on a FIPS-enabled machine?
No. They are not supported.
Q. If I disabled a synced device (for example: HAADJ) in the Azure por tal, why it is re-enabled?
Synced devices might be authored or mastered on premises. If a synced device is enabled on premises, it might be
re-enabled in the Azure portal even if was previously disabled by an administrator. To disable a synced device, use
the on-premises Active Directory to disable the computer account.
Q. If I block user sign-in at the Office 365 or Azure AD por tal for synced users, why it is unblocked
upon signing in again?
Synced users might be authored or mastered on premises. If the account is enabled on premises, it can unblock the
sign-in block placed by administrator.
Identity data
Q: Why doesn't the userPrincipalName (UPN) attribute in Azure AD match the on-premises UPN?
For information, see these articles:
Usernames in Office 365, Azure, or Intune don't match the on-premises UPN or alternate login ID
Changes aren't synced by the Azure Active Directory sync tool after you change the UPN of a user account to
use a different federated domain
You can also configure Azure AD to allow the sync engine to update the UPN, as described in Azure AD Connect
sync service features.
Q: Is it suppor ted to soft-match an on-premises Azure AD group or contact object with an existing
Azure AD group or contact object?
Yes, this soft match is based on the proxyAddress. Soft matching is not supported for groups that are not mail-
enabled.
Q: Is it suppor ted to manually set the ImmutableId attribute on an existing Azure AD group or
contact object to hard-match it to an on-premises Azure AD group or contact object?
No, manually setting the ImmutableId attribute on an existing Azure AD group or contact object to hard-match it is
currently not supported.
Custom configuration
Q: Where are the PowerShell cmdlets for Azure AD Connect documented?
With the exception of the cmdlets that are documented on this site, other PowerShell cmdlets found in Azure AD
Connect are not supported for customer use.
Q: Can I use the "Ser ver expor t/ser ver impor t" option that's found in Synchronization Ser vice
Manager to move the configuration between ser vers?
No. This option does not retrieve all configuration settings, and it should not be used. Instead, use the wizard to
create the base configuration on the second server, and use the sync rule editor to generate PowerShell scripts to
move any custom rule between servers. For more information, see Swing migration.
Q: Can passwords be cached for the Azure sign-in page, and can this caching be prevented because it
contains a password input element with the autocomplete = "false" attribute?
Currently, modifying the HTML attributes of the Password field, including the autocomplete tag, is not supported.
We are currently working on a feature that allows for custom JavaScript, which lets you add any attribute to the
Password field.
Q: The Azure sign-in page displays the usernames of users who have previously signed in
successfully. Can this behavior be turned off ?
Currently, modifying the HTML attributes of the Password input field, including the autocomplete tag, is not
supported. We are currently working on a feature that allows for custom JavaScript, which lets you add any
attribute to the Password field.
Q: Is there a way to prevent concurrent sessions?
No.
Auto upgrade
Q: What are the advantages and consequences of using auto upgrade?
We are advising all customers to enable auto upgrade for their Azure AD Connect installation. The benefit is that
you always receive the latest patches, including security updates for vulnerabilities that have been found in Azure
AD Connect. The upgrade process is painless and happens automatically as soon as a new version is available.
Many thousands of Azure AD Connect customers use auto upgrade with every new release.
The auto-upgrade process always first establishes whether an installation is eligible for auto upgrade. If it is eligible,
the upgrade is performed and tested. The process also includes looking for custom changes to rules and specific
environmental factors. If the tests show that an upgrade is unsuccessful, the previous version is automatically
restored.
Depending on the size of the environment, the process can take a couple of hours. While the upgrade is in progress,
no sync between Windows Server Active Directory and Azure AD happens.
Q: I received an email telling me that my auto upgrade no longer works and I need to install a new
version. Why do I need to do this?
Last year, we released a version of Azure AD Connect that, under certain circumstances, might have disabled the
auto-upgrade feature on your server. We have fixed the issue in Azure AD Connect version 1.1.750.0. If you have
been affected by the issue, you can mitigate it by running a PowerShell script to repair it or by manually upgrading
to the latest version of Azure AD Connect.
To run the PowerShell script, download the script and run it on your Azure AD Connect server in an administrative
PowerShell window. To learn how to run the script, view this short video.
To manually upgrade, you must download and run the latest version of the AADConnect.msi file.
If your current version is older than 1.1.750.0, download and upgrade to the latest version.
If your Azure AD Connect version is 1.1.750.0 or later, no further action is required. You’re already using the
version that contains the auto-upgrade fix.
Q: I received an email telling me to upgrade to the latest version to re-enable auto upgrade. I am
using version 1.1.654.0. Do I need to upgrade?
Yes, you need to upgrade to version 1.1.750.0 or later to re-enable auto upgrade. Download and upgrade to the
latest version.
Q: I received an email telling me to upgrade to the latest version to re-enable auto upgrade. If I have
used PowerShell to enable auto upgrade, do I still need to install the latest version?
Yes, you still need to upgrade to version 1.1.750.0 or later. Enabling the auto-upgrade service with PowerShell does
not mitigate the auto-upgrade issue found in versions before 1.1.750.0.
Q: I want to upgrade to a newer version but I’m not sure who installed Azure AD Connect, and we do
not have the username and password. Do we need this? You don’t need to know the username and
password that was initially used to upgrade Azure AD Connect. Use any Azure AD account that has the Global
Administrator role.
Q: How can I find which version of Azure AD Connect I am using?
To verify which version of Azure AD Connect is installed on your server, go to Control Panel and look up the
installed version of Microsoft Azure AD Connect by selecting Programs > Programs and Features , as shown
here:
Q: How do I upgrade to the latest version of Azure AD Connect?

To learn how to upgrade to the latest version, see Azure AD Connect: Upgrade from a previous version to the latest.
Q: We already upgraded to the latest version of Azure AD Connect last year. Do we need to upgrade
again?
The Azure AD Connect team makes frequent updates to the service. To benefit from bug fixes and security updates
as well as new features, it is important to keep your server up to date with the latest version. If you enable auto
upgrade, your software version is updated automatically. To find the version release history of Azure AD Connect,
see Azure AD Connect: Version release history.
Q: How long does it take to perform the upgrade, and what is the impact on my users?
The time needed to upgrade depends on your tenant size. For larger organizations, it might be best to perform the
upgrade in the evening or weekend. During the upgrade, no synchronization activity takes place.
Q: I believe I upgraded to Azure AD Connect, but the Office por tal still mentions DirSync. Why is
this?
The Office team is working to get the Office portal updates to reflect the current product name. It does not reflect
which sync tool you are using.
Q: My auto-upgrade status says, “Suspended." Why is it suspended? Should I enable it?
A bug was introduced in a previous version that, under certain circumstances, leaves the auto-upgrade status set to
“Suspended.” Manually enabling it is technically possible but would require several complex steps. The best thing
you can do is install the latest version of Azure AD Connect.
Q: My company has strict change-management requirements, and I want to control when it’s pushed
out. Can I control when auto upgrade is launched?
No, there is no such feature today. The feature is being evaluated for a future release.
Q: Will I get an email if the auto upgrade failed? How will I know that it was successful?
You will not be notified of the result of the upgrade. The feature is being evaluated for a future release.
Q: Do you publish a timeline for when you plan to push out auto upgrades?
Auto upgrade is the first step in the release process of a newer version. Whenever there is a new release, upgrades
are pushed automatically. Newer versions of Azure AD Connect are pre-announced in the Azure AD Roadmap.
Q: Does auto upgrade also upgrade Azure AD Connect Health?
Yes, auto upgrade also upgrades Azure AD Connect Health.
Q: Do you also auto-upgrade Azure AD Connect ser vers in staging mode?
Yes, you can auto-upgrade an Azure AD Connect server that is in staging mode.
Q: If auto upgrade fails and my Azure AD Connect ser ver does not star t, what should I do?
In rare cases, the Azure AD Connect service does not start after you perform the upgrade. In these cases, rebooting
the server usually fixes the issue. If the Azure AD Connect service still does not start, open a support ticket. For
more information, see Create a service request to contact Office 365 support.
Q: I’m not sure what the risks are when I upgrade to a newer version of Azure AD Connect. Can you
call me to help me with the upgrade?
If you need help upgrading to a newer version of Azure AD Connect, open a support ticket at Create a service
request to contact Office 365 support.
Operational best practice

Below are some best practices you should implement when syncing between Windows Server Active Directory and
Apply Multi-Factor Authentication for all synced accounts Azure Multi-Factor Authentication helps
safeguard access to data and applications while maintaining simplicity for users. It provides additional security by
requiring a second form of authentication and delivers strong authentication via a range of easy to use
authentication methods. Users may or may not be challenged for MFA based on configuration decisions that an
administrator makes. You can read more about MFA here:
https://www.microsoft.com/security/business/identity/mfa?rtc=1
Follow the Azure AD Connect ser ver security guidelines The Azure AD Connect server contains critical
identity data and should be treated as a Tier 0 component as documented in the Active Directory administrative tier
model. Please also refer to our guidelines for securing your AADConnect server.
Enable PHS for leaked credentials detection Password Hash Sync also enables leaked credential detection for
your hybrid accounts. Microsoft works alongside dark web researchers and law enforcement agencies to find
publicly available username/password pairs. If any of these pairs match those of your users, the associated account
is moved to high risk.
Troubleshooting
Q: How can I get help with Azure AD Connect?
Search the Microsoft Knowledge Base (KB)
Search the KB for technical solutions to common break-fix issues about support for Azure AD Connect.
Microsoft Q&A question page for Azure Active Directory
Search for technical questions and answers or ask your own questions by going to the Azure AD community.
Get support for Azure AD
Q: Why am I seeing Events 6311 and 6401 occur after Sync Step Errors?
The events 6311 - The ser ver encountered an unexpected error while performing a callback and 6401 -
The management agent controller encountered an unexpected error - are always logged after a
synchronization step error. To resolve these errors, you need to clean up the synchronization step errors. For more
information, see Troubleshooting errors during synchronization and Troubleshoot object synchronization with
Azure AD Connect Health frequently asked
questions
This article includes answers to frequently asked questions (FAQs) about Azure Active Directory (Azure AD)
Connect Health. These FAQs cover questions about how to use the service, which includes the billing model,
capabilities, limitations, and support.
General questions
Q: I manage multiple Azure AD directories. How do I switch to the one that has Azure Active
Director y Premium?
To switch between different Azure AD tenants, select the currently signed-in User Name on the upper-right
corner, and then choose the appropriate account. If the account is not listed here, select Sign out , and then use
the global admin credentials of the directory that has Azure Active Directory Premium enabled to sign in.
Q: What version of identity roles are suppor ted by Azure AD Connect Health?
The following table lists the roles and supported operating system versions.
RO L E O P ERAT IN G SY ST EM / VERSIO N
Active Directory Federation Services (AD FS) Windows Server 2012

Windows Server 2016
Windows Server 2019
Azure AD Connect Version 1.0.9125 or higher
Active Directory Domain Services (AD DS) Windows Server 2012

Windows Server 2016
Windows Server 2019
Windows Server Core installations are not supported.

Note that the features provided by the service may differ based on the role and the operating system. In other
words, all the features may not be available for all operating system versions. See the feature descriptions for
details.
Q: How many licenses do I need to monitor my infrastructure?
The first Connect Health Agent requires at least one Azure AD Premium license.
Each additional registered agent requires 25 additional Azure AD Premium licenses.
Agent count is equivalent to the total number of agents that are registered across all monitored roles (AD FS,
Azure AD Connect, and/or AD DS).
AAD Connect Health licensing does not require you to assign the license to specific users. You only need to
have the requisite number of valid licenses.
Licensing information is also found on the Azure AD Pricing page.
Example:
EXA M P L E M O N ITO RIN G

REGIST ERED A GEN T S L IC EN SES N EEDED C O N F IGURAT IO N
1 1 1 Azure AD Connect server
2 26 1 Azure AD Connect server and 1

domain controller
3 51 1 Active Directory Federation Services

(AD FS) server, 1 AD FS proxy, and 1
domain controller
4 76 1 AD FS server, 1 AD FS proxy, and 2

domain controllers
5 101 1 Azure AD Connect server, 1 AD FS

server, 1 AD FS proxy, and 2 domain
controllers
Q: Does Azure AD Connect Health suppor t Azure Germany Cloud?

Azure AD Connect Health is not supported in Germany Cloud except for the sync errors report feature.
RO L ES F EAT URES SUP P O RT ED IN GERM A N C LO UD
Connect Health for Sync Monitoring / Insight / Alerts / Analysis No
Sync error report Yes
Connect Health for ADFS Monitoring / Insight / Alerts / Analysis No
Connect Health for ADDS Monitoring / Insight / Alerts / Analysis No
To ensure the agent connectivity of Connect Health for sync, please configure the installation requirement
accordingly.
Installation questions
Q: What is the impact of installing the Azure AD Connect Health Agent on individual ser vers?
The impact of installing the Microsoft Azure AD Connect Health Agent, AD FS, web application proxy servers,
Azure AD Connect (sync) servers, domain controllers is minimal with respect to the CPU, memory consumption,
network bandwidth, and storage.
The following numbers are an approximation:
CPU consumption: ~1-5% increase.
Memory consumption: Up to 10 % of the total system memory.
NOTE
If the agent cannot communicate with Azure, the agent stores the data locally for a defined maximum limit. The agent
overwrites the “cached” data on a “least recently serviced” basis.
Local buffer storage for Azure AD Connect Health Agents: ~20 MB.
For AD FS servers, we recommend that you provision a disk space of 1,024 MB (1 GB) for the AD FS audit
channel for Azure AD Connect Health Agents to process all the audit data before it is overwritten.
Q: Will I have to reboot my ser vers during the installation of the Azure AD Connect Health Agents?
No. The installation of the agents will not require you to reboot the server. However, installation of some
prerequisite steps might require a reboot of the server.
For example, on Windows Server 2008 R2, installation of .NET 4.5 Framework requires a server reboot.
Q: Does Azure AD Connect Health work through a pass-through HTTP proxy?
Yes. For ongoing operations, you can configure the Health Agent to use an HTTP proxy to forward outbound
HTTP requests. Read more about configuring HTTP Proxy for Health Agents.
If you need to configure a proxy during agent registration, you might need to modify your Internet Explorer Proxy
settings beforehand.
1. Open Internet Explorer > Settings > Internet Options > Connections > L AN Settings .
2. Select Use a Proxy Ser ver for your L AN .
3. Select Advanced if you have different proxy ports for HTTP and HTTPS/Secure.
Q: Does Azure AD Connect Health suppor t Basic authentication when connecting to HTTP proxies?
No. A mechanism to specify an arbitrary user name and password for Basic authentication is not currently
supported.
Q: What firewall por ts do I need to open for the Azure AD Connect Health Agent to work?
See the requirements section for the list of firewall ports and other connectivity requirements.
Q: Why do I see two ser vers with the same name in the Azure AD Connect Health por tal?
When you remove an agent from a server, the server is not automatically removed from the Azure AD Connect
Health portal. If you manually remove an agent from a server or remove the server itself, you need to manually
delete the server entry from the Azure AD Connect Health portal.
You might reimage a server or create a new server with the same details (such as machine name). If you did not
remove the already registered server from the Azure AD Connect Health portal, and you installed the agent on
the new server, you might see two entries with the same name.
In this case, manually delete the entry that belongs to the older server. The data for this server should be out of
date.
Health Agent registration and data freshness

Q: What are common reasons for the Health Agent registration failures and how do I troubleshoot
issues?
The health agent can fail to register due to the following possible reasons:
The agent cannot communicate with the required endpoints because a firewall is blocking traffic. This is
particularly common on web application proxy servers. Make sure that you have allowed outbound
communication to the required endpoints and ports. See the requirements section for details.
Outbound communication is subjected to an TLS inspection by the network layer. This causes the certificate
that the agent uses to be replaced by the inspection server/entity, and the steps to complete the agent
registration fail.
The user does not have access to perform the registration of the agent. Global admins have access by default.
You can use Azure role-based access control (Azure RBAC) to delegate access to other users.
Q: I am getting aler ted that "Health Ser vice data is not up to date." How do I troubleshoot the
issue?
Azure AD Connect Health generates the alert when it does not receive all the data points from the server in the
last two hours. Read more.
Operations questions
Q: Do I need to enable auditing on the web application proxy ser vers?
No, auditing does not need to be enabled on the web application proxy servers.
Q: How do Azure AD Connect Health Aler ts get resolved?
Azure AD Connect Health alerts get resolved on a success condition. Azure AD Connect Health Agents detect and
report the success conditions to the service periodically. For a few alerts, the suppression is time-based. In other
words, if the same error condition is not observed within 72 hours from alert generation, the alert is
automatically resolved.
Q: I am getting aler ted that "Test Authentication Request (Synthetic Transaction) failed to obtain a
token." How do I troubleshoot the issue?
Azure AD Connect Health for AD FS generates this alert when the Health Agent installed on an AD FS server fails
to obtain a token as part of a synthetic transaction initiated by the Health Agent. The Health agent uses the local
system context and attempts to get a token for a self relying party. This is a catch-all test to ensure that AD FS is
in a state of issuing tokens.
Most often this test fails because the Health Agent is unable to resolve the AD FS farm name. This can happen if
the AD FS servers are behind a network load balancers and the request gets initiated from a node that's behind
the load balancer (as opposed to a regular client that is in front of the load balancer). This can be fixed by
updating the "hosts" file located under "C:\Windows\System32\drivers\etc" to include the IP address of the AD
FS server or a loopback IP address (127.0.0.1) for the AD FS farm name (such as sts.contoso.com). Adding the
host file will short-circuit the network call, thus allowing the Health Agent to get the token.
Q: I got an email indicating my machines are NOT patched for the recent ransomware attacks. Why
did I receive this email?
Azure AD Connect Health service scanned all the machines it monitors to ensure the required patches were
installed. The email was sent to the tenant administrators if at least one machine did not have the critical patches.
The following logic was used to make this determination.
1. Find all the hotfixes installed on the machine.
2. Check if at least one of the HotFixes from the defined list is present.
3. If Yes, the machine is protected. If Not, the machine is at risk for the attack.
You can use the following PowerShell script to perform this check manually. It implements the above logic.
Function CheckForMS17-010 ()
{
$hotfixes = "KB3205409", "KB3210720", "KB3210721", "KB3212646", "KB3213986", "KB4012212", "KB4012213",
"KB4012214", "KB4012215", "KB4012216", "KB4012217", "KB4012218", "KB4012220", "KB4012598", "KB4012606",
"KB4015219", "KB4019473"
#checks the computer it's run on if any of the listed hotfixes are present
$hotfix = Get-HotFix -ComputerName $env:computername | Where-Object {$hotfixes -contains $_.HotfixID} |
Select-Object -property "HotFixID"
#confirms whether hotfix is found or not

if (Get-HotFix | Where-Object {$hotfixes -contains $_.HotfixID})
{
"Found HotFix: " + $hotfix.HotFixID
} else {
"Didn't Find HotFix"
}
}
CheckForMS17-010
Q: Why does the PowerShell cmdlet Get-MsolDirSyncProvisioningError show less sync errors in the
result?
Get-MsolDirSyncProvisioningError will only return DirSync provisioning errors. Besides that, Connect Health
portal also shows other sync error types such as export errors. This is consistent with Azure AD Connect delta
result. Read more about Azure AD Connect Sync errors.
Q: Why are my ADFS audits not being generated?
Please use PowerShell cmdlet Get-AdfsProperties -AuditLevel to ensure audit logs is not in disabled state. Read
more about ADFS audit logs. Notice if there are advanced audit settings pushed to the ADFS server, any changes
with auditpol.exe will be overwritten (event if Application Generated is not configured). In this case, please set the
local security policy to log Application Generated failures and success.
Q: When will the agent cer tificate be automatic renewed before expiration? The agent certification will
be automatic renewed 6 months before its expiration date. If it is not renewed, please ensure the network
connection of the agent is stable. Restart the agent services or update to the latest version may also solve the
issue.
Related links
Azure AD Connect Health Agent installation
Azure AD Connect Health operations
Hybrid identity considerations for the Azure
Government cloud
This article describes considerations for integrating a hybrid environment with the Microsoft Azure Government
cloud. This information is provided as a reference for administrators and architects who work with the Azure
Government cloud.
NOTE
To integrate an on-premises Microsoft Azure Active Directory (Azure AD) environment with the Azure Government cloud,
you need to upgrade to the latest release of Azure AD Connect.
For a full list of United States government Department of Defense endpoints, refer to the documentation.
Azure AD Pass-through Authentication

The following information describes implementation of Pass-through Authentication and the Azure Government
cloud.
Allow access to URLs
Before you deploy the Pass-through Authentication agent, verify whether a firewall exists between your servers
and Azure AD. If your firewall or proxy allows Domain Name System (DNS) blocked or safe programs, add the
following connections.
NOTE
The following guidance also applies to installing the Azure AD Application Proxy connector for Azure Government
environments.
URL H O W IT 'S USED
*.msappproxy.us The agent uses these URLs to communicate with the Azure
*.servicebus.usgovcloudapi.net AD cloud service.
mscrl.microsoft.us:80 The agent uses these URLs to verify certificates.

crl.microsoft.us:80
ocsp.msocsp.us:80
www.microsoft.us:80
URL H O W IT 'S USED
login.windows.us The agent uses these URLs during the registration process.
secure.aadcdn.microsoftonline-p.com
*.microsoftonline.us
*.microsoftonline-p.us
*.msauth.net
*.msauthimages.net
*.msecnd.net
*.msftauth.net
*.msftauthimages.net
*.phonefactor.net
enterpriseregistration.windows.net
management.azure.com
policykeyservice.dc.ad.msft.net
ctldl.windowsupdate.us:80
Install the agent for the Azure Government cloud

Follow these steps to install the agent for the Azure Government cloud:
1. In the command-line terminal, go to the folder that contains the executable file that installs the agent.
2. Run the following commands, which specify that the installation is for Azure Government.
For Pass-through Authentication:
AADConnectAuthAgentSetup.exe ENVIRONMENTNAME="AzureUSGovernment"
For Application Proxy:
AADApplicationProxyConnectorInstaller.exe ENVIRONMENTNAME="AzureUSGovernment"
Single sign-on
Set up your Azure AD Connect server
If you usePass-through Authenticationas your sign-on method, no additional prerequisite check is required. If you
usepassword hash synchronizationas your sign-on method and there is a firewall between Azure AD Connect and
Azure AD, ensure that:
You use Azure AD Connect version 1.1.644.0 or later.
If your firewall or proxy allows DNS blocked or safe programs, add the connections to
the*.msappproxy.usURLs over port 443.
If not, allow access to theAzure datacenter IP ranges, which are updated weekly. This prerequisite applies
only when you enable the feature. It isn't required for actual user sign-ons.
Roll out Seamless Single Sign-On
You can gradually roll out Azure AD Seamless Single Sign-On to your users by using the following instructions.
You start by adding the Azure AD URL https://autologon.microsoft.us to all or selected users' Intranet zone
settings by using Group Policy in Active Directory.
You also need to enable the intranet zone policy setting Allow updates to status bar via script through
Group Policy .
Browser considerations
Mozilla Firefox (all platforms)
Mozilla Firefox doesn't automatically use Kerberos authentication. Each user must manually add the Azure AD URL
to their Firefox settings by following these steps:
1. Run Firefox and enterabout:config in the address bar. Dismiss any notifications that you might see.
2. Search for thenetwork .negotiate-auth.trusted-uris preference. This preference lists the sites trusted by
Firefox for Kerberos authentication.
3. Right-click the preference name and then selectModify .
4. Enter https://autologon.microsoft.us in the box.
5. SelectOK and then reopen the browser.
Microsoft Edge based on Chromium (all platforms)
If you have overridden the AuthNegotiateDelegateAllowlist or AuthServerAllowlist policy settings in your
environment, ensure that you add the Azure AD URL https://autologon.microsoft.us to them.
Google Chrome (all platforms)
If you have overridden the AuthNegotiateDelegateWhitelist or AuthServerWhitelist policy settings in your
environment, ensure that you add the Azure AD URL https://autologon.microsoft.us to them.
Next steps
Pass-through Authentication
Single Sign-On
User privacy and Azure AD Connect
NOTE
NOTE
This article deals with Azure AD Connect and user privacy. For information on Azure AD Connect Health and user privacy see
the article here.
Improve user privacy for Azure AD Connect installations in two ways:

1. Upon request, extract data for a person and remove data from that person from the installations
The Azure AD Connect team recommends the second option since it is much easier to implement and maintain.
An Azure AD Connect sync server stores the following user privacy data:
1. Data about a person in the Azure AD Connect database
2. Data in the Windows Event log files that may contain information about a person
3. Data in the Azure AD Connect installation log files that may contain about a person
Azure AD Connect customers should use the following guidelines when removing user data:
1. Delete the contents of the folder that contains the Azure AD Connect installation log files on a regular basis – at
least every 48 hours
2. This product may also create Event Logs. To learn more about Event Logs logs, please see the documentation
here.
Data about a person is automatically removed from the Azure AD Connect database when that person’s data is
removed from the source system where it originated from. No specific action from administrators is required to be
GDPR compliant. However, it does require that the Azure AD Connect data is synced with your data source at least
every two days.
Delete the Azure AD Connect installation log file folder contents

Regularly check and delete the contents of c:\programdata\aadconnect folder – except for the
PersistedState.Xml file. This file maintains the state of the previous installation of Azure A Connect and is used
when an upgrade installation is performed. This file doesn't contain any data about a person and shouldn't be
deleted.
IMPORTANT
Do not delete the PersistedState.xml file. This file contains no user information and maintains the state of the previous
installation.
You can either review and delete these files using Windows Explorer or you can use a script like the following to
perform the necessary actions:
$Files = ((Get-childitem -Path "$env:programdata\aadconnect" -Recurse).VersionInfo).FileName

Foreach ($file in $files) {
If ($File.ToUpper() -ne "$env:programdata\aadconnect\PERSISTEDSTATE.XML".toupper()) # Do not delete this file
}
Schedule this script to run every 48 hours

Use the following steps to schedule the script to run every 48 hours.
1. Save the script in a file with the extension .PS1 , then open the Control Panel and click on Systems and
Security .
2. Under the Administrative Tools heading, click on Schedule Tasks .
3. In Task Scheduler, right click on Task Schedule Librar y and click on Create Basic task …
4. Enter the name for the new task and click Next .
5. Select Daily for the task trigger and click on Next .
6. Set the recurrence to 2 days and click Next .
7. Select Star t a program as the action and click on Next .
8. Type PowerShell in the box for the Program/script, and in box labeled Add arguments (optional) , enter
the full path to the script that you created earlier, then click Next .
9. The next screen shows a summary of the task you are about to create. Verify the values and click Finish to
create the task.
Next steps
Azure AD Connect Health and User Privacy
User privacy and Azure AD Connect Health
NOTE
NOTE
This article deals with Azure AD Connect Health and user privacy. For information on Azure AD Connect and user privacy see
the article here.
User privacy classification

Azure AD Connect Health falls into the data processor category of GDPR classification. As a data processor
pipeline, the service provides data processing services to key partners and end consumers. Azure AD Connect
Health does not generate user data and has no independent control over what personal data is collected and how
it is used. Data retrieval, aggregation, analysis, and reporting in Azure AD Connect Health are based on existing on-
premises data.
Data retention policy

Azure AD Connect Health does not generate reports, perform analytics, or provide insights beyond 30 days.
Therefore, Azure AD Connect Health does not store, process, or retain any data beyond 30 days. This design is
compliant with the GDPR regulations, Microsoft privacy compliance regulations, and Azure AD data retention
policies.
Servers with active Health ser vice data is not up to date error alerts for over 30 consecutive days suggest
that no data has reached Connect Health during that time span. These servers will be disabled and not shown in
Connect Health portal. To re-enable the servers, you must uninstall and reinstall the health agent. Please note that
this does not apply to warnings with the same alert type. Warnings indicate that partial data is missing from the
server you are alerted for.
Disable data collection and monitoring in Azure AD Connect Health

Azure AD Connect Health enables you to stop data collection for each individual monitored server or for an
instance of a monitored service. For example, you can stop data collection for individual ADFS (Active Directory
Federation Services) servers that are monitored using Azure AD Connect Health. You can also stop data collection
for the entire ADFS instance that is being monitored using Azure AD Connect Health. When you choose to do so,
the corresponding servers are deleted from the Azure AD Connect Health portal, after stopping data collection.
IMPORTANT
You need either Azure AD Global Administrator privileges or the Contributor role in Azure RBAC to delete monitored servers
from Azure AD Connect Health.
Removing a server or service instance from Azure AD Connect Health is not a reversible action.
What to expect?
If you stop data collection and monitoring for an individual monitored server or an instance of a monitored
service, note the following:
When you delete an instance of a monitored service, the instance is removed from the Azure AD Connect
Health monitoring service list in the portal.
When you delete a monitored server or an instance of a monitored service, the Health Agent is NOT uninstalled
or removed from your servers. The Health Agent is configured not to send data to Azure AD Connect Health.
You need to manually uninstall the Health Agent on previously monitored servers.
If you have not uninstalled the Health Agent before performing this step, you may see error events on the
server(s) related to the Health Agent.
All data belonging to the instance of the monitored service is deleted as per the Microsoft Azure Data Retention
Policy.
Disable data collection and monitoring for an instance of a monitored service
See how to remove a service instance from Azure AD Connect Health.
Disable data collection and monitoring for a monitored server
See how to remove a server from Azure AD Connect Health.
Disable data collection and monitoring for all monitored services in Azure AD Connect Health
Azure AD Connect Health also provides the option to stop data collection of all registered services in the tenant.
We recommend careful consideration and full acknowledgement of all global admins before taking the action.
Once the process begins, Connect Health service will stop receiving, processing, and reporting any data of all your
services. Existing data in Connect Health service will be retained for no more than 30 days. If you want to stop data
collection of specific server, please follow steps at deletion of specific servers. To stop tenant-wise data collection,
follow the following steps to stop data collection and delete all services of the tenant.
1. Click on General Settings under configuration in the main blade.
2. Click on Stop Data Collection button on the top of the blade. The other options of tenant configuration
settings will be disabled once the process starts.
3. Ensure the list of onboarded services which are affected by stopping data collections.
4. Enter the exact tenant name to enable the Delete action button
5. Click on Delete to trigger the deletion of all services. Connect Health will stop receiving, processing,
reporting any data sent from your onboarded services. The entire process of can take up to 24 hours.
Notice that this step is not reversible.
6. After the process is completed, you will not see any registered services in Connect Health any more.
Re-enable data collection and monitoring in Azure AD Connect Health
To re-enable monitoring in Azure AD Connect Health for a previously deleted monitored service, you must
uninstall and reinstall the health agent on all the servers.
Re -enable data collection and monitoring for all monitored services
Tenant-wise data collection can be resumed in Azure AD Connect Health. We recommend careful consideration
and full acknowledgement of all global admins before taking the action.
IMPORTANT
The following steps will be available after 24 hours of disable action. After enabling of data collection, the presented insight
and monitoring data in Connect Health will not show any legacy data collected before.
1. Click on General Settings under configuration in the main blade.

2. Click on Enable Data Collection button on the top of the blade.
3. Enter the exact tenant name to activate the Enable button.

4. Click on Enable button to grant permission of data collection in Connect Health service. The change will be
applied shortly.
5. Follow the installation process to reinstall the agent in the servers to be monitored and the services will be
present in the portal.
Next steps
Azure AD Connect and User Privacy
Azure AD Connect in Microsoft Cloud Germany -
Public Preview
Introduction
Azure AD Connect provides synchronization between your on-premises Active Directory and Azure Active
Directory. Currently, many of the scenarios in Microsoft Cloud Germany must be done by the operator. When using
Microsoft Cloud Germany, you must be aware of the following information:
The following URLs must be opened on a proxy server for synchronization to occur successfully:
*.microsoftonline.de
*.windows.net
Certificate Revocation Lists
When you sign in to your Azure AD directory, you must use an account in the onmicrosoft.de domain.
Download
You can download Azure AD Connect from the Azure AD Connect blade within the portal. Use the instructions
below to locate the Azure AD Connect blade.
The Azure AD Connect Blade
Once you've signed in to the Azure portal:
1. Go to Browse
2. Select Azure Active Directory
3. Then select Azure AD Connect
You'll see these details:
The following table describes the features shown in the blade.
T IT L E DESC RIP T IO N
SYNC STATUS Let's you know whether synchronization is enabled or

disabled.
LAST SYNC The last time a successful sync completed.
FEDERATED DOMAINS Shows the number of federated domains currently configured.
Installation
To install Azure AD Connect, you can use the documentation here.
Advanced features and Additional Information

For additional information about custom settings or advanced configurations, go to Integrating your on-premises
identities with Azure Active Directory. This page provides information and links to additional guidance.
Upgrade Windows Azure Active Directory Sync and
Azure Active Directory Sync
Azure AD Connect is the best way to connect your on-premises directory with Azure AD and Office 365. This is a
great time to upgrade to Azure AD Connect from Windows Azure Active Directory Sync (DirSync) or Azure AD Sync
as these tools are now deprecated and are no longer supported as of April 13, 2017.
The two identity synchronization tools that are deprecated were offered for single forest customers (DirSync) and
for multi-forest and other advanced customers (Azure AD Sync). These older tools have been replaced with a single
solution that is available for all scenarios: Azure AD Connect. It offers new functionality, feature enhancements, and
support for new scenarios. To be able to continue to synchronize your on-premises identity data to Azure AD and
Office 365, we strongly recommend that you upgrade to Azure AD Connect. Microsoft does not guarantee these
older versions to work after December 31, 2017.
The last release of DirSync was released in July 2014 and the last release of Azure AD Sync was released in May
2015.
What is Azure AD Connect

Azure AD Connect is the successor to DirSync and Azure AD Sync. It combines all scenarios these two supported.
You can read more about it in Integrating your on-premises identities with Azure Active Directory.
Deprecation schedule
DAT E C O M M EN T
April 13, 2016 Windows Azure Active Directory Sync (“DirSync”) and
Microsoft Azure Active Directory Sync (“Azure AD Sync”) are
announced as deprecated.
April 13, 2017 Support ends. Customers will no longer be able to open a
support case without upgrading to Azure AD Connect first.
December 31, 2017 Azure AD may no longer accept communications from

Windows Azure Active Directory Sync ("DirSync") and
Microsoft Azure Active Directory Sync ("Azure AD Sync").
How to transition to Azure AD Connect

If you are running DirSync, there are two ways you can upgrade: In-place upgrade and parallel deployment. An in-
place upgrade is recommended for most customers and if you have a recent operating system and less than 50,000
objects. In other cases, it is recommended to do a parallel deployment where your DirSync configuration is moved
to a new server running Azure AD Connect.
Upgrade from DirSync If you have an existing DirSync server already running.
Upgrade from Azure AD Sync If you are moving from Azure AD Sync.
If you want to see how to do an in-place upgrade from DirSync to Azure AD Connect, then see this Channel 9 video:
FAQ
Q: I have received an email notification from the Azure Team and/or a message from the Office 365
message center, but I am using Connect.
The notification was also sent to customers using Azure AD Connect with a build number 1.0.*.0 (using a pre-1.1
release). Microsoft recommends customers to stay current with Azure AD Connect releases. The automatic upgrade
feature introduced in 1.1 makes it easy to always have a recent version of Azure AD Connect installed.
Q: Will DirSync/Azure AD Sync stop working on April 13, 2017?
DirSync/Azure AD Sync will continue to work on April 13, 2017. However, Azure AD may no longer accept
communications from DirSync/Azure AD Sync after December 31, 2017.
Q: Which DirSync versions can I upgrade from?
It is supported to upgrade from any DirSync release currently being used.
Q: What about the Azure AD Connector for FIM/MIM?
The Azure AD Connector for FIM/MIM has not been announced as deprecated. It is at feature freeze ; no new
functionality is added and it receives no bug fixes. Microsoft recommends customers using it to plan to move from
it to Azure AD Connect. It is strongly recommended to not start any new deployments using it. This Connector will
be announced deprecated in the future.
Azure AD Connect sync: Attributes synchronized to
This topic lists the attributes that are synchronized by Azure AD Connect sync.
The attributes are grouped by the related Azure AD app.
Attributes to synchronize
A common question is what is the list of minimum attributes to synchronize. The default and recommended
approach is to keep the default attributes so a full GAL (Global Address List) can be constructed in the cloud and to
get all features in Office 365 workloads. In some cases, there are some attributes that your organization does not
want synchronized to the cloud since these attributes contain sensitive or PII (Personally identifiable information)
data, like in this example:
In this case, start with the list of attributes in this topic and identify those attributes that would contain sensitive or
PII data and cannot be synchronized. Then deselect those attributes during installation using Azure AD app and
attribute filtering.
WARNING
When deselecting attributes, you should be cautious and only deselect those attributes absolutely not possible to
synchronize. Unselecting other attributes might have a negative impact on features.
Office 365 ProPlus

AT T RIB UT E N A M E USER C O M M EN T
accountEnabled X Defines if an account is enabled.
cn X
displayName X
objectSID X mechanical property. AD user identifier

used to maintain sync between Azure
AD and AD.
pwdLastSet X mechanical property. Used to know

when to invalidate already issued
tokens. Used by both password hash
sync, pass-through authentication and
federation.
samAccountName X
sourceAnchor X mechanical property. Immutable

identifier to maintain relationship
between ADDS and Azure AD.
usageLocation X mechanical property. The user’s

country/region. Used for license
assignment.
userPrincipalName X UPN is the login ID for the user. Most

often the same as [mail] value.
Exchange Online
AT T RIB UT E N A M E USER C O N TA C T GRO UP C O M M EN T
accountEnabled X Defines if an account

is enabled.
assistant X X
altRecipient X Requires Azure AD

Connect build
1.1.552.0 or after.
authOrig X X X
c X X
cn X X
co X X
company X X
countryCode X X
department X X
description X
displayName X X X
dLMemRejectPerms X X X
dLMemSubmitPerms X X X
extensionAttribute1 X X X
facsimiletelephonenu X X
mber
givenName X X
homePhone X X
info X X X This attribute is

currently not
consumed for groups.
Initials X X
l X X
legacyExchangeDN X X X
mailNickname X X X
managedBy X
manager X X
member X
mobile X X
msDS- X X X
HABSeniorityIndex
msDS- X X X
PhoneticDisplayName
msExchArchiveGUID X
msExchArchiveName X
msExchAssistantName X X
msExchAuditAdmin X
msExchAuditDelegate X
msExchAuditDelegate X
Admin
msExchAuditOwner X
msExchBlockedSender X X
sHash
msExchBypassAudit X
msExchBypassModera X Available in Azure AD

tionLink Connect version
1.1.524.0
msExchCoManagedBy X
Link
msExchDelegateListLi X
nk
msExchELCExpirySusp X
ensionEnd
msExchELCExpirySusp X
ensionStart
msExchELCMailboxFla X
gs
msExchEnableModera X X
tion
msExchExtensionCust X X X This attribute is

omAttribute1 currently not
consumed by
Exchange Online.

consumed by
Exchange Online.

consumed by
Exchange Online.

consumed by
Exchange Online.

consumed by
Exchange Online.
msExchHideFromAddr X X X
essLists
msExchImmutableID X
msExchLitigationHold X X X
Date
msExchLitigationHold X X X
Owner
msExchMailboxAuditE X
nable
msExchMailboxAuditL X
ogAgeLimit
msExchMailboxGuid X
msExchModeratedByL X X X
ink
msExchModerationFla X X X
gs
msExchRecipientDispla X X X
yType
msExchRecipientType X X X
Details
msExchRemoteRecipie X
ntType
msExchRequireAuthTo X X X
SendTo
msExchResourceCapac X
ity
msExchResourceDispla X
y
msExchResourceMeta X
Data
msExchResourceSearc X
hProperties
msExchRetentionCom X X X
ment
msExchRetentionURL X X X
msExchSafeRecipients X X
Hash
msExchSafeSendersHa X X
sh
msExchSenderHintTra X X X
nslations
msExchTeamMailboxE X
xpiration
msExchTeamMailboxO X
wners
msExchTeamMailboxS X
harePointUrl
msExchUserHoldPolici X
es
msOrg- X
IsOrganizational
objectSID X X mechanical property.

AD user identifier
used to maintain sync
between Azure AD
and AD.
oOFReplyToOriginator X
otherFacsimileTelepho X X
ne
otherHomePhone X X
otherTelephone X X
pager X X
physicalDeliveryOffice X X
Name
postalCode X X
proxyAddresses X X X
publicDelegates X X X
pwdLastSet X mechanical property.

Used to know when
to invalidate already
issued tokens. Used
by both password
sync and federation.
reportToOriginator X
reportToOwner X
sn X X
sourceAnchor X X X mechanical property.

Immutable identifier
to maintain
relationship between
ADDS and Azure AD.
st X X
streetAddress X X
targetAddress X X
telephoneAssistant X X
telephoneNumber X X
thumbnailphoto X X synced only once

from Azure AD to
Exchange Online after
which Exchange
Online becomes
source of authority
for this attribute and
any later changes
can't be synced from
on-premise. See (KB)
for more.
title X X
unauthOrig X X X
usageLocation X mechanical property.

The user’s
country/region. Used
for license
assignment.
userCertificate X X
userPrincipalName X UPN is the login ID

for the user. Most
often the same as
[mail] value.
userSMIMECertificate X X
s
wWWHomePage X X
SharePoint Online

is enabled.
authOrig X X X
c X X
cn X X
co X X
company X X
countryCode X X
department X X
description X X X
displayName X X X
dLMemRejectPerms X X X
dLMemSubmitPerms X X X
mber
givenName X X
hideDLMembership X
homephone X X
info X X X
initials X X
ipPhone X X
l X X
mail X X X
mailnickname X X X
managedBy X
manager X X
member X
middleName X X
mobile X X
msExchTeamMailboxE X
xpiration
msExchTeamMailboxO X
wners
harePointLinkedBy
harePointUrl

AD user identifier
between Azure AD
and AD.
oOFReplyToOriginator X
otherFacsimileTelepho X X
ne
otherHomePhone X X
otherIpPhone X X
otherMobile X X
otherPager X X
otherTelephone X X
pager X X
Name
postalCode X X
postOfficeBox X X This attribute is

currently not
consumed by
SharePoint Online.
preferredLanguage X

Used to know when
issued tokens. Used
by both password
hash sync, pass-
through
authentication and
federation.
reportToOriginator X
reportToOwner X
sn X X

to maintain
ADDS and Azure AD.
st X X
streetAddress X X
targetAddress X X
telephoneAssistant X X
telephoneNumber X X

from Azure AD to
which Exchange
Online becomes
source of authority
any later changes
for more.
title X X
unauthOrig X X X
url X X

The user’s
country/region
. Used for license

assignment.

for the user. Most
often the same as
[mail] value.
wWWHomePage X X
Teams and Skype for Business Online


is enabled.
c X X
cn X X
co X X
company X X
department X X
description X X X
displayName X X X
facsimiletelephonenu X X X
mber
givenName X X
homephone X X
ipPhone X X
l X X
mail X X X
mailNickname X X X
managedBy X
manager X X
member X
mobile X X
msExchHideFromAddr X X X
essLists
msRTCSIP- X
ApplicationOptions
msRTCSIP- X X
DeploymentLocator
msRTCSIP-Line X X
msRTCSIP- X X
OptionFlags
msRTCSIP-OwnerUrn X
msRTCSIP- X X
PrimaryUserAddress
msRTCSIP- X X
UserEnabled

AD user identifier
between Azure AD
and AD.
otherTelephone X X
Name
postalCode X X
preferredLanguage X

Used to know when
issued tokens. Used
by both password
hash sync, pass-
through
authentication and
federation.
sn X X

to maintain
ADDS and Azure AD.
st X X
streetAddress X X
telephoneNumber X X

from Azure AD to
which Exchange
Online becomes
source of authority
any later changes
for more.
title X X

The user’s
for license
assignment.

for the user. Most
often the same as
[mail] value.
wWWHomePage X X
Azure RMS

is enabled.
cn X X Common name or
alias. Most often the
prefix of [mail] value.
displayName X X X A string that

represents the name
often shown as the
friendly name (first
name last name).
mail X X X full email address.
member X

AD user identifier
between Azure AD
and AD.
proxyAddresses X X X mechanical property.

Used by Azure AD.
Contains all
secondary email
addresses for the user.

Used to know when
issued tokens.

to maintain
ADDS and Azure AD.

The user’s
for license
assignment.
userPrincipalName X This UPN is the login

ID for the user. Most
often the same as
[mail] value.
Intune

is enabled.
c X X
cn X X
description X X X
displayName X X X
mail X X X
mailnickname X X X
member X

AD user identifier
between Azure AD
and AD.

Used to know when
issued tokens. Used
by both password
hash sync, pass-
through
authentication and
federation.

to maintain
ADDS and Azure AD.

The user’s
for license
assignment.

for the user. Most
often the same as
[mail] value.
Dynamics CRM

is enabled.
c X X
cn X X
co X X
company X X
countryCode X X
description X X X
displayName X X X
mber
givenName X X
l X X
managedBy X
manager X X
member X
mobile X X

AD user identifier
between Azure AD
and AD.
Name
postalCode X X
preferredLanguage X

Used to know when
issued tokens. Used
by both password
hash sync, pass-
through
authentication and
federation.
sn X X

to maintain
ADDS and Azure AD.
st X X
streetAddress X X
telephoneNumber X X
title X X

The user’s
for license
assignment.

for the user. Most
often the same as
[mail] value.
3rd party applications

This group is a set of attributes used as the minimal attributes needed for a generic workload or application. It can
be used for a workload not listed in another section or for a non-Microsoft app. It is explicitly used for the
following:
Yammer (only User is consumed)
Hybrid Business-to-Business (B2B) cross-org collaboration scenarios offered by resources like SharePoint
This group is a set of attributes that can be used if the Azure AD directory is not used to support Office 365,
Dynamics, or Intune. It has a small set of core attributes. Note that single sign-on or provisioning to some third-
party applications requires configuring synchronization of attributes in addition to the attributes described here.
Application requirements are described in the SaaS app tutorial for each application.

is enabled.
cn X X
displayName X X X
employeeID X
givenName X X
mail X X
managedBy X
mailNickName X X X
member X
objectSID X mechanical property.

AD user identifier
between Azure AD
and AD.

Used to know when
issued tokens. Used
by both password
hash sync, pass-
through
authentication and
federation.
sn X X

to maintain
ADDS and Azure AD.

The user’s
for license
assignment.

for the user. Most
often the same as
[mail] value.
Windows 10
A Windows 10 domain-joined computer(device) synchronizes some attributes to Azure AD. For more information
on the scenarios, see Connect domain-joined devices to Azure AD for Windows 10 experiences. These attributes
always synchronize and Windows 10 does not appear as an app you can unselect. A Windows 10 domain-joined
computer is identified by having the attribute userCertificate populated.
AT T RIB UT E N A M E DEVIC E C O M M EN T
accountEnabled X
deviceTrustType X Hardcoded value for domain-joined

computers.
displayName X
ms-DS-CreatorSID X Also called registeredOwnerReference.
objectGUID X Also called deviceID.
objectSID X Also called onPremisesSecurityIdentifier.
operatingSystem X Also called deviceOSType.
operatingSystemVersion X Also called deviceOSVersion.
userCertificate X
These attributes for user are in addition to the other apps you have selected.
domainFQDN X Also called dnsDomainName. For

example, contoso.com.
domainNetBios X Also called netBiosName. For example,

CONTOSO.
msDS-KeyCredentialLink X Once the user is enrolled in Windows

Hello for Business.
Exchange hybrid writeback
These attributes are written back from Azure AD to on-premises Active Directory when you select to enable
Exchange hybrid . Depending on your Exchange version, fewer attributes might be synchronized.
AT T RIB UT E AT T RIB UT E
NAME (ON- NAME
P REM ISES A D) ( C O N N EC T UI) USER C O N TA C T GRO UP C O M M EN T
msDS- ms-DS-External- X Derived from

ExternalDirectory Directory-Object- cloudAnchor in
ObjectID Id Azure AD. This
attribute is new
in Exchange 2016
and Windows
Server 2016 AD.
msExchArchiveSta ms-Exch- X Online Archive:

tus ArchiveStatus Enables
customers to
archive mail.
msExchBlockedSe ms-Exch- X Filtering: Writes

ndersHash BlockedSendersH back on-premises
ash filtering and
online safe and
blocked sender
data from clients.
msExchSafeRecipi ms-Exch- X Filtering: Writes

entsHash SafeRecipientsHas back on-premises
h filtering and
online safe and
blocked sender
data from clients.
msExchSafeSende ms-Exch- X Filtering: Writes

rsHash SafeSendersHash back on-premises
filtering and
online safe and
blocked sender
data from clients.
msExchUCVoice ms-Exch- X Enable Unified

MailSettings UCVoiceMailSetti Messaging (UM)
ngs - Online voice
mail: Used by
Microsoft Lync
Server
integration to
indicate to Lync
Server on-
premises that the
user has voice
mail in online
services.
AT T RIB UT E AT T RIB UT E
NAME (ON- NAME
P REM ISES A D) ( C O N N EC T UI) USER C O N TA C T GRO UP C O M M EN T
msExchUserHold ms-Exch- X Litigation Hold:

Policies UserHoldPolicies Enables cloud
services to
determine which
users are under
Litigation Hold.
proxyAddresses proxyAddresses X X X Only the x500

address from
Exchange Online
is inserted.
publicDelegates ms-Exch-Public- X Allows an

Delegates Exchange Online
mailbox to be
granted
SendOnBehalfTo
rights to users
with on-premises
Exchange
mailbox. Requires
Azure AD
Connect build
1.1.552.0 or after.
Exchange Mail Public Folder

These attributes are synchronized from on-premises Active Directory to Azure AD when you select to enable
Exchange Mail Public Folder .
AT T RIB UT E N A M E P UB L IC F O L DER C O M M EN T
displayName X
mail X
msExchRecipientTypeDetails X
objectGUID X
proxyAddresses X
targetAddress X
Device writeback
Device objects are created in Active Directory. These objects can be devices joined to Azure AD or domain-joined
Windows 10 computers.
altSecurityIdentities X
displayName X
dn X
msDS-CloudAnchor X
msDS-DeviceID X
msDS-DeviceObjectVersion X
msDS-DeviceOSType X
msDS-DeviceOSVersion X
msDS-DevicePhysicalIDs X
msDS-KeyCredentialLink X Only with Windows Server 2016 AD

schema
msDS-IsCompliant X
msDS-IsEnabled X
msDS-IsManaged X
msDS-RegisteredOwner X
Notes
When using an Alternate ID, the on-premises attribute userPrincipalName is synchronized with the Azure AD
attribute onPremisesUserPrincipalName. The Alternate ID attribute, for example mail, is synchronized with the
Azure AD attribute userPrincipalName.
In the lists above, the object type User also applies to the object type iNetOrgPerson .
Next steps
In Azure AD Connect, functions are used to manipulate an attribute value during synchronization.
The Syntax of the functions is expressed using the following format:
<output type> FunctionName(<input type> <position name>, ..)
If a function is overloaded and accepts multiple syntaxes, all valid syntaxes are listed.
The functions are strongly typed and they verify that the type passed in matches the documented type.
If the type does not match, an error is thrown.
The types are expressed with the following syntax:
bin – Binary
bool – Boolean
dt – UTC Date/Time
enum – Enumeration of known constants
exp – Expression, which is expected to evaluate to a Boolean
mvbin – Multi-Valued Binary
mvstr – Multi-Valued String
mvref – Multi-Valued Reference
num – Numeric
ref – Reference
str – String
var – A variant of (almost) any other type
void – doesn’t return a value
The functions with the types mvbin , mvstr , and mvref can only work on multi-valued attributes. Functions with
bin , str , and ref work on both single-valued and multi-valued attributes.
Functions Reference
Cer tificate
CertExtensionOids
CertFormat
CertFriendlyName
CertHashString
CertIssuer
CertIssuerDN
CertIssuerOid
CertKeyAlgorithm
CertKeyAlgorithmParams
CertNameInfo
CertNotAfter
CertNotBefore
CertPublicKeyOid
CertPublicKeyParametersOid
CertSerialNumber
CertSignatureAlgorithmOid
CertSubject
CertSubjectNameDN
CertSubjectNameOid
CertThumbprint
CertVersion
IsCert
Conversion
CBool
CDate
CGuid
ConvertFromBase64
ConvertToBase64
ConvertFromUTF8Hex
ConvertToUTF8Hex
CNum
CRef
CStr
StringFromGuid
StringFromSid
Date / Time
DateAdd
DateFromNum
FormatDateTime
Now
NumFromDate
Director y
DNComponent
DNComponentRev
EscapeDNComponent
Evaluation
IsBitSet
IsDate
IsEmpty
IsGuid
IsNull
IsNullOrEmpty
IsNumeric
IsPresent
IsString
Math
BitAnd
BitOr
RandomNum
Multi*valued
Contains
Count
Item
ItemOrNull
Join
RemoveDuplicates
Split
Program Flow
Error
IIF
Select
Switch
Where
With
Text
GUID
InStr
InStrRev
LCase
Left
Len
LTrim
Mid
PadLeft
PadRight
PCase
Replace
ReplaceChars
Right
RTrim
Trim
UCase
Word
BitAnd
Description:
The BitAnd function sets specified bits on a value.
Syntax:
num BitAnd(num value1, num value2)
value1, value2: numeric values that should be AND’ed together

Remarks:
This function converts both parameters to the binary representation and sets a bit to:
0 - if one or both of the corresponding bits in value1 and value2 are 0
1 - if both of the corresponding bits are 1.
In other words, it returns 0 in all cases except when the corresponding bits of both parameters are 1.
Example:
BitAnd(&HF, &HF7)
Returns 7 because hexadecimal "F" AND "F7" evaluate to this value.
BitOr
Description:
The BitOr function sets specified bits on a value.
Syntax:
num BitOr(num value1, num value2)
value1, value2: numeric values that should be OR’ed together

Remarks:
This function converts both parameters to the binary representation and sets a bit to 1 if one or both of the
corresponding bits in mask and flag are 1, and to 0 if both of the corresponding bits are 0. In other words, it
returns 1 in all cases except where the corresponding bits of both parameters are 0.
CBool
Description:
The CBool function returns a Boolean based on the evaluated expression
Syntax:
bool CBool(exp Expression)
Remarks:
If the expression evaluates to a non-zero value, then CBool returns True, else it returns False.
Example:
CBool([attrib1] = [attrib2])
Returns True if both attributes have the same value.
CDate
Description:
The CDate function returns a UTC DateTime from a string. DateTime is not a native attribute type in Sync but is
used by some functions.
Syntax:
dt CDate(str value)
Value: A string with a date, time, and optionally time zone

Remarks:
The returned string is always in UTC.
Example:
CDate([employeeStartTime])
Returns a DateTime based on the employee’s start time
CDate("2013-01-10 4:00 PM -8")
Returns a DateTime representing "2013-01-11 12:00 AM"
CertExtensionOids
Description:
Returns the Oid values of all the critical extensions of a certificate object.
Syntax:
mvstr CertExtensionOids(binary certificateRawData)
certificateRawData: Byte array representation of an X.509 certificate. The byte array can be binary (DER)
encoded or Base64-encoded X.509 data.
CertFormat
Description:
Returns the name of the format of this X.509v3 certificate.
Syntax:
str CertFormat(binary certificateRawData)
CertFriendlyName
Description:
Returns the associated alias for a certificate.
Syntax:
str CertFriendlyName(binary certificateRawData)
CertHashString
Description:
Returns the SHA1 hash value for the X.509v3 certificate as a hexadecimal string.
Syntax:
str CertHashString(binary certificateRawData)
CertIssuer
Description:
Returns the name of the certificate authority that issued the X.509v3 certificate.
Syntax:
str CertIssuer(binary certificateRawData)
CertIssuerDN
Description:
Returns the distinguished name of the certificate issuer.
Syntax:
str CertIssuerDN(binary certificateRawData)
CertIssuerOid
Description:
Returns the Oid of the certificate issuer.
Syntax:
str CertIssuerOid(binary certificateRawData)
CertKeyAlgorithm
Description:
Returns the key algorithm information for this X.509v3 certificate as a string.
Syntax:
str CertKeyAlgorithm(binary certificateRawData)
Description:
Returns the key algorithm parameters for the X.509v3 certificate as a hexadecimal string.
Syntax:
CertNameInfo
Description:
Returns the subject and issuer names from a certificate.
Syntax:
str CertNameInfo(binary certificateRawData, str x509NameType, bool includesIssuerName)
X509NameType: The X509NameType value for the subject.
includesIssuerName: true to include the issuer name; otherwise, false.
CertNotAfter
Description:
Returns the date in local time after which a certificate is no longer valid.
Syntax:
dt CertNotAfter(binary certificateRawData)
CertNotBefore
Description:
Returns the date in local time on which a certificate becomes valid.
Syntax:
dt CertNotBefore(binary certificateRawData)
CertPublicKeyOid
Description:
Returns the Oid of the public key for the X.509v3 certificate.
Syntax:
Description:
Returns the Oid of the public key parameters for the X.509v3 certificate.
Syntax:
str CertPublicKeyParametersOid(binary certificateRawData)
CertSerialNumber
Description:
Returns the serial number of the X.509v3 certificate.
Syntax:
str CertSerialNumber(binary certificateRawData)
Description:
Returns the Oid of the algorithm used to create the signature of a certificate.
Syntax:
str CertSignatureAlgorithmOid(binary certificateRawData)
CertSubject
Description:
Gets the subject distinguished name from a certificate.
Syntax:
str CertSubject(binary certificateRawData)
CertSubjectNameDN
Description:
Returns the subject distinguished name from a certificate.
Syntax:
str CertSubjectNameDN(binary certificateRawData)
CertSubjectNameOid
Description:
Returns the Oid of the subject name from a certificate.
Syntax:
str CertSubjectNameOid(binary certificateRawData)
CertThumbprint
Description:
Returns the thumbprint of a certificate.
Syntax:
str CertThumbprint(binary certificateRawData)
CertVersion
Description:
Returns the X.509 format version of a certificate.
Syntax:
str CertThumbprint(binary certificateRawData)
CGuid
Description:
The CGuid function converts the string representation of a GUID to its binary representation.
Syntax:
bin CGuid(str GUID)
A String formatted in this pattern: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx or {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}

Contains
Description:
The Contains function finds a string inside a multi-valued attribute
Syntax:
num Contains (mvstring attribute, str search) - case-sensitive
num Contains (mvstring attribute, str search, enum Casetype)
num Contains (mvref attribute, str search) - case-sensitive
attribute: the multi-valued attribute to search.
search: string to find in the attribute.
Casetype: CaseInsensitive or CaseSensitive.
Returns index in the multi-valued attribute where the string was found. 0 is returned if the string is not found.
Remarks:
For multi-valued string attributes, the search finds substrings in the values.
For reference attributes, the searched string must exactly match the value to be considered a match.
Example:
IIF(Contains([proxyAddresses],"SMTP:")>0,[proxyAddresses],Error("No primary SMTP address found."))
If the proxyAddresses attribute has a primary email address (indicated by uppercase "SMTP:"), then return the
proxyAddress attribute, else return an error.
ConvertFromBase64
Description:
The ConvertFromBase64 function converts the specified base64 encoded value to a regular string.
Syntax:
str ConvertFromBase64(str source) - assumes Unicode for encoding
str ConvertFromBase64(str source, enum Encoding)
source: Base64 encoded string

Encoding: Unicode, ASCII, UTF8
Example
ConvertFromBase64("SABlAGwAbABvACAAdwBvAHIAbABkACEA")
ConvertFromBase64("SGVsbG8gd29ybGQh", UTF8)
Both examples return "Hello world!"
ConvertFromUTF8Hex
Description:
The ConvertFromUTF8Hex function converts the specified UTF8 Hex encoded value to a string.
Syntax:
str ConvertFromUTF8Hex(str source)
source: UTF8 2-byte encoded sting

Remarks:
The difference between this function and ConvertFromBase64([],UTF8) in that the result is friendly for the DN
attribute.
This format is used by Azure Active Directory as DN.
Example:
ConvertFromUTF8Hex("48656C6C6F20776F726C6421")
Returns "Hello world!"
ConvertToBase64
Description:
The ConvertToBase64 function converts a string to a Unicode base64 string.
Converts the value of an array of integers to its equivalent string representation that is encoded with base-64
digits.
Syntax:
str ConvertToBase64(str source)
Example:
ConvertToBase64("Hello world!")
Returns "SABlAGwAbABvACAAdwBvAHIAbABkACEA"
ConvertToUTF8Hex
Description:
The ConvertToUTF8Hex function converts a string to a UTF8 Hex encoded value.
Syntax:
str ConvertToUTF8Hex(str source)
Remarks:
The output format of this function is used by Azure Active Directory as DN attribute format.
Example:
ConvertToUTF8Hex("Hello world!")
Returns 48656C6C6F20776F726C6421
Count
Description:
The Count function returns the number of elements in a multi-valued attribute
Syntax:
num Count(mvstr attribute)
CNum
Description:
The CNum function takes a string and returns a numeric data type.
Syntax:
num CNum(str value)
CRef
Description:
Converts a string to a reference attribute
Syntax:
ref CRef(str value)
Example:
CRef("CN=LC Services,CN=Microsoft,CN=lcspool01,CN=Pools,CN=RTC Service," & %Forest.LDAP%)
CStr
Description:
The CStr function converts to a string data type.
Syntax:
str CStr(num value)
str CStr(ref value)
str CStr(bool value)
value: Can be a numeric value, reference attribute, or Boolean.

Example:
CStr([dn])
Could return "cn=Joe,dc=contoso,dc=com"
DateAdd
Description:
Returns a Date containing a date to which a specified time interval has been added.
Syntax:
dt DateAdd(str interval, num value, dt date)
interval: String expression that is the interval of time you want to add. The string must have one of the
following values:
yyyy Year
q Quarter
m Month
y Day of year
d Day
w Weekday
ww Week
h Hour
n Minute
s Second
value: The number of units you want to add. It can be positive (to get dates in the future) or negative (to get
dates in the past).
date: DateTime representing date to which the interval is added.
Example:
DateAdd("m", 3, CDate("2001-01-01"))
Adds 3 months and returns a DateTime representing "2001-04-01".
DateFromNum
Description:
The DateFromNum function converts a value in AD’s date format to a DateTime type.
Syntax:
dt DateFromNum(num value)
Example:
DateFromNum([lastLogonTimestamp])
DateFromNum(129699324000000000)
Returns a DateTime representing 2012-01-01 23:00:00
DNComponent
Description:
The DNComponent function returns the value of a specified DN component going from left.
Syntax:
str DNComponent(ref dn, num ComponentNumber)
dn: the reference attribute to interpret

ComponentNumber: The component in the DN to return
Example:
DNComponent(CRef([dn]),1)
If dn is "cn=Joe,ou=…," it returns Joe
DNComponentRev
Description:
The DNComponentRev function returns the value of a specified DN component going from right (the end).
Syntax:
str DNComponentRev(ref dn, num ComponentNumber)
str DNComponentRev(ref dn, num ComponentNumber, enum Options)
dn: the reference attribute to interpret

ComponentNumber - The component in the DN to return
Options: DC – Ignore all components with "dc="
Example:
If dn is "cn=Joe,ou=Atlanta,ou=GA,ou=US, dc=contoso,dc=com" then
DNComponentRev(CRef([dn]),3)
DNComponentRev(CRef([dn]),1,"DC")
Both return US.
Error
Description:
The Error function is used to return a custom error.
Syntax:
void Error(str ErrorMessage)
Example:
IIF(IsPresent([accountName]),[accountName],Error("AccountName is required"))
If the attribute accountName is not present, throw an error on the object.
EscapeDNComponent
Description:
The EscapeDNComponent function takes one component of a DN and escapes it so it can be represented in LDAP.
Syntax:
str EscapeDNComponent(str value)
Example:
EscapeDNComponent("cn=" & [displayName]) & "," & %ForestLDAP%)
Makes sure the object can be created in an LDAP directory even if the displayName attribute has characters that
must be escaped in LDAP.
FormatDateTime
Description:
The FormatDateTime function is used to format a DateTime to a string with a specified format
Syntax:
str FormatDateTime(dt value, str format)
value: a value in the DateTime format

format: a string representing the format to convert to.
Remarks:
The possible values for the format can be found here: Custom date and time formats for the FORMAT function.
Example:
FormatDateTime(CDate("12/25/2007"),"yyyy-mm-dd")
Results in "2007-12-25".
FormatDateTime(DateFromNum([pwdLastSet]),"yyyyMMddHHmmss.0Z")
Can result in "20140905081453.0Z"
Guid
Description:
The function Guid generates a new random GUID
Syntax:
str Guid()
IIF
Description:
The IIF function returns one of a set of possible values based on a specified condition.
Syntax:
var IIF(exp condition, var valueIfTrue, var valueIfFalse)
condition: any value or expression that can be evaluated to true or false.

valueIfTrue: If the condition evaluates to true, the returned value.
valueIfFalse: If the condition evaluates to false, the returned value.
Example:
IIF([employeeType]="Intern","t-" & [alias],[alias])
If the user is an intern, returns the alias of a user with "t-" added to the beginning of it, else returns the user’s alias
as is.
InStr
Description:
The InStr function finds the first occurrence of a substring in a string
Syntax:
num InStr(str stringcheck, str stringmatch)
num InStr(str stringcheck, str stringmatch, num start)
num InStr(str stringcheck, str stringmatch, num start , enum compare)
stringcheck: string to be searched
stringmatch: string to be found
start: starting position to find the substring
compare: vbTextCompare or vbBinaryCompare
Remarks:
Returns the position where the substring was found or 0 if not found.
Example:
InStr("The quick brown fox","quick")
Evalues to 5
InStr("repEated","e",3,vbBinaryCompare)
Evaluates to 7
InStrRev
Description:
The InStrRev function finds the last occurrence of a substring in a string
Syntax:
num InstrRev(str stringcheck, str stringmatch)
num InstrRev(str stringcheck, str stringmatch, num start)
num InstrRev(str stringcheck, str stringmatch, num start, enum compare)
stringcheck: string to be searched

stringmatch: string to be found
start: starting position to find the substring
compare: vbTextCompare or vbBinaryCompare
Remarks:
Returns the position where the substring was found or 0 if not found.
Example:
InStrRev("abbcdbbbef","bb")
Returns 7
IsBitSet
Description:
The function IsBitSet Tests if a bit is set or not
Syntax:
bool IsBitSet(num value, num flag)
value: a numeric value that is evaluated.flag: a numeric value that has the bit to be evaluated
Example:
IsBitSet(&HF,4)
Returns True because bit "4" is set in the hexadecimal value "F"
IsDate
Description:
If the expression can be evaluates as a DateTime type, then the IsDate function evaluates to True.
Syntax:
bool IsDate(var Expression)
Remarks:
Used to determine if CDate() can be successful.
IsCert
Description:
Returns true if the raw data can be serialized into .NET X509Certificate2 certificate object.
Syntax:
bool CertThumbprint(binary certificateRawData)
IsEmpty
Description:
If the attribute is present in the CS or MV but evaluates to an empty string, then the IsEmpty function evaluates to
True.
Syntax:
bool IsEmpty(var Expression)
IsGuid
Description:
If the string could be converted to a GUID, then the IsGuid function evaluated to true.
Syntax:
bool IsGuid(str GUID)
Remarks:
A GUID is defined as a string following one of these patterns: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx or {xxxxxxxx-
xxxx-xxxx-xxxx-xxxxxxxxxxxx}
Used to determine if CGuid() can be successful.
Example:
IIF(IsGuid([strAttribute]),CGuid([strAttribute]),NULL)
If the StrAttribute has a GUID format, return a binary representation, otherwise return a Null.
IsNull
Description:
If the expression evaluates to Null, then the IsNull function returns true.
Syntax:
bool IsNull(var Expression)
Remarks:
For an attribute, a Null is expressed by the absence of the attribute.
Example:
IsNull([displayName])
Returns True if the attribute is not present in the CS or MV.
IsNullOrEmpty
Description:
If the expression is null or an empty string, then the IsNullOrEmpty function returns true.
Syntax:
bool IsNullOrEmpty(var Expression)
Remarks:
For an attribute, this would evaluate to True if the attribute is absent or is present but is an empty string.
The inverse of this function is named IsPresent.
Example:
IsNullOrEmpty([displayName])
Returns True if the attribute is not present or is an empty string in the CS or MV.
IsNumeric
Description:
The IsNumeric function returns a Boolean value indicating whether an expression can be evaluated as a number
type.
Syntax:
bool IsNumeric(var Expression)
Remarks:
Used to determine if CNum() can be successful to parse the expression.
IsString
Description:
If the expression can be evaluated to a string type, then the IsString function evaluates to True.
Syntax:
bool IsString(var expression)
Remarks:
Used to determine if CStr() can be successful to parse the expression.
IsPresent
Description:
If the expression evaluates to a string that is not Null and is not empty, then the IsPresent function returns true.
Syntax:
bool IsPresent(var expression)
Remarks:
The inverse of this function is named IsNullOrEmpty.
Example:
Switch(IsPresent([directManager]),[directManager], IsPresent([skiplevelManager]),[skiplevelManager],
IsPresent([director]),[director])
Item
Description:
The Item function returns one item from a multi-valued string/attribute.
Syntax:
var Item(mvstr attribute, num index)
attribute: multi-valued attribute
index: index to an item in the multi-valued string.
Remarks:
The Item function is useful together with the Contains function since the latter function returns the index to an
item in the multi-valued attribute.
Throws an error if index is out of bounds.
Example:
Mid(Item([proxyAddresses],Contains([proxyAddresses], "SMTP:")),6)
Returns the primary email address.
ItemOrNull
Description:
The ItemOrNull function returns one item from a multi-valued string/attribute.
Syntax:
var ItemOrNull(mvstr attribute, num index)
attribute: multi-valued attribute

index: index to an item in the multi-valued string.
Remarks:
The ItemOrNull function is useful together with the Contains function since the latter function returns the index to
an item in the multi-valued attribute.
If index is out of bounds, then returns a Null value.
Join
Description:
The Join function takes a multi-valued string and returns a single-valued string with specified separator inserted
between each item.
Syntax:
str Join(mvstr attribute)
str Join(mvstr attribute, str Delimiter)
attribute: Multi-valued attribute containing strings to be joined.

delimiter: Any string, used to separate the substrings in the returned string. If omitted, the space character (" ")
is used. If Delimiter is a zero-length string ("") or Nothing, all items in the list are concatenated with no
delimiters.
Remarks
There is parity between the Join and Split functions. The Join function takes an array of strings and joins them
using a delimiter string, to return a single string. The Split function takes a string and separates it at the delimiter,
to return an array of strings. However, a key difference is that Join can concatenate strings with any delimiter
string, Split can only separate strings using a single character delimiter.
Example:
Join([proxyAddresses],",")
Could return: "SMTP:john.doe@contoso.com,smtp:jd@contoso.com"
LCase
Description:
The LCase function converts all characters in a string to lower case.
Syntax:
str LCase(str value)
Example:
LCase("TeSt")
Returns "test".
Left
Description:
The Left function returns a specified number of characters from the left of a string.
Syntax:
str Left(str string, num NumChars)
string: the string to return characters from

NumChars: a number identifying the number of characters to return from the beginning (left) of string
Remarks:
A string containing the first numChars characters in string:
If numChars = 0, return empty string.
If numChars < 0, return input string.
If string is null, return empty string.
If string contains fewer characters than the number specified in numChars, a string identical to string (that is,
containing all characters in parameter 1) is returned.
Example:
Left("John Doe", 3)
Returns "Joh".
Len
Description:
The Len function returns number of characters in a string.
Syntax:
num Len(str value)
Example:
Len("John Doe")
Returns 8
LTrim
Description:
The LTrim function removes leading white spaces from a string.
Syntax:
str LTrim(str value)
Example:
LTrim(" Test ")
Returns "Test "
Mid
Description:
The Mid function returns a specified number of characters from a specified position in a string.
Syntax:
str Mid(str string, num start, num NumChars)

start: a number identifying the starting position in string to return characters from
NumChars: a number identifying the number of characters to return from position in string
Remarks:
Return numChars characters starting from position start in string.
A string containing numChars characters from position start in string:
If start > the length of string, return input string.
If start <= 0, return input string.
If there are not numChar characters remaining in string from position start, as many characters as possible are
returned.
Example:
Mid("John Doe", 3, 5)
Returns "hn Do".
Mid("John Doe", 6, 999)
Returns "Doe"
Now
Description:
The Now function returns a DateTime specifying the current date and time, according to your computer's system
date and time.
Syntax:
dt Now()
NumFromDate
Description:
The NumFromDate function returns a date in AD’s date format.
Syntax:
num NumFromDate(dt value)
Example:
NumFromDate(CDate("2012-01-01 23:00:00"))
Returns 129699324000000000
PadLeft
Description:
The PadLeft function left-pads a string to a specified length using a provided padding character.
Syntax:
str PadLeft(str string, num length, str padCharacter)
string: the string to pad.

length: An integer representing the desired length of string.
padCharacter: A string consisting of a single character to use as the pad character
Remarks:
If the length of string is less than length, then padCharacter is repeatedly appended to the beginning (left) of
string until it has a length equal to length.
PadCharacter can be a space character, but it cannot be a null value.
If the length of string is equal to or greater than length, string is returned unchanged.
If string has a length greater than or equal to length, a string identical to string is returned.
If the length of string is less than length, then a new string of the desired length is returned containing string
padded with a padCharacter.
If string is null, the function returns an empty string.
Example:
PadLeft("User", 10, "0")
Returns "000000User".
PadRight
Description:
The PadRight function right-pads a string to a specified length using a provided padding character.
Syntax:
str PadRight(str string, num length, str padCharacter)
string: the string to pad.

length: An integer representing the desired length of string.
padCharacter: A string consisting of a single character to use as the pad character
Remarks:
If the length of string is less than length, then padCharacter is repeatedly appended to the end (right) of string
until it has a length equal to length.
padCharacter can be a space character, but it cannot be a null value.
If the length of string is equal to or greater than length, string is returned unchanged.
If string has a length greater than or equal to length, a string identical to string is returned.
If the length of string is less than length, then a new string of the desired length is returned containing string
padded with a padCharacter.
If string is null, the function returns an empty string.
Example:
PadRight("User", 10, "0")
Returns "User000000".
PCase
Description:
The PCase function converts the first character of each space delimited word in a string to upper case, and all
other characters are converted to lower case.
Syntax:
String PCase(string)
Remarks:
This function does not currently provide proper casing to convert a word that is entirely uppercase, such as an
acronym.
Example:
PCase("TEsT")
Returns "Test".
PCase(LCase("TEST"))
Returns "Test"
RandomNum
Description:
The RandomNum function returns a random number between a specified interval.
Syntax:
num RandomNum(num start, num end)
start: a number identifying the lower limit of the random value to generate
end: a number identifying the upper limit of the random value to generate
Example:
Random(100,999)
Can return 734.
RemoveDuplicates
Description:
The RemoveDuplicates function takes a multi-valued string and make sure each value is unique.
Syntax:
mvstr RemoveDuplicates(mvstr attribute)
Example:
RemoveDuplicates([proxyAddresses])
Returns a sanitized proxyAddress attribute where all duplicate values have been removed.
Replace
Description:
The Replace function replaces all occurrences of a string to another string.
Syntax:
str Replace(str string, str OldValue, str NewValue)
string: A string to replace values in.

OldValue: The string to search for and to replace.
NewValue: The string to replace to.
Remarks:
The function recognizes the following special monikers:
\n – New Line
\r – Carriage Return
\t – Tab
Example:
Replace([address],"\r\n",", ")
Replaces CRLF with a comma and space, and could lead to "One Microsoft Way, Redmond, WA, USA"
ReplaceChars
Description:
The ReplaceChars function replaces all occurrences of characters found in the ReplacePattern string.
Syntax:
str ReplaceChars(str string, str ReplacePattern)
string: A string to replace characters in.

ReplacePattern: a string containing a dictionary with characters to replace.
The format is {source1}:{target1},{source2}:{target2},{sourceN},{targetN} where source is the character to find and
target the string to replace with.
Remarks:
The function takes each occurrence of defined sources and replaces them with the targets.
The source must be exactly one (unicode) character.
The source cannot be empty or longer than one character (parsing error).
The target can have multiple characters, for example ö:oe, β:ss.
The target can be empty indicating that the character should be removed.
The source is case-sensitive and must be an exact match.
The , (comma) and : (colon) are reserved characters and cannot be replaced using this function.
Spaces and other white characters in the ReplacePattern string are ignored.
Example:
%ReplaceString% = ’:,Å:A,Ä:A,Ö:O,å:a,ä:a,ö,o
ReplaceChars("Räksmörgås",%ReplaceString%)
Returns Raksmorgas
ReplaceChars("O’Neil",%ReplaceString%)
Returns "ONeil", the single tick is defined to be removed.
Right
Description:
The Right function returns a specified number of characters from the right (end) of a string.
Syntax:
str Right(str string, num NumChars)

NumChars: a number identifying the number of characters to return from the end (right) of string
Remarks:
NumChars characters are returned from the last position of string.
A string containing the last numChars characters in string:
If string contains fewer characters than the number specified in NumChars, a string identical to string is returned.
Example:
Right("John Doe", 3)
Returns "Doe".
RTrim
Description:
The RTrim function removes trailing white spaces from a string.
Syntax:
str RTrim(str value)
Example:
RTrim(" Test ")
Returns " Test".
Select
Description:
Process all values in a multi-valued attribute (or output of an expression) based on function specified.
Syntax:
mvattr Select(variable item, mvattr attribute, func function)
mvattr Select(variable item, exp expression, func function)
item: Represents an element in the multi-valued attribute

attribute: the multi-valued attribute
expression: an expression that returns a collection of values
condition: any function that can process an item in the attribute
Examples:
Select($item,[otherPhone],Replace($item,"-",""))
Return all the values in the multi-valued attribute otherPhone after hyphens (-) have been removed.
Split
Description:
The Split function takes a string separated with a delimiter and makes it a multi-valued string.
Syntax:
mvstr Split(str value, str delimiter)
mvstr Split(str value, str delimiter, num limit)
value: the string with a delimiter character to separate.

delimiter: single character to be used as the delimiter.
limit: maximum number of values that can return.
Example:
Split("SMTP:john.doe@contoso.com,smtp:jd@contoso.com",",")
Returns a multi-valued string with 2 elements useful for the proxyAddress attribute.
StringFromGuid
Description:
The StringFromGuid function takes a binary GUID and converts it to a string
Syntax:
str StringFromGuid(bin GUID)
StringFromSid
Description:
The StringFromSid function converts a byte array containing a security identifier to a string.
Syntax:
str StringFromSid(bin ObjectSID)
Switch
Description:
The Switch function is used to return a single value based on evaluated conditions.
Syntax:
var Switch(exp expr1, var value1[, exp expr2, var value … [, exp expr, var valueN]])
expr: Variant expression you want to evaluate.

value: Value to be returned if the corresponding expression is True.
Remarks:
The Switch function argument list consists of pairs of expressions and values. The expressions are evaluated from
left to right, and the value associated with the first expression to evaluate to True is returned. If the parts aren't
properly paired, a run-time error occurs.
For example, if expr1 is True, Switch returns value1. If expr-1 is False, but expr-2 is True, Switch returns value-2,
and so on.
Switch returns a Nothing if:
None of the expressions are True.
The first True expression has a corresponding value that is Null.
Switch evaluates all expressions, even though it returns only one of them. For this reason, you should watch for
undesirable side effects. For example, if the evaluation of any expression results in a division by zero error, an
error occurs.
Value can also be the Error function, which would return a custom string.
Example:
Switch([city] = "London", "English", [city] = "Rome", "Italian", [city] = "Paris", "French", True,
Error("Unknown city"))
Returns the language spoken in some major cities, otherwise returns an Error.
Trim
Description:
The Trim function removes leading and trailing white spaces from a string.
Syntax:
str Trim(str value)
Example:
Trim(" Test ")
Returns "Test".
Trim([proxyAddresses])
Removes leading and trailing spaces for each value in the proxyAddress attribute.
UCase
Description:
The UCase function converts all characters in a string to upper case.
Syntax:
str UCase(str string)
Example:
UCase("TeSt")
Returns "TEST".
Where
Description:
Returns a subset of values from a multi-valued attribute (or output of an expression) based on specific condition.
Syntax:
mvattr Where(variable item, mvattr attribute, exp condition)
mvattr Where(variable item, exp expression, exp condition)
item: Represents an element in the multi-valued attribute

attribute: the multi-valued attribute
condition: any expression that can be evaluated to true or false
expression: an expression that returns a collection of values
Example:
Where($item,[userCertificate],CertNotAfter($item)>Now())
Return the certificate values in the multi-valued attribute userCertificate which aren’t expired.
With
Description:
The With function provides a way to simplify a complex expression by using a variable to represent a
subexpression which appears one or more times in the complex expression.
Syntax: With(var variable, exp subExpression, exp complexExpression)
variable: Represents the subexpression.

subExpression: subexpression represented by variable.
complexExpression: A complex expression.
Example:
With($unExpiredCerts,Where($item,
[userCertificate],CertNotAfter($item)>Now()),IIF(Count($unExpiredCerts)>0,$unExpiredCerts,NULL))
Is functionally equivalent to:
IIF (Count(Where($item,[userCertificate],CertNotAfter($item)>Now()))>0, Where($item,
[userCertificate],CertNotAfter($item)>Now()),NULL)
Which returns only unexpired certificate values in the userCertificate attribute.
Word
Description:
The Word function returns a word contained within a string, based on parameters describing the delimiters to use
and the word number to return.
Syntax:
str Word(str string, num WordNumber, str delimiters)
string: the string to return a word from.

WordNumber: a number identifying which word number should return.
delimiters: a string representing the delimiter(s) that should be used to identify words
Remarks:
Each string of characters in string separated by the one of the characters in delimiters are identified as words:
If number < 1, returns empty string.
If string is null, returns empty string.
If string contains less than number words, or string does not contain any words identified by delimiters, an empty
string is returned.
Example:
Word("The quick brown fox",3," ")
Returns "brown"
Word("This,string!has&many separators",3,",!&#")
Would return "has"
Understanding Declarative Provisioning Expressions
Azure Active Directory provides single-sign on and enhanced application access security for Office 365 and other
Microsoft Online services for hybrid and cloud-only implementations without requiring any third party solution.
Office 365, like most of Microsoft’s Online services, is integrated with Azure Active Directory for directory
services, authentication, and authorization. Azure Active Directory also provides single sign-on to thousands of
SaaS applications and on-premises web applications. See the Azure Active Directory application gallery for
supported SaaS applications.
IDP Validation
If your organization uses a third-party federation solution, you can configure single sign-on for your on-
premises Active Directory users with Microsoft Online services, such as Office 365, provided the third-party
federation solution is compatible with Azure Active Directory. For questions regarding compatibility, please
contact your identity provider. If you would like to see a list of identity providers who have previously been
tested for compatibility with Azure AD, by Microsoft, click here.
NOTE
Microsoft no longer provides validation testing to independent identity providers for compatibility with Azure Active
Directory. If you would like to test your product for interoperability please refer to these guidelines.
Next Steps
TLS 1.2 enforcement for Azure AD Connect
Transport Layer Security (TLS) protocol version 1.2 is a cryptography protocol that is designed to provide secure
communications. The TLS protocol aims primarily to provide privacy and data integrity. TLS has gone through
many iterations with version 1.2 being defined in RFC 5246. Azure Active Directory Connect version 1.2.65.0 and
later now fully support using only TLS 1.2 for communications with Azure. This document will provide information
on how to force your Azure AD Connect server to use only TLS 1.2.
Update the registry

In order to force the Azure AD Connect server to only use TLS 1.2 the registry of the Windows server must be
updated. Set the following registry keys on the Azure AD Connect server.
IMPORTANT
After you have updated the registry, you must restart the Windows server for the changes to take affect.
Enable TLS 1.2

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Server]
"Enabled"=dword:00000001
1.2\Server]
"DisabledByDefault"=dword:00000000
1.2\Client]
1.2\Client]
PowerShell script to enable TLS 1.2
You can use the following PowerShell script to enable TLS 1.2 on your Azure AD Connect server.
New-Item 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -name

'SystemDefaultTlsVersions' -value '1' -PropertyType 'DWord' -Force | Out-Null

'SchUseStrongCrypto' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -name 'SystemDefaultTlsVersions' -

value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -name 'SchUseStrongCrypto' -value

'1' -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force |

Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS

1.2\Server' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force | Out-Null

1.2\Server' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Force |

Out-Null

1.2\Client' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force | Out-Null

1.2\Client' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force | Out-Null
Write-Host 'TLS 1.2 has been enabled.'
Disable TLS 1.2

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
1.2\Server]
1.2\Server]
1.2\Client]
1.2\Client]
PowerShell script to disable TLS 1.2
You can use the following PowerShell script to disable TLS 1.2 on your Azure AD Connect server.\
New-Item 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null

'SystemDefaultTlsVersions' -value '0' -PropertyType 'DWord' -Force | Out-Null

'SchUseStrongCrypto' -value '0' -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -name 'SystemDefaultTlsVersions' -

value '0' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -name 'SchUseStrongCrypto' -value

'0' -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force |

Out-Null

1.2\Server' -name 'Enabled' -value '0' -PropertyType 'DWord' -Force | Out-Null

1.2\Server' -name 'DisabledByDefault' -value 1 -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Force |

Out-Null

1.2\Client' -name 'Enabled' -value '0' -PropertyType 'DWord' -Force | Out-Null

1.2\Client' -name 'DisabledByDefault' -value 1 -PropertyType 'DWord' -Force | Out-Null
Write-Host 'TLS 1.2 has been disabled.'
Next steps
Azure AD Connect: ADSyncConfig PowerShell
Reference
The following documentation provides reference information for the ADSyncConfig.psm1 PowerShell Module that
is included with Azure AD Connect.
SYNOPSIS
Gets the account name and domain that is configured in each AD Connector
SYNTAX
DESCRIPTION
This function uses the 'Get-ADSyncConnector' cmdlet that is present in AAD Connect to retrieve from Connectivity
Parameters a table showing the AD Connector(s) account.
EXAMPLES
EXAMPLE 1
Get-ADSyncObjectsWithInheritanceDisabled
SYNOPSIS
Gets AD objects with permission inheritance disabled
SYNTAX
Get-ADSyncObjectsWithInheritanceDisabled [-SearchBase] <String> [[-ObjectClass] <String>] [<CommonParameters>]
DESCRIPTION
Searches in AD starting from the SearchBase parameter and returns all objects, filtered by ObjectClass parameter,
that have the ACL Inheritance currently disabled.
EXAMPLES
EXAMPLE 1
Find objects with disabled inheritance in 'Contoso' domain (by default returns 'organizationalUnit' objects only)
Get-ADSyncObjectsWithInheritanceDisabled -SearchBase 'Contoso'
EXAMPLE 2
Find 'user' objects with disabled inheritance in 'Contoso' domain
Get-ADSyncObjectsWithInheritanceDisabled -SearchBase 'Contoso' -ObjectClass 'user'
EXAMPLE 3
Find all types of objects with disabled inheritance in a OU
Get-ADSyncObjectsWithInheritanceDisabled -SearchBase OU=AzureAD,DC=Contoso,DC=com -ObjectClass '*'
PARAMETERS
-SearchBase
The SearchBase for the LDAP query that can be an AD Domain DistinguishedName or a FQDN
Type: String
Parameter Sets: (All)
Aliases:
Required: True
Position: 1
Default value: None
Accept pipeline input: False
Accept wildcard characters: False
-ObjectClass
The class of the objects to search that can be '*' (for any object class), 'user', 'group', 'container', etc. By default, this
function will search for 'organizationalUnit' object class.
Type: String
Aliases:
Required: False
Position: 2
Default value: OrganizationalUnit
CommonParameters
This cmdlet supports the common parameters: -Debug, -ErrorAction, -ErrorVariable, -InformationAction, -
InformationVariable, -OutVariable, -OutBuffer, -PipelineVariable, -Verbose, -WarningAction, and -WarningVariable.
For more information, see about_CommonParameters (https://go.microsoft.com/fwlink/?LinkID=113216).
Set-ADSyncBasicReadPermissions
SYNOPSIS
Initialize your Active Directory forest and domain for basic read permissions.
SYNTAX
UserDomain
Set-ADSyncBasicReadPermissions -ADConnectorAccountName <String> -ADConnectorAccountDomain <String>

[-ADobjectDN <String>] [-SkipAdminSdHolders] [-WhatIf] [-Confirm] [<CommonParameters>]
DistinguishedName
Set-ADSyncBasicReadPermissions -ADConnectorAccountDN <String> [-ADobjectDN <String>] [-SkipAdminSdHolders]
[-WhatIf] [-Confirm] [<CommonParameters>]
DESCRIPTION
The Set-ADSyncBasicReadPermissions Function will give required permissions to the AD synchronization account,
which include the following: 1. Read Property access on all attributes for all descendant computer objects 2. Read
Property access on all attributes for all descendant device objects 3. Read Property access on all attributes for all
descendant foreignsecurityprincipal objects 5. Read Property access on all attributes for all descendant user objects
6. Read Property access on all attributes for all descendant inetorgperson objects 7. Read Property access on all
attributes for all descendant group objects 8. Read Property access on all attributes for all descendant contact
objects
These permissions are applied to all domains in the forest. Optionally you can provide a DistinguishedName in
ADobjectDN parameter to set these permissions on that AD Object only (including inheritance to sub objects).
EXAMPLES
EXAMPLE 1
Set-ADSyncBasicReadPermissions -ADConnectorAccountName 'ADConnector' -ADConnectorAccountDomain 'Contoso.com'
EXAMPLE 2
Set-ADSyncBasicReadPermissions -ADConnectorAccountDN 'CN=ADConnector,OU=AzureAD,DC=Contoso,DC=com'
EXAMPLE 3
Set-ADSyncBasicReadPermissions -ADConnectorAccountDN 'CN=ADConnector,OU=AzureAD,DC=Contoso,DC=com' -

SkipAdminSdHolders
EXAMPLE 4
Set-ADSyncBasicReadPermissions -ADConnectorAccountName 'ADConnector' -ADConnectorAccountDomain 'Contoso.com' -

ADobjectDN 'OU=AzureAD,DC=Contoso,DC=com'
PARAMETERS
-ADConnectorAccountName
The Name of the Active Directory account that is or will be used by Azure AD Connect Sync to manage objects in
the directory.
Type: String
Parameter Sets: UserDomain
Aliases:
Required: True
Position: Named
Default value: None
-ADConnectorAccountDomain
The Domain of the Active Directory account that is or will be used by Azure AD Connect Sync to manage objects in
the directory.
Type: String
Aliases:
Required: True
Position: Named
Default value: None
-ADConnectorAccountDN
The DistinguishedName of the Active Directory account that is or will be used by Azure AD Connect Sync to
manage objects in the directory.
Type: String
Parameter Sets: DistinguishedName
Aliases:
Required: True
Position: Named
Default value: None
-ADobjectDN
DistinguishedName of the target AD object to set permissions (optional)
Type: String
Aliases:
Required: False
Position: Named
Default value: None
-SkipAdminSdHolders
Optional parameter to indicate if AdminSDHolder container should not be updated with these permissions
Type: SwitchParameter
Aliases:
Required: False
Position: Named
Default value: False
-WhatIf
Shows what would happen if the cmdlet runs. The cmdlet is not run.
Aliases: wi
Required: False
Position: Named
Default value: None
-Confirm
Prompts you for confirmation before running the cmdlet.
Aliases: cf
Required: False
Position: Named
Default value: None
CommonParameters
Set-ADSyncExchangeHybridPermissions
SYNOPSIS
Initialize your Active Directory forest and domain for Exchange Hybrid feature.
SYNTAX
UserDomain
Set-ADSyncExchangeHybridPermissions -ADConnectorAccountName <String> -ADConnectorAccountDomain <String>

DistinguishedName
Set-ADSyncExchangeHybridPermissions -ADConnectorAccountDN <String> [-ADobjectDN <String>] [-

SkipAdminSdHolders]
DESCRIPTION
The Set-ADSyncExchangeHybridPermissions Function will give required permissions to the AD synchronization
account, which include the following: 1. Read/Write Property access on all attributes for all descendant user objects
2. Read/Write Property access on all attributes for all descendant inetorgperson objects 3. Read/Write Property
access on all attributes for all descendant group objects 4. Read/Write Property access on all attributes for all
descendant contact objects
EXAMPLES
EXAMPLE 1
Set-ADSyncExchangeHybridPermissions -ADConnectorAccountName 'ADConnector' -ADConnectorAccountDomain

'Contoso.com'
EXAMPLE 2
Set-ADSyncExchangeHybridPermissions -ADConnectorAccountDN 'CN=ADConnector,OU=AzureAD,DC=Contoso,DC=com'
EXAMPLE 3
Set-ADSyncExchangeHybridPermissions -ADConnectorAccountDN 'CN=ADConnector,OU=AzureAD,DC=Contoso,DC=com' -

SkipAdminSdHolders
EXAMPLE 4
Set-ADSyncExchangeHybridPermissions -ADConnectorAccountName 'ADConnector' -ADConnectorAccountDomain

'Contoso.com' -ADobjectDN 'OU=AzureAD,DC=Contoso,DC=com'
PARAMETERS
the directory.
Type: String
Aliases:
Required: True
Position: Named
Default value: None
the directory.
Type: String
Aliases:
Required: True
Position: Named
Default value: None
Type: String
Aliases:
Required: True
Position: Named
Default value: None
-ADobjectDN
Type: String
Aliases:
Required: False
Position: Named
Default value: None
-SkipAdminSdHolders
Aliases:
Required: False
Position: Named
-WhatIf
Aliases: wi
Required: False
Position: Named
Default value: None
-Confirm
Aliases: cf
Required: False
Position: Named
Default value: None
CommonParameters
Set-ADSyncExchangeMailPublicFolderPermissions
SYNOPSIS
Initialize your Active Directory forest and domain for Exchange Mail Public Folder feature.
SYNTAX
UserDomain
Set-ADSyncExchangeMailPublicFolderPermissions -ADConnectorAccountName <String>

-ADConnectorAccountDomain <String> [-ADobjectDN <String>] [-SkipAdminSdHolders] [-WhatIf] [-Confirm]
DistinguishedName
Set-ADSyncExchangeMailPublicFolderPermissions -ADConnectorAccountDN <String> [-ADobjectDN <String>]

[-SkipAdminSdHolders] [-WhatIf] [-Confirm] [<CommonParameters>]
DESCRIPTION
The Set-ADSyncExchangeMailPublicFolderPermissions Function will give required permissions to the AD
synchronization account, which include the following: 1. Read Property access on all attributes for all descendant
publicfolder objects
EXAMPLES
EXAMPLE 1
Set-ADSyncExchangeMailPublicFolderPermissions -ADConnectorAccountName 'ADConnector' -ADConnectorAccountDomain

'Contoso.com'
EXAMPLE 2
Set-ADSyncExchangeMailPublicFolderPermissions -ADConnectorAccountDN
'CN=ADConnector,OU=AzureAD,DC=Contoso,DC=com'
EXAMPLE 3
Set-ADSyncExchangeMailPublicFolderPermissions -ADConnectorAccountDN
'CN=ADConnector,OU=AzureAD,DC=Contoso,DC=com' -SkipAdminSdHolders
EXAMPLE 4
Set-ADSyncExchangeMailPublicFolderPermissions -ADConnectorAccountName 'ADConnector' -ADConnectorAccountDomain

PARAMETERS
the directory.
Type: String
Aliases:
Required: True
Position: Named
Default value: None
the directory.
Type: String
Aliases:
Required: True
Position: Named
Default value: None
Type: String
Aliases:
Required: True
Position: Named
Default value: None
-ADobjectDN
Type: String
Aliases:
Required: False
Position: Named
Default value: None
-SkipAdminSdHolders
Aliases:
Required: False
Position: Named
-WhatIf
Aliases: wi
Required: False
Position: Named
Default value: None
-Confirm
Aliases: cf
Required: False
Position: Named
Default value: None
CommonParameters
Set-ADSyncMsDsConsistencyGuidPermissions
SYNOPSIS
Initialize your Active Directory forest and domain for mS-DS-ConsistencyGuid feature.
SYNTAX
UserDomain
Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountName <String> -ADConnectorAccountDomain <String>

DistinguishedName
Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountDN <String> [-ADobjectDN <String>]

DESCRIPTION
The Set-ADSyncMsDsConsistencyGuidPermissions Function will give required permissions to the AD
synchronization account, which include the following: 1. Read/Write Property access on mS-DS-ConsistencyGuid
attribute for all descendant user objects
EXAMPLES
EXAMPLE 1
Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountName 'ADConnector' -ADConnectorAccountDomain

'Contoso.com'
EXAMPLE 2
Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountDN 'CN=ADConnector,OU=AzureAD,DC=Contoso,DC=com'
EXAMPLE 3
Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountDN 'CN=ADConnector,OU=AzureAD,DC=Contoso,DC=com' -

SkipAdminSdHolders
EXAMPLE 4
Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountName 'ADConnector' -ADConnectorAccountDomain

PARAMETERS
the directory.
Type: String
Aliases:
Required: True
Position: Named
Default value: None
the directory.
Type: String
Aliases:
Required: True
Position: Named
Default value: None
Type: String
Aliases:
Required: True
Position: Named
Default value: None
-ADobjectDN
Type: String
Aliases:
Required: False
Position: Named
Default value: None
-SkipAdminSdHolders
Aliases:
Required: False
Position: Named
-WhatIf
Aliases: wi
Required: False
Position: Named
Default value: None
-Confirm
Aliases: cf
Required: False
Position: Named
Default value: None
CommonParameters
Set-ADSyncPasswordHashSyncPermissions
SYNOPSIS
Initialize your Active Directory forest and domain for password hash synchronization.
SYNTAX
UserDomain
Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountName <String> -ADConnectorAccountDomain <String>

DistinguishedName
Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountDN <String> [-WhatIf] [-Confirm] [<CommonParameters>]
DESCRIPTION
The Set-ADSyncPasswordHashSyncPermissions Function will give required permissions to the AD synchronization
account, which include the following: 1. Replicating Directory Changes 2. Replicating Directory Changes All
These permissions are given to all domains in the forest.
EXAMPLES
EXAMPLE 1
Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountName 'ADConnector' -ADConnectorAccountDomain

'Contoso.com'
EXAMPLE 2
Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountDN 'CN=ADConnector,OU=AzureAD,DC=Contoso,DC=com'
PARAMETERS
The Name of the Active Directory account that will be used by Azure AD Connect Sync to manage objects in the
directory.
Type: String
Aliases:
Required: True
Position: Named
Default value: None
The Domain of the Active Directory account that will be used by Azure AD Connect Sync to manage objects in the
directory.
Type: String
Aliases:
Required: True
Position: Named
Default value: None
The DistinguishedName of the Active Directory account that will be used by Azure AD Connect Sync to manage
objects in the directory.
Type: String
Aliases:
Required: True
Position: Named
Default value: None
-WhatIf
Aliases: wi
Required: False
Position: Named
Default value: None
-Confirm
Aliases: cf
Required: False
Position: Named
Default value: None
CommonParameters
Set-ADSyncPasswordWritebackPermissions
SYNOPSIS
Initialize your Active Directory forest and domain for password write-back from Azure AD.
SYNTAX
UserDomain
Set-ADSyncPasswordWritebackPermissions -ADConnectorAccountName <String> -ADConnectorAccountDomain <String>

DistinguishedName
Set-ADSyncPasswordWritebackPermissions -ADConnectorAccountDN <String> [-ADobjectDN <String>]

DESCRIPTION
The Set-ADSyncPasswordWritebackPermissions Function will give required permissions to the AD synchronization
account, which include the following: 1. Reset Password on descendant user objects 2. Write Property access on
lockoutTime attribute for all descendant user objects 3. Write Property access on pwdLastSet attribute for all
descendant user objects
EXAMPLES
EXAMPLE 1
Set-ADSyncPasswordWritebackPermissions -ADConnectorAccountName 'ADConnector' -ADConnectorAccountDomain

'Contoso.com'
EXAMPLE 2
Set-ADSyncPasswordWritebackPermissions -ADConnectorAccountDN 'CN=ADConnector,OU=AzureAD,DC=Contoso,DC=com'
EXAMPLE 3
Set-ADSyncPasswordWritebackPermissions -ADConnectorAccountDN 'CN=ADConnector,OU=AzureAD,DC=Contoso,DC=com' -
SkipAdminSdHolders
EXAMPLE 4
Set-ADSyncPasswordWritebackPermissions -ADConnectorAccountName 'ADConnector' -ADConnectorAccountDomain

PARAMETERS
the directory.
Type: String
Aliases:
Required: True
Position: Named
Default value: None
the directory.
Type: String
Aliases:
Required: True
Position: Named
Default value: None
Type: String
Aliases:
Required: True
Position: Named
Default value: None
-ADobjectDN
Type: String
Aliases:
Required: False
Position: Named
Default value: None
-SkipAdminSdHolders
Aliases:
Required: False
Position: Named
-WhatIf
Aliases: wi
Required: False
Position: Named
Default value: None
-Confirm
Aliases: cf
Required: False
Position: Named
Default value: None
CommonParameters
Set-ADSyncRestrictedPermissions
SYNOPSIS
Tighten permissions on an AD object that is not otherwise included in any AD protected security group. A typical
example is the AD Connect account (MSOL) created by AAD Connect automatically. This account has replicate
permissions on all domains, however can be easily compromised as it is not protected.
SYNTAX
Set-ADSyncRestrictedPermissions [-ADConnectorAccountDN] <String> [-Credential] <PSCredential>

[-DisableCredentialValidation] [-WhatIf] [-Confirm] [<CommonParameters>]
DESCRIPTION
The Set-ADSyncRestrictedPermissions Function will tighten permissions oo the account provided. Tightening
permissions involves the following steps:
1. Disable inheritance on the specified object
2. Remove all ACEs on the specific object, except ACEs specific to SELF. We want to keep the default
permissions intact when it comes to SELF.
3. Assign these specific permissions:

Controllers Read All Properties
Read Permissions

Read All Properties
Read Permissions
EXAMPLES
EXAMPLE 1
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=TestAccount1,CN=Users,DC=Contoso,DC=com" -Credential

$(Get-Credential)
PARAMETERS
DistinguishedName of the Active Directory account whose permissions need to be tightened. This is typically the
MSOL_nnnnnnnnnn account or a custom domain account that is configured in your AD Connector.
Type: String
Aliases:
Required: True
Position: 1
Default value: None
-Credential
Administrator credential that has the necessary privileges to restrict the permissions on the
ADConnectorAccountDN account. This is typically the Enterprise or Domain administrator. Use the fully qualified
domain name of the administrator account to avoid account lookup failures. Example: CONTOSO\admin
Type: PSCredential
Aliases:
Required: True
Position: 2
Default value: None
-DisableCredentialValidation
When DisableCredentialValidation is used, the function will not check if the credentials provided in -Credential are
valid in AD and if the account provided has the necessary privileges to restrict the permissions on the
ADConnectorAccountDN account.
Aliases:
Required: False
Position: Named
-WhatIf
Aliases: wi
Required: False
Position: Named
Default value: None
-Confirm
Aliases: cf
Required: False
Position: Named
Default value: None
CommonParameters
Set-ADSyncUnifiedGroupWritebackPermissions
SYNOPSIS
Initialize your Active Directory forest and domain for Group writeback from Azure AD.
SYNTAX
UserDomain
Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountName <String> -ADConnectorAccountDomain <String>

DistinguishedName
Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountDN <String> [-ADobjectDN <String>]

DESCRIPTION
The Set-ADSyncUnifiedGroupWritebackPermissions Function will give required permissions to the AD
synchronization account, which include the following: 1. Generic Read/Write, Delete, Delete Tree and Create\Delete
Child for all group Object types and SubObjects
ADobjectDN parameter to set these permissions on that AD Object only (including inheritance to sub objects). In
this case, ADobjectDN will be the Distinguished Name of the Container that you desire to link with the
GroupWriteback feature.
EXAMPLES
EXAMPLE 1
Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountName 'ADConnector' -ADConnectorAccountDomain

'Contoso.com'
EXAMPLE 2
Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountDN 'CN=ADConnector,OU=AzureAD,DC=Contoso,DC=com'
EXAMPLE 3
Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountDN 'CN=ADConnector,OU=AzureAD,DC=Contoso,DC=com'
-SkipAdminSdHolders
EXAMPLE 4
Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountName 'ADConnector' -ADConnectorAccountDomain

PARAMETERS
the directory.
Type: String
Aliases:
Required: True
Position: Named
Default value: None
the directory.
Type: String
Aliases:
Required: True
Position: Named
Default value: None
Type: String
Aliases:
Required: True
Position: Named
Default value: None
-ADobjectDN
Type: String
Aliases:
Required: False
Position: Named
Default value: None
-SkipAdminSdHolders
Aliases:
Required: False
Position: Named
-WhatIf
Aliases: wi
Required: False
Position: Named
Default value: None
-Confirm
Aliases: cf
Required: False
Position: Named
Default value: None
CommonParameters
Show-ADSyncADObjectPermissions
SYNOPSIS
Shows permissions of a specified AD object.
SYNTAX
Show-ADSyncADObjectPermissions [-ADobjectDN] <String> [<CommonParameters>]
DESCRIPTION
This function returns all the AD permissions currently set for a given AD object provided in the parameter -
ADobjectDN. The ADobjectDN must be provided in a DistinguishedName format.
EXAMPLES
EXAMPLE 1
Show-ADSyncADObjectPermissions -ADobjectDN 'OU=AzureAD,DC=Contoso,DC=com'
PARAMETERS
-ADobjectDN
{{Fill ADobjectDN Description}}
Type: String
Aliases:
Required: True
Position: 1
Default value: None
CommonParameters
Azure AD Connect: ADSyncTools PowerShell
Reference
The following documentation provides reference information for the ADSyncTools.psm1 PowerShell Module that is
included with Azure AD Connect.
Install the ADSyncTools PowerShell Module

To install the ADSyncTools PowerShell Module do the following:
1. Open Windows PowerShell with administrative priviledges
2. Type or copy and paste the following:
Import-module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\Tools\AdSyncTools"
3. Hit enter.
4. To verify the module was installed, enter or copy and paste the following"
Get-module AdSyncTools
5. You should now see information about the module.
Clear-ADSyncToolsConsistencyGuid
SYNOPSIS
Clear the mS-Ds-ConsistencyGuid from AD User
SYNTAX
Clear-ADSyncToolsConsistencyGuid [-User] <Object> [<CommonParameters>]
DESCRIPTION
Clear the value in mS-Ds-ConsistencyGuid for the target AD user
EXAMPLES
EXAMPLE 1
Example of how to use this cmdlet
EXAMPLE 2
Another example of how to use this cmdlet
PARAMETERS
-User
Target User in AD to set
Type: Object
Aliases:
Required: True
Position: 1
Default value: None
Accept pipeline input: True (ByPropertyName, ByValue)
CommonParameters
Confirm-ADSyncToolsADModuleLoaded
SYNOPSIS
{{Fill in the Synopsis}}
SYNTAX
Confirm-ADSyncToolsADModuleLoaded
DESCRIPTION
{{Fill in the Description}}
EXAMPLES
Example 1
PS C:\> {{ Add example code here }}
{{ Add example description here }}
Connect-AdSyncDatabase
SYNOPSIS
SYNTAX
Connect-AdSyncDatabase [-Server] <String> [[-Instance] <String>] [[-Database] <String>] [[-UserName] <String>]

[[-Password] <String>] [<CommonParameters>]
DESCRIPTION
EXAMPLES
Example 1

PARAMETERS
-Database
{{Fill Database Description}}
Type: String
Aliases:
Required: False
Position: 2
Default value: None
-Instance
{{Fill Instance Description}}
Type: String
Aliases:
Required: False
Position: 1
Default value: None
-Password
{{Fill Password Description}}
Type: String
Aliases:
Required: False
Position: 4
Default value: None
-Server
{{Fill Server Description}}
Type: String
Aliases:
Required: True
Position: 0
Default value: None
-UserName
{{Fill UserName Description}}
Type: String
Aliases:
Required: False
Position: 3
Default value: None
CommonParameters
Export-ADSyncToolsConsistencyGuidMigration
SYNOPSIS
Export ConsistencyGuid Report
SYNTAX
Export-ADSyncToolsConsistencyGuidMigration [-AlternativeLoginId] [-UserPrincipalName] <String>

[-ImmutableIdGUID] <String> [-Output] <String> [<CommonParameters>]
DESCRIPTION
Generates a ConsistencyGuid report based on an import CSV file from Import-ADSyncToolsImmutableIdMigration
EXAMPLES
EXAMPLE 1
Import-Csv .\AllSyncUsers.csv | Export-ADSyncToolsConsistencyGuidMigration -Output ".\AllSyncUsers-Report"
EXAMPLE 2
PARAMETERS
-AlternativeLoginId
Use Alternative Login ID (mail)
Aliases:
Required: False
Position: Named
-UserPrincipalName
UserPrincipalName
Type: String
Aliases:
Required: True
Position: 1
Default value: None
-ImmutableIdGUID
ImmutableIdGUID
Type: String
Aliases:
Required: True
Position: 2
Default value: None
-Output
Output filename for CSV and LOG files
Type: String
Aliases:
Required: True
Position: 3
Default value: None
CommonParameters
Get-ADSyncSQLBrowserInstances
SYNOPSIS
SYNTAX
Get-ADSyncSQLBrowserInstances [[-hostName] <String>]
DESCRIPTION
EXAMPLES
Example 1

PARAMETERS
-hostName
{{Fill hostName Description}}
Type: String
Aliases:
Required: False
Position: 0
Default value: None
Get-ADSyncToolsADuser
SYNOPSIS
Get user from AD
SYNTAX
Get-ADSyncToolsADuser [-User] <Object> [<CommonParameters>]
DESCRIPTION
Returns an AD object TO DO: Multi forest support
EXAMPLES
EXAMPLE 1
EXAMPLE 2
PARAMETERS
-User
Target User in AD to set ConsistencyGuid
Type: Object
Aliases:
Required: True
Position: 1
Default value: None
CommonParameters
Get-ADSyncToolsConsistencyGuid
SYNOPSIS
Get the mS-Ds-ConsistencyGuid from AD User
SYNTAX
Get-ADSyncToolsConsistencyGuid [-User] <Object> [<CommonParameters>]
DESCRIPTION
Returns the value in mS-Ds-ConsistencyGuid attribute of the target AD user in GUID format
EXAMPLES
EXAMPLE 1
EXAMPLE 2
PARAMETERS
-User
Type: Object
Aliases:
Required: True
Position: 1
Default value: None
CommonParameters
Get-ADSyncToolsObjectGuid
SYNOPSIS
Get the ObjectGuid from AD User
SYNTAX
Get-ADSyncToolsObjectGuid [-User] <Object> [<CommonParameters>]
DESCRIPTION
Returns the value in ObjectGUID attribute of the target AD user in GUID format
EXAMPLES
EXAMPLE 1
EXAMPLE 2
PARAMETERS
-User
Type: Object
Aliases:
Required: True
Position: 1
Default value: None
CommonParameters
Get-ADSyncToolsRunHistory
SYNOPSIS
Get AAD Connect Run History
SYNTAX
Get-ADSyncToolsRunHistory [[-Days] <Int32>] [<CommonParameters>]
DESCRIPTION
Function that returns the AAD Connect Run History in XML format
EXAMPLES
EXAMPLE 1
Get-ADSyncToolsRunHistory
EXAMPLE 2
Get-ADSyncToolsRunHistory -Days 1
PARAMETERS
-Days
{{Fill Days Description}}
Type: Int32
Aliases:
Required: False
Position: 1
Default value: 3
CommonParameters
Get-ADSyncToolsSourceAnchorChanged
SYNOPSIS
Get users with SourceAnchor changed errors
SYNTAX
Get-ADSyncToolsSourceAnchorChanged [-sourcePath] <Object> [-outputPath] <Object> [<CommonParameters>]
DESCRIPTION
Function queries AAD Connect Run History and exports all the users reporting the Error: "SourceAnchor attribute
has changed."
EXAMPLES
EXAMPLE 1
#Required Parameters
$sourcePath = Read-Host -Prompt "Enter your log file path with file name" #"<Source_Path>" $outputPath = Read-
Host -Prompt "Enter your out file path with file name" #"<Out_Path>"
Get-ADSyncToolsUsersSourceAnchorChanged -sourcePath $sourcePath -outputPath $outputPath
EXAMPLE 2
PARAMETERS
-sourcePath
{{Fill sourcePath Description}}
Type: Object
Aliases:
Required: True
Position: 1
Default value: None
-outputPath
{{Fill outputPath Description}}
Type: Object
Aliases:
Required: True
Position: 2
Default value: None
CommonParameters
Import-ADSyncToolsImmutableIdMigration
SYNOPSIS
Import ImmutableID from AAD
SYNTAX
Import-ADSyncToolsImmutableIdMigration [-Output] <String> [-IncludeSyncUsersFromRecycleBin]

DESCRIPTION
Generates a file with all Azure AD Synchronized users containing the ImmutableID value in GUID format
Requirements: MSOnline PowerShell Module
EXAMPLES
EXAMPLE 1
Import-ADSyncToolsImmutableIdMigration -OutputFile '.\AllSyncUsers.csv'
EXAMPLE 2
PARAMETERS
-Output
Output CSV file
Type: String
Aliases:
Required: True
Position: 1
Default value: None
-IncludeSyncUsersFromRecycleBin
Get Synchronized Users from Azure AD Recycle Bin
Aliases:
Required: False
Position: Named
CommonParameters
Invoke-AdSyncDatabaseQuery
SYNOPSIS
SYNTAX
Invoke-AdSyncDatabaseQuery [-SqlConnection] <SqlConnection> [[-Query] <String>] [<CommonParameters>]
DESCRIPTION
EXAMPLES
Example 1

PARAMETERS
-Query
{{Fill Query Description}}
Type: String
Aliases:
Required: False
Position: 1
Default value: None
-SqlConnection
{{Fill SqlConnection Description}}
Type: SqlConnection
Aliases:
Required: True
Position: 0
Default value: None
CommonParameters
Remove-ADSyncToolsExpiredCertificates
SYNOPSIS
Script to Remove Expired Certificates from UserCertificate Attribute
SYNTAX
Remove-ADSyncToolsExpiredCertificates [-TargetOU] <String> [[-BackupOnly] <Boolean>] [-ObjectClass] <String>

DESCRIPTION
This script takes all the objects from a target Organizational Unit in your Active Directory domain - filtered by
Object Class (User/Computer) and deletes all expired certificates present in the UserCertificate attribute. By default
(BackupOnly mode) it will only backup expired certificates to a file and not do any changes in AD. If you use -
BackupOnly $false then any Expired Certificate present in UserCertificate attribute for these objects will be
removed from AD after being copied to file. Each certificate will be backed up to a separated filename:
ObjectClass_ObjectGUID_CertThumprint.cer The script will also create a log file in CSV format showing all the users
with certificates that either are valid or expired including the actual action taken (Skipped/Exported/Deleted).
EXAMPLES
EXAMPLE 1
Check all users in target OU - Expired Certificates will be copied to separated files and no certificates will
be removed
Remove-ADSyncToolsExpiredCertificates -TargetOU "OU=Users,OU=Corp,DC=Contoso,DC=com" -ObjectClass user

EXAMPLE 2
Delete Expired Certs from all Computer objects in target OU - Expired Certificates will be copied to files and
removed from AD
Remove-ADSyncToolsExpiredCertificates -TargetOU "OU=Computers,OU=Corp,DC=Contoso,DC=com" -

ObjectClass computer -BackupOnly $false
PARAMETERS
-TargetOU
Target OU to lookup for AD objects
Type: String
Aliases:
Required: True
Position: 1
Default value: None
-BackupOnly
BackupOnly will not delete any certificates from AD
Type: Boolean
Aliases:
Required: False
Position: 2
Default value: True
-ObjectClass
Object Class filter
Type: String
Aliases:
Required: True
Position: 3
Default value: None
CommonParameters
Repair-ADSyncToolsAutoUpgradeState
SYNOPSIS
Short description
SYNTAX
Repair-ADSyncToolsAutoUpgradeState
DESCRIPTION
Long description
EXAMPLES
EXAMPLE 1
EXAMPLE 2
Resolve-ADSyncHostAddress
SYNOPSIS
SYNTAX
Resolve-ADSyncHostAddress [[-hostName] <String>]
DESCRIPTION
EXAMPLES
Example 1

PARAMETERS
-hostName
Type: String
Aliases:
Required: False
Position: 0
Default value: None
Restore-ADSyncToolsExpiredCertificates
SYNOPSIS
(TO DO) Restores AD UserCertificate attribute from a certificate file
SYNTAX
Restore-ADSyncToolsExpiredCertificates
DESCRIPTION
Long description
EXAMPLES
EXAMPLE 1
EXAMPLE 2
Set-ADSyncToolsConsistencyGuid
SYNOPSIS
Set mS-Ds-ConsistencyGuid on AD User
SYNTAX
Set-ADSyncToolsConsistencyGuid [-User] <Object> [-Value] <Object> [<CommonParameters>]
DESCRIPTION
Set a value in mS-Ds-ConsistencyGuid attribute for the target AD user
EXAMPLES
EXAMPLE 1
EXAMPLE 2
PARAMETERS
-User
Target User in AD to set ConsistencyGuid
Type: Object
Aliases:
Required: True
Position: 1
Default value: None
-Value
ImmutableId (Byte array, GUID, GUID string or Base64 string)
Type: Object
Aliases:
Required: True
Position: 2
Default value: None
CommonParameters
Test-ADSyncNetworkPort
SYNOPSIS
SYNTAX
Test-ADSyncNetworkPort [[-hostName] <String>] [[-port] <String>]
DESCRIPTION
EXAMPLES
Example 1

PARAMETERS
-hostName
Type: String
Aliases:
Required: False
Position: 0
Default value: None
-port
{{Fill port Description}}
Type: String
Aliases:
Required: False
Position: 1
Default value: None
Trace-ADSyncToolsADImport
SYNOPSIS
Creates a trace file from and AD Import Step
SYNTAX
Trace-ADSyncToolsADImport [[-ADConnectorXML] <String>] [[-dc] <String>] [[-rootDN] <String>]

[[-filter] <String>] [-SkipCredentials] [[-ADwatermark] <String>] [<CommonParameters>]
DESCRIPTION
Traces all ldap queries of an AAD Connect AD Import run from a given AD watermark checkpoint (partition cookie).
Creates a trace file '.\ADimportTrace_yyyyMMddHHmmss.log' on the current folder.
EXAMPLES
EXAMPLE 1
EXAMPLE 2
PARAMETERS
-ADConnectorXML
{{Fill ADConnectorXML Description}}
Type: String
Aliases:
Required: False
Position: 1
Default value: None
-dc
XML file of AD Connector Export
Type: String
Aliases:
Required: False
Position: 2
Default value: DC1.domain.contoso.com
-rootDN
Target Domain Controller
Type: String
Aliases:
Required: False
Position: 3
Default value: DC=Domain,DC=Contoso,DC=com
-filter
Forest Root DN
Type: String
Aliases:
Required: False
Position: 4
Default value: (&(objectClass=*))
-SkipCredentials
Types of AD objects to trace > * = all object types
Aliases:
Required: False
Position: Named
-ADwatermark
If already running as Domain Administrator there's no need to provide AD credentials. Manual input of watermark,
instead of XML file e.g. $ADwatermark = "TVNEUwMAAAAXyK9ir1zSAQAAAAAAAAAA(...)"
Type: String
Aliases:
Required: False
Position: 5
Default value: None
CommonParameters
Trace-ADSyncToolsLdapQuery
SYNOPSIS
Short description
SYNTAX
Trace-ADSyncToolsLdapQuery [-Context] <String> [-Server] <String> [-Port] <Int32> [-Filter] <String>

DESCRIPTION
Long description
EXAMPLES
EXAMPLE 1
EXAMPLE 2
PARAMETERS
-Context
Param1 help description
Type: String
Aliases:
Required: True
Position: 1
Default value: None
-Server
Type: String
Aliases:
Required: True
Position: 2
Default value: Localhost
-Port
Type: Int32
Aliases:
Required: True
Position: 3
Default value: 389
-Filter
Type: String
Aliases:
Required: True
Position: 4
Default value: (objectClass=*)
CommonParameters
Update-ADSyncToolsConsistencyGuidMigration
SYNOPSIS
Updates users with the new ConsistencyGuid (ImmutableId)
SYNTAX
Update-ADSyncToolsConsistencyGuidMigration [[-DistinguishedName] <String>] [-ImmutableIdGUID] <String>

[-Action] <String> [-Output] <String> [-WhatIf] [-Confirm] [<CommonParameters>]
DESCRIPTION
Updates users with the new ConsistencyGuid (ImmutableId) value taken from the ConsistencyGuid Report This
function supports the WhatIf switch Note: ConsistencyGuid Report must be imported with Tab Demiliter
EXAMPLES
EXAMPLE 1
Import-Csv .\AllSyncUsersTEST-Report.csv -Delimiter "`t"| Update-ADSyncToolsConsistencyGuidMigration -Output
.\AllSyncUsersTEST-Result2 -WhatIf
EXAMPLE 2
Import-Csv .\AllSyncUsersTEST-Report.csv -Delimiter "`t"| Update-ADSyncToolsConsistencyGuidMigration -Output

.\AllSyncUsersTEST-Result2
PARAMETERS
-DistinguishedName
DistinguishedName
Type: String
Aliases:
Required: False
Position: 1
-ImmutableIdGUID
ImmutableIdGUID
Type: String
Aliases:
Required: True
Position: 2
Default value: None
-Action
Action
Type: String
Aliases:
Required: True
Position: 3
Default value: None
-Output
Output filename for LOG files
Type: String
Aliases:
Required: True
Position: 4
Default value: None
-WhatIf
Aliases: wi
Required: False
Position: Named
Default value: None
-Confirm
Aliases: cf
Required: False
Position: Named
Default value: None
CommonParameters
Azure AD Connect: ADConnectivityTools PowerShell
Reference
The following documentation provides reference information for the ADConnectivityTools.psm1 PowerShell
Module that is included with Azure AD Connect.
Confirm-DnsConnectivity
SYNOPSIS
Detects local Dns issues.
SYNTAX
Confirm-DnsConnectivity [-Forest] <String> [-DCs] <Array> [-ReturnResultAsPSObject] [<CommonParameters>]
DESCRIPTION
Runs local Dns connectivity tests. In order to configure the Active Directory connector, user must have both name
resolutionthe for the forest they is attempting to connect to as well as in the domain controllers associated to this
forest.
EXAMPLES
EXAMPLE 1
Confirm-DnsConnectivity -Forest "TEST.CONTOSO.COM" -DCs "MYDC1.CONTOSO.COM","MYDC2.CONTOSO.COM"
EXAMPLE 2
Confirm-DnsConnectivity -Forest "TEST.CONTOSO.COM"
PARAMETERS
-Forest
Specifies the name of the forest to test against.
Type: String
Aliases:
Required: True
Position: 1
Default value: None
-DCs
Specify DCs to test against.
Type: Array
Aliases:
Required: True
Position: 2
Default value: None
-ReturnResultAsPSObject
Returns the result of this diagnosis in the form of a PSObject. Not necessary during manual interaction with this
tool.
Aliases:
Required: False
Position: Named
CommonParameters
Confirm-ForestExists
SYNOPSIS
Determines if a specified forest exists.
SYNTAX
Confirm-ForestExists [-Forest] <String> [<CommonParameters>]
DESCRIPTION
Queries a DNS server for the IP addresses associated with a forest.
EXAMPLES
EXAMPLE 1
Confirm-TargetsAreReachable -Forest "TEST.CONTOSO.COM"
PARAMETERS
-Forest
Type: String
Aliases:
Required: True
Position: 1
Default value: None
CommonParameters
Confirm-FunctionalLevel
SYNOPSIS
Verifies AD forest functional level.
SYNTAX
SamAccount
Confirm-FunctionalLevel -Forest <String> [-RunWithCurrentlyLoggedInUserCredentials] [<CommonParameters>]
ForestFQDN
Confirm-FunctionalLevel -ForestFQDN <Forest> [-RunWithCurrentlyLoggedInUserCredentials] [<CommonParameters>]
DESCRIPTION
Verifies that the AD forest functional level is equal or more than a given MinAdForestVersion
(WindowsServer2003). Account (Domain\Username) and Password may be requested.
EXAMPLES
EXAMPLE 1
Confirm-FunctionalLevel -Forest "test.contoso.com"
EXAMPLE 2
Confirm-FunctionalLevel -Forest "test.contoso.com" -RunWithCurrentlyLoggedInUserCredentials -Verbose
EXAMPLE 3
Confirm-FunctionalLevel -ForestFQDN $ForestFQDN -RunWithCurrentlyLoggedInUserCredentials -Verbose
PARAMETERS
-Forest
Target forest. Default value is the Forest of the currently logged in user.
Type: String
Parameter Sets: SamAccount
Aliases:
Required: True
Position: Named
Default value: None
-ForestFQDN
Target ForestFQDN Object.
Type: Forest
Parameter Sets: ForestFQDN
Aliases:
Required: True
Position: Named
Default value: None
-RunWithCurrentlyLoggedInUserCredentials
The function will use the credentials of the user that is currently logged in the computer, rather than requesting
custom credentials from the user.
Aliases:
Required: False
Position: Named
CommonParameters
Confirm-NetworkConnectivity
SYNOPSIS
Detects local network connectivity issues.
SYNTAX
Confirm-NetworkConnectivity [-DCs] <Array> [-SkipDnsPort] [-ReturnResultAsPSObject] [<CommonParameters>]
DESCRIPTION
Runs local network connectivity tests.
For the local networking tests, AAD Connect must be able to communicate with the named domain controllers on
ports 53 (DNS), 88 (Kerberos) and 389 (LDAP) Most organizations run DNS on their DCs, which is why this test is
currently integrated. Port 53 should be skipped if another DNS server has been specified.
EXAMPLES
EXAMPLE 1
Confirm-NetworkConnectivity -SkipDnsPort -DCs "MYDC1.CONTOSO.COM","MYDC2.CONTOSO.COM"
EXAMPLE 2
Confirm-NetworkConnectivity -DCs "MYDC1.CONTOSO.COM","MYDC2.CONTOSO.COM" -Verbose
PARAMETERS
-DCs
Type: Array
Aliases:
Required: True
Position: 1
Default value: None
-SkipDnsPort
If the user is not using DNS services provided by the AD Site / Logon DC, then they may want to skip checking
port 53. The user must still be able to resolve _.ldap._tcp.<forestfqdn> in order for the Active Directory Connector
configuration to succeed.
Aliases:
Required: False
Position: Named
Returns the result of this diagnosis in the form of a PSObject. Not necessary during manual interaction with this
tool.
Aliases:
Required: False
Position: Named
CommonParameters
Confirm-TargetsAreReachable
SYNOPSIS
Determines if a specified forest and its associated Domain Controllers are reachable.
SYNTAX
Confirm-TargetsAreReachable [-Forest] <String> [-DCs] <Array> [<CommonParameters>]
DESCRIPTION
Runs "ping" tests (whether a computer can reach a destination computer through the network and/or the internet)
EXAMPLES
EXAMPLE 1
Confirm-TargetsAreReachable -Forest "TEST.CONTOSO.COM" -DCs "MYDC1.CONTOSO.COM","MYDC2.CONTOSO.COM"
EXAMPLE 2
Confirm-TargetsAreReachable -Forest "TEST.CONTOSO.COM"
PARAMETERS
-Forest
Type: String
Aliases:
Required: True
Position: 1
Default value: None
-DCs
Type: Array
Aliases:
Required: True
Position: 2
Default value: None
CommonParameters
Confirm-ValidDomains
SYNOPSIS
Validate that the domains in the obtained Forest FQDN are reachable
SYNTAX
SamAccount
Confirm-ValidDomains [-Forest <String>] [-RunWithCurrentlyLoggedInUserCredentials] [<CommonParameters>]
ForestFQDN
Confirm-ValidDomains -ForestFQDN <Forest> [-RunWithCurrentlyLoggedInUserCredentials] [<CommonParameters>]
DESCRIPTION
Validate that all of the domains in the obtained Forest FQDN are reachable by attempting to retrieve DomainGuid
and DomainDN. Account (Domain\Username) and Password may be requested.
EXAMPLES
EXAMPLE 1
Confirm-ValidDomains -Forest "test.contoso.com" -Verbose
EXAMPLE 2
Confirm-ValidDomains -Forest "test.contoso.com" -RunWithCurrentlyLoggedInUserCredentials -Verbose
EXAMPLE 3
Confirm-ValidDomains -ForestFQDN $ForestFQDN -RunWithCurrentlyLoggedInUserCredentials -Verbose
PARAMETERS
-Forest
Target forest.
Type: String
Parameter Sets: SamAccount
Aliases:
Required: False
Position: Named
Default value: None
-ForestFQDN
Target ForestFQDN Object.
Type: Forest
Parameter Sets: ForestFQDN
Aliases:
Required: True
Position: Named
Default value: None
Aliases:
Required: False
Position: Named
CommonParameters
Confirm-ValidEnterpriseAdminCredentials
SYNOPSIS
Verifies if a user has Enterprise Admin credentials.
SYNTAX
Confirm-ValidEnterpriseAdminCredentials [-RunWithCurrentlyLoggedInUserCredentials] [<CommonParameters>]
DESCRIPTION
Searches if provided user has Enterprise Admin credentials. Account (Domain\Username) and Password may be
requested.
EXAMPLES
EXAMPLE 1
Confirm-ValidEnterpriseAdminCredentials -DomainName test.contoso.com -Verbose
EXAMPLE 2
Confirm-ValidEnterpriseAdminCredentials -RunWithCurrentlyLoggedInUserCredentials -Verbose
PARAMETERS
Aliases:
Required: False
Position: Named
CommonParameters
Get-DomainFQDNData
SYNOPSIS
Retrieves a DomainFQDN out of an account and password combination.
SYNTAX
Get-DomainFQDNData [[-DomainFQDNDataType] <String>] [-RunWithCurrentlyLoggedInUserCredentials]

[-ReturnExceptionOnError] [<CommonParameters>]
DESCRIPTION
Attempts to obtain a domainFQDN object out of provided credentials. If the domainFQDN is valid, a
DomainFQDNName or RootDomainName will be returned, depending on the user's choice. Account
(Domain\Username) and Password may be requested.
EXAMPLES
EXAMPLE 1
Get-DomainFQDNData -DomainFQDNDataType DomainFQDNName -Verbose
EXAMPLE 2
Get-DomainFQDNData -DomainFQDNDataType RootDomainName -RunWithCurrentlyLoggedInUserCredentials
PARAMETERS
-DomainFQDNDataType
Desired kind of data that will be retrieved. Currently limited to "DomainFQDNName" or "RootDomainName".
Type: String
Aliases:
Required: False
Position: 1
Default value: None
Aliases:
Required: False
Position: Named
-ReturnExceptionOnError
Auxiliary parameter used by Start-NetworkConnectivityDiagnosisTools function
Aliases:
Required: False
Position: Named
CommonParameters
Get-ForestFQDN
SYNOPSIS
Retrieves a ForestFQDN out of an account and password combination.
SYNTAX
Get-ForestFQDN [-Forest] <String> [-RunWithCurrentlyLoggedInUserCredentials] [<CommonParameters>]
DESCRIPTION
Attempts to obtain a ForestFQDN out of the provided credentials. Account (Domain\Username) and Password may
be requested.
EXAMPLES
EXAMPLE 1
Get-ForestFQDN -Forest CONTOSO.MICROSOFT.COM -Verbose
EXAMPLE 2
Get-ForestFQDN -Forest CONTOSO.MICROSOFT.COM -RunWithCurrentlyLoggedInUserCredentials -Verbose
PARAMETERS
-Forest
Target forest.Default value is the Domain of the currently logged in user.
Type: String
Aliases:
Required: True
Position: 1
Default value: None
Aliases:
Required: False
Position: Named
CommonParameters
Start-ConnectivityValidation
SYNOPSIS
Main function.
SYNTAX
Start-ConnectivityValidation [-Forest] <String> [-AutoCreateConnectorAccount] <Boolean> [[-UserName] <String>]

DESCRIPTION
Runs all the available mechanisms that verify AD credentials are valid.
EXAMPLES
EXAMPLE 1
Start-ConnectivityValidation -Forest "test.contoso.com" -AutoCreateConnectorAccount $True -Verbose
PARAMETERS
-Forest
Target forest.
Type: String
Aliases:
Required: True
Position: 1
Default value: None
-AutoCreateConnectorAccount
For Custom-installations: Flag that is $True if the user chose "Create new AD account" on the AD Forest Account
window of AADConnect's wizard. $False if the user chose "Use existing AD account". For Express-installations: The
value of this variable must be $True for Express-installations.
Type: Boolean
Aliases:
Required: True
Position: 2
-UserName
Parameter that pre-populates the Username field when user's credentials are requested.
Type: String
Aliases:
Required: False
Position: 3
Default value: None
CommonParameters
Start-NetworkConnectivityDiagnosisTools
SYNOPSIS
Main function for network connectivity tests.
SYNTAX
Start-NetworkConnectivityDiagnosisTools [[-Forest] <String>] [-Credentials] <PSCredential>

[[-LogFileLocation] <String>] [[-DCs] <Array>] [-DisplayInformativeMessage] [-ReturnResultAsPSObject]
[-ValidCredentials] [<CommonParameters>]
DESCRIPTION
Runs local network connectivity tests.
EXAMPLES
EXAMPLE 1
Start-NetworkConnectivityDiagnosisTools -Forest "TEST.CONTOSO.COM"
EXAMPLE 2
Start-NetworkConnectivityDiagnosisTools -Forest "TEST.CONTOSO.COM" -DCs "DC1.TEST.CONTOSO.COM",

"DC2.TEST.CONTOSO.COM"
PARAMETERS
-Forest
Specifies forest name to test against.
Type: String
Aliases:
Required: False
Position: 1
Default value: None
-Credentials
The user name and password of the user that is running the test. It requires the same level of permissions that is
required to run the Azure AD Connect Wizard.
Type: PSCredential
Aliases:
Required: True
Position: 2
Default value: None
-LogFileLocation
Specifies a the location of a log file that will contain the output of this function.
Type: String
Aliases:
Required: False
Position: 3
Default value: None
-DCs
Type: Array
Aliases:
Required: False
Position: 4
Default value: None
-DisplayInformativeMessage
Flag that allows displaying a message about the purpose of this function.
Aliases:
Required: False
Position: Named
Returns the result of this diagnosis in the form of a PSObject. Not necessary to specify during manual interaction
with this tool.
Aliases:
Required: False
Position: Named
-ValidCredentials
Indicates if the credentials the user typed are valid. Not necessary to specify during manual interaction with this
tool.
Aliases:
Required: False
Position: Named
CommonParameters
Azure AD Connect - msExchUserHoldPolicies and
cloudMsExchUserHoldPolicies
The following reference document describes these attributes used by Exchange and the proper way to edit the
default sync rules.
What are msExchUserHoldPolicies and cloudMsExchUserHoldPolicies?

There are two types of holds available for an Exchange Server: Litigation Hold and In-Place Hold. When Litigation
Hold is enabled, all mailbox all items are placed on hold. An In-Place Hold is used to preserve only those items that
meet the criteria of a search query that you defined by using the In-Place eDiscovery tool.
The MsExchUserHoldPolcies and cloudMsExchUserHoldPolicies attributes allow on-premises AD and Azure AD to
determine which users are under a hold depending on whether they are using on-premises Exchange or Exchange
on-line.
msExchUserHoldPolicies synchronization flow

By default MsExchUserHoldPolcies is synchronized by Azure AD Connect directly to the msExchUserHoldPolicies
attribute in the metaverse and then to the msExchUserHoldPolices attribute in Azure AD
The following tables describe the flow:
Inbound from on-premises Active Directory:
A C T IVE DIREC TO RY M ETAVERSE

AT T RIB UT E AT T RIB UT E N A M E F LO W T Y P E AT T RIB UT E SY N C RUL E
On-premises Active msExchUserHoldPolici Direct msExchUserHoldPolice In from AD - User

Directory es s Exchange
Outbound to Azure AD:
M ETAVERSE
AT T RIB UT E AT T RIB UT E N A M E F LO W T Y P E A Z URE A D AT T RIB UT E SY N C RUL E
Azure Active msExchUserHoldPolici Direct msExchUserHoldPolici Out to AAD –

Directory es es UserExchangeOnline
cloudMsExchUserHoldPolicies synchronization flow

By default cloudMsExchUserHoldPolicies is synchronized by Azure AD Connect directly to the
cloudMsExchUserHoldPolicies attribute in the metaverse. Then, if msExchUserHoldPolices is not null in the
metaverse, the attribute in flowed out to Active Directory.
The following tables describe the flow:
Inbound from Azure AD:
A C T IVE DIREC TO RY M ETAVERSE
AT T RIB UT E AT T RIB UT E N A M E F LO W T Y P E AT T RIB UT E SY N C RUL E
On-premises Active cloudMsExchUserHold Direct cloudMsExchUserHold In from AAD - User

Directory Policies Policies Exchange
Outbound to on-premises Active Directory:
M ETAVERSE
AT T RIB UT E AT T RIB UT E N A M E F LO W T Y P E A Z URE A D AT T RIB UT E SY N C RUL E
Azure Active cloudMsExchUserHold IF(NOT NULL) msExchUserHoldPolici Out to AD –

Directory Policies es UserExchangeOnline
Information on the attribute behavior

The msExchangeUserHoldPolicies is a single authority attribute. A single authority attribute can be set on an object
(in this case, user object) in the on-premises directory or in the cloud directory. The Start of Authority rules dictate,
that if the attribute is synchronized from on-premises, then Azure AD will not be allowed to update this attribute.
To allow users to set a hold policy on a user object in the cloud, the cloudMSExchangeUserHoldPolicies attribute is
used. This attribute is used because Azure AD cannot set msExchangeUserHoldPolicies directly based on the rules
explained above. This attribute will then synchronize back to the on-premises directory if, the
msExchangeUserHoldPolicies is not null and replace the current value of msExchangeUserHoldPolicies.
Under certain circumstances, for instance, if both were changed on-premises and in Azure at the same time, this
could cause some issues.
Next steps
Understanding Azure AD Connect 1.4.xx.x and device
disappearance
With version 1.4.xx.x of Azure AD Connect, some customers may see some or all of their Windows devices
disappear from Azure AD. This is not a cause for concern, as these device identities are not used by Azure AD
during Conditional Access authorization. This change won't delete any Windows devices that were correctly
registered with Azure AD for Hybrid Azure AD Join.
If you see the deletion of device objects in Azure AD exceeding the Export Deletion Threshold, it is advised that the
customer allow the deletions to go through. How To: allow deletes to flow when they exceed the deletion threshold
Background
Windows devices registered as Hybrid Azure AD Joined are represented in Azure AD as device objects. These
device objects can be used for Conditional Access. Windows 10 devices are synced to the cloud via Azure AD
Connect, down level Windows devices are registered directly using either AD FS or seamless single sign-on.
Windows 10 devices
Only Windows 10 devices with a specific userCertificate attribute value configured by Hybrid Azure AD Join are
supposed to be synced to the cloud by Azure AD Connect. In previous versions of Azure AD Connect this
requirement was not rigorously enforced, resulting in unnecessary device objects in Azure AD. Such devices in
Azure AD always stayed in the “pending” state because these devices were not intended to be registered with Azure
AD.
This version of Azure AD Connect will only sync Windows 10 devices that are correctly configured to be Hybrid
Azure AD Joined. Windows 10 device objects without the Azure AD join specific userCertificate will be removed
from Azure AD.
Down-Level Windows devices

Azure AD Connect should never be syncing down-level Windows devices. Any devices in Azure AD previously
synced incorrectly will now be deleted from Azure AD. If Azure AD Connect is attempting to delete down-level
Windows devices, then the device is not the one that was created by the Microsoft Workplace Join for non-
Windows 10 computers MSI and it is not able to be consumed by any other Azure AD feature.
Some customers may need to revisit How To: Plan your hybrid Azure Active Directory join implementation to get
their Windows devices registered correctly and ensure that such devices can fully participate in device-based
Conditional Access.
How can I verify which devices are deleted with this update?
To verify which devices are deleted, you can use this PowerShell script:
https://gallery.technet.microsoft.com/scriptcenter/Export-Hybrid-Azure-AD-f8e51436
This script generates a report about certificates stored in Active Directory Computer objects, specifically, certificates
issued by the Hybrid Azure AD join feature. It checks the certificates present in the UserCertificate property of a
Computer object in AD and, for each non-expired certificate present, validates if the certificate was issued for the
Hybrid Azure AD join feature (i.e. Subject Name matches CN={ObjectGUID}). Before, Azure AD Connect would
synchronize to Azure AD any Computer that contained at least one valid certificate but starting on Azure AD
Connect version 1.4, the synchronization engine can identify Hybrid Azure AD join certificates and will ‘cloudfilter’
the computer object from synchronizing to Azure AD unless there’s a valid Hybrid Azure AD join certificate. Azure
AD Devices that were already synchronized to AD but do not have a valid Hybrid Azure AD join certificate will be
deleted (CloudFiltered=TRUE) by the sync engine.
Next Steps
Azure AD Connect Version history
Azure AD Connect: Version release history archive
The Azure Active Directory (Azure AD) team regularly updates Azure AD Connect with new features and
functionality. Not all additions are applicable to all audiences.
NOTE
This article contains version reference information about all archived versions of Azure AD - 1.3.20.0 and older. For current
releases, see the Azure AD Connect Version release history
1.3.20.0
Release status
Add support for Domain Refresh
Exchange Mail Public Folders feature goes GA
Improve wizard error handling for service failures
Added warning link on Synchronization Service Manager UI in the connector properties page.
The Unified Groups Writeback feature is now GA
Improved SSPR error message when the DC is missing an LDAP control
Added diagnostics for DCOM registry errors during install
Improved tracing of PHS RPC errors
Allow EA creds from a child domain
Allow database name to be entered during install (default name ADSync)
Upgrade to ADAL 3.19.8 to pick up a WS-Trust fix for Ping and add support for new Azure instances
Modify Group Sync Rules to flow samAccountName, DomainNetbios and DomainFQDN to cloud - needed for
claims
Modified Default Sync Rule Handling – read more here.
Added a new agent running as a windows service. This agent, named “Admin Agent”, enables deeper remote
diagnostics of the Azure AD Connect server to help Microsoft Engineers troubleshoot when you open a support
case. This agent is not installed and enabled by default. For more information on how to install and enable the
agent see What is the Azure AD Connect Admin Agent?.
Updated the End User License Agreement (EULA)
Added auto upgrade support for deployments that use AD FS as their login type. This also removed the
requirement of updating the AD FS Azure AD Relying Party Trust as part of the upgrade process.
Added an Azure AD trust management task that provides two options: analyze/update trust and reset trust.
Changed the AD FS Azure AD Relying Party trust behavior so that it always uses the -SupportMultipleDomain
switch (includes trust and Azure AD domain updates).
Changed the install new AD FS farm behavior so that it requires a .pfx certificate by removing the option of
using a pre-installed certificate.
Updated the install new AD FS farm workflow so that it only allows deploying 1 AD FS and 1 WAP server. All
additional servers will be done after initial installation.
Fixed issues
Fix the SQL reconnect logic for ADSync service
Fix to allow clean Install using an empty SQL AOA DB
Fix PS Permissions script to refine GWB permissions
Fix VSS Errors with LocalDB
Fix misleading error message when object type is not in scope
Corrected an issue where installation of Azure AD PowerShell on a server could potentially cause an assembly
conflict with Azure AD Connect.
Fixed PHS bug on Staging Server when Connector Credentials are updated in the Synchronization Service
Manager UI.
Fixed some memory leaks
Miscellaneous Autoupgrade fixes
Miscellaneous fixes to Export and Unconfirmed Import Processing
Fixed a bug with handling a backslash in Domain and OU filtering
Fixed an issue where ADSync service takes more than 2 minutes to stop and causes a problem at upgrade time.
1.2.70.0
Release status
Fixed issues
This build updates the non-standard connectors (for example, Generic LDAP Connector and Generic SQL
Connector) shipped with Azure AD Connect. For more information on applicable connectors, see version 1.1.911.0
in Connector Version Release History.
1.2.69.0
Release status
Fixed issues
This hotfix build allows the user to select a target domain, within the specified forest, for the RegisteredDevices
container when enabling device writeback. In the previous versions that contain the new Device Options
functionality (1.1.819.0 – 1.2.68.0), the RegisteredDevices container location was limited to the forest root and did
not allow child domains. This limitation only manifested itself on new deployments – in-place upgrades were
unaffected.
If any build containing the updated Device Options functionality was deployed to a new server and device
writeback was enabled, you will need to manually specify the location of the container if you do not want it in the
forest root. To do this, you need to disable device writeback and re-enable it which will allow you to specify the
container location on the “Writeback forest” page.
1.2.68.0
Release status
Fixed issues
This hotfix build fixes a conflict where an authentication error might occur due to the independent presence of the
MSOnline PowerShell Gallery module on the synchronization server.
1.2.67.0
Release status
Fixed issues
This hotfix build fixes a regression in the previous build where Password Writeback fails when using an ADDS
Domain Controller on Windows Server 2008/R2.
1.2.65.0
Release status
10/25/2018: released for download
Changed the functionality of attribute write-back to ensure hosted voice-mail is working as expected. Under
certain scenarios, Azure AD was overwriting the msExchUcVoicemailSettings attribute during write-back with a
null value. Azure AD will now no longer clear the on-premises value of this attribute if the cloud value is not set.
Added diagnostics in the Azure AD Connect wizard to investigate and identify Connectivity issues to Azure AD.
These same diagnostics can also be run directly through PowerShell using the Test-
AdSyncAzureServiceConnectivity Cmdlet.
Added diagnostics in the Azure AD Connect wizard to investigate and identify Connectivity issues to AD. These
same diagnostics can also be run directly through PowerShell using the Start-ConnectivityValidation function in
the ADConnectivityTools PowerShell module. For more information see What is the ADConnectivityTool
PowerShell Module?
Added an AD schema version pre-check for Hybrid Azure Active Directory Join and device write-back
Changed the Directory Extension page attribute search to be non-case sensitive.
Added full support for TLS 1.2. This release supports all other protocols being disabled and only TLS 1.2 being
enabled on the machine where Azure AD Connect is installed. For more information see TLS 1.2 enforcement
for Azure AD Connect
Fixed issues
Fixed a bug where Azure AD Connect Upgrade would fail if SQL Always On was being used.
Fixed a bug to correctly parse OU names that contain a forward slash.
Fixed an issue where Pass-Through Authentication would be disabled for a clean install in staging mode.
Fixed a bug that prevented the PowerShell module to be loaded when running the Troubleshooting tools
Fixed a bug that would block customers from using numeric values in the first character of a host name.
Fixed a bug where Azure AD Connect would allow invalid partitions and container selection
Fixed the “Invalid Password” error message when Desktop SSO is enabled.
Various Bug fixes for AD FS Trust Management
When configuring Device Writeback - fixed the schema check to look for the msDs-DeviceContainer object class
(introduced on WS2012 R2)
1.1.882.0
9/7/2018: released for download, will not be release for auto upgrade
Fixed issues
Azure AD Connect Upgrade fails if SQL Always On Availability is configured for the ADSync DB. This hotfix
addresses this issue and allows Upgrade to succeed.
1.1.880.0
Release status
8/21/2018: Released for download and auto upgrade.
The Ping Federate integration in Azure AD Connect is now available for General Availability. Learn more about
how to federated Azure AD with Ping Federate
Azure AD Connect now creates the backup of Azure AD trust in AD FS every time an update is made and stores
it in a separate file for easy restore if required. Learn more about the new functionality and Azure AD trust
management in Azure AD Connect.
New troubleshooting tooling helps troubleshoot changing primary email address and hiding account from
global address list
Azure AD Connect was updated to include the latest SQL Server 2012 Native Client
When you switch user sign-in to Password Hash Synchronization or Pass-through Authentication in the
"Change user sign-in" task, the Seamless Single Sign-On checkbox is enabled by default.
Added support for Windows Server Essentials 2019
The Azure AD Connect Health agent was updated to the latest version 3.1.7.0
During an upgrade, if the installer detects changes to the default sync rules, the admin is prompted with a
warning before overwriting the modified rules. This will allow the user to take corrective actions and resume
later. Old Behavior: If there was any modified out-of-box rule then manual upgrade was overwriting those rules
without giving any warning to the user and sync scheduler was disabled without informing user. New Behavior:
User will be prompted with warning before overwriting the modified out-of-box sync rules. User will have
choice to stop the upgrade process and resume later after taking corrective action.
Provide a better handling of a FIPS compliance issue, providing an error message for MD5 hash generation in a
FIPS compliant environment and a link to documentation that provides a work around for this issue.
UI update to improve federation tasks in the wizard, which are now under a separate sub group for federation.
All federation additional tasks are now grouped under a single sub-menu for ease of use.
A new revamped ADSyncConfig Posh Module (AdSyncConfig.psm1) with new AD Permissions functions moved
from the old ADSyncPrep.psm1 (which may be deprecated shortly)
Fixed issues
Fixed a bug where the Azure AD Connect server would show high CPU usage after upgrading to .NET 4.7.2
Fixed a bug that would intermittently produce an error message for an auto-resolved SQL deadlock issue
Fixed several accessibility issues for the Sync Rules Editor and the Sync Service Manager
Fixed a bug where Azure AD Connect can not get registry setting information
Fixed a bug that created issues when the user goes forward/back in the wizard
Fixed a bug to prevent an error happening due to incorrect multi-thread handing in the wizard
When Group Sync Filtering page encounters an LDAP error when resolving security groups, Azure AD Connect
now returns the exception with full fidelity. The root cause for the referral exception is still unknown and will be
addressed by a different bug.
Fixed a bug where permissions for STK and NGC keys (ms-DS-KeyCredentialLink attribute on User/Device
objects for WHfB) were not correctly set.
Fixed a bug where 'Set-ADSyncRestrictedPermissions’ was not called correctly
Adding support for permission granting on Group Writeback in Azure ADConnect's installation wizard
When changing sign in method from Password Hash Sync to AD FS, Password Hash Sync was not disabled.
Added verification for IPv6 addresses in AD FS configuration
Updated the notification message to inform that an existing configuration exists.
Device writeback fails to detect container in untrusted forest. This has been updated to provide a better error
message and a link to the appropriate documentation
Deselecting an OU and then synchronization/writeback corresponding to that OU gives a generic sync error.
This has been changed to create a more understandable error message.
1.1.819.0
Release status
5/14/2018: Released for auto upgrade and download.
This release includes the public preview of the integration of PingFederate in Azure AD Connect. With this
release, customers can easily, and reliably configure their Azure Active Directory environment to leverage
PingFederate as their federation provider. To learn more about how to use this new feature, please visit our
online documentation.
Updated the Azure AD Connect Wizard Troubleshooting Utility, where it now analyzes more error scenario’s,
such as Linked Mailboxes and AD Dynamic Groups. Read more about the troubleshooting utility here.
Device Writeback configuration is now managed solely within the Azure AD Connect Wizard.
A new PowerShell Module called ADSyncTools.psm1 is added that can be used to troubleshoot SQL Connectivity
issues and various other troubleshooting utilities. Read more about the ADSyncTools module here.
A new additional task “Configure device options” has been added. You can use the task to configure the
following two operations:
Hybrid Azure AD join : If your environment has an on-premises AD footprint and you also want
benefit from the capabilities provided by Azure Active Directory, you can implement hybrid Azure AD
joined devices. These are devices that are both, joined to your on-premises Active Directory and your
Device writeback : Device writeback is used to enable Conditional Access based on devices to AD FS
(2012 R2 or higher) protected devices
NOTE
The option to enable device writeback from Customize synchronization options will be greyed out.
The PowerShell module for ADPrep is deprecated with this release.
Fixed issues
This release updates the SQL Server Express installation to SQL Server 2012 SP4, which, among others,
provides fixes for several security vulnerabilities. Please see here for more information about SQL Server 2012
SP4.
Sync Rule Processing: outbound Join sync rules with no Join Condition should be de-applied if the parent sync
rule is no longer applicable
Several accessibility fixes have been applied to the Synchronization Service Manager UI and the Sync Rules
Editor
Azure AD Connect Wizard: Error creating AD Connector account when Azure AD Connect is in a workgroup
Azure AD Connect Wizard: On the Azure AD Sign-in page display the verification checkbox whenever there is
any mismatch in AD domains and Azure AD Verified domains
Auto-upgrade PowerShell fix to set auto upgrade state correctly in certain cases after auto upgrade attempted.
Azure AD Connect Wizard: Updated telemetry to capture previously missing information
Azure AD Connect Wizard: The following changes have been made when you use the Change user sign-in
task to switch from AD FS to Pass-through Authentication:
The Pass-through Authentication Agent is installed on the Azure AD Connect server and the Pass-through
Authentication feature is enabled, before we convert domain(s) from federated to managed.
Users are no longer converted from federated to managed. Only domain(s) are converted.
Azure AD Connect Wizard: AD FS Multi Domain Regex is not correct when user UPN has ' special character
Regex update to support special characters
Azure AD Connect Wizard: Remove spurious "Configure source anchor attribute" message when no change
Azure AD Connect Wizard: AD FS support for the dual federation scenario
Azure AD Connect Wizard: AD FS Claims are not updated for added domain when converting a managed
domain to federated
Azure AD Connect Wizard: During detection of installed packages, we find stale Dirsync/Azure AD Sync/Azure
AD Connect related products. We will now attempt to uninstall the stale products.
Azure AD Connect Wizard: Correct Error Message Mapping when installation of passthrough authentication
agent fails
Azure AD Connect Wizard: Removed "Configuration" container from Domain OU Filtering page
Sync Engine install: remove unnecessary legacy logic that occasionally failed from Sync Engine install msi
Azure AD Connect Wizard: Fix popup help text on Optional Features page for Password Hash Sync
Sync Engine runtime: Fix the scenario where a CS object has an imported delete and Sync Rules attempt to re-
provision the object.
Sync Engine runtime: Add help link for Online connectivity troubleshooting guide to the event log for an Import
Error
Sync Engine runtime: Reduced memory usage of Sync Scheduler when enumerating Connectors
Azure AD Connect Wizard: Fix an issue resolving a custom Sync Service Account which has no AD Read
privileges
Azure AD Connect Wizard: Improve logging of Domain and OU filtering selections
Azure AD Connect Wizard: AD FS Add default claims to federation trust created for MFA scenario
Azure AD Connect Wizard: AD FS Deploy WAP: Adding server fails to use new certificate
Azure AD Connect Wizard: DSSO exception when onPremCredentials aren't initialized for a domain
Preferentially flow the AD distinguishedName attribute from the Active User object.
Fixed a cosmetic bug were the Precedence of the first OOB Sync Rule was set to 99 instead of 100
1.1.751.0
Status 4/12/2018: Released for download only
NOTE
This release is a hotfix for Azure AD Connect

Fixed issues
Corrected an issue were automatic Azure instance discovery for China tenants was occasionally failing.
AD FS Management
Fixed issues
There was a problem in the configuration retry logic that would result in an ArgumentException stating “an item
with the same key has already been added.” This would cause all retry operations to fail.
1.1.750.0
Status 3/22/2018: Released for auto-upgrade and download.
NOTE
When the upgrade to this new version completes, it will automatically trigger a full sync and full import for the Azure AD
connector and a full sync for the AD connector. Since this may take some time, depending on the size of your Azure AD
Connect environment, make sure that you have taken the necessary steps to support this or hold off on upgrading until you
have found a convenient moment to do so.
NOTE
“AutoUpgrade functionality was incorrectly disabled for some tenants who deployed builds later than 1.1.524.0. To ensure
that your Azure AD Connect instance is still eligible for AutoUpgrade, run the following PowerShell cmdlet: “Set-
ADSyncAutoUpgrade -AutoupGradeState Enabled”
Azure AD Connect
Fixed issues
Set-ADSyncAutoUpgrade cmdlet would previously block Autoupgrade if auto-upgrade state is set to
Suspended. This functionality has now changed so it does not block AutoUpgrade of future builds.
Changed the User Sign-in page option "Password Synchronization" to "Password Hash Synchronization".
Azure AD Connect synchronizes password hashes, not passwords, so this aligns with what is actually occurring.
For more information see Implement password hash synchronization with Azure AD Connect sync
1.1.749.0
Status: Released to select customers
NOTE
When the upgrade to this new version completes, it will automatically trigger a full sync and full import for the Azure AD
connector and a full sync for the AD connector. Since this may take some time, depending on the size of your Azure AD
Connect environment, please make sure that you have taken the necessary steps to support this or hold off on upgrading
until you have found a convenient moment to do so.
Azure AD Connect
Fixed issues
Fix timing window on background tasks for Partition Filtering page when switching to next page.
Fixed a bug that caused Access violation during the ConfigDB custom action.
Fixed a bug to recover from SQL connection timeout.
Fixed a bug where certificates with SAN wildcards failed a prerequisite check.
Fixed a bug which causes miiserver.exe to crash during an Azure AD connector export.
Fixed a bug which bad password attempt logged on DC when running the Azure AD Connect wizard to
change configuration.
Adding Privacy Settings for the General Data Protection Regulation (GDPR). For more information see the article
here.
NOTE
application telemetry - admin can switch this class of data on/off at will
Azure AD Health data - admin must visit the health portal to control their health settings. Once the service
policy has been changed, the agents will read and enforce it.
Added device write-back configuration actions and a progress bar for page initialization
Improved General Diagnostics with HTML report and full data collection in a ZIP-Text / HTML Report
Improved the reliability of auto upgrade and added additional telemetry to ensure the health of the server
can be determined
Restrict permissions available to privileged accounts on AD Connector account
For new installations, the wizard will restrict the permissions that privileged accounts have on the MSOL
account after creating the MSOL account.
The changes will take care of following:
1. Express Installations
2. Custom Installations with Auto-Create account
3. Changed the installer so it doesn't require SA privilege on clean install of Azure AD Connect
Added a new utility to troubleshoot synchronization issues for a specific object. It is available under
'Troubleshoot Object Synchronization' option of Azure AD Connect Wizard Troubleshoot Additional Task.
Currently, the utility checks for the following:
UserPrincipalName mismatch between synchronized user object and the user account in Azure AD
Tenant.
If the object is filtered from synchronization due to domain filtering
If the object is filtered from synchronization due to organizational unit (OU) filtering
Added a new utility to synchronize the current password hash stored in the on-premises Active Directory for
a specific user account.
The utility does not require a password change. It is available under 'Troubleshoot Password Hash Synchronization'
option of Azure AD Connect Wizard Troubleshoot Additional Task.
1.1.654.0
Status: December 12th, 2017
NOTE
This release is a security related hotfix for Azure AD Connect
Azure AD Connect
An improvement has been added to Azure AD Connect version 1.1.654.0 (and after) to ensure that the
recommended permission changes described under section Lock down access to the AD DS account are
automatically applied when Azure AD Connect creates the AD DS account.
When setting up Azure AD Connect, the installing administrator can either provide an existing AD DS account,
or let Azure AD Connect automatically create the account. The permission changes are automatically applied to
the AD DS account that is created by Azure AD Connect during setup. They are not applied to existing AD DS
account provided by the installing administrator.
For customers who have upgraded from an older version of Azure AD Connect to 1.1.654.0 (or after), the
permission changes will not be retroactively applied to existing AD DS accounts created prior to the upgrade.
They will only be applied to new AD DS accounts created after the upgrade. This occurs when you are adding
new AD forests to be synchronized to Azure AD.
NOTE
This release only removes the vulnerability for new installations of Azure AD Connect where the service account is created by
the installation process. For existing installations, or in cases where you provide the account yourself, you should ensure that
this vulnerability does not exist.
Lock down access to the AD DS account

Lock down access to the AD DS account by implementing the following permission changes in the on-premises AD:
Disable inheritance on the specified object
Remove all ACEs on the specific object, except ACEs specific to SELF. We want to keep the default permissions
intact when it comes to SELF.
Assign these specific permissions:

Controllers
Allow Enterprise Domain Read All Properties This object

Controllers
Allow Enterprise Domain Read Permissions This object

Controllers
Allow Authenticated Users Read All Properties This object
Allow Authenticated Users Read Permissions This object
PowerShell script to tighten a pre-existing service account

To use the PowerShell script, to apply these settings, to a pre-existing AD DS account, (ether provided by your
organization or created by a previous installation of Azure AD Connect, please download the script from the
provided link above.
U sa g e :
Set-ADSyncRestrictedPermissions -ObjectDN <$ObjectDN> -Credential <$Credential>
Where
$ObjectDN = The Active Directory account whose permissions need to be tightened.
$Credential = Administrator credential that has the necessary privileges to restrict the permissions on the
$ObjectDN account. These privileges are typically held by the Enterprise or Domain administrator. Use the fully
qualified domain name of the administrator account to avoid account lookup failures. Example:
contoso.com\admin.
NOTE
$credential.UserName should be in FQDN\username format. Example: contoso.com\admin
Ex a m p l e :
Set-ADSyncRestrictedPermissions -ObjectDN "CN=TestAccount1,CN=Users,DC=bvtadwbackdc,DC=com" -Credential

$credential
Was this vulnerability used to gain unauthorized access?

To see if this vulnerability was used to compromise your Azure AD Connect configuration you should verify the last
password reset date of the service account. If the timestamp in unexpected, further investigation, via the event log,
for that password reset event, should be undertaken.
For more information, see Microsoft Security Advisory 4056318
1.1.649.0
Status: October 27 2017
NOTE
This build is not available to customers through the Azure AD Connect Auto Upgrade feature.
Azure AD Connect
Fixed issue
Fixed a version compatibility issue between Azure AD Connect and Azure AD Connect Health Agent (for sync).
This issue affects customers who are performing Azure AD Connect in-place upgrade to version 1.1.647.0, but
currently has Health Agent version 3.0.127.0. After the upgrade, the Health Agent can no longer send health
data about Azure AD Connect Synchronization Service to Azure AD Health Service. With this fix, Health Agent
version 3.0.129.0 is installed during Azure AD Connect in-place upgrade. Health Agent version 3.0.129.0 does
not have compatibility issue with Azure AD Connect version 1.1.649.0.
1.1.647.0
Status: October 19 2017
IMPORTANT
There is a known compatibility issue between Azure AD Connect version 1.1.647.0 and Azure AD Connect Health Agent (for
sync) version 3.0.127.0. This issue prevents the Health Agent from sending health data about the Azure AD Connect
Synchronization Service (including object synchronization errors and run history data) to Azure AD Health Service. Before
manually upgrading your Azure AD Connect deployment to version 1.1.647.0, please verify the current version of Azure AD
Connect Health Agent installed on your Azure AD Connect server. You can do so by going to Control Panel → Add Remove
Programs and look for application Microsoft Azure AD Connect Health Agent for Sync. If its version is 3.0.127.0, it is
recommended that you wait for the next Azure AD Connect version to be available before upgrade. If the Health Agent
version isn't 3.0.127.0, it is fine to proceed with the manual, in-place upgrade. Note that this issue does not affect swing
upgrade or customers who are performing new installation of Azure AD Connect.
Azure AD Connect
Fixed issues
Fixed an issue with the Change user sign-in task in Azure AD Connect wizard:
The issue occurs when you have an existing Azure AD Connect deployment with Password
Synchronization enabled , and you are trying to set the user sign-in method as Pass-through
Authentication. Before the change is applied, the wizard incorrectly shows the "Disable Password
Synchronization" prompt. However, Password Synchronization remains enabled after the change is
applied. With this fix, the wizard no longer shows the prompt.
By design, the wizard does not disable Password Synchronization when you update the user sign-in
method using the Change user sign-in task. This is to avoid disruption to customers who want to
keep Password Synchronization, even though they are enabling Pass-through Authentication or
federation as their primary user sign-in method.
If you wish to disable Password Synchronization after updating the user sign-in method, you must
execute the Customize Synchronization Configuration task in the wizard. When you navigate to the
Optional features page, uncheck the Password Synchronization option.
Note that the same issue also occurs if you try to enable/disable Seamless Single Sign-On.
Specifically, you have an existing Azure AD Connect deployment with Password Synchronization
enabled and the user sign-in method is already configured as Pass-through Authentication. Using the
Change user sign-in task, you try to check/uncheck the Enable Seamless Single Sign-On option while
the user sign-in method remains configured as "Pass-through Authentication". Before the change is
applied, the wizard incorrectly shows the "Disable Password Synchronization" prompt. However,
Password Synchronization remains enabled after the change is applied. With this fix, the wizard no
longer shows the prompt.
Fixed an issue with the Change user sign-in task in Azure AD Connect wizard:
The issue occurs when you have an existing Azure AD Connect deployment with Password
Synchronization disabled , and you are trying to set the user sign-in method as Pass-through
Authentication. When the change is applied, the wizard enables both Pass-through Authentication
and Password Synchronization. With this fix, the wizard no longer enables Password Synchronization.
Previously, Password Synchronization was a pre-requisite for enabling Pass-through Authentication.
When you set the user sign-in method as Pass-through Authentication, the wizard would enable both
Pass-through Authentication and Password Synchronization. Recently, Password Synchronization was
removed as a pre-requisite. As part of Azure AD Connect version 1.1.557.0, a change was made to
Azure AD Connect to not enable Password Synchronization when you set the user sign-in method as
Pass-through Authentication. However, the change was only applied to Azure AD Connect installation.
With this fix, the same change is also applied to the Change user sign-in task.
Note that the same issue also occurs if you try to enable/disable Seamless Single Sign-On.
Specifically, you have an existing Azure AD Connect deployment with Password Synchronization
disabled and the user sign-in method is already configured as Pass-through Authentication. Using the
Change user sign-in task, you try to check/uncheck the Enable Seamless Single Sign-On option while
the user sign-in method remains configured as "Pass-through Authentication". When the change is
applied, the wizard enables Password Synchronization. With this fix, the wizard no longer enables
Password Synchronization.
Fixed an issue that caused Azure AD Connect upgrade to fail with error "Unable to upgrade the
Synchronization Service". Further, the Synchronization Service can no longer start with event error "The
service was unable to start because the version of the database is newer than the version of the binaries
installed". The issue occurs when the administrator performing the upgrade does not have sysadmin
privilege to the SQL server that is being used by Azure AD Connect. With this fix, Azure AD Connect only
requires the administrator to have db_owner privilege to the ADSync database during upgrade.
Fixed an Azure AD Connect Upgrade issue that affected customers who have enabled Seamless Single Sign-
On. After Azure AD Connect is upgraded, Seamless Single Sign-On incorrectly appears as disabled in Azure
AD Connect wizard, even though the feature remains enabled and fully functional. With this fix, the feature
now appears correctly as enabled in the wizard.
Fixed an issue that caused Azure AD Connect wizard to always show the “Configure Source Anchor” prompt
on the Ready to Configure page, even if no changes related to Source Anchor were made.
When performing manual in-place upgrade of Azure AD Connect, the customer is required to provide the
Global Administrator credentials of the corresponding Azure AD tenant. Previously, upgrade could proceed
even though the Global Administrator's credentials belonged to a different Azure AD tenant. While upgrade
appears to complete successfully, certain configurations are not correctly persisted with the upgrade. With
this change, the wizard prevents the upgrade from proceeding if the credentials provided do not match the
Azure AD tenant.
Removed redundant logic that unnecessarily restarted Azure AD Connect Health service at the beginning of
a manual upgrade.
Added logic to simplify the steps required to set up Azure AD Connect with Microsoft Germany Cloud.
Previously, you are required to update specific registry keys on the Azure AD Connect server for it to work
correctly with Microsoft Germany Cloud, as described in this article. Now, Azure AD Connect can automatically
detect if your tenant is in Microsoft Germany Cloud based on the global administrator credentials provided
during setup.
NOTE
Note: The Synchronization Service has a WMI interface that lets you develop your own custom scheduler. This interface is
now deprecated and will be removed from future versions of Azure AD Connect shipped after June 30, 2018. Customers who
want to customize synchronization schedule should use the built-in scheduler.
Fixed issues
When Azure AD Connect wizard creates the AD Connector account required to synchronize changes from
on-premises Active Directory, it does not correctly assign the account the permission required to read
PublicFolder objects. This issue affects both Express installation and Custom installation. This change fixes
the issue.
Fixed an issue that caused the Azure AD Connect Wizard troubleshooting page to not render correctly for
administrators running from Windows Server 2016.
When troubleshooting Password Synchronization using the Azure AD Connect wizard troubleshooting page,
the troubleshooting page now returns domain-specific status.
Previously, if you tried to enable Password Hash Synchronization, Azure AD Connect does not verify whether
the AD Connector account has required permissions to synchronize password hashes from on-premises AD.
Now, Azure AD Connect wizard will verify and warn you if the AD Connector account does not have
sufficient permissions.
AD FS Management
Fixed issue
Fixed an issue related to the use of ms-DS-ConsistencyGuid as Source Anchor feature. This issue affects
customers who have configured Federation with AD FS as the user sign-in method. When you execute
Configure Source Anchor task in the wizard, Azure AD Connect switches to using *ms-DS-ConsistencyGuid as
source attribute for immutableId. As part of this change, Azure AD Connect attempts to update the claim rules
for ImmutableId in AD FS. However, this step failed because Azure AD Connect did not have the administrator
credentials required to configure AD FS. With this fix, Azure AD Connect now prompts you to enter the
administrator credentials for AD FS when you execute the Configure Source Anchor task.
1.1.614.0
Status: September 05 2017
Azure AD Connect
Known issues
There is a known issue that is causing Azure AD Connect upgrade to fail with error "Unable to upgrade the
Synchronization Service". Further, the Synchronization Service can no longer start with event error "The
service was unable to start because the version of the database is newer than the version of the binaries
installed". The issue occurs when the administrator performing the upgrade does not have sysadmin
privilege to the SQL server that is being used by Azure AD Connect. Dbo permissions are not sufficient.
There is a known issue with Azure AD Connect Upgrade that is affecting customers who have enabled
Seamless Single Sign-On. After Azure AD Connect is upgraded, the feature appears as disabled in the
wizard, even though the feature remains enabled. A fix for this issue will be provided in future release.
Customers who are concerned about this display issue can manually fix it by enabling Seamless Single Sign-
On in the wizard.
Fixed issues
Fixed an issue that prevented Azure AD Connect from updating the claims rules in on-premises AD FS while
enabling the ms-DS-ConsistencyGuid as Source Anchor feature. The issue occurs if you try to enable the feature
for an existing Azure AD Connect deployment that has AD FS configured as the sign-in method. The issue
occurs because the wizard does not prompt for ADFS credentials before trying to update the claims rules in AD
FS.
Fixed an issue that caused Azure AD Connect to fail installation if the on-premises AD forest has NTLM disabled.
The issue is due to Azure AD Connect wizard not providing fully qualified credentials when creating the security
contexts required for Kerberos authentication. This causes Kerberos authentication to fail and Azure AD Connect
wizard to fall back to using NTLM.
Fixed issues
Fixed an issue where new synchronization rule cannot be created if the Tag attribute isn’t populated.
Fixed an issue that caused Azure AD Connect to connect to on-premises AD for Password Synchronization using
NTLM, even though Kerberos is available. This issue occurs if the on-premises AD topology has one or more
domain controllers that were restored from a backup.
Fixed an issue that caused full synchronization steps to occur unnecessarily after upgrade. In general, running
full synchronization steps is required after upgrade if there are changes to out-of-box synchronization rules. The
issue was due to an error in the change detection logic that incorrectly detected a change when encountering
synchronization rule expression with newline characters. Newline characters are inserted into sync rule
expression to improve readability.
Fixed an issue that can cause the Azure AD Connect server to not work correctly after Automatic Upgrade. This
issue affects Azure AD Connect servers with version 1.1.443.0 (or earlier). For details about the issue, refer to
article Azure AD Connect is not working correctly after an automatic upgrade.
Fixed an issue that can cause Automatic Upgrade to be retried every 5 minutes when errors are encountered.
With the fix, Automatic Upgrade retries with exponential back-off when errors are encountered.
Fixed an issue where password synchronization event 611 is incorrectly shown in Windows Application Event
logs as informational instead of error . Event 611 is generated whenever password synchronization
encounters an issue.
Fixed an issue in the Azure AD Connect wizard that allows Group writeback feature to be enabled without
selecting an OU required for Group writeback.
Added a Troubleshoot task to Azure AD Connect wizard under Additional Tasks. Customers can leverage this
task to troubleshoot issues related to password synchronization and collect general diagnostics. In the future,
the Troubleshoot task will be extended to include other directory synchronization-related issues.
Azure AD Connect now supports a new installation mode called Use Existing Database . This installation
mode allows customers to install Azure AD Connect that specifies an existing ADSync database. For more
information about this feature, refer to article Use an existing database.
For improved security, Azure AD Connect now defaults to using TLS1.2 to connect to Azure AD for directory
synchronization. Previously, the default was TLS1.0.
When Azure AD Connect Password Synchronization Agent starts up, it tries to connect to Azure AD well-known
endpoint for password synchronization. Upon successful connection, it is redirected to a region-specific
endpoint. Previously, the Password Synchronization Agent caches the region-specific endpoint until it is
restarted. Now, the agent clears the cache and retries with the well-known endpoint if it encounters connection
issue with the region-specific endpoint. This change ensures that password synchronization can failover to a
different region-specific endpoint when the cached region-specific endpoint is no longer available.
To synchronize changes from an on-premises AD forest, an AD DS account is required. You can either (i) create
the AD DS account yourself and provide its credential to Azure AD Connect, or (ii) provide an Enterprise Admin's
credentials and let Azure AD Connect create the AD DS account for you. Previously, (i) is the default option in the
Azure AD Connect wizard. Now, (ii) is the default option.
Added support for Microsoft Azure Government Cloud and Microsoft Cloud Germany.
AD FS Management
Fixed issues
The Initialize-ADSyncNGCKeysWriteBack cmdlet in the AD prep PowerShell module was incorrectly applying
ACLs to the device registration container and would therefore only inherit existing permissions. This was
updated so that the sync service account has the correct permissions.
The Azure AD Connect Verify ADFS Login task was updated so that it verifies logins against Microsoft Online
and not just token retrieval from ADFS.
When setting up a new ADFS farm using Azure AD Connect, the page asking for ADFS credentials was moved
so that it now occurs before the user is asked to provide ADFS and WAP servers. This allows Azure AD Connect
to check that the account specified has the correct permissions.
During Azure AD Connect upgrade, we will no longer fail an upgrade if the ADFS Azure AD Trust fails to update.
If that happens, the user will be shown an appropriate warning message and should proceed to reset the trust
via the Azure AD Connect additional task.
Seamless Single Sign-On
Fixed issues
Fixed an issue that caused Azure AD Connect wizard to return an error if you try to enable Seamless Single
Sign-On. The error message is “Configuration of Microsoft Azure AD Connect Authentication Agent failed.” This
issue affects existing customers who had manually upgraded the preview version of the Authentication Agents
for Pass-through Authentication based on the steps described in this article.
1.1.561.0
Status: July 23 2017
Azure AD Connect
Fixed issue
Fixed an issue that caused the out-of-box synchronization rule “Out to AD - User ImmutableId” to be
removed:
The issue occurs when Azure AD Connect is upgraded, or when the task option Update
Synchronization Configuration in the Azure AD Connect wizard is used to update Azure AD Connect
synchronization configuration.
This synchronization rule is applicable to customers who have enabled the ms-DS-ConsistencyGuid
as Source Anchor feature. This feature was introduced in version 1.1.524.0 and after. When the
synchronization rule is removed, Azure AD Connect can no longer populate on-premises AD ms-DS-
ConsistencyGuid attribute with the ObjectGuid attribute value. It does not prevent new users from
being provisioned into Azure AD.
The fix ensures that the synchronization rule will no longer be removed during upgrade, or during
configuration change, as long as the feature is enabled. For existing customers who have been
affected by this issue, the fix also ensures that the synchronization rule is added back after upgrading
to this version of Azure AD Connect.
Fixed an issue that causes out-of-box synchronization rules to have precedence value that is less than 100:
In general, precedence values 0 - 99 are reserved for custom synchronization rules. During upgrade,
the precedence values for out-of-box synchronization rules are updated to accommodate sync rule
changes. Due to this issue, out-of-box synchronization rules may be assigned precedence value that is
less than 100.
The fix prevents the issue from occurring during upgrade. However, it does not restore the
precedence values for existing customers who have been affected by the issue. A separate fix will be
provided in the future to help with the restoration.
Fixed an issue where the Domain and OU Filtering screen in the Azure AD Connect wizard is showing Sync
all domains and OUs option as selected, even though OU-based filtering is enabled.
Fixed an issue that caused the Configure Directory Partitions screen in the Synchronization Service Manager
to return an error if the Refresh button is clicked. The error message is “An error was encountered while
refreshing domains: Unable to cast object of type ‘System.Collections.ArrayList’ to type
‘Microsoft.DirectoryServices.MetadirectoryServices.UI.PropertySheetBase.MaPropertyPages.PartitionObject.”
The error occurs when new AD domain has been added to an existing AD forest and you are trying to
update Azure AD Connect using the Refresh button.
Automatic Upgrade feature has been expanded to support customers with the following configurations:
You have enabled the device writeback feature.
You have enabled the group writeback feature.
The installation is not an Express settings or a DirSync upgrade.
You have more than 100,000 objects in the metaverse.
You are connecting to more than one forest. Express setup only connects to one forest.
The AD Connector account is not the default MSOL_ account anymore.
The server is set to be in staging mode.
You have enabled the user writeback feature.
NOTE
The scope expansion of the Automatic Upgrade feature affects customers with Azure AD Connect build 1.1.105.0 and
after. If you do not want your Azure AD Connect server to be automatically upgraded, you must run following cmdlet
on your Azure AD Connect server: Set-ADSyncAutoUpgrade -AutoUpgradeState disabled . For more information
about enabling/disabling Automatic Upgrade, refer to article Azure AD Connect: Automatic upgrade.
1.1.558.0
Status: Will not be released. Changes in this build are included in version 1.1.561.0.
Azure AD Connect
Fixed issue
Fixed an issue that caused the out-of-box synchronization rule “Out to AD - User ImmutableId” to be
removed when OU-based filtering configuration is updated. This synchronization rule is required for the ms-
DS-ConsistencyGuid as Source Anchor feature.
Fixed an issue where the Domain and OU Filtering screen in the Azure AD Connect wizard is showing Sync
all domains and OUs option as selected, even though OU-based filtering is enabled.
Fixed an issue that caused the Configure Directory Partitions screen in the Synchronization Service Manager
to return an error if the Refresh button is clicked. The error message is “An error was encountered while
refreshing domains: Unable to cast object of type ‘System.Collections.ArrayList’ to type
‘Microsoft.DirectoryServices.MetadirectoryServices.UI.PropertySheetBase.MaPropertyPages.PartitionObject.”
The error occurs when new AD domain has been added to an existing AD forest and you are trying to
update Azure AD Connect using the Refresh button.
Automatic Upgrade feature has been expanded to support customers with the following configurations:
You have enabled the device writeback feature.
You have enabled the group writeback feature.
The installation is not an Express settings or a DirSync upgrade.
You have more than 100,000 objects in the metaverse.
You are connecting to more than one forest. Express setup only connects to one forest.
The AD Connector account is not the default MSOL_ account anymore.
The server is set to be in staging mode.
You have enabled the user writeback feature.
NOTE
The scope expansion of the Automatic Upgrade feature affects customers with Azure AD Connect build 1.1.105.0 and
after. If you do not want your Azure AD Connect server to be automatically upgraded, you must run following cmdlet
on your Azure AD Connect server: Set-ADSyncAutoUpgrade -AutoUpgradeState disabled . For more information
about enabling/disabling Automatic Upgrade, refer to article Azure AD Connect: Automatic upgrade.
1.1.557.0
Status: July 2017
NOTE
Azure AD Connect
Fixed issue
Fixed an issue with the Initialize-ADSyncDomainJoinedComputerSync cmdlet that caused the verified domain
configured on the existing service connection point object to be changed even if it is still a valid domain. This
issue occurs when your Azure AD tenant has more than one verified domains that can be used for configuring
the service connection point.
Password writeback is now available for preview with Microsoft Azure Government cloud and Microsoft
Cloud Germany. For more information about Azure AD Connect support for the different service instances,
refer to article Azure AD Connect: Special considerations for instances.
The Initialize-ADSyncDomainJoinedComputerSync cmdlet now has a new optional parameter named
AzureADDomain. This parameter lets you specify which verified domain to be used for configuring the
service connection point.
The name of the agent required for Pass-through Authentication has been changed from Microsoft Azure
AD Application Proxy Connector to Microsoft Azure AD Connect Authentication Agent.
Enabling Pass-through Authentication no longer enables Password Hash Synchronization by default.
1.1.553.0
Status: June 2017
IMPORTANT
There are schema and sync rule changes introduced in this build. Azure AD Connect Synchronization Service will trigger Full
Import and Full Synchronization steps after upgrade. Details of the changes are described below. To temporarily defer Full
Import and Full Synchronization steps after upgrade, refer to article How to defer full synchronization after upgrade.

Known issue
There is an issue that affects customers who are using OU-based filtering with Azure AD Connect sync. When
you navigate to the Domain and OU Filtering page in the Azure AD Connect wizard, the following behavior is
expected:
If OU-based filtering is enabled, the Sync selected domains and OUs option is selected.
Otherwise, the Sync all domains and OUs option is selected.
The issue that arises is that the Sync all domains and OUs option is always selected when you run the Wizard.
This occurs even if OU-based filtering was previously configured. Before saving any Azure AD Connect
configuration changes, make sure the Sync selected domains and OUs option is selected and confirm that all
OUs that need to synchronize are enabled again. Otherwise, OU-based filtering will be disabled.
Fixed issues
Fixed an issue with Password writeback that allows an Azure AD Administrator to reset the password of an
on-premises AD privileged user account. The issue occurs when Azure AD Connect is granted the Reset
Password permission over the privileged account. The issue is addressed in this version of Azure AD
Connect by not allowing an Azure AD Administrator to reset the password of an arbitrary on-premises AD
privileged user account unless the administrator is the owner of that account. For more information, refer to
Security Advisory 4033453.
Fixed an issue related to the ms-DS-ConsistencyGuid as Source Anchor feature where Azure AD Connect
does not writeback to on-premises AD ms-DS-ConsistencyGuid attribute. The issue occurs when there are
multiple on-premises AD forests added to Azure AD Connect and the User identities exist across multiple
directories option is selected. When such configuration is used, the resultant synchronization rules do not
populate the sourceAnchorBinary attribute in the Metaverse. The sourceAnchorBinary attribute is used as
the source attribute for ms-DS-ConsistencyGuid attribute. As a result, writeback to the ms-
DSConsistencyGuid attribute does not occur. To fix the issue, following sync rules have been updated to
ensure that the sourceAnchorBinary attribute in the Metaverse is always populated:
In from AD - InetOrgPerson AccountEnabled.xml
In from AD - InetOrgPerson Common.xml
In from AD - User AccountEnabled.xml
In from AD - User Common.xml
In from AD - User Join SOAInAAD.xml
Previously, even if the ms-DS-ConsistencyGuid as Source Anchor feature isn’t enabled, the “Out to AD –
User ImmutableId” synchronization rule is still added to Azure AD Connect. The effect is benign and does not
cause writeback of ms-DS-ConsistencyGuid attribute to occur. To avoid confusion, logic has been added to
ensure that the sync rule is only added when the feature is enabled.
Fixed an issue that caused password hash synchronization to fail with error event 611. This issue occurs
after one or more domain controllers have been removed from on-premises AD. At the end of each
password synchronization cycle, the synchronization cookie issued by on-premises AD contains Invocation
IDs of the removed domain controllers with USN (Update Sequence Number) value of 0. The Password
Synchronization Manager is unable to persist synchronization cookie containing USN value of 0 and fails
with error event 611. During the next synchronization cycle, the Password Synchronization Manager reuses
the last persisted synchronization cookie that does not contain USN value of 0. This causes the same
password changes to be resynchronized. With this fix, the Password Synchronization Manager persists the
synchronization cookie correctly.
Previously, even if Automatic Upgrade has been disabled using the Set-ADSyncAutoUpgrade cmdlet, the
Automatic Upgrade process continues to check for upgrade periodically, and relies on the downloaded
installer to honor disablement. With this fix, the Automatic Upgrade process no longer checks for upgrade
periodically. The fix is automatically applied when upgrade installer for this Azure AD Connect version is
executed once.
Previously, the ms-DS-ConsistencyGuid as Source Anchor feature was available to new deployments only.
Now, it is available to existing deployments. More specifically:
To access the feature, start the Azure AD Connect wizard and choose the Update Source Anchor option.
This option is only visible to existing deployments that are using objectGuid as sourceAnchor attribute.
When configuring the option, the wizard validates the state of the ms-DS-ConsistencyGuid attribute in
your on-premises Active Directory. If the attribute isn't configured on any user object in the directory, the
wizard uses the ms-DS-ConsistencyGuid as the sourceAnchor attribute. If the attribute is configured on
one or more user objects in the directory, the wizard concludes the attribute is being used by other
applications and is not suitable as sourceAnchor attribute and does not permit the Source Anchor change
to proceed. If you are certain that the attribute isn't used by existing applications, you need to contact
Support for information on how to suppress the error.
Specific to userCer tificate attribute on Device objects, Azure AD Connect now looks for certificates values
required for Connecting domain-joined devices to Azure AD for Windows 10 experience and filters out the
rest before synchronizing to Azure AD. To enable this behavior, the out-of-box sync rule “Out to AAD - Device
Join SOAInAD” has been updated.
Azure AD Connect now supports writeback of Exchange Online cloudPublicDelegates attribute to on-
premises AD publicDelegates attribute. This enables the scenario where an Exchange Online mailbox can
be granted SendOnBehalfTo rights to users with on-premises Exchange mailbox. To support this feature, a
new out-of-box sync rule “Out to AD – User Exchange Hybrid PublicDelegates writeback” has been added.
This sync rule is only added to Azure AD Connect when Exchange Hybrid feature is enabled.
Azure AD Connect now supports synchronizing the altRecipient attribute from Azure AD. To support this
change, following out-of-box sync rules have been updated to include the required attribute flow:
In from AD – User Exchange
Out to AAD – User ExchangeOnline
The cloudSOAExchMailbox attribute in the Metaverse indicates whether a given user has Exchange Online
mailbox or not. Its definition has been updated to include additional Exchange Online RecipientDisplayTypes
as such Equipment and Conference Room mailboxes. To enable this change, the definition of the
cloudSOAExchMailbox attribute, which is found under out-of-box sync rule “In from AAD – User Exchange
Hybrid”, has been updated from:
CBool(IIF(IsNullOrEmpty([cloudMSExchRecipientDisplayType]),NULL,BitAnd([cloudMSExchRecipientDisplayType]
,&HFF) = 0))
... to the following:
CBool(
IIF(IsPresent([cloudMSExchRecipientDisplayType]),(
IIF([cloudMSExchRecipientDisplayType]=0,True,(
IF([cloudMSExchRecipientDisplayType]=1073741840,True,False)))))))))))))))))))),False))
Added the following set of X509Certificate2-compatible functions for creating synchronization rule
expressions to handle certificate values in the userCertificate attribute:
CertSubject
CertIssuer
CertKeyAlgorithm
CertSubjectNameDN
CertIssuerOid
CertNameInfo
CertSubjectNameOid
CertIssuerDN
IsCert
CertFriendlyName
CertThumbprint
CertExtensionOids
CertFormat
CertNotAfter
CertPublicKeyOid
CertSerialNumber
CertNotBefore
CertVersion
Select
CertHashString
Where
With
Following schema changes have been introduced to allow customers to create custom synchronization rules
to flow sAMAccountName, domainNetBios, and domainFQDN for Group objects, as well as
distinguishedName for User objects:
Following attributes have been added to MV schema:
Group: AccountName
Group: domainNetBios
Group: domainFQDN
Person: distinguishedName
Following attributes have been added to Azure AD Connector schema:
Group: OnPremisesSamAccountName
Group: NetBiosName
Group: DnsDomainName
User: OnPremisesDistinguishedName
The ADSyncDomainJoinedComputerSync cmdlet script now has a new optional parameter named
AzureEnvironment. The parameter is used to specify which region the corresponding Azure Active Directory
tenant is hosted in. Valid values include:
AzureCloud (default)
AzureChinaCloud
AzureGermanyCloud
USGovernment
Updated Sync Rule Editor to use Join (instead of Provision) as the default value of link type during sync rule
creation.
AD FS management
Issues fixed
Following URLs are new WS-Federation endpoints introduced by Azure AD to improve resiliency against
authentication outage and will be added to on-premises AD FS replying party trust configuration:
https://ests.login.microsoftonline.com/login.srf
https://stamp2.login.microsoftonline.com/login.srf
https://ccs.login.microsoftonline.com/login.srf
https://ccs-sdf.login.microsoftonline.com/login.srf
Fixed an issue that caused AD FS to generate incorrect claim value for IssuerID. The issue occurs if there are
multiple verified domains in the Azure AD tenant and the domain suffix of the userPrincipalName attribute
used to generate the IssuerID claim is at least 3-levels deep (for example, johndoe@us.contoso.com). The
issue is resolved by updating the regex used by the claim rules.
Previously, the ADFS Certificate Management feature provided by Azure AD Connect can only be used with
ADFS farms managed through Azure AD Connect. Now, you can use the feature with ADFS farms that are not
managed using Azure AD Connect.
1.1.524.0
Released: May 2017
IMPORTANT
There are schema and sync rule changes introduced in this build. Azure AD Connect Synchronization Service will trigger Full
Import and Full Sync steps after upgrade. Details of the changes are described below.
Fixed issues:
Fixed an issue that causes Automatic Upgrade to occur on the Azure AD Connect server even if customer has
disabled the feature using the Set-ADSyncAutoUpgrade cmdlet. With this fix, the Automatic Upgrade process on
the server still checks for upgrade periodically, but the downloaded installer honors the Automatic Upgrade
configuration.
During DirSync in-place upgrade, Azure AD Connect creates an Azure AD service account to be used by the
Azure AD connector for synchronizing with Azure AD. After the account is created, Azure AD Connect
authenticates with Azure AD using the account. Sometimes, authentication fails because of transient issues,
which in turn causes DirSync in-place upgrade to fail with error “An error has occurred executing Configure AAD
Sync task: AADSTS50034: To sign into this application, the account must be added to the xxx.onmicrosoft.com
directory.” To improve the resiliency of DirSync upgrade, Azure AD Connect now retries the authentication step.
There was an issue with build 443 that causes DirSync in-place upgrade to succeed but run profiles required for
directory synchronization are not created. Healing logic is included in this build of Azure AD Connect. When
customer upgrades to this build, Azure AD Connect detects missing run profiles and creates them.
Fixed an issue that causes Password Synchronization process to fail to start with Event ID 6900 and error “An
item with the same key has already been added”. This issue occurs if you update OU filtering configuration to
include AD configuration partition. To fix this issue, Password Synchronization process now synchronizes
password changes from AD domain partitions only. Non-domain partitions such as configuration partition are
skipped.
During Express installation, Azure AD Connect creates an on-premises AD DS account to be used by the AD
connector to communicate with on-premises AD. Previously, the account is created with the PASSWD_NOTREQD
flag set on the user-Account-Control attribute and a random password is set on the account. Now, Azure AD
Connect explicitly removes the PASSWD_NOTREQD flag after the password is set on the account.
Fixed an issue that causes DirSync upgrade to fail with error “a deadlock occurred in sql server which trying to
acquire an application lock” when the mailNickname attribute is found in the on-premises AD schema, but is not
bounded to the AD User object class.
Fixed an issue that causes Device writeback feature to automatically be disabled when an administrator is
updating Azure AD Connect sync configuration using Azure AD Connect wizard. This issue is caused by the
wizard performing a pre-requisite check for the existing Device writeback configuration in on-premises AD and
the check fails. The fix is to skip the check if Device writeback is already enabled previously.
To configure OU filtering, you can either use the Azure AD Connect wizard or the Synchronization Service
Manager. Previously, if you use the Azure AD Connect wizard to configure OU filtering, new OUs created
afterwards are included for directory synchronization. If you do not want new OUs to be included, you must
configure OU filtering using the Synchronization Service Manager. Now, you can achieve the same behavior
using Azure AD Connect wizard.
Fixed an issue that causes stored procedures required by Azure AD Connect to be created under the schema of
the installing admin, instead of under the dbo schema.
Fixed an issue that causes the TrackingId attribute returned by Azure AD to be omitted in the Azure AD Connect
Server Event Logs. The issue occurs if Azure AD Connect receives a redirection message from Azure AD and
Azure AD Connect is unable to connect to the endpoint provided. The TrackingId is used by Support Engineers
to correlate with service side logs during troubleshooting.
When Azure AD Connect receives LargeObject error from Azure AD, Azure AD Connect generates an event with
EventID 6941 and message “The provisioned object is too large. Trim the number of attribute values on this
object.” At the same time, Azure AD Connect also generates a misleading event with EventID 6900 and message
“Microsoft.Online.Coexistence.ProvisionRetryException: Unable to communicate with the Windows Azure Active
Directory service.” To minimize confusion, Azure AD Connect no longer generates the latter event when
LargeObject error is received.
Fixed an issue that causes the Synchronization Service Manager to become unresponsive when trying to update
the configuration for Generic LDAP connector.
New features/improvements:
Sync Rule Changes – The following sync rule changes have been implemented:
Updated default sync rule set to not export attributes userCer tificate and userSMIMECer tificate if
the attributes have more than 15 values.
AD attributes employeeID and msExchBypassModerationLink are now included in the default sync
rule set.
AD attribute photo has been removed from default sync rule set.
Added preferredDataLocation to the Metaverse schema and Azure AD Connector schema. Customers
who want to update either attributes in Azure AD can implement custom sync rules to do so.
Added userType to the Metaverse schema and Azure AD Connector schema. Customers who want to
update either attributes in Azure AD can implement custom sync rules to do so.
Azure AD Connect now automatically enables the use of ConsistencyGuid attribute as the Source Anchor
attribute for on-premises AD objects. Further, Azure AD Connect populates the ConsistencyGuid attribute
with the objectGuid attribute value if it is empty. This feature is applicable to new deployment only. To find
out more about this feature, refer to article section Azure AD Connect: Design concepts - Using ms-DS-
New troubleshooting cmdlet Invoke-ADSyncDiagnostics has been added to help diagnose Password Hash
Synchronization related issues. For information about using the cmdlet, refer to article Troubleshoot
password hash synchronization with Azure AD Connect sync.
Azure AD Connect now supports synchronizing Mail-Enabled Public Folder objects from on-premises AD to
Azure AD. You can enable the feature using Azure AD Connect wizard under Optional Features. To find out
more about this feature, refer to article Office 365 Directory Based Edge Blocking support for on-premises
Mail Enabled Public Folders.
Azure AD Connect requires an AD DS account to synchronize from on-premises AD. Previously, if you
installed Azure AD Connect using the Express mode, you could provide the credentials of an Enterprise
Admin account and Azure AD Connect would create the AD DS account required. However, for a custom
installation and adding forests to an existing deployment, you were required to provide the AD DS account
instead. Now, you also have the option to provide the credentials of an Enterprise Admin account during a
custom installation and let Azure AD Connect create the AD DS account required.
Azure AD Connect now supports SQL AOA. You must enable SQL AOA before installing Azure AD Connect.
During installation, Azure AD Connect detects whether the SQL instance provided is enabled for SQL AOA or
not. If SQL AOA is enabled, Azure AD Connect further figures out if SQL AOA is configured to use
synchronous replication or asynchronous replication. When setting up the Availability Group Listener, it is
recommended that you set the RegisterAllProvidersIP property to 0. This recommendation is because Azure
AD Connect currently uses SQL Native Client to connect to SQL and SQL Native Client does not support the
use of MultiSubNetFailover property.
If you are using LocalDB as the database for your Azure AD Connect server and has reached its 10-GB size
limit, the Synchronization Service no longer starts. Previously, you need to perform ShrinkDatabase
operation on the LocalDB to reclaim enough DB space for the Synchronization Service to start. After which,
you can use the Synchronization Service Manager to delete run history to reclaim more DB space. Now, you
can use Start-ADSyncPurgeRunHistory cmdlet to purge run history data from LocalDB to reclaim DB space.
Further, this cmdlet supports an offline mode (by specifying the -offline parameter) which can be used when
the Synchronization Service is not running. Note: The offline mode can only be used if the Synchronization
Service is not running and the database used is LocalDB.
To reduce the amount of storage space required, Azure AD Connect now compresses sync error details
before storing them in LocalDB/SQL databases. When upgrading from an older version of Azure AD
Connect to this version, Azure AD Connect performs a one-time compression on existing sync error details.
Previously, after updating OU filtering configuration, you must manually run Full import to ensure existing
objects are properly included/excluded from directory synchronization. Now, Azure AD Connect
automatically triggers Full import during the next sync cycle. Further, Full import is only be applied to the
AD connectors affected by the update. Note: this improvement is applicable to OU filtering updates made
using the Azure AD Connect wizard only. It is not applicable to OU filtering update made using the
Synchronization Service Manager.
Previously, Group-based filtering supports Users, Groups, and Contact objects only. Now, Group-based
filtering also supports Computer objects.
Previously, you can delete Connector Space data without disabling Azure AD Connect sync scheduler. Now,
the Synchronization Service Manager blocks the deletion of Connector Space data if it detects that the
scheduler is enabled. Further, a warning is returned to inform customers about potential data loss if the
Connector space data is deleted.
Previously, you must disable PowerShell transcription for Azure AD Connect wizard to run correctly. This
issue is partially resolved. You can enable PowerShell transcription if you are using Azure AD Connect wizard
to manage sync configuration. You must disable PowerShell transcription if you are using Azure AD Connect
wizard to manage ADFS configuration.
1.1.486.0
Released: April 2017
Fixed issues:
Fixed the issue where Azure AD Connect will not install successfully on localized version of Windows Server.
1.1.484.0
Known issues:
This version of Azure AD Connect will not install successfully if the following conditions are all true:
1. You are performing either DirSync in-place upgrade or fresh installation of Azure AD Connect.
2. You are using a localized version of Windows Server where the name of built-in Administrator group on
the server isn't "Administrators".
3. You are using the default SQL Server 2012 Express LocalDB installed with Azure AD Connect instead of
providing your own full SQL.
Fixed issues:
Fixed an issue where the sync scheduler skips the entire sync step if one or more connectors are missing run
profile for that sync step. For example, you manually added a connector using the Synchronization Service
Manager without creating a Delta Import run profile for it. This fix ensures that the sync scheduler continues to
run Delta Import for other connectors.
Fixed an issue where the Synchronization Service immediately stops processing a run profile when it is
encounters an issue with one of the run steps. This fix ensures that the Synchronization Service skips that run
step and continues to process the rest. For example, you have a Delta Import run profile for your AD connector
with multiple run steps (one for each on-premises AD domain). The Synchronization Service will run Delta
Import with the other AD domains even if one of them has network connectivity issues.
Fixed an issue that causes the Azure AD Connector update to be skipped during Automatic Upgrade.
Fixed an issue that causes Azure AD Connect to incorrectly determine whether the server is a domain controller
during setup, which in turn causes DirSync upgrade to fail.
Fixed an issue that causes DirSync in-place upgrade to not create any run profile for the Azure AD Connector.
Fixed an issue where the Synchronization Service Manager user interface becomes unresponsive when trying to
configure Generic LDAP Connector.
AD FS management
Fixed an issue where the Azure AD Connect wizard fails if the AD FS primary node has been moved to another
server.
Desktop SSO
Fixed an issue in the Azure AD Connect wizard where the Sign-In screen does not let you enable Desktop SSO
feature if you chose Password Synchronization as your Sign-In option during new installation.
Azure AD Connect Sync now supports the use of Virtual Service Account, Managed Service Account and Group
Managed Service Account as its service account. This applies to new installation of Azure AD Connect only.
When installing Azure AD Connect:
By default, Azure AD Connect wizard will create a Virtual Service Account and uses it as its service
account.
If you are installing on a domain controller, Azure AD Connect falls back to previous behavior where it
will create a domain user account and uses it as its service account instead.
You can override the default behavior by providing one of the following:
A Group Managed Service Account
A Managed Service Account
A domain user account
A local user account
Previously, if you upgrade to a new build of Azure AD Connect containing connectors update or sync rule
changes, Azure AD Connect will trigger a full sync cycle. Now, Azure AD Connect selectively triggers Full Import
step only for connectors with update, and Full Synchronization step only for connectors with sync rule changes.
Previously, the Export Deletion Threshold only applies to exports which are triggered through the sync
scheduler. Now, the feature is extended to include exports manually triggered by the customer using the
Synchronization Service Manager.
On your Azure AD tenant, there is a service configuration which indicates whether Password Synchronization
feature is enabled for your tenant or not. Previously, it is easy for the service configuration to be incorrectly
configured by Azure AD Connect when you have an active and a staging server. Now, Azure AD Connect will
attempt to keep the service configuration consistent with your active Azure AD Connect server only.
Azure AD Connect wizard now detects and returns a warning if on-premises AD does not have AD Recycle Bin
enabled.
Previously, Export to Azure AD times out and fails if the combined size of the objects in the batch exceeds
certain threshold. Now, the Synchronization Service will reattempt to resend the objects in separate, smaller
batches if the issue is encountered.
The Synchronization Service Key Management application has been removed from Windows Start Menu.
Management of encryption key will continue to be supported through command-line interface using
miiskmu.exe. For information about managing encryption key, refer to article Abandoning the Azure AD
Connect Sync encryption key.
Previously, if you change the Azure AD Connect sync service account password, the Synchronization Service will
not be able start correctly until you have abandoned the encryption key and reinitialized the Azure AD Connect
sync service account password. Now, this process is no longer required.
Desktop SSO
Azure AD Connect wizard no longer requires port 9090 to be opened on the network when configuring Pass-
through Authentication and Desktop SSO. Only port 443 is required.
1.1.443.0
Released: March 2017
Fixed issues:
Fixed an issue which causes Azure AD Connect wizard to fail if the display name of the Azure AD Connector
does not contain the initial onmicrosoft.com domain assigned to the Azure AD tenant.
Fixed an issue which causes Azure AD Connect wizard to fail while making connection to SQL database when
the password of the Sync Service Account contains special characters such as apostrophe, colon and space.
Fixed an issue which causes the error “The image has an anchor that is different than the image” to occur on an
Azure AD Connect server in staging mode, after you have temporarily excluded an on-premises AD object from
syncing and then included it again for syncing.
Fixed an issue which causes the error “The object located by DN is a phantom” to occur on an Azure AD Connect
server in staging mode, after you have temporarily excluded an on-premises AD object from syncing and then
included it again for syncing.
AD FS management
Fixed an issue where Azure AD Connect wizard does not update AD FS configuration and set the right claims on
the relying party trust after Alternate Login ID is configured.
Fixed an issue where Azure AD Connect wizard is unable to correctly handle AD FS servers whose service
accounts are configured using userPrincipalName format instead of sAMAccountName format.
Fixed an issue which causes Azure AD Connect wizard to fail if Pass Through Authentication is selected but
registration of its connector fails.
Fixed an issue which causes Azure AD Connect wizard to bypass validation checks on sign-in method selected
when Desktop SSO feature is enabled.
Password Reset
Fixed an issue which may cause the Azure Azure AD Connect server to not attempt to re-connect if the
connection was killed by a firewall or proxy.
Get-ADSyncScheduler cmdlet now returns a new Boolean property named SyncCycleInProgress. If the returned
value is true, it means that there is a scheduled synchronization cycle in progress.
Destination folder for storing Azure AD Connect installation and setup logs has been moved from
%localappdata%\AADConnect to %programdata%\AADConnect to improve accessibility to the log files.
AD FS management
Added support for updating AD FS Farm TLS/SSL Certificate.
Added support for managing AD FS 2016.
You can now specify existing gMSA (Group Managed Service Account) during AD FS installation.
You can now configure SHA-256 as the signature hash algorithm for Azure AD relying party trust.
Password Reset
Introduced improvements to allow the product to function in environments with more stringent firewall rules.
Improved connection reliability to Azure Service Bus.
1.1.380.0
Released: December 2016
Fixed issue:
Fixed the issue where the issuerid claim rule for Active Directory Federation Services (AD FS) is missing in this
build.
NOTE
1.1.371.0
Known issue:
The issuerid claim rule for AD FS is missing in this build. The issuerid claim rule is required if you are federating
multiple domains with Azure Active Directory (Azure AD). If you are using Azure AD Connect to manage your
on-premises AD FS deployment, upgrading to this build removes the existing issuerid claim rule from your AD
FS configuration. You can work around the issue by adding the issuerid claim rule after the installation/upgrade.
For details on adding the issuerid claim rule, refer to this article on Multiple domain support for federating with
Azure AD.
Fixed issue:
If Port 9090 is not opened for the outbound connection, the Azure AD Connect installation or upgrade fails.
NOTE
1.1.370.0
Known issues:
multiple domains with Azure AD. If you are using Azure AD Connect to manage your on-premises AD FS
deployment, upgrading to this build removes the existing issuerid claim rule from your AD FS configuration.
You can work around the issue by adding the issuerid claim rule after installation/upgrade. For details on adding
issuerid claim rule, refer to this article on Multiple domain support for federating with Azure AD.
Port 9090 must be open outbound to complete installation.
New features:
Pass-through Authentication (Preview).
NOTE
1.1.343.0
Released: November 2016
Known issue:
multiple domains with Azure AD. If you are using Azure AD Connect to manage your on-premises AD FS
deployment, upgrading to this build removes the existing issuerid claim rule from your AD FS configuration.
You can work around the issue by adding the issuerid claim rule after installation/upgrade. For details on adding
issuerid claim rule, refer to this article on Multiple domain support for federating with Azure AD.
Fixed issues:
Sometimes, installing Azure AD Connect fails because it is unable to create a local service account whose
password meets the level of complexity specified by the organization's password policy.
Fixed an issue where join rules are not reevaluated when an object in the connector space simultaneously
becomes out-of-scope for one join rule and become in-scope for another. This can happen if you have two or
more join rules whose join conditions are mutually exclusive.
Fixed an issue where inbound synchronization rules (from Azure AD), which do not contain join rules, are not
processed if they have lower precedence values than those containing join rules.
Improvements:
Added support for installing Azure AD Connect on Windows Server 2016 Standard or higher.
Added support for using SQL Server 2016 as the remote database for Azure AD Connect.
1.1.281.0
Released: August 2016
Fixed issues:
Changes to sync interval do not take place until after the next sync cycle is complete.
Azure AD Connect wizard does not accept an Azure AD account whose username starts with an underscore (_).
Azure AD Connect wizard fails to authenticate the Azure AD account if the account password contains too many
special characters. Error message "Unable to validate credentials. An unexpected error has occurred." is
returned.
Uninstalling staging server disables password synchronization in Azure AD tenant and causes password
synchronization to fail with active server.
Password synchronization fails in uncommon cases when there is no password hash stored on the user.
When Azure AD Connect server is enabled for staging mode, password writeback is not temporarily disabled.
Azure AD Connect wizard does not show the actual password synchronization and password writeback
configuration when server is in staging mode. It always shows them as disabled.
Configuration changes to password synchronization and password writeback are not persisted by Azure AD
Connect wizard when server is in staging mode.
Improvements:
Updated the Start-ADSyncSyncCycle cmdlet to indicate whether it is able to successfully start a new sync cycle
or not.
Added the Stop-ADSyncSyncCycle cmdlet to terminate sync cycle and operation, which are currently in
progress.
Updated the Stop-ADSyncScheduler cmdlet to terminate sync cycle and operation, which are currently in
progress.
When configuring Directory extensions in Azure AD Connect wizard, the Azure AD attribute of type "Teletex
string" can now be selected.
1.1.189.0
Released: June 2016
Fixed issues and improvements:
Azure AD Connect can now be installed on a FIPS-compliant server.
For password synchronization, see Password hash sync and FIPS.
Fixed an issue where a NetBIOS name could not be resolved to the FQDN in the Active Directory Connector.
1.1.180.0
Released: May 2016
New features:
Warns and helps you verify domains if you didn’t do it before running Azure AD Connect.
Added support for Microsoft Cloud Germany.
Added support for the latest Microsoft Azure Government cloud infrastructure with new URL requirements.
Added filtering to the Sync Rule Editor to make it easy to find sync rules.
Improved performance when deleting a connector space.
Fixed an issue when the same object was both deleted and added in the same run (called delete/add).
A disabled sync rule no longer re-enables included objects and attributes on upgrade or directory schema
refresh.
1.1.130.0
New features:
Added support for multi-valued attributes to Directory extensions.
Added support for more configuration variations for automatic upgrade to be considered eligible for upgrade.
Added some cmdlets for custom scheduler.
1.1.119.0
Released: March 2016
Fixed issues:
Made sure Express installation cannot be used on Windows Server 2008 (pre-R2) because password sync is not
supported on this operating system.
Upgrade from DirSync with a custom filter configuration did not work as expected.
When upgrading to a newer release and there are no changes to the configuration, a full
import/synchronization should not be scheduled.
1.1.110.0
Released: February 2016
Fixed issues:
Upgrade from earlier releases does not work if the installation is not in the default C:\Program Files folder.
If you install and clear Star t the synchronization process at the end of the installation wizard, running the
installation wizard a second time will not enable the scheduler.
The scheduler doesn't work as expected on servers where the US-en date/time format is not used. It will also
block Get-ADSyncScheduler to return correct times.
If you installed an earlier release of Azure AD Connect with AD FS as the sign-in option and upgrade, you cannot
run the installation wizard again.
1.1.105.0
New features:
Automatic upgrade feature for Express settings customers.
Support for the global admin by using Azure Multi-Factor Authentication and Privileged Identity Management
in the installation wizard.
You need to allow your proxy to also allow traffic to https://secure.aadcdn.microsoftonline-p.com if you
use Multi-Factor Authentication.
You need to add https://secure.aadcdn.microsoftonline-p.com to your trusted sites list for Multi-Factor
Authentication to properly work.
Allow changing the user's sign-in method after initial installation.
Allow Domain and OU filtering in the installation wizard. This also allows connecting to forests where not all
domains are available.
Scheduler is built in to the sync engine.
Features promoted from preview to GA:
Device writeback.
Directory extensions.
The new default sync cycle interval is 30 minutes. Used to be three hours for all earlier releases. Adds support to
change the scheduler behavior.
Fixed issues:
The verify DNS domains page didn't always recognize the domains.
Prompts for domain admin credentials when configuring AD FS.
The on-premises AD accounts are not recognized by the installation wizard if located in a domain with a
different DNS tree than the root domain.
1.0.9131.0
Fixed issues:
Password sync might not work when you change passwords in Active Directory Domain Services (AD DS), but
works when you do set a password.
When you have a proxy server, authentication to Azure AD might fail during installation, or if an upgrade is
canceled on the configuration page.
Updating from a previous release of Azure AD Connect with a full SQL Server instance fails if you are not a SQL
Server system administrator (SA).
Updating from a previous release of Azure AD Connect with a remote SQL Server shows the “Unable to access
the ADSync SQL database” error.
1.0.9125.0
Released: November 2015
New features:
Can reconfigure AD FS to Azure AD trust.
Can refresh the Active Directory schema and regenerate sync rules.
Can disable a sync rule.
Can define "AuthoritativeNull" as a new literal in a sync rule.
Azure AD Connect Health for sync.
Support for Azure AD Domain Services password synchronization.
New suppor ted scenario:
Supports multiple on-premises Exchange organizations. For more information, see Hybrid deployments with
multiple Active Directory forests.
Fixed issues:
Password synchronization issues:
An object moved from out-of-scope to in-scope will not have its password synchronized. This includes
both OU and attribute filtering.
Selecting a new OU to include in sync does not require a full password sync.
When a disabled user is enabled the password does not sync.
The password retry queue is infinite and the previous limit of 5,000 objects to be retired has been
removed.
Not able to connect to Active Directory with Windows Server 2016 forest-functional level.
Not able to change the group that is used for group filtering after the initial installation.
No longer creates a new user profile on the Azure AD Connect server for every user doing a password change
with password writeback enabled.
Not able to use Long Integer values in sync rules scopes.
The check box "device writeback" remains disabled if there are unreachable domain controllers.
1.0.8667.0
Released: August 2015
New features:
The Azure AD Connect installation wizard is now localized to all Windows Server languages.
Added support for account unlock when using Azure AD password management.
Fixed issues:
Azure AD Connect installation wizard crashes if another user continues installation rather than the person who
first started the installation.
If a previous uninstallation of Azure AD Connect fails to uninstall Azure AD Connect sync cleanly, it is not
possible to reinstall.
Cannot install Azure AD Connect using Express installation if the user is not in the root domain of the forest or if
a non-English version of Active Directory is used.
If the FQDN of the Active Directory user account cannot be resolved, a misleading error message “Failed to
commit the schema” is shown.
If the account used on the Active Directory Connector is changed outside the wizard, the wizard fails on
subsequent runs.
Azure AD Connect sometimes fails to install on a domain controller.
Cannot enable and disable “Staging mode” if extension attributes have been added.
Password writeback fails in some configurations because of a bad password on the Active Directory Connector.
DirSync cannot be upgraded if a distinguished name (DN) is used in attribute filtering.
Excessive CPU usage when using password reset.
Removed preview features:
The preview feature User writeback was temporarily removed based on feedback from our preview customers.
It will be added again later after we have addressed the provided feedback.
1.0.8641.0
Released: June 2015
Initial release of Azure AD Connect.
Changed name from Azure AD Sync to Azure AD Connect.
New features:
Express settings installation
Can configure AD FS
Can upgrade from DirSync
Prevent accidental deletes
Introduced staging mode
User writeback
Device writeback
Directory extensions
1.0.494.0501
Released: May 2015
New Requirement:
Azure AD Sync now requires the .NET Framework version 4.5.1 to be installed.
Fixed issues:
Password writeback from Azure AD is failing with an Azure Service Bus connectivity error.
1.0.491.0413
The Active Directory Connector does not process deletes correctly if the recycle bin is enabled and there are
multiple domains in the forest.
The performance of import operations has been improved for the Azure Active Directory Connector.
When a group has exceeded the membership limit (by default, the limit is set to 50,000 objects), the group was
deleted in Azure Active Directory. With the new behavior, the group is not deleted, an error is thrown, and new
membership changes are not exported.
A new object cannot be provisioned if a staged delete with the same DN is already present in the connector
space.
Some objects are marked for synchronization during a delta sync even though there's no change staged on the
object.
Forcing a password sync also removes the preferred DC list.
CSExportAnalyzer has problems with some objects states.
New features:
A join can now connect to “ANY” object type in the MV.
1.0.485.0222
Improvements:
Improved import performance.
Fixed issues:
Password Sync honors the cloudFiltered attribute that is used by attribute filtering. Filtered objects are no longer
in scope for password synchronization.
In rare situations where the topology had many domain controllers, password sync doesn’t work.
“Stopped-server” when importing from the Azure AD Connector after device management has been enabled in
Azure AD/Intune.
Joining Foreign Security Principals (FSPs) from multiple domains in same forest causes an ambiguous-join
error.
1.0.475.1202
New features:
Password synchronization with attribute-based filtering is now supported. For more information, see Password
synchronization with filtering.
The ms-DS-ExternalDirectoryObjectID attribute is written back to Active Directory. This feature adds support for
Office 365 applications. It uses OAuth2 to access online and on-premises mailboxes in a Hybrid Exchange
Deployment.
Fixed upgrade issues:
A newer version of the sign-in assistant is available on the server.
A custom installation path was used to install Azure AD Sync.
An invalid custom join criterion blocks the upgrade.
Other fixes:
Fixed the templates for Office Pro Plus.
Fixed installation issues caused by user names that start with a dash.
Fixed losing the sourceAnchor setting when running the installation wizard a second time.
Fixed ETW tracing for password synchronization.
1.0.470.1023
Released: October 2014
New features:
Password synchronization from multiple on-premises Active Directory to Azure AD.
Localized installation UI to all Windows Server languages.
Upgrading from AADSync 1.0 GA
If you already have Azure AD Sync installed, there is one additional step you have to take in case you have changed
any of the out-of-box synchronization rules. After you have upgraded to the 1.0.470.1023 release, the
synchronization rules you have modified are duplicated. For each modified sync rule, do the following:
1. Locate the sync rule you have modified and take a note of the changes.
2. Delete the sync rule.
3. Locate the new sync rule that is created by Azure AD Sync and then reapply the changes.
Permissions for the Active Director y account
The Active Directory account must be granted additional permissions to be able to read the password hashes from
Active Directory. The permissions to grant are named “Replicating Directory Changes” and “Replicating Directory
Changes All.” Both permissions are required to be able to read the password hashes.
1.0.419.0911
Released: September 2014
Initial release of Azure AD Sync.
Next steps

Hybrid Identity Documentation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hybrid Identity Documentation

Uploaded by

Copyright:

Available Formats

Contents

Hybrid identity documentation

Common scenarios and recommendations

I N EED TO : P H S A N D SSO 1 P TA A N D SSO 2 A D F S3

Sync new user, contact,

Set up my tenant for

Enable my users to sign

Implement single sign-on

Display password expiry

1 Password hash synchronization with single sign-on.

2 Pass-through authentication and single sign-on.

3 Federated single sign-on with AD FS.

License requirements for using Azure AD Connect

Create a virtual machine

#Create New Virtual Machine

#Set the memory to be non-dynamic

#Add DVD Drive to Virtual Machine

#Mount Installation Media

#Configure Virtual Machine to Boot from DVD

Complete the operating system deployment

Install Active Directory prerequisites

#Set static IP address

# Set the DNS servers

#Rename the computer

#Restart the computer

Create a Windows Server AD environment

#Install AD DS, DNS and GPMC

#Create New AD Forest

#Create the user

#Set the password to never expire

Create an Azure AD tenant

Create a global administrator in Azure AD

Download and install Azure AD Connect

Verify users are created and synchronization is occurring

Test signing in with one of our users

Create a virtual machine

#Create New Virtual Machine

#Set the memory to be non-dynamic

#Add DVD Drive to Virtual Machine

#Mount Installation Media

#Configure Virtual Machine to Boot from DVD

Complete the operating system deployment

Install Active Directory prerequisites

#Set static IP address

# Set the DNS servers

#Rename the computer

#Restart the computer

Create a Windows Server AD environment

#Install AD DS, DNS and GPMC

#Create New AD Forest

Create a Windows Server AD user

#Create the user

#Set the password to never expire

Create an Azure AD tenant

Create a global administrator in Azure AD

Add the custom domain name to your directory

6. To ensure that it is verified, click the Verify button.

Download and install Azure AD Connect

Verify users are created and synchronization is occurring

Test signing in with one of our users

Create a virtual machine

#Create New Virtual Machine

#Set the memory to be non-dynamic

#Add DVD Drive to Virtual Machine