Jamf Connect and Microsoft Azure Conditional Access

rabbitt
New Contributor III
New Contributor III

Updated 14JAN2022 - The github link below has been updated to simplify the setup of the application registrations in Azure and allows for full testing in Jamf Connect Configuration before deploying to a test machine.

https://www.jamf.com/blog/how-to-azure-conditional-access-and-jamf-connect/  - Updated instructions posted to Jamf Blog.

UPDATED: 10 December 2021 - Includes information on how to create a custom scope for Microsoft Azure Conditional Access policies.

Overview: This covers the following topics:
  • Administrators finding "failed" login attempts in Azure sign-in logs when using Jamf Connect
  • How the ROPG workflow and Jamf Connect communicate
  • How to make an App Registration in Microsoft Azure Active Directory that allows for Conditional Access policies
  • How to make Conditional Access policies NOT apply to the ROPG workflow

Problem:

Administrators may observe failed login attempts in the log for the enterprise application created in Microsoft Azure Active Directory when using Jamf Connect and a Conditional Access policy that requires multi-factor authentication for the target of "All cloud apps." While this is expected behavior of the Resource Owner Password Grant (ROPG) workflow, it may trigger a user appearing in the Risky Sign-Ins in Azure Active Directory security reports.

What is happening:

The target of "All cloud apps" applies policies far beyond the logins to specific cloud services and applies policies to non-interactive workflows like those with ROPG.  Specifically, the "All cloud apps" appears to apply to any application requesting a login with the scope of any of the following:

 

 

 

 

openid profile email

 

 

 

 

The Open ID Connect 2.0 specification uses these default scopes to obtain an access or identity token for a client application.  Consequently, in its default configuration, Jamf Connect login uses the "openid profile email" scope in its authentication requests, and the only way to apply a CA policy in this default behavior is to apply the policy to "All cloud apps" with NO exceptions applied or the CA policy will break.

 
Administrators have multiple options for solutions to enforce MFA on the Jamf Connect login screen:
  • Simplest, but most impact on user logins: Set hard requirements for MFA via the older method of Azure Multi-Factor Authentication which applies an MFA requirement to ALL logins to ANY service for a specific user.  Ignore failed logins in the sign-in logs for ROPG checks of the password.  (Additional information on how to determine if a failed login is due to Jamf Connect menu bar agent doing an ROPG request is below.)
  • Simple, but may affect other services: Apply a Conditional Access policy applied to "All cloud apps" requiring Multi-factor Authentication for login.  Do NOT use an exception to the policy as that appears to break functionality of the CA rule as of testing done 10DEC2021.  Ignore failed logins in the sign-in logs for ROPG checks of the password.
  • Complex, but exacting: Follow the instructions from https://github.com/sean-rabbitt/jamf-connect-azure-conditional-access/ to create a custom scope for Jamf Connect applications.  Verify that no policies are created that apply to "All cloud apps" as to not affect the ROPG workflow.  CA policy will be applied as expected to the Jamf Connect login application and ROPG check will appear as a successful login in sign-in logs.

Azure Multi-factor Authentication vs. Conditional Access

Administrators can enable multi-factor authentication requirements for a user account in two ways:
  • Multi-factor Authentication which is reachable via the “All services” list in the Azure portal
  • Conditional Access which is reachable via Azure Active Directory under Security
Multi-factor Authentication is a system wide, all login attempts, master switch system for enforcing MFA at authentication. While IP address ranges can be exempted, the rules apply to all authentications.
Conditional Access allows for fine grain details to apply for when MFA is required including exempting MFA for web applications. 

Resource Owner Password Grant workflow

Jamf Connect uses a Resource Owner Password Grant (ROPG) workflow to synchronize the user’s password in the identity provider with the password on the user’s client machine. The user name and the password are sent to the identity provider in a “non-interactive” login to receive a response. This means that the user is not prompted for any sort of user name or password when logging in; Jamf Connect is using the information securely stored in the user’s keychain for this event.
 
For Azure, the responses are one of the following:
  • Success, no MFA requirements: An access, refresh, and ID token encoded in HS256
  • Success, MFA required through a policy: An error response like 

 

 

 

 

AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access [application UUID]

 

 

 

 

  • Failure, bad password or user name: An error response like 

 

 

 

 

AADSTS50126: Error validating credentials due to invalid username or password.

 

 

 

 

As long as the user password is correct, the ROPG flow has succeeded - the password has been validated to be correct. Whereas Jamf Connect has no need for the access, refresh, and ID token to keep the local password in sync with the identity provider, an appropriate error response is interpreted as a successful password check.
 

Diagnosing MFA vs. failed password in Azure logs

Navigate to Azure Active Directory → Enterprise Applications and select the name of your Jamf Connect application in Azure. Navigate to Activity → Sign-ins to open user usage logs.
e644115f1f7546b4a4b419716c76c032
Shown above are two logins which appear to be failures. Under the “Authentication required” column, the first login says “Multi-factor authentication”. Clicking on the row will pull up additional details about the login attempt.
7758b4369d17439ba5a45eb2e32049ce
Under Authentication Details, the “Result detail” will let an administrator determine if the login was successful or a failure. In this example, the login was a success - the Result detail shows that the “User did not pass the MFA challenge (non interactive).” This login can be interpreted in that the user was required to use MFA by either a Conditional Access policy or through Azure Multi-factor authentication.

In the second example, a user with MFA required failed to enter their correct password:
c4f45b236d6442798ea95376ba15f075

The Authentication required column shows “Single-factor authentication” and the Authentication Details show “Invalid username or password or Invalid on-premise username or password.” While the user is required to use Multi-factor authentication, the user failed the first, single factor and thus was never prompted for MFA.

Creating a custom scope for Jamf Connect

To eliminate the inaccurate "failed responses" for ROPG, admins must remove any "All cloud apps" scoped requirements for multi-factor authentication and create a custom scope for Jamf Connect login.

Follow the guide in Azure_Conditional_Access_and_Jamf_Connect.pdf (source: GitHub) for step by step instructions.

Conditional Access Policy Considerations

Several Conditional Access Grant policies can create unacceptable behavior to access a client device:

  • Require device to be marked as compliant
  • Require Hybrid Azure AD joined device

In the above cases, a user would be unable to log into a client machine to fix the issue of being out of compliance by running a Jamf Pro policy to get the device back into compliance.

  • Require approved client app
  • Require app protection policy

In the above cases, the Jamf Connect software is not of the Microsoft apps accessing a specific service (for example, Microsoft Outlook accessing O365 mail), and all access would be blocked.

Administrators are recommended to carefully read conditional access polices and conditions applied to avoid locking users out of client devices inadvertently.

18 REPLIES 18

dpace-cs
New Contributor

I've been advised by Jamf support not to implement this.

"We would advise against using the KB. Right now due to limitations in Azure, we can not exclude it from the CA policy - so those errors are expected. We can mitigate the volume of errors by changing the network check to something longer such as 30 minutes to an hour, and set "checkOnNetworkChange" to false."

rabbitt
New Contributor III
New Contributor III

Hopefully these new instructions with a custom scope will help.

vcherubino
New Contributor II

Any updates to this? Still looking for a solution.

nebjamf
New Contributor II

also looking for a solution.  does JAMF Connect even support Azure MFA/conditional access?

rabbitt
New Contributor III
New Contributor III
Jamf Connect is a native/desktop application, and according to Microsoft’s support, Conditional Access is used for limiting access to cloud resources. I would highly recommend reaching out to Microsoft Support on why Jamf Connect is included in a definition of “All Cloud Apps” for Conditional Access policies as it appears to be an unintended result.

rabbitt
New Contributor III
New Contributor III

Updated information - through further research, determined that "openid" scope was what gets triggered by an "All cloud apps" CA definition.  Workaround posted.

jonahhebert
New Contributor

I have followed these steps exactly and ensured everything has been set properly.  I am able to successfully be prompted for MFA via the login window and my sign-in logs show the login with the OICD application to be successful, however the login shows the error message "An error occurred. Contact your it administrator".  Not sure what I'm missing.

rabbitt
New Contributor III
New Contributor III

I've got an update I JUST posted to GitHub (the official jamf blog will be updated soon too) which simplifies the process, requires only two App registrations, and can be fully tested inside of Jamf Connect Configuration. Hit https://github.com/sean-rabbitt/jamf-connect-azure-conditional-access/blob/main/Azure_Conditional_Ac...with the updated deets.

Thank you so much for the updated document! Glad I caught you just in time :).

After making the changes, the OICD test worked in the configuration application, however ROPG did not.  It appears to require the client secret.  After entering my client secret in both the IdP and Connect tabs, it proceeds to error out for OICD and ROPG.  I can gather additional troubleshooting info if necessary.  Would like to clarify if I'm missing anything about the client secret first.

rabbitt
New Contributor III
New Contributor III

Client secret should not be required.  If you defined a client secret in the public app (the one without any API permissions at all), you can either remove it or add that client secret to the OIDC and ROPG configuration in Jamf Connect Configuration to test it.  I was not testing with a client secret.

The link appears to be broken!

rabbitt
New Contributor III
New Contributor III

Links updated. I changed the name of the pdf. 

rabbitt
New Contributor III
New Contributor III

Sample configuration profile with this setup:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>AllowNetworkSelection</key>
<true/>
<key>CreateJamfConnectPassword</key>
<true/>
<key>OIDCAdmin</key>
<array>
<string>Admin</string>
</array>
<key>OIDCAdminAttribute</key>
<string>roles</string>
<key>OIDCClientID</key>
<string>[YOUR PUBLIC APPLICATION UUID STRING HERE]</string>
<key>OIDCDiscoveryURL</key>
<string>https://login.microsoftonline.com/[YOUR TENANT UUID STRING HERE]/v2.0/.well-known/openid-configuration</string>
<key>OIDCNewPassword</key>
<false/>
<key>OIDCProvider</key>
<string>Azure</string>
<key>OIDCROPGID</key>
<string>[YOUR PUBLIC APPLICATION UUID STRING HERE]</string>
<key>OIDCRedirectURI</key>
<string>https://127.0.0.1/jamfconnect</string>
<key>OIDCScopes</key>
<string>api://[YOUR RANDOMLY GENERATED API IDENTIFIER HERE]/jamfconnect+openid+profile+email</string>
<key>OIDCTenant</key>
<string>[YOUR TENANT UUID STRING HERE]</string>
<key>OIDCUsePassthroughAuth</key>
<true/>
<key>ROPGDiscoveryURL</key>
<string>https://login.microsoftonline.com/[YOUR TENANT UUID STRING HERE]/.well-known/openid-configuration</string>
<key>ROPGTenant</key>
<string>[YOUR TENANT UUID STRING HERE]</string>
</dict>
</plist>

astiephi
New Contributor II
New Contributor II

Hi there !

I've worked on many Connect implementations with Azure, and used your article as a reference many times.

Now, I was wondering, why would the ROPG part of JAMF Connect simply not ask for MFA when getting the AADSTS50076 answer ? People would not really be surprised to get a prompt to confirm MFA when changing location.

 

This would simplify a lot the discussions with organisations whhich really want to apply MFA to any app, and are annoyed by creating a second app which is MFA-exempt.

rabbitt
New Contributor III
New Contributor III

The ROPG check that happens every 60 minutes is supposed to be a "non-interactive" login.  End users may become... unhappy if they're prompted to MFA every 60 minutes.

The real trick here is that the request for MFA response AADSTS50076 will ONLY come up if the non-interactive send of the user name and password is correct.  At that point, Jamf Connect's menu bar agent knows the password is correct and we don't really need the identity/access token.  We just want to know the password is still correct.

astiephi
New Contributor II
New Contributor II

Agreed, however that some companies will lock the account of a number of failed attempts, and they are not happy with failed logins in Azure logs. It could be an idea to give a configuration key to allow re-entering MFA for those cases.

rabbitt
New Contributor III
New Contributor III

This is the purpose of the instructions above - allow there to be a app registration that is not subject to MFA requirements to prevent the "failed" login.  

To me, an MFA request every 60 minutes risks a larger danger of training a user to accept every MFA request blindly rather than improve security.

astiephi
New Contributor II
New Contributor II

Oh yes, and this is what I did. Some organisations are a bit stubborn and refusing any app that does not have MFA...