Hey all,

As I’ve recently been getting quite some questions on Jamf Connect and Conditional Access, I’d like to clarify a few things.

To keep things simple, I’ll keep it very short and only highlight what matters.

First of all, there is this blog post: https://www.jamf.com/blog/how-to-azure-conditional-access-and-jamf-connect/. All good, and the basics to tackle some roadblocks are in there, but – and all credits to Sean and the extensive work he has done to figure all this out – there are a few things which changed recently. Therefore, due to changed endpoint behaviour, please follow the updated Github page to the letter to achieve the goals described: https://github.com/jamf/jamfconnect/tree/main/azure_conditional_access

And with to the letter I really mean to follow every single step exactly as described.

Important is for instance not to create the Jamf Connect app as ‘web’ app instead of the documented ‘Public Client/Native” (Mobile and Desktop) type (EXCEPT when doing so exactly as in Sean’s workflow of course) I know, setting it to ‘web’ allows you to put it in exclusion for Conditional Access Policies etc… in an attempt to exclude the Jamf Connect flow from hitting a CAP set to ‘All Cloud Apps”, but that is NOT how the workaround is documented. Nor will it work.

Now, the main thing I want to highlight here is the discussion on ‘All Cloud Apps’ as scope for the CAPs.

As long as you have 1 policy set to ‘All Cloud Apps’, you will ALWAYS trigger errors in the Azure sign in logs when Jamf Connect is doing an ROPG call to validate or sync the password.

There is NO workaround for that because of the way Azure AD Conditional Access behaves when there is an ‘All Cloud Apps’ CAP configured. Even misconfiguring the Jamf Connect app, and adding it as exclusion to any ‘All Cloud Apps’ CAP, will NOT solve that.

This is the first thing I wanted to be clear on here: if you want to REDUCE the errors in the Azure Sign In logs for Jamf Connect ROPG calls, you MUST remove all CAP’s set to ‘All Cloud Apps’ and/or define those specific for the apps you do want to trigger.

Now, as you saw, I said REDUCE the errors, and not ‘get rid of all errors’. Why? Because this is currently NOT possible.

To elaborate this, let’s have a look at what is discussed in the workflow on the Github page. When you do follow the workflow, you should reach a point where you have created a custom scope, and as documented, this scope needs to be set in the settings of Jamf Connect. It should look like: 

api://3b56609e-aaaa-bbbb-cccc-f6b1e6cbf191/jamfconnect+openid+profile+email

This is the scope we then set in the configuration profile / plist for Jamf Connect LOGIN:

If you did the workflow from the Github page correctly, the above settings should allow you to trigger MFA at the OIDC login page, and successfully authenticate with ROPG as well with same configuration.

HOWEVER, the problem is that using the same scope for both OIDC as ROPG, WILL result in logging an error in Azure AD Sign In logs. The ROPG will work, but it will log an error.

For this, as per current JC design and Azure behaviour, there is unfortunately no way to avoid this. Logins will always trigger a succesfull MFA auth on OIDC but log an error on the ROPG call of Jamf Connect Login.

So why do all the work of this custom workflow if we still get errors? Well, because those errors will be limited to logins through the login window ONLY.

The bigger problem is Jamf Connect Menu bar however, which syncs the password on a regular interval in the background, and hence, by lack of this custom workflow, triggers a lot more spamming errors in the Azure AD sign in logs.

The good news here is that as per above workflow, if we then configure Jamf Connect Menu Bar without defining a special or custom scope, or put the default openid+profile+email for that matter… all will work fine without any errors in the Azure sign in logs!

To test ROPG, duplicate the config and change the scope to openid+profile+email:

Long story short:

  • If you want MFA at the OIDC login window you can not totally get rid of the ROPG MFA errors in the Azure Sign In logs
  • You can reduce the amount of errors by applying the discussed workflow and setup
  • And you MUST remove ALL CAP’s set to ‘All Cloud Apps’ for this to work.

I hope this clarifies the confusion I’ve seen in a lot of discussions lately!

That’s it! As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!

Brgds,
TTG