Secure Registration and TAP with a password-less CA baseline

[Miike]

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 fine with the password-less requirements if an account is already configured. If its a new account needing to enroll or an account with a lost authenticator, TAP cant provide access to register methods again without seeing "Additional authentication is required to complete the sign-in" bricking the user without excluding them from the CA baseline. How are people getting past this and maintaining a password-less baseline within their environment? 

I was hoping their was a cloud App for Security Registration that could be excluded from a password-less baseline or something similar. This seems to defeat the purpose and introduce a weaker link, however I'm sure its still better than managing accounts in exclusion groups. 

Hoping someone might have some thoughts.

Thanks!

[#2]

Getting closer:

To keep passwordless baseline and include TAP i can create a cutom security strength and include TAP. If I also add the Grant control of require hybrid join, a new account can enrol into the authenticator, an account with a lost authenticator can also re-enroll through a hybrid device. 

However, enable phone sign-in still dies in the app where it requests TAP to meet the baseline to register the device (Fine for onboarding a new user - issue at scale for existing users).

Would like to hear how others are solving this to go passwordless.

[#3]

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.

[#4]

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!

[#5]

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-mul...) , 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.

[#6]

@Simon Håkansson Thanks appreciate your insight too!

I'll test out your process today, see if I can address the challenge. 

[#7]

This worked perfectly, I think the main difference I had was pushing the TAP as OTP rather than multi-use, makes sense looking back at the issue now.

I agree, when we can enforce passwordless enrollment through guided prompts or have it enabled as default to managed devices it will be a lot easier, hopefully one day soon!

[#8]

Great, yes it makes sense then but it's not intuitive at all as of now. Hopefully that will be a bit more user friendly going forward.