Welcome (back) to Part 3 in my series about the modern Microsoft productivity platform.
- The previous two posts are here:
- Initial hybrid ID synch setup/configuration – https://techcommunity.microsoft.com/t5/Core-Infrastructure-and-Security/The-Adventure-Begins-Plan-an...
- Custom branding – https://techcommunity.microsoft.com/t5/Core-Infrastructure-and-Security/The-Adventure-Continues-Cust...
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).
- Here is our SSPR Deployment plan (very thorough/detailed) - https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-deployment
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.
Licensing
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.
Authentication Methods
SSPR works for all AAD authentication mechanisms:
- Cloud-only authentication (as I mentioned above, SSPR is supported for cloud-only users but it’s out of scope for this post)
- Password hash sync (PHS)
- Pass-through authentication (PTA)
- Federation/ADFS
- I’m seeing less and less ADFS ‘in the wild’ so I won’t go into the ADFS side but suffice it to say, you can absolutely use SSPR for federated environments including modifying the ADFS sign-in page with links to the SSPR entry point and writing back password changes to on-prem AD, even WITHOUT sync’ing password hashes from AD to AAD.
Capabilities
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.’
- Change - ‘I know what my password is, and I want to change it’
- This is integrated into the My Apps portal/My Profile, as well as the O365 User Portal and the write-back function is tied in, too.
- Reset - ‘I don’t know what my password is’
- This also unlocks the account, if it’s locked out in AD
- Unlock - ‘I know my password; I only need to unlock my account’
Unified registration
- Get users signed up for both SSPR and MFA with one flow/experience. This is out of scope for my post but registration is a key aspect of SSPR design, rollout and support (and is covered in the deployment guide above)
Reporting
- SSPR activities are exposed in the ‘all up’ Azure AD audit logs but here’s a tip (which applies to many other spots in the AAD and Intune portal ‘blades’):
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)
- Optionally, you can download a JSON or CSV file that you can filter in Excel to you little heart’s content. Note, the record limit of 250k – this is now much bigger than the previous limit of 5k.
- PowerBI has a ‘report pack’ for Azure AD Activity Logs that includes SSPR (and a lot of other goods):
- ...and this one is HOT OFF THE PRESSES – the Azure AD ‘Usage and Insights’ reporting for Authentication Methods activity can show you who is/is not SSPR and/or MFA registered/enabled
End-user experience
Self-service password management functionality is accessible from a browser, as well as the sign in screen from Win 7, 8.1 and 10.
- Browser:
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.
- Once the ID is in the ID field, the UPN suffix will be used to check for any custom branding in the tenant and it will display, if applied:
- After this, you’ll be taken to the SSPR portal to either reset the password or unlock the account (‘unlock’ will be automatically attempted during a password reset unless you have a really old version of AAD Connect – of course, you stay current on AAD Connect, don't you? ;) )
- “I forgot my password” process
- Complete the security verification(s) and set a new password
- NOTE: Later in the post, I’ll cover some FAQs about “password policies”
- “I know my password, but still can’t sign in” process
- Complete the security verification(s) and then the on-prem ID will be unlocked without a password reset.
NOTE – This unlock doesn’t apply to ‘smart lockout’ in AAD
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-smart-lockout
- “I know my password and want to change it” process
- This is initiated from the O365 or My Apps portal
- Sign in Screen Password Reset:
- https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-windows
- Win10:
- NOTE – There isn’t an ‘unlock’ option on the sign-in screen (yet?)
- NOTE – On Win10, you won’t see this from an RDP/enhanced-session, but you’ll see it on a physical PC or if you use VM Connect/console via Hyper-V
- This initiates a captive portal for Win10 password reset:
- Win7:
- NOTE – There isn’t an ‘unlock’ option on the sign-in screen (yet?)
- NOTE – On Win7, you will see this from an RDP/enhanced session or if you use VM Connect via Hyper-V
- This initiates a captive portal for Win7/8.1 password reset:
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.
Setup
There are several separate configuration aspects required for SSPR (see the deployment plan for complete information):
- On-prem AD permissions
- The on-prem AD user attributes/permissions need to be modified so the Azure AD Connect AD service account has rights to unlock/change/reset passwords on behalf of the sync’d users.
- https://docs.microsoft.com/en-us/azure/active-directory/active-directory-passwords-how-it-works#acti...
- Reset Password
- Change Password
- lockoutTime <read/write>
- pwdLastSet <read/write>
- The permissions can be scoped broadly - to the top-level of a domain (this is how the ‘Express’ install for AAD Connect sets things up) - or – they can be scoped to only targeted/sync’d OUs where users reside.
- If you aren’t sync’ing a certain OU to AAD, you don’t need the permissions there (i.e. a service account OU containing IDs that don’t sync to AAD)
- The permissions need to apply to ‘all descendent user objects’ in any targeted OUs
- These permissions are commonly delegated this way for password reset tools or helpdesk teams
- https://docs.microsoft.com/en-us/azure/active-directory/active-directory-passwords-how-it-works#acti...
- On-prem Azure AD Connect Configuration
- The “Password writeback” option needs to be set in AAD Connect:
3. Azure AD - Premium P1 Licenses
- Any/all users of SSPR need to have an AAD Premium P1 license assigned
- This is super-easy to do by assigning licenses via a group
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
- Azure AD tenant/portal settings review:
- PROPERTIES (SCOPE)
SSPR can be scoped to no one, a selected group or all users
- IMPORTANT: Setting this to “All” shouldn’t have any impact on users; there aren’t any prompts or interrupts in doing this. It’s just establishing a scope of potential users for the service.
- AUTHENTICATION METHODS
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.
- https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-authenticationdata
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)
- +1 2223334444 (there is a space after the “+1”)
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:
- REQUIRE Registration
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:
- Before you set the value below to ‘Yes’ you should be well into your communications/roll-out notification effort for your end-users.
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.
- NOTIFICATIONS
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: )
- CUSTOMIZATION
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
- For example, in my lab enviro, if I fail to complete the MFA, my password reset flow is interrupted and I’ll see a “Contact your administrator” link. In my lab setup, clicking the link initiates a blank email to the above “Custom helpdesk email” address
- ON-PREMISES INTEGRATION
Choose to allow password write-back and/or allow unlock without resetting password.
- A password reset will also attempt an unlock on the account in AD
The green check icon is displayed as a ‘real-time’ check against the on-prem aspects of SSPR/password-writeback:
- There will be a red “!” instead of the green check if there is a problem with the connection:
FAQ
“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’
- And if you REAAALLLY want to get cray-cray (and why wouldn’t you?), publish the site as an ‘app’ via AAD App Proxy - and your users will see it in their app list. Obviously, if a user doesn’t know his password, he won’t be able to login to this PC to get to the portal in the first place but the registration button, password change button and profile button could be helpful to your users.
“What’s the typical deployment model at a high-level?”
- The common model for an enterprise-type rollout means "controlled and staged" - no 'big bang' changes:
- Communicate to end users – notify users about what SSPR is, that it’s coming and send the SSPR registration link in emails, desks in conference rooms, the lobby, etc. but leave the value for “Registration” set to ‘No’
- Follow up w/ scheduled/recurring emails, posters, etc. reminding people to register in recurring emails, notifications, etc.
- At some point, communicate a deadline for SSPR registration and after that deadline, set the “Registration” value to ‘Yes.’
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?”
- Download and edit/customize these - https://www.microsoft.com/en-us/download/details.aspx?id=56768
“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).
- During a password reset, the ‘new’ password is checked against the on-prem policy and cloud password policy (which you can’t edit today)
- If the new password doesn’t meet/exceed the on-prem AD password policy(ies), the user is informed that the value doesn’t meet the “corporate password policy” (but not with the details of the password policy rules - ☹ ).
- Here’s the portal audit entry for one of those failed attempts:
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.
- Here is the end-user error messaging and portal audit entry if we encounter one of the ‘built-in’ simple/common banned passwords (i.e. password123):
- Here is the end-user error messaging and portal audit entry if we encounter one of your own custom banned passwords (if they’re in use):
“Whoa … what are banned passwords” you ask?
- Yet another excellent feature that is part of your Azure AD Premium P1 service (teaser: does 'passflt.dll' mean anything to you?)
- If the new password meets/exceeds any/all policies, the value is set in both AD and AAD - you’re good immediately.
“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:
- Example A: Helpdesk sets the temporary password in AD to a strong/random password but doesn’t check the box to force a password change at next login - inform the user to go to the SSPR portal (passwordreset.microsoftonline.com) to reset his/her password, eliminating the need to change it from a temporary administrator-known/set value.
- Example B: Helpdesk sets the temporary password, checks the box to force a password change at next login - but informs the user they must login/change the temporary password from a domain-joined PC on the corporate LAN.
“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:
- The on-prem AD ACLs –
- Missing, not complete, not pushed down to all descendent user objects, etc.
- https://docs.microsoft.com/en-us/azure/active-directory/active-directory-passwords-getting-started#s...
- Is the user licensed for AAD Premium?
- Are the “Password reset” settings in AAD configured appropriately?
- Is the user ‘in scope’ for SSPR? In the event you’re scoping SSPR to a group, is the user in that group? Has that group sync’d to AAD?
“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?”
- Manually, via the portal, an admin can enter “Authentication information”
- PowerShell is an option, too:
“What about ‘password expiration,’ ‘locked accounts’ and ‘disabled accounts’ in AD – how does password hash sync and/or SSPR interop w/ those conditions/situations?”
- We don’t sync password expiration status from on-prem to on-line. So, if the on-prem pwd expires, what happens?
- The actual behavior depends on the authentication configuration – (password hash sync, federation or pass-through auth)
- For one, users will not get any prompts/reminders when accessing cloud resources
- Your cloud id/access may not be impacted and will continue to allow access to cloud resources (in the case of pwd hash sync)
- https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchron...
- Regardless, when users update the on-prem pwd, it will sync to the cloud
- We don’t sync account lockout status from on-prem to on-line
- The on-prem account is what gets locked out
- Again, depending on the authentication configuration (password hash sync, federation or pass-through auth), someone who locks out her on-prem account could possibly still have access to cloud services and resources (in the case of password hash sync)
- We do sync disabled status to the cloud accounts if the on-prem sync’d ID is disabled.
- That means when someone leaves the org and you disable the ID in AD, that will sync to the AAD instance of the ID, too, disabling it.
“I fear I might have a malicious user/session(s); how can I address that?”
- With modern authentication and ‘access from anywhere,’ there are often concerns around quickly terminating a user’s existing sessions; you can take a few actions as part of a process to address this:
- In AD > Reset the password and disable the ID; force a sync to AAD
- In AAD/O365 Portal > specific targeted user:
- Block sign in
- NOTE - If you reset the password here or in the AAD portal, you’re only changing the ‘cloud’ password (which might be ok if there is an urgent situation). Just realize that this change won’t be written back to the on-prem AD password
- Block sign in
AAD Portal:
O365 Portal:
- Initiate a sign-out (from One Drive section of the user settings in the O365 Portal)
- You might also consider using PowerShell to ‘revoke’ tokens
- We have detailed guidance on ‘How to effectively and timely manage a terminated user’
- Also, review configurable sign in frequency – this is some good stuff and a similar capability was previously in preview as ‘configurable token lifetimes’
- If you’re still thirsty for more FAQs, head over - https://docs.microsoft.com/en-us/azure/active-directory/authentication/active-directory-passwords-fa...
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)!
Hilde