Deep Dive: Password Reset with On-Premise Sync in Azure AD Premium

Deep Dive: Password Reset with On-Premise Sync in Azure AD Premium

  • Comments 15
  • Likes

Howdy folks,

Administrators have been able to reset their forgotten passwords in Azure AD for a long time now and we've heard lots of requests from customers who also want to enable their end users to reset their own passwords.

Well, we've heard your feedback, and have been working to let you enable end user self-service password reset in just a few clicks. To help you begin using password reset, let me introduce Adam Steenwyk, a senior program manager on the Active Directory team. He's written a detailed guide to the feature and how you can get started with it.

To try it out, sign in to the Windows Azure Management Portal, click on Active Directory in the left navigation bar, then head to the directory configuration tab and look for the 'user password reset policy' section.

Best Regards,

Alex Simons (twitter: @Alex_A_Simons)

Director of Program Management

Active Directory Team

-----------------------------------------------------------------------------------------------------

Hi everyone,

I'm Adam Steenwyk, Senior PM on the AD team, and I'm here today to introduce to you our cool new user self-service password reset functionality.

Self-Service Password Reset for Users is part of the latest set of changes included in Windows Azure Active Directory Premium. With this feature, users can reset their passwords using their mobile or office phones, or their alternate email addresses. Users can even self-register their own password reset data with a few mouse clicks! In addition to this, as the administrator you have total control over the policies applied to these users when they reset their passwords. You don't want users to reset using their mobile phone number? No problem! You want to specify how many verification steps users must go through? You bet you can!

There are three questions that you'll be able to answer after reading through this post:

  • How can I configure password reset from the Azure management portal?
  • How can my users register for password reset?
  • How can my users reset their passwords after they are registered?
  • How can I configure password reset to write passwords back to a local Active Directory?

Let's get started!

How to configure password reset in the Azure management portal

In order to enable Self-Service Password Reset, you'll need to be using Windows Azure Active Directory Premium. You can learn how to do that by following the instructions here. Once you've done that, sign in to the Windows Azure Management Portal, navigate to your directory, click on the CONFIGURE tab, and scroll down until you see the "user password reset policy" section (see Fig. 1). This is where all the magic happens.

 

Fig. 1: The directory configuration tab

 

Fig. 2: The user password reset policy configuration section

 

Once in configure tab, the above is what you'll see in the "user password reset policy" section (see Fig 2.). There are a lot of neat knobs you can tweak to change the behavior of password reset in your organization. They are split into a few logical categories:

  • Security Policy
  • Registration Policy
  • Portal Customization

Let's take a moment to go through them one by one.

 

Fig. 3: Password reset security policy

 

How to manage password reset security policy

Controls in this section (outlined in Fig 3. above) affect how password reset works in your organization. Read on below to see a description of what each of these controls does.

  • Is password reset enabled for my directory? Once you're using Windows Azure Active Directory Premium, you'll see a new configuration setting which allows you to turn password reset on or off for all your users. In order to see the rest of the policy controls, you'll have to turn this on first. Also, stay tuned, we're looking at ways that will let you enable this feature on a per-user or per-group basis.
  • What types of contact methods can users use to reset their passwords? Once you've turned this feature on, you'll be able to choose which contact methods a user is able to use to reset his or her password. For those of you with international phone numbers, you'll be happy to know that we support both voice and SMS calls for the mobile phone-based contact method. All of our SMS and voice messages are also fully localized for your users coming from different locales. Don't see a contact method you are interested in? Let us know!
  • How many contact methods must a user provide when resetting their passwords? For those of you with high security requirements, or those who just want a bit more assurance that passwords are being reset securely, we allow you to require that your users go through either one or two of your selected contact methods above.

 

 

Fig. 4: Password reset registration policy

 

How to manage your password reset registration policy

Controls in this section (outlined in Fig 4. above) affect how and when users register for password reset. Read on below to see a description of what each of these controls does.

  • Where do my users go to register their data? Don't have contact data defined for all of your users? No problem! We provide an end-user accessible portal where users can provide their contact data in a simple and secure way. As we make our service richer over time, we'll make sure to all of the newest challenges we build so your users stay up-to-date.
  • Are users required to register for password reset when signing into the access panel? Want to register users in your organization for password reset quickly and easily? You can configure password reset to gather contact data from your users when they go to http://myapps.microsoft.com. Also, stay tuned, we'll be looking into allowing you to enforce this when users sign in, too.
  • How long before users must re-confirm their contact data? Want to keep your user's contact data up-to-date over time? You can do that, as well. With this feature, you can optionally configure the time that must elapse before a user is prompted to verify their contact data again after their initial registration. If you set this time to 0 days, we will never prompt users to re-verify their data.

 

Fig. 5: Password reset portal customization (tenant branding not shown)

 

How to manage password reset portal behavior and appearance

Controls in this section (outlined in Fig 5. above) customize the appearance and behavior of the password reset portal. Read on below to see a description of what each of these controls does.

  • When a user has a problem, what helpdesk link do they see? We provide a capability which will automatically dispatch an email to the user, password, or global administrators of a tenant if a user sees an error while resetting his or her password. Don't like it? No problem, you can override the link users see when resetting their passwords to point to a custom email address or website URL where you can describe to them how they can access your organization's helpdesk.
  • When branding do users see when they come to the password reset portal? Using the tenant branding and customization feature that we've talked about before, you can set an organizational logo to show up on your organization's sign in page and access panel. We'll show this same logo when users come to the password reset portal. Furthermore, we'll also use your directory name in all email communications we send to your users. Finally, if you have another branding requirement, we'd love to hear about it!

Want to learn more about how password reset for users works under the covers? Check out TechNet for more detailed documentation.

 

How end users can register for password reset

Once you configure the service to your liking, you can provide contact data for your directory users by using DirSync, PowerShell, or the Azure or Office Admin Portals. If you choose to provide the data yourself, make sure you include a country code and a + in the phone number, like this "+1 4251234567", so that we know how to reach you. The detailed documentation will give you more information about how you should format your phone numbers so that they work with our system.

In the case that you want your users to do this on their own, below is what they'll see when they come to the password reset registration portal. If you want to try it out yourself, you can access the registration portal by going to this link: http://aka.ms/SSPRSetup and logging in as a test user. Just make sure that you have SSPR enabled for that tenant, first.

Fig. 6: The password reset registration portal

 

Fig. 7: Verifying a phone number in the password reset registration portal

 

Users can register both their mobile phones and personal email addresses on this web page (see Fig. 6 and Fig. 7 above). They can then use this data to reset their passwords at a later time.

 

Fig. 8: Updating an existing phone number or email on the registration portal

 

Once they're configured, users can come back to this page later to update their contact info without having to bother you, the admin (see Fig. 8 above).

 

Fig. 9: Accessing the registration portal from the application access panel

 

Users can also access the registration page at a later time by clicking a tile on their profile page in the application access panel (see Fig. 9 above).

 

How end users can reset a password

When it comes time to reset a forgotten password users can access the password reset portal by clicking the "can't access your account?" link at the bottom of any Organizational ID sign in page, or going directly to https://passwordreset.microsoftonline.com.

 

Fig. 10: Accessing the password reset portal from the sign in screen

 

Fig. 11: Starting the password reset process for a user

 

Once a user clicks on the link in Fig. 10 above, he or she will then be asked to enter a UserID and pass a captcha (see Fig. 11 above). Don't worry, we check to make sure all of their data is valid and that they meet your password reset security policies before sending them through the password reset process so that calls to your helpdesk are minimized.

 

Fig. 12: Performing the first verification step to reset a password

 

Fig. 12 illustrates what a user might see if they have self-registered a mobile phone number and an alternate email address, and have an office phone defined by their administrator. Notice that any customized branding you may have defined shows up on this page, too.

 

Fig. 13: Performing the second verification step to reset a password

 

As users proceed through the verification steps, the contact methods they've already used are removed, and they are left with only those options that are within policy and properly configured. In Fig. 13 above, you can see that because the user already used a mobile phone as his or her first contact method in Fig. 12, he or she doesn't have that as a verification option any longer.

 

Fig. 14: Contacting an administrator as part of the password reset experience

 

And, if any problem occurs, users can get in contact with your organization's helpdesk with a single click! As described in the "how to manage password reset portal behavior and appearance" section earlier, try overriding the link below to a custom URL or email address to give your users the best possible password reset experience.

How you can enable passwords to be written back to a local Active Directory

Another cool feature we've recently added allows you to write passwords that have been reset in the cloud back to an on premises AD deployment. This means that if you are using federation or password hash sync, whenever your users come to reset their passwords in the cloud, those passwords will be written back to your local AD environment, too. What's even cooler is that this feature ships right along with DirSync, so if you are using DirSync, all you have to do is upgrade to the latest version and turn on the feature to get started!

Here's are some of the highlights of this new feature:

  • Supports resetting passwords for users using ADFS or other federation technologies. With writeback, as long as users are DirSync'd into your cloud tenant, they'll be able to manage their local AD passwords from the cloud.
  • Supports resetting passwords for users using password hash sync. When the password reset service detects a user is enabled for password hash sync, we reset both her on-prem and cloud password simultaneously.
  • Enforces your local AD and cloud AD password policies. When a user resets her password, we first ensure that it meets your local and cloud AD password policies before committing it to any directory.
  • Doesn't require any new firewall rules. Password writeback uses an Azure Service Bus relay as an underlying communication channel, meaning that you do not have to open any new ports on your firewall for this feature to work.

Password writeback is currently in public preview as part of the latest release of DirSync. Click here to learn more about how to download, install, and use it today!

Next Steps

Of course, this is just the beginning! We constantly strive to improve these services to make them better for you and your users. Here are some of the things we're working on for upcoming releases:

  • Enabling write back of passwords when they are changed (not just reset).
  • Enabling more contact / verification methods. Do you have one you'd like? Let us know!
  • Allowing an administrator to choose whether or not users are required to register for password reset when they sign-in from anywhere, not just the access panel.

To wrap things up, thanks for taking the time to read about password reset, and remember: we're always interesting in hearing what you think! If you have any feedback for us – whether it be new feature requests, confusing aspects of the current experience, or something you really like – please do not hesitate to drop us a line on the Azure Active Directory forum on TechNet.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Hello Alex/Adam, thanks for the post. Just so I am clear. Write back to on prem is enabled for password resets but not for changes. So, if a user's password expires as per the organisational password expiration policy how will this play out?

  • I am loving this feature but I need a couple more features before I can do away with my onprem solution. I need the ability to at least unlock the onprem account when the password is reset, as well as the ability to click a Forgot Password link on the Windows login that launches the reset process for the user. Otherwise I'm looking forward to the future of this offering.

  • Hey folks,

    @SSPR - Great question! For the public preview release of this feature, we only support writeback of passwords when they are reset. Our goal is to provide writeback of passwords for all scenarios, including change, when this feature GAs. For now, if a user changes his or her password in the cloud, they'll also need to change it on prem. As a workaround in the short term, even if a user's password is expired, he or she can still perform a password reset and have that new password flow back to on prem with the current solution.

    @Adam - This is great feedback, thank you. Could you help me to understand your unlock scenario? Would it be sufficient in your mind if we were able to unlock an on-prem account from the cloud using the same reset password experience we have today? If this is what you're after, how would you foresee getting users to use this experience when their accounts are locked: would you simply direct those users to the password reset page?

    Let me know if you have further questions or comments, happy to help!

  • Great feature - looking forward to the GA release. One quick question the password reset site mentioned above: http://passwordreset.microsoftonline.com/ just goes to a blank white page, i.e no timeout, or 404 errors or the like. I Know you can follow the "Cant access your account" links on the login pages, but it would also be good to direct users to a distinct page to do this as well. Is this page going to be working soon?

  • Thanks, Tom!

    Good catch on the http:// vs https:// distinction. To be clear https://passwordreset.microsoftonline.com will always work, but http://passwordreset.microsoftonline.com will sometimes not, based on the browser. Certain browsers work around this (like chrome), which will do automatic http:// -> https:// redirects, but others do not (like IE) which do not perform this operation. In any case, we will investigate this issue and provide a fix based off what we find during our investigation. Thanks for reporting!

  • We found DirSync, including latest 1.0.6862.0, password sync is using System.Security.Cryptography.MD5CryptoServiceProvider, which breaks the application in FIPS compliant mode (part of the Windows Server 2012 Security Baseline). Are there any plans to implement stronger hashing?

    Details:
    Microsoft.Online.PasswordSynchronization.SynchronizationManagerException: Recovery task failed. ---> System.InvalidOperationException: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.
    at System.Security.Cryptography.MD5CryptoServiceProvider..ctor()
    at Microsoft.Online.PasswordSynchronization.PasswordUtility.ComputeMd5(Byte[] sessionKey, Byte[] salt)
    at Microsoft.Online.PasswordSynchronization.PasswordUtility.Decrypt(Byte[] rid, Byte[] sessionKey, Byte[] salt, Byte[] encryptedData)
    at Microsoft.Online.PasswordSynchronization.ClearPasswordHashGenerator.CreatePasswordHash(ChangeObject changeObject)
    at Microsoft.Online.PasswordSynchronization.PasswordHashGenerator.CreatePasswordHash(ChangeObject changeObject)
    at Microsoft.Online.PasswordSynchronization.PasswordSynchronizationTask.CreatePasswordData(ChangeObject changeObject)
    at Microsoft.Online.PasswordSynchronization.PasswordSynchronizationTask.BuildPasswordBatch(IList`1 passwordChanges, IEnumerable`1 changeObjects)
    at Microsoft.Online.PasswordSynchronization.RecoveryTask.SynchronizeCredentialsToCloud()

  • Hi, When using SSO and implementing SSPR, are there any AD FS requirements? To confirm, if running AD FS version 2.0 we can still use the SSPR portal as long as we're running DirSync 6862? There is no dependency on AD FS?

  • Ok, I guess I'm still a little confused...

    "For now, if a user changes his or her password in the cloud, they'll also need to change it on prem. As a workaround in the short term, even if a user's password is expired, he or she can still perform a password reset and have that new password flow back to on prem with the current solution." ...

    Sounds like you are saying no you cannot, then saying yes you can in the next sentence.

    So if I have only Dirsync running, if I allow users to change their password at Azure, will this automatically change their password in my internal AD?

  • I appreciate this post a lot because it teaches us a lot of things we do not know. I hope that you will continue to posts more blogs like this one! http://www.globalchange.org/

  • Hello !! I'm working on Azure AD, and i wanna know how to have the icon : "additional security ..." of Fig. 9 .
    I also wanna know about the workflow : is it possible to have a FIM in the cloud or some other method for doing more workflow with azure . Thank you