03-08-2021 02:01 PM - edited 09-14-2022 09:18 AM
Updated 14SEPT2022 - I moved the GitHub link over to the official Jamf Github - https://github.com/jamf/jamfconnect/tree/main/azure_conditional_access will have the latest until the official Jamf Connect docs get updated.
Updated 14JUL2022 - The github link below has been updated with some steps removed for version 2.13 or greater of Jamf Connect, details about custom ROPG scopes in the menu bar, notes on how the login may still show a failure after doing this but that's fine. https://www.jamf.com/blog/how-to-azure-conditional-access-and-jamf-connect/ will supersede instructions currently on the Jamf Blog.
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.
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.
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.
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.
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.
Several Conditional Access Grant policies can create unacceptable behavior to access a client 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.
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.
Posted on 05-27-2021 08:06 AM
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."
Posted on 12-10-2021 01:39 PM
Hopefully these new instructions with a custom scope will help.
Posted on 10-18-2021 07:21 AM
Any updates to this? Still looking for a solution.
Posted on 10-25-2021 07:14 PM
also looking for a solution. does JAMF Connect even support Azure MFA/conditional access?
Posted on 10-26-2021 08:26 AM
Posted on 12-10-2021 01:39 PM
Updated information - through further research, determined that "openid" scope was what gets triggered by an "All cloud apps" CA definition. Workaround posted.
Posted on 01-14-2022 11:00 AM
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.
01-14-2022 11:06 AM - edited 03-15-2022 07:56 AM
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.
Posted on 01-14-2022 02:33 PM
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.
Posted on 01-14-2022 02:36 PM
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.
Posted on 03-15-2022 07:29 AM
The link appears to be broken!
Posted on 03-15-2022 07:57 AM
Links updated. I changed the name of the pdf.
Posted on 01-14-2022 02:48 PM
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">
<string>[YOUR PUBLIC APPLICATION UUID STRING HERE]</string>
<string>https://login.microsoftonline.com/[YOUR TENANT UUID STRING HERE]/v2.0/.well-known/openid-configuration</string>
<string>[YOUR PUBLIC APPLICATION UUID STRING HERE]</string>
<string>api://[YOUR RANDOMLY GENERATED API IDENTIFIER HERE]/jamfconnect+openid+profile+email</string>
<string>[YOUR TENANT UUID STRING HERE]</string>
<string>https://login.microsoftonline.com/[YOUR TENANT UUID STRING HERE]/.well-known/openid-configuration</string>
<string>[YOUR TENANT UUID STRING HERE]</string>
Posted on 03-08-2023 02:52 PM
I do not see the ROPG Scopes key in this example and when trying to add it in JC Configurator, I get a invalid keys error and it removes them.
Posted on 04-13-2022 02:11 AM
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.
Posted on 04-13-2022 07:29 AM
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.
Posted on 04-13-2022 07:34 AM
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.
Posted on 04-13-2022 07:40 AM
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.
04-13-2022 07:50 AM - edited 04-13-2022 07:51 AM
Oh yes, and this is what I did. Some organisations are a bit stubborn and refusing any app that does not have MFA...
Posted on 05-26-2022 11:56 AM
When I attempt to test the ROPG login with the Jamf Connect Configuration application, it displays the error AADSTS900144: The request body must contain the following parameter: 'resource'. Fortunately, the OIDC test is working great with MFA. I have yet to test in an actual install.
I'm not sure if I'm missing a step during this setup or if I have something misconfigured. I'd appreciate any help with this. Thanks!
Posted on 05-26-2022 03:27 PM
Try removing the
key from your setup. I have a feeling you're running a version before 2.12 where ROPG was redesigned to detect if it was on the V1 or the V2 endpoint.
Posted on 05-27-2022 05:39 AM
Removing the ROPGDiscoveryURL still provides the same error message. I am running Jamf Connect Configuration version 2.12.
Posted on 05-27-2022 05:51 AM
I would like to add it seems the ROPG test is attempting to send the request to https://login.microsoftonline.com/[tenantid]/oauth2/token
Posted on 05-27-2022 08:03 AM
Because it contains personal information, you'll want to contact email@example.com with a copy of the com.jamf.connect.login and com.jamf.connect config profiles so we can see what is wrong with the config.
Posted on 07-14-2022 08:26 AM
In regards to the following:
(H3) Step Four: Remove any Conditional Access policies applied to All cloud apps Navigate to
portal.azure.com → Azure Conditional Access. Examine any application applied to the scope of “All
cloud apps”. Either set “Enable policy” to “Oﬀ” for any application that has a Grant of “Require
multi-factor authentication” or modify the “Cloud apps or actions” to specifically list resources
that should have MFA applied.Applying a policy to require MFA for “All cloud apps” will cause the ROPG application in the next
step to inaccurately show failed logins in the Azure sign-in
Rather than modify "All cloud apps" to include all apps except Jamf, can Jamf just be added as an exclusion to existing CA's that require MFA? Would it just be "Jamf Connect - Conditional Access Policy API" that needs to be excluded?
Posted on 07-14-2022 11:10 AM
Wondering this as well.
Posted on 07-14-2022 02:23 PM
Yes, you can definitely do that. And correct, the "private" app registration will be the app you want to add to the "Exclude" list in the Conditional Access policy.
Posted on 09-12-2022 01:24 PM
Anyone seeing an "AADSTS500113: No reply address is registered for the application"? I walked thru all of the steps and still get this. We are using Duo for MFA and it works, but gives this error after.
Posted on 09-12-2022 02:25 PM
Never mind, figured it out. Had to add https://127.0.0.1/jamfconnect to the Conditional Access app registration. Now it works fine.
Posted on 09-13-2022 10:37 AM
So to be clear - this will result in the following?
Jamf Connect logging failures in Azure with the 50076 sign in error code, even when the MFA has prompted and been accepted by the Mac? Is there a way to have the 50076 errors in Azure show as successes instead of failures?
We're worried about the constant failures resulting in the triggering of a block out for the user.
We're on 2.14 and have configured things to spec per the instructions and the chat here. Just want to make sure I can properly communicate what's occurring back to the powers that be. Or if we need to tweak something - that we do so. Thanks in advance for any input.
Posted on 09-14-2022 09:16 AM
The error isn't really an error - it's just an interrupted login. By the time the user needs to MFA in the password check to get an access token, Jamf Connect already knows the password is right.
If we think of the menu bar agent as the thing that checks the local client password against the cloud password, we don't really need the full access/ID/refresh tokens that would be sent down to the client if the user actually did the MFA. JC would look at that and say, "Thanks, but..." and then pitch those into the bit bucket anyway. JC got what it needed - was the password right? If you're prompting for MFA, then the password HAD to be right.
What the "complex but exacting" method of setting up two apps does will exclude the "public" endpoint, the one that does ROPG, from needing MFA at all. This will eliminate the 50076 errors. When the user is doing an interactive login (aka logging into the Mac, seeing the Azure login web page) then they'll be prompted for MFA because the scope requests access to a resource that needs MFA.
It's confusing, but it eliminates the errors in the logs.