Microsoft release Combined security registration in April 2020 as optional and it was enabled by default for tenants created after 15th August 2020 but not for tenants in the China region.
Table of Contents
Before combined registration, users registered authentication methods for Azure AD Multi-Factor Authentication and self-service password reset (SSPR) separately. People were confused that similar methods were used for Multi-Factor Authentication and SSPR but they had to register for both features. Now, with combined registration, users can register once and get the benefits of both Multi-Factor Authentication and SSPR.
How to find out when Your tenant was created?
Not mandatory for this but nice tips coming up!
With Microsoft Graph
Consent on behalf of your organization.
Open modify permissions and Consent to Directory.Read.All
Once done, run the following query
See creation date and time from the query.
And because it was created in 2021 I can’t modify those settings.
Connect to Graph and run the following.
Consent Graph PowerShell.
My other demo tenant is created in 2017
So I can switch the registration if I want.
Methods available in combined registration
|Microsoft Authenticator||Yes (maximum of 5)||No||Yes|
|Other authenticator app||Yes (maximum of 5)||No||Yes|
|FIDO2 security keys|
Managed mode only from the Security info page
Which makes sense, In my opinion App passwords are bad thing to enable but of course there are circumstances that require them to be enabled.
Here’s an excellent flow diagram from Microsoft.
How to setup?
And choose select or all. With select You can try it out before enabling to all.
Conditional access to the rescue, what could be easier than CA policies for this task.
Then to Cloud apps or actions and choose User actions -> Register security information.
And finally define it for all locations or selected ones.
And exclude all trusted.
Choose and grant access.
Finally enable the policy or just put it to report mode.
This scenario applies to external networks and excluding any trusted networks
Self-Service Password Reset
Enable password writeback for SSPR
With password writeback enabled in Azure AD Connect cloud sync, now verify, and configure Azure AD self-service password reset (SSPR) for password writeback. When you enable SSPR to use password writeback, users who change or reset their password have that updated password synchronized back to the on-premises AD DS environment as well.
To verify and enable password writeback in SSPR, complete the following steps:
- Sign into the Azure portal using a global administrator account.
- Navigate to Azure Active Directory, select Password reset, then choose On-premises integration.
- Verify the Azure AD Connect cloud sync agent set up is complete.
- Set Write back passwords to your on-premises directory? to Yes.
- Set Allow users to unlock accounts without resetting their password? to Yes.
And SSPR for the End-users
Logon to https://aka.ms/sspr
And it will offer you options to verity that you are you.
So I choose Authenticator and it went thru, now it will ask the second method to verify you.
and when it finished, you done.
When ready, select Save.
Users can access manage mode by going to https://aka.ms/mysecurityinfo or by selecting Security info from My Account. From there, users can add methods, delete or change existing methods, change the default method, and more.
You find the user actions in the Audit logs.
The following table lists all audit events generated by combined registration:
|User registered all required security info||Success||User registered all required security info.||This event occurs when a user has successfully completed registration.|
|User registered all required security info||Failure||User canceled security info registration.||This event occurs when a user cancels registration from interrupt mode.|
|User registered security info||Success||User registered method.||This event occurs when a user registers an individual method. Method can be Authenticator app, Phone, Email, Security questions, App password, Alternate phone, and so on.|
|User reviewed security info||Success||User successfully reviewed security info.||This event occurs when a user selects Looks good on the security info review page.|
|User reviewed security info||Failure||User failed to review security info.||This event occurs when a user selects Looks good on the security info review page but something fails on the backend.|
|User deleted security info||Success||User deleted method.||This event occurs when a user deletes an individual method. Method can be Authenticator app, Phone, Email, Security questions, App password, Alternate phone, and so on.|
|User deleted security info||Failure||User failed to delete method.||This event occurs when a user tries to delete a method but the attempt fails for some reason. Method can be Authenticator app, Phone, Email, Security questions, App password, Alternate phone, and so on.|
|User changed default security info||Success||User changed the default security info for method.||This event occurs when a user changes the default method. Method can be Authenticator app notification, A code from my authenticator app or token, Call +X XXXXXXXXXX, Text a code to +X XXXXXXXXX, and so on.|
|User changed default security info||Failure||User failed to change the default security info for method.||This event occurs when a user tries to change the default method but the attempt fails for some reason. Method can be Authenticator app notification, A code from my authenticator app or token, Call +X XXXXXXXXXX, Text a code to +X XXXXXXXXX, and so on.|
After enabling combined registration, users who sign up or confirm their phone numbers or mobile apps through the new experience can use them for Azure AD MultiFactor Authentication and SSPR, if those methods are enabled in Azure AD MultiFactor Authentication and SSPR policy.
If you then disable this experience, users who previously visited the SSPR registration page at https://aka.ms/ssprsetup must perform multi-factor authentication before they can access the page.