Customers that are currently running the Azure Active Directory Sync tool and have configured Federated Authentication with the Windows Azure Active Directory Service (or associated services such as Office 365 or InTune) may decide that Password Sync is sufficient to meet their business requirements.  If this is the case, then they may elect to transition back from a Federated State to a Managed State (with respect to their authentication flows).  Customers may also choose to keep some portion of their users in a federated state, while others will be in a managed (with their passwords synchronizing) state, if the two groups of users are in different root domains.

Please see Implement Password Synchronization for how to deploy the Password Sync feature of the Windows Azure Active Directory Sync tool.
This document only addresses the scenario of migrating users from Federated Authentication to Managed Authentication with Password Sync.

Note
To provide feedback about this article, create a post on the Windows Azure AD TechNet Forum.

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.

Important
Password Synchronization is a one-way push of password hashes from your on-premises Active Directory to Azure Active Directory. You must ensure that your user’s password is sync’d AFTER they are converted from a Federated to Managed Identity (per the procedure below). Step 2 in both Approaches provide guidance on how to do this.

↑ Back to top

Background

At General Availability, the Password Synchronization feature will not synchronize passwords for users in a Federated namespace.
In order to successfully transition a user from Federated Authentication to Managed Authentication (with password sync), administrators will need to perform one of the procedures outlined below.

Mixing Password Sync and Federated Authentication

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.

↑ Back to top

Approaches

Customers that are migrating users from Federated to Managed Authentication may proceed in one of two approaches:

1.  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.
2.  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 after you convert the user from Federated to Managed Authentication. 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

1. 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
   You can trigger a Directory Sync cycle manually by opening the file C:\Program Files\Windows Azure Active Directory\DirSyncConfigShell.psc1. When the powershell console opens, run the Start-OnlineCoexistenceSync cmdlet. This will begin a Directory Sync cycle.

    

2. 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: http://technet.microsoft.com/en-us/library/jj151815.aspx

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.

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 this activity over a weekend 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.
Documentation on this commandlet can be found here: http://technet.microsoft.com/en-us/library/dn194122.aspx

Detailed steps are as follows:

1. Click Windows Azure Active Directory, right-click Windows Azure Active Directory Module for Windows PowerShell, and then click Run as administrator.
2.  Run the following commands in the order in which they are presented. Press Enter after you type each command.
   1. $cred = Get-Credential
      When you are prompted, enter Office 365 administrator credentials that are not SSO-enabled.
   2. Connect-MsolService –credential $cred
   3. Set-MsolADFSContext –Computer <AD FS 2.0 server name>

       

      Note
      In this command, the placeholder <AD FS 2.0 server name> represents the name of the primary AD FS 2.0 server. If the AD FS server is on a remote server you must set the AD FS server context, if the AD FS server is local you can skip this step.

       

   4. Convert-MSOLDomainToStandard –DomainName <federated domain name> -SkipUserConversion $false -PasswordFile c:\userpasswords.txt
      
      

      Note

      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
      The –SkipUserConversion should always be set to $false to ensure users are converted correctly

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 you can manually convert all users in a domain by following the sample script below

Stage 2 - Synchronize user passwords

After Stage 1 is complete (namespace and users have been converted), set up the new DirSync with Password Sync.
This will synchronize all your on-premises users’ current passwords with Office 365 (for managed users).

Alternatively, if you have previously set up DirSync without Password Sync, have your users change their passwords on-premises after they have been converted to Managed Users to synchronize their password to the cloud. 

If the namespace you have converted contains many users, 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: http://social.technet.microsoft.com/wiki/contents/articles/18096.dirsyncwindows-azure-ad-password-sync-frequently-asked-questions.aspx#How_can_I_trigger_a_full_password_sync.

Note

A user must be fully converted to Managed Authentication in order for their password to synchronize successfully. This means, you must ensure that the entire Namespace and all associated users have been completely converted to Managed Authentication before executing the password sync. Otherwise user passwords will not successfully synchronize to the cloud. The conversion process documented in Stage 1 provides details on how this process should be performed.

↑ Back to top

Verifying synchronized passwords

The simplest way to ensure that user passwords have successfully synchronized after being migrated to a Managed Namespace is to have the users try to log into the service.
If users are not able to sign into the cloud service, see Password synchronization troubleshooting guide for Office 365 for details on troubleshooting this issue.

↑ Back to top

Sample script to manually convert all users in a domain

The script below will enable you to convert all users in a domain to standard users.

Note that you must first convert the domain to standard before calling this procedure.
It is also recommend to start a transcript of the session to record the passwords for the users if needed.

↑ Back to top 

See Also

• Azure Active Directory Forum
• Implement Password Synchronization
• Dirsync/WAAD Password Sync Frequently Asked Questions 
• Configure filtering for directory synchronization

↑ Back to top