Browser requests from Azure AD Joined machines never pass through ADFS. Why?

Question

We noticed that, on Azure AD Joined devices on the internet, the browser requests to authenticate on web resources protected by Azure AD (e.g. authentication on office.com) do not pass through ADFS, despite the fact that we have federated authentication in Azure AD. Why this happen?

We also noticed that the MFA challenge is requested only once, on the very first user access to any Azure AD protected resource, despite the fact that we have not allowed MFA token caching (we unchecked the option: “Allow users to remember multi-factor authentication on devices they trust”). Why this happen?

Where are these behaviors documented?

NOTES:

• In our tests, the PCs are on the internet (not on the internal network)
• On the Azure AD sign-in logs, we see that, every time a user login to the Azure AD Joined PC, there is a Windows Sign-In event logged with source IP equal to the internal IP of the Load Balancer in front of ADFS. That authentication then goes through ADFS. As said, this event does not appear in the logs when the signed-in user then authenticate to a web page protected by Azure AD.
• Our Conditional Access policy asks for MFA on every access with the single exclusion of "trusted networks" that, in our case, corresponds to the MFA option "Skip multi-factor authentication for requests from federated users on my intranet"
• We are doing our tests on Chrome browser with the W10 Account extension installed for the current user (but no profile authenticated) and on Edge with the profile authenticated with the same user who did the windows sign-in. Same behavior.
• If we repeat the tests on the same PC, with another account not having the W10 Account extension installed on Chrome, the behavior on Chrome is completely different: we go through the authentication in ADFS and the MFA challenge, exactly as we see on PC not Azure AD Joined.

Thank you

Answer 1

About my question "Is there a way to force the MFA challenge every time when accessing specific cloud applications from a W10 Azure AD Joined device (with a PRT) by using Chrome W10 Account Extension or Edge with logged in profile?" My understanding is that the answer is NO. Can you please confirm?

I understand and totally agree on the need to minimize MFA challenges but not all the enterprises already moving to modern device management with the first devices in AAD Join & MDM have previously developed a fully comprehensive set of security policies for their devices. For sure, not all of them are ready to use WHfB. I know enterprises that - for some reasons - have excluded the MFA challenge for the MDM device enrollment actions: in these (bad) conditions, from any AAD joined devices, any AD user synched in Azure can access sensitive cloud applications which were protected by MFA when accessed from devices not joined to Azure AD.

IMHO, the documentation is not clear enough on that evidence that the PRT suppresses the MFA: I could see only this small paragraph describing the evidence that AAD Joned device with "adequate" browser conditions do not get MFA challenges. IMHO, this should be clearly highlighted in the documentation related to planning for device management in Azure AD.

About the question on "applicable to the Registered owner of the device and not to any other user who signs in to that device", let me clarify the context, already tested on different lab/prod environments.

• Get an Azure AD Joined device registered in Azure AD by the AAD User X
• Sign-in to Windows with User X. Open Edge with signed-in profile for User X, open office.com and authenticate: no MFA challenge. This is expected: SSO by PRT
• Sign-in to Windows with another User Y in the same directory. Open Edge with signed-in profile for User Y, open office.com and authenticate: no MFA challenge. This is not expected according to this documentation ("[no MFA is] applicable to the Registered owner of the device and not to any other user who signs in to that device").

Thank you

Answer 2

Thank you for your answer. I have a few additional doubts about this.

• Is there a way to force the MFA challenge every time when accessing specific cloud applications from a W10 Azure AD Joined device (with a PRT) by using Chrome W10 Account Extension or Edge with logged in profile? All our tests with Conditional Access Policies were unsuccessful: in the sign-in logs we always found the condition: "MFA requirement satisfied by claim in the token". I understand that the recommendation is to "Configure authentication session management with Conditional Access", but this solution cannot force the MFA challenge for every access to specific cloud applications.
• I understand that the PRT is automatically renewed with a rolling window of X days. Here it is written that the lifetime of a PRT is 14 days. Here I read that the sign-in frequency for the rolling window is 90 days. So, what is the default number of days for the renewal of the PRT? And under which conditions (Azure AD settings) the user get an MFA challenge when the PRT is expired? Is the PRT renewed only at Windows Sign-In or also when authenticating through the browser on a Cloud application or in other conditions, maybe also automatically, without user intervention?
• The SSO through PRT should be "applicable to the Registered owner of the device and not to any other user who signs in to that device". In our tests this is not true: other Azure AD users who signin to the Azure AD jojned device go in SSO without MFA. Why?

Thank you again

Answer 3

Its because the Azure AD joined devices have a PRT. See https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token for details. The PRT is a feature to provide an enhanced SSO experience. It is available regardless of whether user is federated or not.

The PRT is acquired during logon. This is what you see as a "Windows signin event" in the Azure AD signin logs. The PRT prevents the need for further AAD resource access to be redirected via AD FS.

Chrome with the Windows 10 account extension makes use of the PRT. Not having the extension forces the federated logon you've observed.