Azure Active Directory now supports Password Synchronization as both an alternative to Single Sign-On, as well as a temporary backup for your Single Sign-On experience.

Whereas you could previously only enable a user for Single Sign-On OR you could sync their password, we have now completed updates to the service so that you can be synchronizing passwords for your Federated Users, and if your on-premises Single Sign-On infrastructure becomes unavailable, you can switch to let users sign in with their synchronized passwords while you’re resolving those infrastructure problems!

Best of all, there is no need to update your DirSync if you’re already running Password Sync!

Timing Considerations

Changing a user’s authentication details can be a disruptive activity. As such, you should plan carefully and schedule the migration at a time that is least disruptive to the end-user(s) that are being affected. Additionally it can take up to 2 hours for the domain conversation from federated to standard authentication to be updated in the various systems.

Background

At General Availability, the Password Synchronization feature did not support the synchronization of passwords for users in a Federated namespace.

We have recently updated the service code to allow this.

This enables the added possibility of running Password Sync while using Single Sign-On, and temporarily switching over to use synchronized passwords for login if you experience availability issues with your SSO infrastructure!

Mixing Password Sync and Federated Authentication in the same tenant

Customers can have a mix of managed and federated namespaces within the same tenant. For example, a customer with 3 domains (domain1.com, domain2.com, domain3.com) may elect to configure domain1.com and domain3.com for Password Sync, but continue to have domain2.com configured for federated authentication. It is not supported to configure users within the same namespace for both federated authentication and password sync. Similarly, a customer may enable

Deploying Password Sync as a backup for Single Sign-On

With this latest update, you may elect to deploy Password Sync to provide a backup solution for your Single Sign-On infrastructure. To accomplish this task, simply deploy the Directory Sync tool and enable the Password Sync option when prompted in the Configuration Wizard (if you haven’t already). More information on the Implementing Password Sync can be found here .

If you are already running Password Sync, you don’t need to upgrade your DirSync tool to light up this feature! Just make sure you run a full password sync now so that all of your users’ passwords are synchronized to the cloud. You can trigger a full Password Sync to re-synchronize all DirSync’ing user passwords via the Set-FullPasswordSync cmdlet. Documentation on how to use this password may be found here.

Temporarily Switching from Single Sign-On to Synchronizated Passwords for Sign-In

If your Single Sign-On infrastructure becomes unavailable, you can now “switch” to using the synchronized password hashes for user sign-in while you resolve your infrastructure incident on a per-domain basis. Please refer to the “Entire Namespace Conversion” section below on how to do this. Be sure to set -SkipUserConversion $true when calling the Convert-MsolDomainToStandard commandlet.

It is recommended that you do not change UserPrincipalNames or ImmutableIds after converting your domain to managed state (via the Convert-MsolDomainToStandard commandlet) for users that have been switched to use sync’d passwords.

In the case where such changes have been made, administrators will notice that these changes do not show up in the cloud – this is by design.

When you convert the domain back to a federated state, the changes will be processed per usual.

Important

Switching from Single Sign-On to use Synchronized Passwords for Sign-In is not instantaneous.

Please see the Timing Considerations section below for guidance on when you should consider switching or waiting out the Single Sign-On outage window.

Switch to use Password Sync exclusively

If you have decided that you no longer wish to use Single Sign-On and that Password Synchronization will meet your business needs, you can switch to use Password Synchronization. There are two approaches to accomplishing this task:

Incremental migration – consider this approach if you wish to test out password sync for some users in your company before switching a larger set of users.

Entire namespace conversion – consider this approach if you are ready to switch large sets of users from federated authentication to managed authentication with password sync.

Important

In both cases, you need to ensure that the user’s password is sync’d before the user logs in.

You can accomplish this by running a full password sync prior to domain conversion, after domain conversion, or having the user will change their password on-premises to get their passwords consistent.

See Stage 2 of either Approach outlined below for guidance on this.

Approach 1 – Incremental Migration

If you want to incrementally transition your users from Federated Authentication to Managed Authentication, you can do so by switching your users from a Federated Namespace to a Managed Namespace, then synchronizing the passwords for the converted users.

Important

Following this approach will change the namespace of the migrated user’s UserPrincipalName (the domain following the ‘@’ sign).

This will potentially impact your users’ login experience.

Be sure to notify your users that their login name has changed.

The procedure, at a high level, is as follows:

Stage 1 – Update the users to migrate

Update the user’s UserPrincipalName from a Federated to a Managed Namespace for the users you wish to migrate from federated to managed authentication.

Do this in your on-premises Active Directory, then trigger a Directory Sync cycle to sync those changes to the cloud.

Note

To trigger a Directory Sync manually, perform the following steps:

Open PowerShell, and then type Import-Module DirSync

Type Start-OnlineCoexistenceSync, and then press Enter

Verify the user’s UserPrincipalName has changed in the cloud.

This can be done using the Get-MsolUser commandlet.

The Azure Active Directory Powershell Module and documentation on the commandlet set can be found here .

Stage 2 – Synchronize user passwords

After you have confirmed that your users’ UserPrincipalNames have been updated in the on-premises AD, have those users update their password in your on-premises Active Directory. This will trigger the password to synchronize to the cloud.

Once their password has been synchronized to the cloud, the user will be able to log into their cloud services using the same password as their on-premises password.

Approach 2 – Entire namespace conversion

Once a customer is ready to transition an entire namespace from Federated to Managed Authentication, they may follow this procedure to migrate all of their users from Federated Authentication to Managed Authentication. This is the same procedure that should be used if converting a to Managed state while troubleshooting your on-premises Single Sign-On infrastructure.

Important

Users will not be able to log into the cloud with their on-premises password until Password Sync has successfully synchronized their passwords.

This means that users will not be able to use the service during the period of time between Stage 1 completion and Stage 2 completion.

It is important to schedule the conversion over a weekend (if this is a planned activity) or another time during which the user will not be disrupted while their credentials are being converted and password synchronized.

Stage 1 – Convert the namespace

Convert the desired namespace from Federated to Managed with the Convert-MsolDomainToStandard cmdlet.

Replace <federated domain name> represents the name of the domain you are converting.

This command removes the Relying Party Trust information from the Office 365 authentication system federation service and the on-premises AD FS 2.0 federation service. The -PasswordFile parameter indicates the path of the text file that contains the newly created temporary password of each formerly federated user’s account and must not exist before calling the cmdlet.

Important

If you are temporariliy switching to use synchronized passwords while you are repairing your SSO infrastructure, set –SkipUserConversion to be $true.

If you are permanently decommissioning your SSO Infrastructure, set -SkipUserConversion to $false to ensure users are converted correctly

Additionally if the AD FS server is not available because of a failure you can convert the domain to Standard using the Set-MsolDomainAuthentication cmdlet to set the authentication to managed.

You can confirm if all users are converted by running the cmdlet Convert-MSOLDomainToStandard a second time. When run the second time, you must specify a different password file. For users that have already be converted they will not be issued a new password. Similarly if you have problems with converting some users you can call the cmdlet Convert-MsolFederatedUser to convert a single user.

If required/desired you can manually convert all users in a domain by following the sample script below.

Stage 2 – Synchronize user passwords

At this point, if you have not previously run a full Password Sync, (or you first deployed Password Sync before May 1, 2014), you should trigger a full Password Sync to re-synchronize all DirSync’ing user passwords via the Set-FullPasswordSync cmdlet. Documentation on how to use this password may be found here.

Password Sync is a feature of the Azure Active Directory Sync tool that synchronizes user passwords from your on-premises Active Directory to Azure Active Directory (“Azure AD”). This feature enables your users to log into their Azure Active Directory services (such as Office 365, InTune, CRM Online, etc.) using the same password as they use to log into your on-premises network. It is important to note that this feature does not provide a Single Sign-On (SSO) solution because there is no token sharing / exchange in the Password Sync based process.

Note

Active Directory Domain Services that are configured for FIPS are not compatible with the Password Sync feature.

Any customer of Azure Active Directory is eligible to run Password Sync. See below for information on the compatibility of Password Sync and other features such as Federated Authentication.

You must be running version 6382.0000 or greater of the Directory Sync tool in order to enable the Password Sync feature (version is available on the .exe installer download). The latest version of the Directory Sync tool can be downloaded from the Admin Portal.

Password Sync is an extension to the directory synchronization feature implemented by the Directory Sync tool. As a consequence of this, this feature requires directory synchronization between your on-premises and your Azure Active Directory to be configured.

The Active Directory Domain Service stores passwords in form of a hash value representation of the actual user password. The Password hash cannot be used to login to your on-premises network. It is also designed so that it cannot be reversed in order to gain access to the user’s plaintext password. To synchronize a password, the Directory Sync tool extracts the user password hash from the on-premises Active Directory. Additional security processing is applied to the password hash before it is synchronized to the Azure Active Directory Authentication service. The actual data flow of the password synchronization process is similar to the synchronization of user data such as DisplayName or Email Addresses.

Passwords are synchronized more frequently than the standard Directory Sync window for other attributes. The Password Sync feature checks every two minutes whether passwords need to be synchronized. Passwords are synchronized on a per-user basis and are generally synchronized in chronological order. When a user’s password is synchronized from the on-premises AD to the cloud, the existing cloud password will be overwritten.

When you first enable the Password Sync feature in your DirSync tool, it will perform an initial synchronization of the passwords of all in-scope users from your on-premises Active Directory to Azure Active Directory. You cannot explicitly define the set of users that will have their passwords synchronized to the cloud. Subsequently, when an on-premises user changes their password, the Password Sync feature will detect and synchronize the changed password, most often in a matter of minutes. The Password Sync feature will automatically retry failed user password syncs. If an error occurs during an attempt to synchronize a password the error is logged in your event viewer.

The synchronization of a password has no impact on currently logged on users. If a user that is logged into a cloud service also changes their on-premise password, the cloud service session will continue uninterrupted. However, as soon as the cloud service attempts requires the user to re-authenticate, the new password needs to be provided. At this point, the user is required to provide the new password – the password that has been recently synchronized from the on-premise Active Directory to the cloud.

When synchronizing passwords using the password sync feature, the plain text version of a user’s password is neither exposed to the password sync tool nor to Azure AD or any of the associated services.

Additionally, there is no requirement on the on-premises Active Directory to store the password in a reversibly encrypted format. A digest of the Windows Active Directory password hash is used for the transmission between the on-premises AD and Azure Active Directory. The digest of the password hash cannot be used to access resources in the customer’s on-premises environment.

When you enable password sync, the password complexity policies configured in the on-premises Active Directory override any complexity policies that may be defined in the cloud for synchronized users. This means any password that is valid in the customer’s on-premises Active Directory environment can be used for accessing 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.

If a user is in the scope of the password sync feature, the cloud account password is set to “Never Expire”. This means that it is possible for a user’s password to expire in the on-premises environment, but they can continue to log into cloud services using this expired password.

The cloud password will be updated the next time the user changes the password in the on-premises environment.

The password sync feature will not synchronize passwords for users with Federated Identities. This has several implications:

If an initially managed user with a password that has been synchronized to the cloud is converted to a federated user and then converted back to a managed user, the password that was initially synchronized is lost.

If an initially federated user that has updated a password on-premises is converted to a managed user, the password will not be synchronized to the cloud. As a consequence of this, the user will not be able to use the password that has been set in the on-premises environment to log into cloud services.

You can determine which users have successfully had their passwords synchronized by reviewing the events that match the following criteria:

Source

Event ID

Directory Synchronization

656

Directory Synchronization

657

The events with the Event ID 656 provide a report of processed password change requests:

The corresponding events with the ID 657 provide the result for these requests:

In the events, the affected objects are identified by their anchor and the DN value. The anchor value corresponds to the ImmutableId value that is returned for a user by the Get-MsoUser cmdlet.

In addition to the object identifiers, Event ID 656 provides the date the user’s password was changed in the on-premises Active Directory::

Event ID 657 has a Result field in addition to the source object identifiers to indicate the status of synchronization for that user object.

A successfully synchronized password is in an event with the Event ID 657 indicated by a value of Success for the Result attribute. When a password synchronization attempt failed, the value of the Result attribute is Failure:

When prompted by the Wizard, de-select the “Enable Password Synchronization” checkbox.

Note

This process will trigger a full synchronization. Full synchronization cycles generally take longer than other sync cycles to complete.

After running the Configuration Wizard, your tenant will no longer be synchronizing passwords. New password changes will not synchronize to the cloud. Users that previously had their passwords synchronized will be able to continue logging in with those passwords until they manually change their passwords in the cloud.