Welcome (back) to Part 3 in my series about the modern Microsoft productivity platform.
As you all know, password resets are a pretty costly and time-consuming endeavor for your users and your helpdesk folks, especially early on Monday mornings (or Tuesday, if Monday happened to be a holiday).
In today’s post, I’ll cover a really great feature of your Azure AD Premium services – self-service password reset (SSPR) with password writeback to AD.
There is excellent official documentation available on-line; how it works, how to set it up, FAQs, troubleshooting, etc. In fact, I’ll go on record here as saying the SSPR docs are some of the best docs we have. However, herein, I will post-up some obscure details, some of my own wonders/Q&As, FAQs I’ve heard from customers and other pieces of info I’ve collected over my time with SSPR (one of my favorite aspects of AAD).
My focus here is “enterprise” SSPR in a hybrid ID model (on-premises AD synchronized to Azure AD via Azure AD Connect). SSPR is available for cloud-only users but I’m not covering that here, specifically.
Just like the other “pay-per-user” Microsoft cloud services, a license is needed for any user who is ‘in scope’ for the feature. Azure AD Premium P1 (AADP P1) is what your users need for SSPR + write-back. AADP P1 is available as a stand-alone service, or as part of the Enterprise Mobility + Security suite (EMS) as well as the M365 roll-up of products/services.
SSPR works for all AAD authentication mechanisms:
End user self-service password management
While we conveniently refer to this as ‘SSPR’ - where 'R' stands for 'Reset' - it includes more than just ‘reset.’
From the SSPR portal page/blade, you can access a pre-filtered 'set' of activity logs for just the SSPR service (adjust the columns if you want to see more/less/other specifics)
Self-service password management functionality is accessible from a browser, as well as the sign in screen from Win 7, 8.1 and 10.
From any of the main Microsoft service entry points/portals, such as MyApps or the O365 sign-in page, without entering your ID, you can click the link at the bottom (“Can’t access your account?”), select ‘work or school’ as the account type and get to the generic SSPR portal. There, you can put in your user ID to initiate the password reset flow.
NOTE – This unlock doesn’t apply to ‘smart lockout’ in AAD
IMPORTANT - For all OSes, if the device is Hybrid AAD Joined (AD-domain joined + AAD-registered), the device needs to have line of sight to a DC or the password change process might fail. The local cache of the old password usually won’t get updated properly on an 'offline' PC and all sorts of chaos/end-user confusion ensues. Make sure this is part of your process planning/testing and end-user communications.
There are several separate configuration aspects required for SSPR (see the deployment plan for complete information):
3. Azure AD - Premium P1 Licenses
IMPORTANT - SSPR is one of the few aspects of AAD Premium that actively checks users for a license and will pop an error during the SSPR process for unlicensed users
4. Azure AD - “Password reset” settings
SSPR can be scoped to no one, a selected group or all users
Users need some verified/verifiable pieces of information (sometimes referred to as ‘gates’) – a registered mobile app, an alternate email address, a mobile or office phone, or security questions.
NOTE – Some of these authentication methods apply to SSPR and/or MFA (such as mobile app or phone call) but others only apply to SSPR (such as Security Questions or email)
NOTE - You can sync certain phone number attributes from on-prem AD to AAD.
NOTE – Some people/laws object to having “personal information” visible in a “work directory” (AD or AAD). In this case, the ‘Authentication phone’ attribute can be pre-populated by admins via the AAD portal or via PowerShell – and this entry is not viewable in the directory, except by admins and the specific end-user.
IMPORTANT - The numeric format for phone numbers (important)
NOTE – Some users may not have an email account or mobile phone; in that case, consider using ‘Security Questions’ as an additional method.
NOTE – Once a phone number is verified during SSPR registration, it will be written into the ‘Authentication method’ area of AAD:
Yes (aka “automatic registration”) - the next time any targeted user signs in to a cloud service (not their PC - but the MyApps portal, for example – below), they’ll be interrupted and redirected to the registration process to configure their password reset settings
IMPORTANT - I mentioned above where there is no impact to setting the “Properties” section value to ‘All’ users for scoping. However, this "Registration" point/option is where end-user impact may be introduced
If you set the ‘Registration’ section below to ‘Yes,’ then any user in-scope in the ‘Properties’ section (above) will get interrupted to register for SSPR:
No (aka “manual registration”) – communicate the registration portal URL to users somehow (email, intranet site, etc.) and each user can choose when/if they register.
Choose if users and/or admins should be emailed if their passwords are reset via the service.
Here is a sample notification email message (the custom branding here should look familiar to you if you read my last post :smiling_face_with_smiling_eyes: )
Set a custom support email address or URL, if desired:
IMPORTANT - This affects users only after a failed password reset attempt – it is NOT displayed in the initial SSPR portal pages anywhere
Choose to allow password write-back and/or allow unlock without resetting password.
The green check icon is displayed as a ‘real-time’ check against the on-prem aspects of SSPR/password-writeback:
“What’s the URL to the SSPR portal?
The generic SSPR portal URL is https://passwordreset.microsoftonline.com
TIP - You can also use our short URL – https://aka.ms/sspr
TIP - Your custom-branded experience can be reached directly by appending that URL with /?whr=yourDomain.com: https://passwordreset.microsoftonline.com/?whr=contosowindpower.com
This and the other SSPR-related links can be creatively used. You can add the links to emails, intranet sites and other communications.
Going a little further, you could easily create a simple intranet site (or, host it in Azure - Azure Web Sites) with clickable buttons/links to password reset, SSPR registration, password change, etc. You could create a simple internal DNS alias for the site, like ‘SSPR’ or ‘SSPM’
“What’s the typical deployment model at a high-level?”
The next FAQ below has some materials you can customize and then distribute as part of your pre-rollout. Also, the SSPR deployment plan (2nd link at the top of this post) is VERY thorough and includes the aspect of "end user rollout."
“Do you have any pre-canned end-user communication materials, signs, emails, etc?”
“How does this really work, under the covers?”
NOTE – While we refer to this as ‘password writeback’ it really isn’t setting the password in AAD and then writing it back to on-prem AD from AAD. Functionally, it’s resetting the password against the on-prem AD and in AAD at the same time.
“I want to use Security Questions as a gate but I’m wondering if admins can see the answers to users’ questions? Or, for that matter, can a user review his/her answers?”
No one (not even the user) can see the answers to security questions. The answers are one-way hashed/encrypted in a non-reversible method as they’re setup - and stored as attributes on the user’s object in AAD, similar to the way password storage works.
“Which Password Policy settings apply?”
For Hybrid AD, we give precedence to the on-prem AD password policies (default domain as well as any in-scope Fine Grained Password Policies – FGPP, as well as any banned passwords if you’re using that feature).
If the new password meets/exceeds the on-prem but not the cloud policy (unlikely), the password is set in on-prem AD but it’s not written to AAD right then. During the next password sync cycle, the cloud password value will be sync’d/updated. This might introduce a 1-2 min delay in getting the new password up to the cloud.
“Whoa … what are banned passwords” you ask?
“How does password hash sync and/or SSPR react if the on-prem AD user account is set to “User must change password at next logon?”
Passwords in this state are known as “temporary passwords” - and AAD Connect does NOT sync “temporary passwords.“
Due to this, accounts in this state won’t operate as expected. Users who try to sign in via the Internet/AAD (i.e. away from the LAN and a Domain Controller) will get ‘password or login ID is wrong’ errors when they try to sign in.
If your helpdesk process uses this checkbox currently, you should evaluate a change to the workflow:
“This sounds great, but we’re federated; don’t I need to sync my AD passwords into AAD to use SSPR?”
Nope – although it might seem like the two processes are intertwined, they’re not. Syncing password hash values from on-prem AD into AAD is a totally separate and distinct activity from password reset – you do NOT need to sync passwords into AAD to use SSPR and write them back to AD. Hopefully, that just made someone’s day. :smiling_face_with_smiling_eyes:
“What are some of the common issues?”
There are a few possible points to mis-configure SSPR but the biggest issue I encounter is missing one (or all) of the AD attribute permissions. Here are a few others that are also common:
“Does it work for AD admin accounts (members of on-prem DA)?”
Functionally, it is possible to reset an ‘elevated’ on-prem AD ID as long as the ID is sync’d to AAD – BUT - some sensitive objects are tagged in AD with the ‘IsCriticalSystemObject’ attribute set to TRUE. Those AD objects won’t be sync’d to AAD (i.e. built-in Administrator account).
Now, given that you CAN do it, doesn’t mean you SHOULD. I would usually recommend against sync of on-prem admin accounts to AAD.
“Can I use PowerShell or manually populate ‘authentication information’ (phone number, alternate email address) for my users?”
“What about ‘password expiration,’ ‘locked accounts’ and ‘disabled accounts’ in AD – how does password hash sync and/or SSPR interop w/ those conditions/situations?”
“I fear I might have a malicious user/session(s); how can I address that?”
Ok, ok, I’ll admit it … that was longer and more detailed than I'd planned :smiling_face_with_smiling_eyes:
Hopefully, you found some helpful nuggets in there and now, you’re eager to get this going in your environment to make your users and helpdesk happier on Monday mornings (or anytime)!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.