Hi all,
ADFS… one of those things…
As there is an ongoing discussion about the matter on my Upgrade to Jamf Connect 2.0 post, I had to test some things. I did not have time to do so prior to this discussion, but it was obviously on my to do list.
Quick summary of the discussion:
Some admins are seeing the following error when trying to validate the password in the Jamf Connect Menu Bar App:
First of all I’d like to mention that you get the similar error when you enter the wrong password, but obviously that was ruled out. So what happened?
Note: The exact error message is important. Here “Optional(400)” which refers to “bad syntax”. Similar errors mentioning JCAError 15 with different optional error number do exist, e.g. “Optional(403)” (which refers to “Forbidden”). In this post I focussed on the error 400 which was mainly due to the plist config. 403 would typically be Firewall or app permissions.
When I tested, I did indeed initially replicate the issue. I created the config profiles (or actually the plists) via the JC Configuration tool, and yes, I got the error. Next I started manually editing the plist, copy pasting keys from the manual, and even worse, creating a Frankenstein plist with the old structure from JC V1.x, wrong copy pasted snippets, missing key, etc… obviously getting the self-induced error again by loosing track of what I was actually doing.
Note: I blame the lack of caffeine, as it was early morning and those who follow this blog since some time know: I normally do my additional outside-working-hours testing and blogging at night. Much better with some energy drink:
ERROR 404: name of sponsored caffeinated energy drink not found. Contact me if you want to fix this :-)However, while getting the error in the real menu bar app,… both my OIDC and ROPG tests in the Configuration tool where successful ¯\_(ツ)_/¯. So I discussed it with other people and got the dreaded answer: “It works fine for me”. So what was wrong?
Well, as this blog is not the place to challenge official documentation, or discuss product issues, I’d advise you to contact Jamf Support if you are getting the error 15 mentioned above.
That said however, I identified some issues, but not with the Jamf Connect Login of Menu Bar app as such. I do confirm that both do indeed work for me with my ADFS federated Azure tenant! The only thing I’d like to advise (apart from contacting support), is to manually check your .plist again and compare it with the one I’m going to share here below.
Also, one additional thing which has tricked me a few times in the past is that, if you are using a .plist file, do not upload a new version over an old plist within an existing payload. With this I mean that, when you upload a .plist, you typically go into the Application and Custom Settings payload to do so. But when you make changes to an existing config profile, you may be tempted to just edit the profile, hit that upload plist button again, save the profile and select “Distribute to all”. However, like I said, this has tricked me into losing very precious time in the past. It’s not really clear to me why or how, but I have been in multiple situations where this actually caused the settings of the domain you are configuring to not correctly update to the new settings.
So, whenever you are updating a plist in a profile, I’d recommend to:
- Delete the Application and Custom Settings payload from the profile
- Add the payload again
- Upload the new plist
- and obviously check if the domain is correct after uploading the plist as it, by default, takes the filename as domain…
One final thing before I dive into the actual example configuration for ADFS is that, even with replacing the payload as per above, with a correct plist, I still ran into the same error again. At that moment it was time for a quick break, walk away from the Mac to avoid any accidental damage, calm down, and try again doing the following:
- Close Jamf Connect Menu bar app
- Unscope the profile and save it
- Manually verify the profile was pulled from the Mac
- Launch Jamf Connect Menu bar app again to confirm it is not configured
- Scope the profile with the now corrected settings again
- Magic -> all good!
Now, so far for the small talk, let’s have a look at my working plists!
Jamf Connect Login:
Jamf Connect Meny Bar App:
Both plists can be downloaded here below:
So, let’s spin it up for a quick run! Let’s start with sharing my Azure AD Connect settings to show you that:
- My Azure AD is FEDERATED
- PHS is disabled!
NOTE: I've tested it with BOTH pure federation (no PHS) and federation + PHS. Also, when testing federation+phs I made sure that the AllowCloudPasswordValidation was DISABLED.
First the login screen:
Next my federation kicks in:
And finally the ROPG password validation:
And without any problem I was presented with the rest of the account config and ended up at the desktop.
Jamf Connect Menu bar app next:
As I did not configure any keys to force the sign-in, I clicked ‘Connect’…
Oops… error:
Well, this was actually before I change my plist (and unscoped/redeployed it as explained above), because the settings still showed me “Azure” as provider:
Fixed that as per above:
Tried again -> All GOOD!
Next I changed the password of this account in my AD, and Jamf Connect immediately noticed it:
And… euh… what? Ah ok, it’s getting late… I entered the wrong local password 🙂
Tried again, with the correct current local password this time -> ALL GOOD!
And finally as a quick bonus: Kerberos! Quick change of my DNS settings to allow DC discovery and Jamf Connect immediately gave me my Kerberos ticket!
So the three-headed hound is happy too!
This all brings me to the worst thing a support engineer can say, but I’m still gonna do it: It all works fine for me!
Don’t hesitate to reach out if it doesn’t work for you, but remember, you do have an entire Jamf Support team at your service for this kind of things!
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
Apple ecosystem enthusiast, geek, tech gadget freak, Belgian living in the Netherlands
Enterprise Support Engineer II | Jamf
Great post!, this has helped me out a lot!
This is solid information. One note — if you make a mistake (like the password thing where you knew you put in a new password)… there is no need to talk about that. It disrupts the flow of your investigation and makes things very hard to read. I had to go over this three times to figure out why that was included. I love the personality of all this, but reading is another matter altogether. Keep focus and keep your flow. You made a cool discovery — keep it tight.
Thanks for the feedback Talo! Appreciate it!
„ do not upload a new version over an old plist within an existing payload.“
Same Issue here. Settings tested in Dev. Uploaded the same plist in Prod, it shows exactly the correct settings and values, but wont apply them. This is extremely annoying.
Hey Remi, yes, I’ll dive into that further. Thanks for confirming. However, I’ve seen this with other plists as well (not only Jamf Connect). So might be something in macOS.
Extremely helpful, thank you. We have PHS enabled, Federation disabled, and we are still getting the same error in our Azure Hybrid setup. Would this just be as simple as changing our settings to Federated?
(If not, here is context)….
For our setup, I have had to do a number of manual things to get JC to work properly. The most recent thing I had manually push down a krb5.conf file to our users /etc folder specifying the default realm (though this seems to be more of a Catalina/kerberos battle vs. Jamf issue).
Before I pushed this the krb5.conf file down though, that is now specifying the default realm, users were previously receiving an error thrown the JC Menu bar app stating “Configuration file does not specify default realm.” The krb5.conf solution fixed this error but also seemed to create a new error as we are now starting to see the JCAError 15 error come up.
Hi Andrew, I would avoid going into federated mode, this would complicate things further and probably even break other integrations.
We’ll need to review the exact setup in Azure, the plists and the logs.
I’d submit all those to support in order to understand the exact reason.
Very useful thanks for the details.
I have a concern and when user changed the password from IDP url ( not jamf connect menu ) will jamf connect give popup for password not match and update new password ? and if restart the mac and reset the password from Jamf connect login will that sync with keychain and allow user to login into mac and sync with keychain ?
Hi Balaji! If you change the password in iDP while a user is logged in and using the Mac, the menu bar app will alert the user that the local password does not match iDP indeed. This via the background check Jamf connect does. The way it does that is by reading the stored iDP password in keychain and test it against iDP again via ROPG. If that does not match it will alert the user.
If the user change the local account password, the same will happen. The keychain password will match iDP but the background local password check will fail. User will be asked for the current local password and Jamf Connect will put it back to what the password is in iDP.
A restart is more problematic, depending if FileVault is enabled or not. When FileVault is enabled the user always needs to unlock FV with the current FV password which should be in sync with the local password. If however the iDP password was changed, and not synced to the local password yet, a reboot will still require the “old” local password to unlock FV. Not the reset iDP password.
Next it will depend if DenyLocal sync is enabled or not. If not unlocking FV will always bypass Jamf Connect after unlocking FV (except on M1 but that is another discussion). If denylocal auth or automatic fv login is disabled, unlocking FC will not pass the credentials to the login window, and the user will need to login via Jamf Connect again.
Logging in via Jamf Connect requires the current iDP password, which will then sync to the local password and if needed ask the local password again to sync it back to iDP password. This will indeed also update the keychain if you have the create Jamf Connect keychain key enabled.
https://travellingtechguy.blog/understanding-the-macos-authentication-flow-with-filevault-and-or-jamf-connect/