Forum Discussion
Solved
Secure Registration and TAP with a password-less CA baseline
Hi All, I've been looking further at password-less in an Azure AD tenant and if it can be set as a baseline CA requirement for access to tenant resources. Access via CA policies appears to work ...
- If you enforce Passwordless (authentication strength) as you've noticed you might need to add TAP as an additional method in that policy. Let's consider the scenario: existing user, new phone.
It's a bit clunky today since you will need TAP for getting the user into Security Info first (to register method), and then provide TAP yet again when you "Enable Phone-Sign in" in the new mobile. You could use the same TAP there if you set it to not require one-time use and then scope it to 1 hour for example. I have an example authenticator scenario you can compare with: https://simonhakansson.com/passwordless-authenticator-configuration-ddb0fa70d32f
Keep in mind that TAP is considered stronger than the other available MFA methods (https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-system-preferred-multifactor-authentication#how-does-system-preferred-mfa-determine-the-most-secure-method) , so it should be handled with care.
I expect the Passwordless registration-flow to become a bit more user friendly in the future, ideally you would want "Enable Phone-sign in" to be automatic in some way, at least for MDM-enrolled phones in my opinion.
Hello Miike.
Indeed, enforcing password-less authentication while ensuring seamless registration and recovery can be a challenge. Here are a couple of strategies that could help you maintain a password-less baseline while addressing the issues you've mentioned:
Create a separate Conditional Access policy for registration and recovery:
Create a new Conditional Access policy and assign it to "All users" or a specific group, as needed.
Set the desired cloud apps or actions, and make sure to include the "Azure AD User Registration" service.
Under "Conditions", configure any additional conditions such as device platform, location, or device state, if required.
Under "Grant", select "Require one of the selected controls" and choose the authentication methods you want to allow for registration and recovery purposes. This could include less secure methods like SMS or even the Temporary Access Pass (TAP).
Set the policy to exclude users who have already registered their password-less authentication methods. This can be done using dynamic groups based on the "authenticationMethodsRegistered" attribute.
Use "Just-in-Time" TAP issuance for registration and recovery:
When a new user needs to register their password-less authentication method or an existing user has lost their authenticator, you can issue a Temporary Access Pass (TAP) with a limited validity duration and a specific purpose (e.g., "registration" or "recovery").
To ensure the TAP can be used for registration, create a separate Conditional Access policy that allows TAP as an authentication method specifically for the "Azure AD User Registration" service, as described in the previous strategy.
Communicate the TAP to the user securely and instruct them to use it only for the intended purpose. Once the user has registered their password-less authentication method or recovered their account, the TAP will no longer be valid, and the user will be required to use their password-less method for accessing resources.
With these strategies in place, you can maintain a password-less baseline within your environment while ensuring a smooth registration and recovery process. Note that it's essential to educate users on the importance of securing their password-less authentication methods and to regularly review and update your organization's security policies to minimize risks.
Indeed, enforcing password-less authentication while ensuring seamless registration and recovery can be a challenge. Here are a couple of strategies that could help you maintain a password-less baseline while addressing the issues you've mentioned:
Create a separate Conditional Access policy for registration and recovery:
Create a new Conditional Access policy and assign it to "All users" or a specific group, as needed.
Set the desired cloud apps or actions, and make sure to include the "Azure AD User Registration" service.
Under "Conditions", configure any additional conditions such as device platform, location, or device state, if required.
Under "Grant", select "Require one of the selected controls" and choose the authentication methods you want to allow for registration and recovery purposes. This could include less secure methods like SMS or even the Temporary Access Pass (TAP).
Set the policy to exclude users who have already registered their password-less authentication methods. This can be done using dynamic groups based on the "authenticationMethodsRegistered" attribute.
Use "Just-in-Time" TAP issuance for registration and recovery:
When a new user needs to register their password-less authentication method or an existing user has lost their authenticator, you can issue a Temporary Access Pass (TAP) with a limited validity duration and a specific purpose (e.g., "registration" or "recovery").
To ensure the TAP can be used for registration, create a separate Conditional Access policy that allows TAP as an authentication method specifically for the "Azure AD User Registration" service, as described in the previous strategy.
Communicate the TAP to the user securely and instruct them to use it only for the intended purpose. Once the user has registered their password-less authentication method or recovered their account, the TAP will no longer be valid, and the user will be required to use their password-less method for accessing resources.
With these strategies in place, you can maintain a password-less baseline within your environment while ensuring a smooth registration and recovery process. Note that it's essential to educate users on the importance of securing their password-less authentication methods and to regularly review and update your organization's security policies to minimize risks.
Thanks josequintino,
Appreciate the insight you have provided here.
The modification to authentication strengths for Register Security Information to include a one-use tap token works getting the authenticator app setup Microsoft Authenticator + Push for lost devices.
The challenge of registering the device in against the authenticator app to turn on password-less conflicts with the passwordless baseline. Your thoughts for this are exactly what I am thinking would remediate this one - if I had the ability to target a Cloud App - Azure AD User Registration Service, or to exclude the device registration user action in the policies I could isolate this.
I'll check against other tenants as I don't have a Cloud App - Azure AD User Registration Service in my environment listed for selection.
Thanks!