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:
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]
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 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
Follow the procedure in https://docs.jamf.com/jamf-connect/administrator-guide/Integrating_with_Microsoft_Azure_AD.html 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.
Follow the procedure in https://www.jamf.com/jamf-nation/discussions/38040/azure-conditional-access-and-jamf-connect to add a bogus web redirect URI of
https://0.0.0.0/jamfconnect to both applications you created in Step One
Open the Azure portal at portal.azure.com 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 https://www.jamf.com/jamf-nation/discussions/38040/azure-conditional-access-and-jamf-connect 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 https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-acces... for full instructions.
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.
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.
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" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CreateJamfConnectPassword</key> <true/> <key>OIDCClientID</key> <string>baf44d07-1930-4f06-96f6-sample</string> <key>OIDCProvider</key> <string>Azure</string> <key>OIDCROPGID</key> <string>2520beb2-535e-4e42-bf70-sample</string> </dict> </plist>
The resultant configuration profile will have a different UUID in the
OIDCClientID field and the
OIDCROPGID fields. Deploy to client devices.
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."