Jamf Blog
How to . . .
December 28, 2021 by Sean Rabbitt

How-to: Azure Conditional Access and Jamf Connect

Finding "failed" login attempts in Azure sign-in logs? Learn:

  • 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


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 (MFA) 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, 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 enforcing 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:
    Create 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 the 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 in the Jamf Nation post "Creating a custom scope for Jamf Connect in Azure for Conditional Access policies" to create a custom scope for Jamf Connect applications (you’ll need to sign into Jamf Nation or create an account to access it). Verify that no policies are created that apply to "All cloud apps" so 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 when MFA is required, including exempting MFA for web applications.

Resource Owner Password Grant workflow

Jamf Connect uses an 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.

Reference: https://docs.jamf.com/jamf-connect/administrator-guide/Authentication_Protocols.html

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.

Example logs from a sample Microsoft Azure instance

Shown above are two logins that 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.

Details on a non-interactive login from Jamf Connect via ROPG:

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:

Details on a failed non-interactive login due to an incorrect 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.

Creating a Custom Scope for Jamf Connect and Conditional Access policies

Workflow overview:

  • Create a “private endpoint” application registration with a custom API
    • With API permissions for "User.read"
    • With "Expose an API" scope created
    • Define roles like "Admin" and "Standard" for elevating macOS account permissions
  • Create a "public endpoint" application registration for OIDC to call that custom API
    • Remove API permissions for "User.read"
    • Add API permission for "My APIs" for the name of the application created in step one and the scope created in step one
  • Create an Azure Conditional Access policy to require multifactor authentication
    • Apply to application created in step one
  • Remove any CA policy applied to "All cloud apps" that would require MFA
  • Create a Jamf Connect Login configuration profile
    • Azure as Identity Provider
    • Define a custom scope
    • Define the Discovery URL for OIDC and ROPG
    • Test with Jamf Connect Configuration

The latest version of step-by-step instructions on how to set up the application in Azure is available here.

Sean Rabbitt
Subscribe to the Jamf Blog

Have market trends, Apple updates and Jamf news delivered directly to your inbox.

To learn more about how we collect, use, disclose, transfer, and store your information, please visit our Privacy Policy.