Field Notes: Azure AD – Configuring Self-Service Password Reset in Hybrid Deployments

This is a continuation of a series on Azure AD Connect. The second blog post of the series covered a custom installation. One of the optional features I promised to cover then was password writeback, which I discuss in this blog post as part of enabling the self-service password reset (SSPR) feature in a hybrid environment.

Getting started

One of the first things to do when planning to deploy SSPR is to create awareness and prepare the service end users for what is coming. This can be done in the form of training, e-mail, posters, stickers, etc. Some guidance is available on aka.ms/ssprtemplates, and below is an example of an e-mail template that you can use to get started.

Enabling SSPR in Azure AD

As a preparation step, I created a security group in Azure AD that I’ll be using for piloting SSPR. I then added a test account used for demonstration as a member. I also assigned an Azure AD Premium licence to this user.

Password reset properties

With that in place, I connect to the Azure AD portal and navigate to the password reset menu available under Azure Active Directory. Under properties, I enable SSPR for the pilot group by choosing selected and specifying the group.

Password reset authentication methods

Under authentication methods, I configure the number of methods required to reset a 1. This defines the number of alternate methods of identification a user must have to reset their password. For methods available to users, I select:

Mobile app code
E-mail
Mobile phone

Note that the mobile app notification option becomes unavailable when 1 is selected as the number of methods required for SSPR.

Users can register their mobile app at aka.ms/mfasetup or in the new security info registration experience at aka.ms/setupsecurityinfo

We will be using the Combined security information registration in this demonstration, which I also configured as part of the preparation work. With combined registration, users can register once and get the benefits of both Multi-Factor Authentication (MFA) and SSPR (instead of separately for both MFA and SSPR).

Password reset registration

I turn on the option to require users to register when signing in. Unregistered users will be prompted to register their own authentication information when signing in for the first time. An alternative is to set this to no, where administrators must manually specify the necessary password reset authentication information in the properties for each user, or instruct users to go to the registration portal URL directly.

I leave the number of days before users are asked to re-confirm their authentication information to the default of 180. This setting designates the period of time before registered users are prompted to re-confirm their existing authentication information is still valid, up to a maximum of 730 days. If set to 0 days, registered users will never be prompted to re-confirm their existing authentication information

These settings only apply to end users in your organization. Admins are always enabled for self-service password reset and a required to use two authentication methods to reset their password.

Password reset notifications

For notifications, I select Yes for both:

Notify users on password resets: this determines whether or not users receive an e-mail to their primary and alternate email addresses notifying them when their own password has been reset via the SSPR portal
Notify all admins when other admins reset their password: this determines whether or not all global administrators receive an email to their primary e-mail address when other administrators reset their own passwords via the SSPR portal

Password reset customization

Customize helpdesk link designates whether or not the “Contact your administrator” link that normally allows users to contact a service administrator directly is overridden to point to a custom location. I select yes and provide a support desk e-mail address as the custom helpdesk e-mail address.

Password reset on-premises integration

Here we see that on-premises integration has not been enabled.

Next, we rectify this in Azure AD Connect!

Configuring password writeback in Azure AD Connect

Password writeback is an optional feature available in Azure AD Connect. To get to it, launch Azure AD Connect and select customize synchronization options.

This is followed by connecting to Azure AD by providing a Global Admin account. I skip through the wizard until I get to the optional features page, where I tick the box to enable password writeback.

We get a confirmation once we click next that password writeback will be enabled.

Configuration is now complete and we are now ready to see this feature in action. Before testing, however I would like to revisit the Azure AD tenant to see if there are changes.

Configuring on-premises integration in Azure AD

Looking back into Azure AD, we see that on-premises writeback client is up and running. I leave the write back passwords to your on-premises directory set to yes.

If you deployed password writeback when installing Azure AD Sync, you can control whether or not this feature is enabled here. If set to “no”, federated or password synchronized users will not be able to reset or change their passwords, even if password writeback has been configured. You can change this setting at any time.

I have also selected to allow users to unlock accounts without resetting their password.

This designates whether or not users who visit the password reset portal should be given the option to unlock their on-premises Active Directory accounts without resetting their password. By default, Azure AD will always unlock accounts when performing a password reset, this setting allows you to separate those two operations. If set to “yes”, then users will be given the option to reset their password and unlock the account, or to unlock without resetting the password. If set to “no”, then users will only be able to perform a combined password reset and account unlock operation.

End user experience

Based on what we have configured, let’s see how the end user is affected whey they login. I’ll open a private browsing window and logon to Office 365 using the test account. I provide a user name, followed by a password to login. More information is requested because the option to require users to register when signing in for the first time is turned on in Azure AD.

Registration process

Clicking next takes us through the new registration experience, and the use is guided through setting up the require information.

Changing the password

Now I’ll change the user’s password by choosing the forgot my password option during logon. This option takes me to the get back into your account page, where I provide a user ID (pre-populated) and a CAPTCHA to prove that I’m not a robot. Next I select I forgot my password. The second option (I know my password, but still can’t sign in) implies “unlock my account“.

… we’ll help you to reset your password using the security info you registered with us.

This is followed by verification using one of the verification methods in our case, then choosing a new password.

Next, we are notified that the password has been reset and there is a link provided to log in.

There is an e-mail sent to the user since we have the Notify users on password resets option turn on in the portal.

Summary

I have just gone through the process of enabling SSPR in an environment where objects are synchronized to Azure AD using Azure AD Connect. Most of the settings are configured in the password protection blade in Azure AD. The password writeback option also needs to be enabled through Azure AD Connect, and this feature requires a premium Azure AD license. I also took a brief look at combined registration, which is a recommended method for user registration.

References

Till next time…

Beystor Makoala