Hey all!

A quick clarification on some using Jamf Connect with MFA in Azure AD.

Having MFA enforced on sign-ins to your iDP is obviously a must in view of security. Especially when we are using tools to leverage iDP to get local access to workstations like we do with Jamf Connect.

However, in view of the authentication mechanisms Jamf Connect uses, as well as how Azure AD Conditional access works, there is some behaviour which can be experienced as unexpected when Jamf Connect uses ROPG (Ressource Owner Password Grant, or in Microsoft’s terminology, ROPC – Ressource Owner Password Credentials).

Let me elaborate that a bit.

Looking are Jamf Connect there are 2 main features:

  • Jamf Connect Login: create a local account if needed, and/or login to the Mac with credentials in sync with iDP
  • Jamf Connect Menu Bar: keep the local account credentials in sync with iDP

For this, Jamf Connect uses 2 authentication mechanisms: OIDC and ROPG.

With OIDC we typically get a web view in which we authenticate to the iDP, just like we would do on a website. Here MFA can be prompted without any problems as the end user is actively interacting with the web view.

But for ROPG, which both Jamf Connect Login and Jamf Connect Menu bar uses to keep the passwords in sync, this happens in the background. I know, Jamf Connect Menu bar does have the option to manually click ‘connect’, which results in a GUI login window popping up, but beyond that it also has functionality to silently check the password sync at predefined intervals.

Looking at those silent authentications in the background, we can understand that by the lack of user interaction but also due to the nature of the ROPG authentication mechanisme, there is no MFA possible.

Hence, if MFA is enforced for ALL types of authentications against the iDP, we quickly run into trouble. Disabling MFA in general is obviously no option, but the way Azure AD is designed and the way the Jamf Connect app needs to be created in Azure AD App Registrations (Public Client/Native Mobile and desktop app, and not as a web app), restricts us from adding Jamf Connect as an exclusion to Conditional Access policies set to enforce MFA on all Cloud Apps. As Jamf Connect should not be created as “Cloud App”.

Fortunately there is a workaround, by using Custom Security Attributes and a custom API.

I’ll not go through the entire setup to do this, as it’s well documented on: https://learn.jamf.com/bundle/technical-articles/page/Creating_a_Custom_Scope_for_Jamf_Connect_and_Conditional_Access_Policies.html

Although the configuration needs to be done exactly as documented (makes sense right 🙂 ) and can be a bit complex at first glance, I can confirm it totally works as documented and expected.

When configuring Azure AD in this way, creating the custom API endpoint and leveraging the custom security attribute, I do confirm that there will be NO “INTERRUPTED” log entries in Azure AD sign-in logs. Even if those interrupted logins did not break any functionality per se, in combination with using the ‘success code’, those interrupts authentications can however trigger false (spamming) alerts for the security teams.

More detail on using the success codes can be found here on https://learn.jamf.com/bundle/jamf-connect-documentation-current/page/Multifactor_Authentication.html and https://learn.jamf.com/bundle/jamf-connect-documentation-current/page/Login_Window_Preferences.html

ROPGSuccessCodes : Specifies an array of strings that contain error codes from your IdP during an ROPG password verification, which should be interpreted as successful by Jamf Connect.

For MFA you would typically add AADSTS50076 as success code, but only if the interrupted/failed sign-in log entries are of no concern for your internal policies. If so, the above mentioned workaround and alternative configuration with the custom security attribute needs to be implemented.

Now, yet again I confirm the documented workflow does work as intended, but there is a catch!

And the catch is: “PER USER MFA“: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates

While the currently recommended workflow to enforce MFA in Azure AD is to use Conditional Access, there is also another functionality in Azure AD to enforce MFA for users, globally, regardless of which app or authentication scenario they are using.

This however should not be enabled in combination with with Conditional Access policies, as clearly stated on Microsoft’s documentation (see link above):

Don’t enable or enforce per-user Azure AD Multi-Factor Authentication if you use Conditional Access policies.

Doing so, will result in Azure AD logging ‘INTERRUPTED‘ sign-ins for all ROPG, even if the alternative configuration with the custom security attribute has been implemented !

As you can see, I did not have any interrupted message on the Jamf Connect authentication when “per user MFA” was disabled for all users, leveraging MFA at Conditional Access level only. But once I enabled it for my test account, the next authentication (although successful) was logged as Interrupted.

Hope that clarifies some roadblocks I see when troubleshooting this kind of issues. Please note however that for this workflow to work, the filter to exclude Jamf Connect (based on the custom security attribute) needs to be configured on ALL CA policies set to ALL CLOUD APS. But that is well mentioned on the documentation for this workflow.

Finally it’s worth to mention that also USER RISK and SIGN IN RISK policies in Azure AD can trigger authentication to be ‘interrupted’ as well: https://learn.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-configure-risk-policies

However, as this is a legacy feature of Azure AD and Microsoft recommends to migrate those policies to Conditional Access, I’ll not elaborate this any further.

That’s it! As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!

Brgds,
TTG