AN UPDATE! (May 1, 2018)
To change from Single Sign-On (AD FS) to Password Hash Synchronization please use guidance provided here: http://aka.ms/aadauthmigrate
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!
This article has been updated and will address two scenarios:
Please see Implement Password Synchronization for how to deploy the Password Sync feature of the Azure Active Directory Sync tool. This document only addresses the scenario of using Password Sync as a backup for SSO or migrating users from Federated Authentication to Managed Authentication with Password Sync.
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.
↑ Back to top
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!
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
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.
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.
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.
The procedure, at a high level, is as follows:
To trigger a Directory Sync manually, perform the following steps:
The Azure Active Directory Powershell Module and documentation on the commandlet set can be found here.
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.
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.
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:
If you are temporarily 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.
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.
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.
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.
How about the password change option in office365 user settings, will it get disabled automatically once Password sync enable?
Yes the change password option Office365 is disabled when you use either Password Sync or SSO. In the first case, your on premise AD is now the source for the Password. In the second Azure AD doesn't have your password so there is nothing to change. In both cases users need to get their passwords reset in AD. A small deployment of FIM can accomplish that.
In my experience, the force password change option does not automatically get disabled. You'll need to run Get-MsolUser -All |? {$_.UserPrincipalName -like '*@mydomain.com'} | Set-MsolUserPassword -ForceChangePassword $false. Since that creates new passwords for the users in the cloud, you'll also have to force another full password sync on the DirSync server:
1. In the registry, set the value of FullSyncRequired under HKLM\SOFTWARE\Microsoft\MSOLCoExistence\PasswordSync to 1.
2. Restart the Forefront Identity Manager Synchronization Service, which also restarts the Windows Azure Active Directory Sync Service.
3. Monitor the Event Viewer Application log. You should see a bunch of 650, 651, 656, and 657 events. When the sync has completed, you will see a 654 event.
Not sure this does actually work in a DR scenario, or if the single-sign on infrastructure becomes unavailable.
As per technet.microsoft.com/.../dn194122.aspx to run the cmdlet Convert-MSOLDomainToStandard, you actually need to be able to connect to the ADFS server and the Office 365 tenancy
"You will require a connection to both the AD FS server and the Microsoft Online Services domain before the command can be run successfully"
So if that's the case, how do you temporarily, or permanently, convert to a managed domain in the event of your ADFS platform becoming unavailable?
Sounds like this has to be a planned activity and not suitable for actual DR
This looks like a good method for resolving an issue when ADFS is not available. How would a loss of connectivity between the Azure AD and the on-prem services affect elements such as Self Service Password Reset. If the user is resetting their own password and the service cannot contact the on-premise solutions would the user be able to set the password correctly in advance of the system being reset to use ID/Password rather than ADFS?
The parameter -SkipUserConversion value is inconsistent between the "Temporarily Switching from Single Sign-On to Synchronizated Passwords for Sign-In" section and the "Approach 2 - Entire namespace conversion" -> Stage 1 -> important note.
Thank you
I can confirm Varol's comment -- this process DOES NOT WORK when SSO/ADFS is unavailable. Convert-MSOLDomainToStandard requires an active ADFS context in order to run. This runs counter to the promise in the initial paragraphs. Also, even with -SkipUserConversion set to $true there will be a delay during which no users will be able to authenticate -- I've heard reports of 15 minutes with ~300 users to several hours with ~3,000 users.
Members of the MCM community have identified a potential workaround -- using Set-MSOLDomainAuthentication -- and it seems to be instantaneous in converting the SSO-less domain to Managed authentication. At that point, you fix ADFS and use Convert-MSOLDomainToFederated to switch the affect domain back, which also seems to be instantaneous (and less error-prone than using Set-MSOLDomainAuthentication and having to provide all the Federated fiddly bits). Are there any known issues with using this instead?
Hi, First thanks for this great article. We are at the point to switch to DirSync instead of ADFS (too complex for us)
Is it required to create a password file? Because in my opinion the passwords are synced with DirSync? What happens when you execute the Convert-MsolDomainToStandard without the PasswordFile parameter?
Some corrections to the process for using Password Sync as a backup to AD FS:
blogs.perficient.com/.../office-365-using-password-sync-as-a-backup-to-ad-fs