Require MFA to Register or Join devices with Azure AD - Device Settings Vs Conditional Access

 

While working on a device management project, I came across the requirement of MFA during device join using Access work or school method. Nothing out of the ordinary, but it did open a discussion with the customer and one of the talking points was the enablement of MFA itself which prompted me to write this blog post.

Multifactor authentication is an integral and important part of Microsoft's Zero Trust security model. The massive increase in mobile devices connecting to corporate resources resulted in evolving of the multifactor authentication system from physical smart cards to a phone-based challenge (phone-factor) and later moving into a more modern experience using the Microsoft Azure Authenticator application. This expanded to enrolling of  devices into a modern management system which checks the health of the device to control access to company resources.

As of writing this blog, there are mainly 2 ways to enable MFA for device registration or join to AAD.

1. A tenant wide setting under Device settings->Require Multi-Factor Authentication to register or join devices with Azure AD
2. Register or join devices through Conditional Access.

While most organizations with go with the tenant wide setting and be done with it, according to Microsoft, this is actually not recommended. Probably one of the reasons as to why the setting is actually set to No as default.


As I see it, Conditional Access provides granularity in general so configuring multifactor authentication for registering or joining devices instead of a tenant-wide policy makes a lot of sense.

You basically create a CA policy against a User action Register or join devices with Grant controls requiring MFA. 




Do you notice how all other access controls are greyed out? That is because there are some considerations to using this user action:


1. Require multifactor authentication is the only access control available with this user action and all others are disabled. This restriction prevents conflicts with access controls that are either dependent on Azure AD device registration or not applicable to Azure AD device registration.

2. Client apps, Filters for devices and Device state conditions aren't available with this user action since they're dependent on Azure AD device registration to enforce Conditional Access policies.

3. When a Conditional Access policy is enabled with this user action, you must set Azure Active Directory > Devices > Device Settings - Devices to be Azure AD joined or Azure AD registered require Multifactor Authentication to No. Otherwise, the Conditional Access policy with this user action isn't properly enforced. This is also clearly stated when you enable the user action in the CA policy.


End Result

I put this to test against different device enrollment scenarios.

1. Device join to Azure AD through Access work or school method.

With the user action CA policy enforced, the targeted user will be prompted to satisfy MFA.





Note: The user action currently shows under Authentication context. I am not sure why it is like this as Authentication context is a separate target resource in CA, but for now it looks like user actions are also captured under Authentication context field in Azure sign-in logs.

2. Device registration through Company Portal enrollment method on iOS.




3. Device registration when accessing corporate data in a MAM scenario.




Final thoughts..

One can use security defaults to enable MFA as well, but I recommend using Conditional access policies if you want granular control. The other benefit is the reporting piece which is extremely handy in my opinion.


Until next time..

Comments

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

Intune: Configure Printers for Non-Administrative Users

Prevent users from running certain programs or applications on Windows endpoints using Intune