Nomad_Soul - Fotolia
Active Directory Federation Services can create a more complex environment that could overwhelm some organizations,...
especially those lacking in experience using it. But there are alternatives for those organizations with little experience. One option is Microsoft Azure's Password synchronization with the write-back option enabled.
Once an organization has enabled on-premises Password Synchronization, it's time to focus on the configuration steps in Azure Active Directory. First, enable Azure AD Premium for the tenant. You can do this through the Azure AD Portal for your subscription. You can get to the Azure AD Portal through the Office 365 portal, where you'll find a link to Azure AD in the admin center section of the portal (Figure 1).
You can enable an Azure AD Premium trial from this portal, which lasts for 90 days. This will allow you to test any premium-related features, including the password write-back feature.
The trial will provide you with 100 licenses. If you've previously used the Azure AD trial, you need to purchase at least two Azure AD Premium licenses to test the write-back feature: one for an administrator and one for an end user.
The administrator account should be a cloud-only end user and not a federated account. Having a cloud-only administrator is a good thing to practice because it will allow you to log on even if Active Directory Federation Services is down.
After enabling the trial, go to Configure and navigate to the User Password Reset policy section -- make sure this is enabled. You may need to assign the Azure AD Premium licenses first before this section becomes visible.
Click Yes to enable a password reset. If needed, you can control which end users have access to the Password Reset feature by selecting Yes for Restrict Access to Password Reset (Figure 2).
Although it's not required, it is recommended to select multiple authentication methods. In addition, set the number of methods to two or more.
When Password Reset is enabled for end users, they can proactively change their passwords and reset their passwords, if needed.
Test the password write-back feature
To test the write-back feature, assign an AD Premium license to the end user (Figure 3).
Next, log on to the Office 365 portal with the end user's information and select Change your password from the Office 365 Settings (Figure 4).
Because the Password Reset feature was previously enabled, end users will be directed to a new webpage within the Azure Active Directory. End users can enter a new password there (Figure 5).
As soon as end users hit Enter, the workflow kicks in and attempts to reset the password on-premises. You can follow the events on the server with the Azure AD Synchronization tool installed.
First, an event with ID 31006 indicates that a password reset has been requested. Shortly thereafter, Event ID 31007 confirms the password was successfully reset (Figure 6).
Why would a password reset fail?
When end users try to reset passwords, they might occasionally face an error that says the new password doesn't meet the organization's corporate on-premises password policy, resulting in a failed password synchronization.
Unfortunately, the error description is rather cryptic and doesn't provide much information as to what is blocking the password reset. But the service call to reset the password made it to the AADSync server. Password policies, that define password complexity requirements more strict than the end user's new password, often cause this kind of error.
In this case, there was no specific password policy configured and I was testing with a newly created end user. It occurred to me that the default domain password policy, which is part of the Default Domain Policy Group Policy Object, doesn't allow multiple password changes in 24 hours. After changing the threshold for the minimum password age to 0, meaning that end users can change passwords as often as they want, end users should be able to reset the password, allowing password synchronization to proceed.
This, of course, is not a change you typically make in production. After all, the password policies you have were put there for a reason. Despite this, taking this step might help keep you busy when you're testing the feature before putting it in to production.
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 two in a series about Azure's password write-back option. Click here for part one, which covers how the write-back process works and how to configure write-back on-premises.