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’…
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!