Most companies will deploy Active Directory Federation Services (AD FS) to enable single sign-on scenarios for...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Office 365 or other cloud-based applications. While AD FS is an excellent choice, it also makes the environment more complex, especially for organizations that don't have much experience with it. Admins should explore alternatives, such as Password Synchronization with the write-back option enabled.
One-way password synchronization can be problematic. If end users change their passwords in the cloud, those passwords won't change on-premises. This can cause some confusion as the Password Sync process won't overwrite the password change on the next synchronization -- it will only do so if it detects a password change on-premises. So, even though password synchronization is used, end users could end up with one password on-premises and one in the cloud.
The password write-back option enables the write-back of the password change into the Active Directory. While it might sound scary, it's not.
How the write-back process works
The password reset and write-back process goes through a series of steps before it's actually changed on-premises. The Password Reset cloud service initiates password resets in Office 365. When end users access the service to reset their passwords, the service first validates whether the write-back service is enabled as part of the Azure AD Sync (AADSync) tool. If it is, the password reset can continue. If not, the process will prevent the password change.
If the end user continues, the chosen password is encrypted and sent over to the Service Bus Relay of the Azure subscription. A unique password protects this component, which generates when you set up the write-back option. The password is only known to your on-premises organization and is safely stored in an encrypted state.
The system then looks up the end user's corresponding account in the AD Connector space, which is set up during the Directory Synchronization process. Once the correct account is located, an attempt is made to reset the password in the appropriate on-premises AD forest. If the password reset is successful, the information returns to the user. If the password couldn't be reset -- because the password didn't meet the on-premises password complexity rules, for example -- then end users will also be notified so they can try again after resolving the issue.
The process outlined in this tip is simplified and depicts the high-level process behind the feature. For a more technical and step-by-step approach, have a look at this TechNet article.
The password write-back feature works with the Directory Synchronization tool that's installed. Always use the latest version of Azure AD Sync
Configure password write-back on-premises
For the following steps, we assume you've already installed the latest AADSync tool. When you go through the steps to set up Directory Synchronization, be sure to select Password write-back (Figure 1). Ensure the server on which you installed AADSync can communicate (outbound) with https://ssprsbprodncu-sb.accesscontrol.windows.net (TCP 443).
To verify whether Password Reset has been enabled correctly, run the following cmdlet from the server on which AADSync is installed. Make sure you change the syntax if you run Windows Server 2008 R2; our example will only work on server versions with at least PowerShell version 4.
PS C:\> Import-Module ADSync
PS C:\> Get-ADSyncAADPasswordResetConfiguration -Connector (Get-ADSyncConnector | ? Subtype -eq "Windows Azure Active Directory (Microsoft)").name
Connector Enabled ModifiedTimestamp
--------- ------- -----------------
exchangelabonline.onmicrosoft.com - AAD True 30/01/2015 10:05:48
Additionally, you can search the Application Event Log for the following event (Figure 2).
For the write-back feature to work properly, the account you configured as part of the Directory Synchronization setup process must be granted the Reset Password and Change Password extended rights for all the end users you want the write-back process to work for. Ideally, you should enable permissions at the root level and ensure they are propagated to all child objects. To do this, open Active Directory Users & Computers and right-click the root (domain) object. Click properties and navigate to the security tab. From there, click Advanced and then click Add. This will display the window shown in Figure 3. Be sure to select the appropriate options.
After clicking OK, you'll see a warning to let you know you'll make a number of changes to objects in the domain. Accept these changes.
One warning: Some organizations might block inheritance at an underlying organizational unit (OU) level. If that happens, you'll have to repeat this process at the OU level and everywhere else where inheritance is blocked or enable inheritance before applying these changes. The problem with the latter process is that you can't always make these changes because it might break something else. After performing these steps, you're ready to enable the write-back feature from the Azure AD Management portal.
About the author:
Michael Van Horenbeeck is a Microsoft Certified Solutions Master and Exchange Server MVP from Belgium and works for ENow, a company that provides systems management software for Microsoft technologies. He specializes in Exchange, Office 365, Active Directory and a bit of Lync. He is an active contributor in the Exchange community by writing articles for several tech websites and his own blog and by participating in the UC Architects podcast. He frequently speaks at international conferences, including TechEd, IT/DEV Connections and the Microsoft Exchange Conference.
This is part one in a series about the password write-back feature. Stay tuned for part two, which walks through how to do enable the write-back feature from the Azure AD Management Portal and execute tests to verify that everything works as expected.