Get started Bring yourself up to speed with our introductory content.

Set up Azure's Password Synchronization write-back feature

Before putting Azure's write-back feature in production, learn the best ways to configure it and how to address any reset problems that arise.

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).

Azure Active Directory link
You can find the link to Azure AD in the portal's admin center.

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).

Restrict Access to Password Reset option
Admins control who has access to Password Reset with this option.

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).

Test the password write-back feature
Assign an AD Premium license to test the feature.

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).

Change your password in Office 365 Settings
Select

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).

Enter password in Azure Active Directory
End users will be directed to a new page in the Azure AD to enter a new password.

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).

Event ID 31007 confirms password reset
This event confirms a successful password reset.

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.

In the Event Logs on the AADSync server, you will see an Event ID 33008, which mentions that a restriction prevents the password from changing to the current one specified (Figure 7).

Event ID 33008 says there's a restriction prevening the password change
This event indicates a restriction in place to prevents the password change.

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.

Next Steps

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.

This was last published in March 2015

Dig Deeper on Microsoft Exchange Server Administration Tools

PRO+

Content

Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close