Device registration and security/MFA registration

bflick I think I do. The key thing is a user is not using his password to log in to his device (but using PIN, Windows Hello...) , to be able to perform SSO towards Azure services, this isn't sufficient, you need a password or some additional factor. This triggers device registration. It is the device registration that needs the mfa (not yet sure why exactly).

So to be tested, if you use password to log in to Windows 10 you will not start the device/mfa registration, but SSO will be possible. If you do not use a password to log in to Windows 10 and skip the device/mfa registration you won't get SSO for Teams and Outlook.  

If the user logs into the machine via a new generation credential (PIN, Hello, ..) that is not already included in the existing PRT or there is no existing PRT on the device then the Azure AD MAM plugin will trigger device registration via a request which includes the “amr_values=ngcmfa” parameter and this will be the source of the MFA.

From MS support

• The user is connecting from an Azure AD registered device via a PRT which only contains the password claim for the registration authentication method used(Registration_amr). This means that the device was previously workplace joined to Azure AD without MFA being required as per your current configuration in which MFA is not required. This evaluation is done based on the device authentication request sent to Azure AD.
• The MFA requirement is enforced by the Azure AD WAM plugin(Microsoft Authentication broker) via the following request parameters “amr_values=ngcmfa”. This is occurring because the user signed into the machine using a new generation credential like a PIN or fingerprint. At this time, because the user signed into the Windows device via a different authentication method than the one included in the PRT(which was password), the authentication broker forces the user to configure MFA so that it can refresh the existing PRT record on the device with the new authentication method used.

Considering the above information, this behavior is by design and to be expected due to the PRT token refresh process and you can find it better detailed in the following articles:

How is a PRT renewed? - https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token#how-is-a-prt-renewed

When does a PRT get an MFA claim? - https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token#when-does-a-prt-get-an-mfa-claim

Regards,

Bart