Enablement of combined security information registration for Azure Active Directory, Beginning on 1st of October 2022

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.

Why?

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

And Consent.

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.

With PowerShell

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

Method	Register	Change	Delete
Microsoft Authenticator	Yes (maximum of 5)	No	Yes
Other authenticator app	Yes (maximum of 5)	No	Yes
Hardware token	No	No	Yes
Phone	Yes	Yes	Yes
Alternate phone	Yes	Yes	Yes
Office phone	Yes	Yes	Yes
Email	Yes	Yes	Yes
Security questions	Yes	No	Yes
App passwords	Yes	No	Yes
FIDO2 security keys Managed mode only from the Security info page	Yes	Yes	Yes

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?

Go to https://portal.azure.com/#blade/Microsoft_AAD_IAM/FeatureSettingsBlade

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:

1. Sign into the Azure portal using a global administrator account.
2. Navigate to Azure Active Directory, select Password reset, then choose On-premises integration.
3. Verify the Azure AD Connect cloud sync agent set up is complete.
4. Set Write back passwords to your on-premises directory? to Yes.
5. 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.

Manage mode

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.

Troubleshooting

You find the user actions in the Audit logs.

The following table lists all audit events generated by combined registration:

Activity	Status	Reason	Description
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

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.