Microsoft Azure Identity Protection, Conditional Access, and Jamf Connect

New Contributor III

Overview: 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. 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.

This document describes why the log incorrectly marks this sign-in as a “Failure” and methods to change the behavior in Microsoft Azure.

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 to receive a response. For Azure, the responses are one of the following:

  • Success, no MFA requirements: An access, refresh, and ID token encoded in HS256
  • Success, MFA enabled by Conditional Access or through Azure Multi-Factor Authentication: 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: 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.
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.
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:

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.

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. It is recommended to use Conditional Access for enabling MFA requirements with Jamf Connect.

Conditional Access Policy Exemptions for Jamf Connect


  1. Create an application in Azure for Open ID Connect 2.0 (OIDC) and create a second application in Azure for Resource Owner Password Grant (ROPG)
  2. Modify applications to allow the apps to appear in Conditional Access
  3. Apply requirement for MFA to OIDC app
  4. Apply exemption for MFA to ROPG app
  5. Create configuration profiles for Jamf Connect on client machines

Step One: Create applications

Follow the procedure in to create an application for Jamf Connect in Azure and name the app “Jamf Connect OIDC”. Repeat the procedure, creating an application with the name “Jamf Connect ROPG”.

(Optional: For the second application named Jamf Connect ROPG, the instructions for “Assigning Users and Designating Roles” may be skipped as the role claim will not be used.)

Optional: An administrator may choose to add a client secret to the ROPG-based app as a second security factor to access the ROPG application. Navigate to the ROPG app registration in Azure Active Directory → App registrations and set a secret under Mange → Certificates & Secrets.

Step Two: Modify applications to allow for Conditional Access

Follow the procedure in to add a bogus web redirect URI of to both applications you created in Step One

Step Three: Apply requirement for MFA to OIDC app

Open the Azure portal at and navigate to Azure Active Directory → Security → Conditional Access. Create a new policy or edit an existing one. Assign the policy at first to a test group of users to assure the policy is applied correctly. Under the section Assignments → “Cloud apps or actions”, select the OIDC app you created in Step One:
Under the section Access Controls → Grant, select the option to “Grant access” and “Require multi-factor authentication”.

Note: Refer to for a discussion on Conditional Access Policy Considerations; it is strongly recommended to not select any additional grants as they may put the client machine in an inextricable state of unable to login and make a device compliant.

Refer to for full instructions.

Step Four: Apply exemption for MFA to ROPG app

In the same conditional access rule from Step Three, navigate to Assignments → “Cloud apps or actions”. Select the option to Exclude and then select the ROPG app name you created in Step One.

Step Five: Create configuration profiles for Jamf Connect on client machines

Use the Jamf Connect Configuration app located in the software distribution DMG file for Jamf Connect located in your Assets in your Jamf Nation account. 28e6dd7e70aa49f9a70a2017f2d4da76
In the OIDC Client ID, use the Application ID for the OIDC app you created in Step One. In the ROPG Client ID, use the Application ID for the ROPG app you created in Step One. Use the Test button in the upper right corner of the application to validate the configuration with a Conditional Access user you assigned in Step Three. With the OIDC test, the user should be prompted for MFA. With the ROPG test, the Azure sign-in logs for the ROPG app should show a successful authentication.

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
    <plist version="1.0">

The resultant configuration profile will have a different UUID in the OIDCClientID field and the OIDCROPGID fields. Deploy to client devices.


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."

New Contributor II

Any updates to this? Still looking for a solution.