Hi all!
As Jamf Connect 2.0 has been released, I want to go through updating (or installing), the new release. I’ll be using the Jamf Connect app which I already have configured in Azure, so please review the Jamf Connect documentation on how to configure this, or one of my previous blogposts on the matter.
So for this post, let’s go through the following topics:
What changed?
Release notes: https://docs.jamf.com/jamf-connect/administrator-guide/Release_History.html
First of all the most important change is the fact that both Jamf Connect Sync and Verify have been merged into one app, called Jamf Connect (aka the menu bar app)
Apart from that, Jamf Connect Login and Jamf Connect have been merged into one installer package.
This means that the Jamf Connect 2.0.0 package installs the following components on computers:
Some important changes:
- The browser extensions have been discontinued
- A new app icon for the menu bar app (Jamf Connect)
- Network Selection: The “Allow Network Selection” button has been replaced with a WiFi icon in the upper-right corner of the login window
- Local Login: The “Local Auth” button is now named “Local Login” and appears along the bottom of the login window.
- Error Messaging: Some error messages have been improved to help users troubleshoot configuration issues.
- Custom Login Window Message: You can now add a custom message to the login window by configuring the LoginWindowMessage preference key.
- Authchanger improvements: The commands arguments executed by the authchanger tool can now be read from a configuration profile. The Jamf Connect installer does not add any arguments to authchanger by default. More about the different methods to change the login window below.
- Licenses: The Jamf Connect menu bar app will now check both the com.jamf.connect and com.jamf.connect.login preference domains for a valid license.
- Menu bar launchAgent: A launch agent for the Jamf Connect menu bar is included as a separate installer package in the Jamf Connect DMG. When installed on computers, the launch agent will ensure that Jamf Connect remains open.
Note: Jamf may collect hashed data about license usage. This data is used to monitor the number of licenses in use with Jamf Connect in your organization and does not include any Personal Information.
Changes to the Preference Domains and Keys
Renamed Preference Domains
The Jamf Connect menu bar app is configured using a single preference domain:
com.jamf.connect
The com.jamf.connect.sync and com.jamf.connect.verify have been discontinued.
Note: Login window preferences will continue to be written to the following domain: com.jamf.connect.login
Renamed Preference Keys
Please check the following link for an overview of all the changed/renamed preference keys (see below for example configuration profiles): https://docs.jamf.com/jamf-connect/administrator-guide/Release_History.html
Additional Changes
- Custom URL scheme, see Jamf Connect URL Scheme. Administrators can perform actions with Jamf Connect using the command line.
- The CreateJamfConnectPassword key in Jamf Connect Login allows Jamf Connect to automatically populate the Sign In window in the menu bar app with a user’s network username and password that was used to log in or create a new local account with Jamf Connect. This setting is enabled by default and replaces the Create Jamf Connect Sync Keychain (CreateSyncPasswords) and Jamf Connect Verify Keychain (CreateVerifyPasswords) settings used in Jamf Connect 1.19.2 or earlier.
- The Jamf Connect loginwindow mechanism that enables FileVault now only runs if the Enable FileVault (EnableFDE) setting is enabled in the Jamf Connect login window configuration profile.
- The Retrieve Kerberos Tickets During Sign-in (GetTicketsAtSignIn) setting has been removed from the menu bar app. Jamf Connect now automatically retrieves Kerberos tickets for users if a Kerberos realm is configured with the Kerberos Realm (Realm) setting.
And last but not least, the design of the Login Window also changed. This gives you more control on branding the deployment and make the Jamf Connect Login Window feel a bit more familiar to the end users. Apart from a more modern UX for the login window itself, background image changes and a new Wifi symbol, the login window will now also include a progress bar allowing user to better understand what is going on when authenticating to their Macs. The login window can now show progress as: Authenticate -> Connect -> Verify.
Preparing the upgrade
As a good practise, starting with reading the official documentation is aways a good first thing to do: Upgrading to Jamf Connect 2.0
Once that’s done, let’s assume I have Jamf Connect installed on my Macs and I want to upgrade, what do I need to do?
- Customise the Jamf Connect installer package (optional, but needed for instance if you want to add custom logos and background images)
- Create a new configuration profile for Jamf Connect Login
- Create a new configuration profile for Jamf Connect (menu bar app)
- Configure the authchanger
- Create a smart group to remove the old configuration and push the new one
Customise the Jamf Connect installer package (optional, but needed for instance if you want to add custom logos and background images)
For a standard deployment test I could just take the Jamf-provided JamfConnect.pkg to install it. However, in view of the changes made to the login window interface, I’d like to test the custom backgrounds and logos as well. Yes, you could package those up into a separate package and deploy both, up to you. I’ll go for one custom package here. I want to have a look at the change in the installer anyway.
The change I’m referring to here is the fact that “The Jamf Connect installer does not add any arguments to authchanger by default“. Let’s check that by having a look at the postinstall script of the new Jamf Connect installer:
As you can see, there is no authchanger command added to this postinstall script, compared to previous Jamf Connect 1.x version:
If you want you can add this authchanger commands back into the post-install script, as per commented commands in the screenshot below. More about the authchanger below in this post.
I my example above I’m not configuring the authchanger (commented), I’m only telling the postinstall script to install the official Jamf Connect installer, which I deploy into the /tmp folder via the package content. This along with some custom images:
Now, apart from exporting the pkg, don’t forget to sign it with a publicly trusted code-signing cert, or the Jamf Pro built in CA, if you want to use the package in prestages for Automated MDM enrolment!
Via Composer:
Or via Terminal:
productsign --sign "[Signing Certificate]" ~/Desktop/example.pkg ~/Desktop/signed-example.pkgCreate a new configuration profile for Jamf Connect Login
With our custom package created and uploaded to our distribution point, let’s now have a look at the configuration profiles. My preferred way of doing this so far was to write my own plist. This is view of keeping the overview of all the keys which I want to configure.
However, the new Jamf Configuration tool now includes an XML editor which you can use to check the plist on the go when adding values to the keys you want to configure. Love it!
So, let’s start adding some keys to this. In view of the purpose of this post, testing out the new Jamf Connect 2.0, I’ll keep the configuration quite basic. Additional keys can be added depending your deployment scenario. I’m using Azure for this post (ok, my Azure is linked to my on-prem AD, but I have ADFS federation disabled and password hash sync enabled so my config will be a simple walk in the park).
- Set the Identity Provider to Azure
- Add the Client ID for the Jamf Connect app which I have in Azure
On the Login tab I set my Admin role (to force Jamf Connect to create accounts with admin privileges for those iDP account which have the ‘Admin’ role assigned in the Azure Jamf Connect App: see https://docs.jamf.com/jamf-connect/administrator-guide/User_Roles_for_Local_Accounts.html)
(Note: You could also check the 'Create Jamf Connect keychain' option to pre-populate the user info in the menu bar app, but Jamf Connect 2.0 actually enables that by default).
As I have PHS enabled (Federation disabled) I do not set anything in the Hybrid secion:
And finally, I allow the network selection, set a Login Window Message and add the path to the custom background and logo (see the package I created above):
That’s it for the Jamf Connect Login config, which we can now check in the plist:
Create a new configuration profile for Jamf Connect (menu bar app)
Now for Jamf Connect, aka ‘menu bar app’, I’ll keep things simple here as well.
The ‘ROPG Client ID‘ should already be filled in automatically:
For the fun of it, I’m adding my Kerberos Realm:
Next, I selected Automatic Sign-in and Require Sign-in (this to use the keychain to automatically log in, and enforce the sign-in window to stay open until the user successfully authenticates). I also defined the Sign In Logo, which I set to the same logo as the one for Jamf Connect Login. The pixel size is probably not optimal, but let’s see how it turns out.
This gives us the following plist:
With both plist configured, I can now hit the test button in the top right corner and test both OIDC and ROPG:
That looks good, so let’s export the plists. Is stick with .plist as I like to make changes directly to the file when needed. Don’t forget to save both plist as com.jamf.connect.login.plist and com.jamf.connect.plist.
Configure the authchanger
Instead of running the authchanger commands by default via the postinstall script, Jamf Connect Login 2.0 will now instead look at the following order of configuration sources to configure the Login Window:
- Commands executed via the command-line. This either manually in Terminal or via a Jamf Pro policy with a script or the Files & Processes payload. Consider the following scenarios:
- If a command is executed with arguments, any preferences found in a configuration profile will be ignored.
- If a command is executed without arguments, Jamf Connect will look for preferences in a configuration profile.
- Preferences found in a configuration profile written to com.jamf.connect.authchanger
- The Identity Provider (OIDCProvider) or Auth Server (AutherServer) preferences written to the com.jamf.connect.login domain. These pass the -JamfConnect argument to automatically enable OpenID Connect or Okta authentication.
- If no arguments or preferences are found, the default loginwindow mechanisms will remain unchanged
Hereby a quick example of a plist to set the com.jamf.connect.authchanger domain:
<?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>Arguments</key>
<array>
<string>-reset</string>
<string>-jamfconnect</string>
</array>
</dict>
</plist>More information about advanced authchanger configuration can be found here: https://docs.jamf.com/jamf-connect/administrator-guide/authchanger.html
I my test here I did not change anything to the authchanger (nothing in the postinstall script, no additional profile, no Terminal commands or Jamf Pro policy script), so it should enable the Jamf Connect Login Window via the OIDCProvider key in my plist.
Create a smart group to remove the old configuration and push the new one
As we are aiming to replace to old configuration of Jamf Connect v1.x, by configuration profiles for 2.0, we’ll use the following Smart Group to achieve this. This will be set as the target scope for the v2.0 config profiles, and as exclusion in the v1.0 profiles.
Deploying the upgrade
With our custom package and plists created, let’s now put this all together into Jamf Pro:
- Create a policy to update Jamf Connect for all required devices
- Upload the new configuration profiles and scope them to the v2.0 Smart Group
- Remove the old configuration profiles by putting the v2.0 Smart Group into exclusion
Create a policy to update Jamf Connect for all required devices
First thing we’ll do is creating a policy to install Jamf Connect 2.0. Upload the installer (and the LaunchAgent) to your distribution point, and create a policy to install them. Make sure to add an inventory update to make sure our v2.0 Smart Group is going to be updated. Scope this policy according to your deployment strategy for devices which are using Jamf Connect, for instance, a specific Computer Group, a Smart Group, or All Computers with the v2.0 Smart Group we created as exclusion. Once per computer.
In Jamf Connect Verify, there was a launchAgent installed by default which forced the app to open after login. In v2.0, the Jamf Connect installer does not include the launchAgent by default. Hence this needs to be deployed separately. I added it to the Jamf Connect installation policy (optional).
The launchAgent installer can be found in the Resources folder of the Jamf Connect DMG. Just upload it to your distribution point and deploy it with a policy.
Upload the new configuration profiles and scope them to the v2.0 Smart Group
As mentioned before, I prefer the .plist method for various reasons. The most important one is that I use the configuration tool to quickly give me the initial plist structure, and later on I add additional keys where needed via my favourite text editor (for testing or configuring additional features).
Remove the old configuration profiles by putting the v2.0 Smart Group into exclusion
Testing the upgrade
Run your policy to install Jamf Connect 2.0. This will:
- Install Jamf Connect 2.0
- Install Jamf Connect Login 2.0
- Install the LaunchAgent (optional)
- Remove Jamf Connect Sync and Jamf Connect Verify apps
- Stop and remove Jamf Connect Sync and Jamf Connect Verify launch agents.
- Any associated installer receipts will be removed from the installer system.
Next your v2.0 Smart Group will be updated and:
- Push out the v2.0 configuration profiles for Jamf Connect and Jamf Connect Login 2.0
- Pull the v1.x configuration profiles from the system
The result:
Our policy runs:
Jamf Connect Verify is replaced by Jamf Connect (menu bar app):
Our v2.0 Smart Group is updated (disregard the duplicate Macs, it’s my physical Mac and its alter-ego VM version):
Our old profiles are removed and replaced by the v2.0 versions:
And we have our new Login Window:
After logging in via Jamf Connect Login, which by default creates a keychain for Jamf Connect, the LauchAgent kicks in and automatically authenticates me. Including the generation of a Kerberos Ticket.
Installing a fresh 2.0
Well, not sure why I added this as a separate topic, because it’s basically the same as everything above, except the part of putting the the v2.0 Smart Group as exception on the (non-existing) v1.x configuration profiles:
- Create a custom package with backgrounds, wallpapers, authchanger postinstall settings, … (optional)
- Upload the installer and the LaunchAgent to your distribution point
- Deploy the installers via a policy or prestage package (for prestage: sign the package and use a Cloud / HTTPS distribution point!)
- Create a Jamf Connect Login 2.0 and Jamf Connect 2.0 plist
- Upload the plists to Jamf and scope them according to your deployment strategy
- Reconfigure the authchanger (where needed)
That’s basically it! Yes, there are so many other features you can enable in Jamf Connect, but elaborating any of them any further would take this long post again way too far. Don’t hesistate to reach out to me if you have any questions!
My conclusion? I love Jamf Connect 2.0! Really, you know me, I advocate free speech. If I did not like it, I would say so, or maybe just not blog about it and pretend it does not exist :-). To me Jamf Connect 2.0 really feels solid, easy to deploy and overall less confusing compared to V1.x. Mainly thanks to the renewed configuration/plist key logic.
That’s it for now! As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!
If I missed something, or you see different behaviour to what I discussed above, let me know!
Brgds,
TTG
Apple ecosystem enthusiast, geek, tech gadget freak, Belgian living in the Netherlands
Enterprise Support Engineer II | Jamf
Hey, brilliant guide! Many thanks.. have you seen in your testing a scenario where it will only work when upgrading from v1? Sure I am missing something.. if I upgrade to v1 to v2 using the above guide, it works great. If I do a fresh install of v2 with same plists, I either don’t get the Jamf connect login window for azure, or sometimes it does show and after verifying password, the screen just goes grey with a mouse pointer. Mostly though, he login window doesn’t show up, just the FileVault login. I haven’t added anything to to authchanger, just basic setup as above. Any idea what’s going on here?
Hi, the grey login window is something requiring a deeper dive into the logs and setup (both plist and iDP app). FileVault however sounds like expected. If FileVault is enabled, default behaviour is to skip JC Login Window. Just like it skips the native login window: https://travellingtechguy.blog/understanding-the-macos-authentication-flow-with-filevault-and-or-jamf-connect/
great update
2 questions
I ( and also some other as I can see on slack etc) are expierencing issues when doing dep enrollment with Jamf connect. Instead of showing jamf connect window it just goes to normal account creation. If I wipe the machine, it may work next time and other times I have to do it more times, so seems very random that the jamf connect package kicks in. Is that a known issue ?
2. When changing the password in jamf connect it launches a webinterface. It is possible to set window size on browser there. On old version users have manually to rezise window to enter old and new password – not very user friendly
Hi!
For issue 1:
What type of distribution point are you using? And is Jamf Connect actually installed when it shows the native login window? You can check by logging in with your managed admin and see if the menu bar JC app is installed.
Are you using a custom package or a Jamf provided one?
If using the default package and JC is installed correctly, the fact that it shows the native macos login window is probably because the authchanger did not run.
As mentioned in the blog, 2.0 does not manually run a command to do so. It looks for config profile. So how did you configure the profile? Added to the prestage? Scoped correctly?
If the profile is added in prestage but not scoped correctly it may install and later be removed at end of enrolment before reaching the login window. Hence JC has no trigger to show the JC login window.
Or the profile installation was delayed for some reason, and you hit the login window before it installed… scoped via smart group by any chance?
For Q2, no keys to change the window to my knowledge unfortunately
Actually I used a custom package that you created in a old blog on your page that I followed. But I could actually try just to add the default package from jamf and config profile. I scope it to “all computers”
My only concern is that I only want the JCL login window to happen in pre-stage enrollment and not during normal login. If I apply the config profile to all computers I guess it will then give issues or ?
If you created a custom package, the reason it skipped installation can be a problem with then package. Did you sign it correctly? Are you using a Cloud Distribution point (I think there is a problem with HTTPS distribution points and prestage).
But you’d have to check if the issue is:
– package did not install
– or login window was not flipped to JC
I am using jamf Cloud and it is signed correctly the package.
If I scope the config profile to all computers in pre-stage should that be enough – or should the config profile also be scoped out-side the pre-stage, as again I don´t want the JCL window to appear after the mac has enrolled
No, if you add the configuration profile to a prestage without scoping it correctly to your computers, the following will happen:
– Before the Setup Assistant kicks in, the prestage is installing the profile.
– Next the Setup Assistant continues, and Jamf Pro is starting calculations on the scoping of all your profiles and policies
– Because the computer is not in the scope of the profile, Jamf Pro removes the profile again
– You reach the end of the Setup Assistant and the login window is triggered, but because there is no profile to tell JC 2.0 to flip the login window (because the profile was installed and removed by lack of scope) you get the native macos window
So you need to be sure to have the computer which is enrolling in the scope of the profile itself.
If you want to disable JCL after enrolment, you will need to disable the JC Login window later: https://docs.jamf.com/jamf-connect/2.0.0/administrator-guide/authchanger.html
This preferably by pushing another profile setting the com.jamf.connect.authchanger domain or command line
OK thansk – last question. Today none of the computers have jamf connect installed. So if I scope the new profile to all computers, will they have issues logging in, as I understand that the config profile change the auth to jamf connect
If JCL is configured correctly they should not have an issue logging in, you could just add the migrate key to migrate them to a JC linked account.
But if that is not what you want, then make a smart group linked to the prestage you are using and set that as scope for he profile. Then add a logic with command line or authchanger profile to reset JCL to native login window at the end of the enrolment
Sorry – I am not sure I understand or we are talking about something different
Today all our clients that already are enrolled is working without the JCL window and not jamf connect installed.
So If I add the new config profile for JCL 2.0 and push to all clients that are running, will that change it to JCL login window, which then will give issues as jamf conncet is not installed
No because the profile will do nothing. It changes the authhanger which is installed with Jamf Connect. If the authchanger is not installed, the profile does nothing. The authchanger is a Jamf Connect binary, not a built in macOS thing.
Arh ok – that was the mainpoint. Actually thought that authchanger was a binary in OS
thanks:)
I did a comment earlier I cannot see ..??
But can just add, I tried to login with the management account and afterwards depotify kicks in with the enrollment –strange ?
Org Tex for com.jamf.connect.authchanger
Arguments
-reset
-jamfconnect
Shouldn’t it be?
Arguments
-reset
-jamfconnect
Hi James, what am I missing? What is the difference?
Hi James, now I found what you ment. Typo in the key / string attributes! Corrected. Sorry the blog did not show < > characters in your comment.
I also only want only jamf connect window at pre-stage and not afterwards
But as also noticed in earlier post, you will have to scope the JCL config profile to both in pre-stage and in generel to all clients
But even I in my depnotify script at the end of pre-stage do a reset of the auth, the config profile will still overwrite it back as far I know config profiles work
So the only solution should be to do a trigger and remove the clients from the smart group the config profile is assigned to after pre-stage?
No, the authchanger is designed to give priority to instructions set by command line: https://docs.jamf.com/jamf-connect/2.0.0/administrator-guide/Release_History.html
Note: Jamf Connect will look for authchanger arguments in this order.
Commands executed via the command-line. Consider the following scenarios:
If a command is executed with arguments, any preferences found in a configuration profile will be ignored.
If a command is executed without arguments, Jamf Connect will look for preferences in a configuration profile.
Preferences found in a configuration profile written to com.jamf.connect.authchanger
The Identity Provider (OIDCProvider) or Auth Server (AutherServer) preferences written to the com.jamf.connect.login. These pass the -JamfConnect argument to automatically enable OpenID Connect or Okta authentication.
If no arguments or preferences are found, the default loginwindow mechanisms will remain unchanged.
So, flipping the login window back to native macOS by command line should take priority.
OK I see. So if I just push a config profile to all mac´s that are enrolled (smart group) it should be ok. Just getting a little panic if suddenly wrecking login screens
Looking at the jamf connect configurator, it does not seem to be able to reset the author, so have to make a config profile outside
Yes, good point. But I’m sure the dev team is constantly working on improvements and additional features.
One thing about everything discussed above: as always, always test before mass deploying. I’m doing the same but can’t always catch all edge cases. I try, time permitting.
Hi,
Thank you for the great guide! Have you tried this with ADFS? We have JCL 1.x set up and Jamf Connect Verify is configured to do a ROPG against ADFS. This is working as expected with Jamf Connect Verify, but with JCL 2.0 it results in the following error:
“Error from request to URL: https://adfs.domain.com/adfs/oauth2/token/, ERROR: The operation couldn’t be completed. (JCAuthentication.JCAError error 15.), STATUS: Optional(403)”
However, when doing a normal JCL login everything works. The error appears after you login and try to sign in using the Menu Bar App.
Hi Carl, I saw that error indeed. A colleague asked me about it. However I have not test ADFS myself yet. So I need to get used to new type of error messages and challenges like ADFS. Just to be sure, in JCL 2.0 you also have OIDCNewpassword set to false right (to confirm ROPG is really used in JCL?). I’ll switch my Azure to Federated again and test ADFS asap.
Yes, I can confirm that I do have the OIDCNewpassword set to false. I have also opened a ticket regarding this with Jamf, but have not heard back from them yet.
Same error here.. password sync actually seems to work but I get that error every time. Also logged with jamf
Hi I just refederated my Azure with ADFS and configured JC and JCL as a pure Azure config. No ADFS keys, no ADFS app or discovery URL.
I do have PHS enabled but now together with the user -sign in configured as Federation.
JCL: Auth against Azure in webApp, redirected to ADFS login window, additional window to do ROPG check. WORKS
JC: Authenticate with Azure account. WORKS.
Only problem, as stubborn as I am, I have this enabled:https://travellingtechguy.blog/jamf-connect-with-adfs-federation-and-allowcloudpasswordvalidation/
Works fine and allows me not to use any ADFS config in the plists.
Federation Enabled (so user sign-in is Federated)
PHS Enabled
AllowCloudPasswordVallidation Enabled
I will test again without CloudPasswordValidation
Ok, disabled AllowCloudPasswordValidation => Error 15 (and JCL fails)
But this is with a pure Azure PHS config for JC, which is not supported by Jamf.
So now, still with AllowCloudPassword Validation disabled, I’ll configure JC in the supported way with ADFS app and making it talk directly to ADFS for ROPG… Will keep you posted.
I have the correct keys set up (ROPGID and DiscoveryURL) but still getting the error 15.
Jamf responded that this seems to be a known issue (PI-008742)
Carl, sorry that’s not correct. I’d contact support again. It works fine for me after identifying the documentation typos with the key. As I did not test with ADFS before, and I copy pasted the keys from the manual… it had that issue. I can confirm I works fine with ADFS with the correct keys. I did however run into the same error as it seems my profile was not honoured by the menu bar app. Unscoped the profile, created a new one and it works.
UPDATE: Documentation issue.
This plist works. Note the following keys:
OIDCROPGID should be ROPGID
ROPGDiscoveryURL should be DiscoveryURL
Hi.. sorry, do you mean that plist works for you with AllowCloudPasswordValidation disabled? I am having this problem too with AAD phs, Error 15, Status Optional 400. Same using a plist of entering the details directly into Jamf Menu..
Tried entering as Custom with ROPG client id and secret, and also tried Azure with ROPG client id and secret. If I enter the discovery URL manually, as ‘https://login.microsoftonline.com/TENANTID/oauth2’ I see error ‘the data couldn’t be read because it isnt in the correct format’.
I feel I am getting a config wrong somewhere. Is the discovery URL required and am I using the correct url?
Hi Matt,
So, AllowCloudPasswordValidation is only when you configure JC against Azure. For both OIDC and ROPG. If enabled on the adfs server it allows Azure to validate the password via ropg against adfs. I’m still trying to find a Microsoft adfs guru to validate all consequences of enabling that…
But the official Jamf supported way of doing JC with adfs federated tenants is to configure JCL OIDC against Azure and JCL ROPG and the menu bar app directly against the adfs farm via an app in the adfs application group on the on prem server.
Do not try to do ROPG against Azure if the tenant is federated. It just does not work. Unless you have AllowCloudPasswordValidation enabled.
So for all ROPG actions in both login as menu bar app, you need to set the ropg provider to custom and define the discovery url. This should be the adfs server discovery url and can not be something with login.microsoft… it needs to be something like adfs.mydomain.com/adfs… your adfs discovery url. Ropg provider can not be Azure. Needs to be custom.
I’m planning to do a quick post with overview of my plists for adfs later today.
Thank, that would be really helpful, will read that when you do 🙂 We do have ADFS with Azure sso.
In our plist for V1 JCverify, we didn’t specify a discovery url, just client secret, OIDCprovider = Azure, OIDCropgid and tenant id, and it worked fine.
Yes doing the same in V2 doesn’t – well.. it actually does sync the password up fine in the menu, but always shows the error 15 first.
Ok just to understand your exact setup. If you go Azure -> Azure AD -> Azure AD Connect: you have Federation = enabled and above that PHS enabled too right? Like this:
Hey, thanks again..
Well, i was told by our azure team when i installed v1 we were adfs. this is what i see in azure ad connect
AD hybrid services. Learn more
PROVISION FROM ACTIVE DIRECTORY
Azure AD Connect cloud provisioning
This feature allows you to manage provisioning from the cloud.
Manage provisioning (Preview)
Azure AD Connect sync
Sync Status Enabled
Last Sync Less than 1 hour ago
Password Hash Sync Enabled
USER SIGN-IN
Federation Disabled 0 domains
Seamless single sign-on Enabled 1 domain
Pass-through authentication Enabled 5 agents
We have a hybrid aad setup
Ok you are not adfs federated. Sso ok but no federated. PTA/PHS instead. So for you there should be no need of doing anything with custom provider of adfs discoveryurl etc. For me (before I enabled federation again) the very basic plist with Azure as provider works just fine, but make sure to have the new plist structure with iDPsettings key etc. So I’d just try with the configuration tool and set it to Azure and test OIDC and ROPG.
Great, thanks again.
So recreated the plist, with idp settings, just azure, my ROPGID and tenant. tests fine in config tool with both OIDC and ROPG. saved plist and deployed to test macs.
changed AD password so mac local password and ad were different, waited for sync message.
When it showed, i got the jCAerror 15 status: optional (400) message. clicked ok, then if i type the wrong password i get the error back. if i type the right ad password, it syncs.
On another mac, with different local and ad password, if i dont use JClogin, and just deploy that menu plist – in menu, i click connect, enter username. if i type the wrong password i get the jCAerror 15 status: optional (400). if i type the right password it is fine and syncs.
So the error only shows when it detects the password it is using is not the right ad password. The full error is :
Error from request to URL : https://login.microsoftonline.com/TENNANTID/oauth2/token, ERROR: the operation couldn’t be completed. (JCAuthentication. JCAError 15.), STATUS: Optional(400).
What does yours show when the password is not correct?
thanks again
Interesting! Will be testing!
It is.. it is actually functioning, but giving that error every time it detects the password is different to what AD has – thanks for looking at this
How is it possible to disable the end user agreement step. Really not something users need to waste time on in our enviroment
Which agreement step are you referring to please? Within the Azure webapp window?
If you look at the configurator there is under jamf login there in the buttom is end user agreement. You can not remove this as I see ?
This is not mandatory. These are optional configurations you can add. If you don’t configure it, it doesn’t do anything.
In my testing it shows just a White page with no text and only a agree button as I haven’t entered anything. So don’t know how I can get rid of this
You must have added the keys by clicking into it or something. Check the plist or xml and remove them. Or start over with new config
So what exactly is wrong with the keys in the documentation? To me they seem to be correctly documented (ROPGID and DiscoveryURL)
https://docs.jamf.com/jamf-connect/2.0.0/administrator-guide/Menu_Bar_App_Preferences.html
In the page for federated setups the title in the left column is OK, but the actual code in the right column is different… and as lazy as I was I copy pasted.
https://docs.jamf.com/jamf-connect/2.0.0/administrator-guide/Federated_Integrations.html
See on the right it says ROPGDiscoveryURL and OIDCROPGID.
This is being corrected.
Ok, but I have all the correct keys defined and am still getting error 15 from the menu bar app. I don’t know what’s the difference in our setups, but for us defining the same values that work in Jamf Connect Verify results in error 15 although the keys have been correctly renamed to the requirements of JC 2.0.
You have the new plist stricture with iDPSettings dictionary? Does it work in the configurator app?
Hi, yes the plist structure is the new one with idpsettings etc. It does work from the configurstion tool and as mentioned after the jcl login when it wants to verify the password, that works as well. After login it seems that it has logged in the user to the menu bar app, but if I then do a sign in from the menu bar app it results in error 15 every time. Regarding the Product Issue jamf support mentioned, doesn’t that apply that they have confirmed that there is an issue with JCL 2.0 and ADFS?
No, contact me on mac admin Slack channel via PM if you want about that. But that PI you mentioned is not a Jamf Connect PI. I was about to open a PI myself yesterday, but after testing with the devs we found I had the wrong keys copied from the documentation (which is being updated). But ass Matt is reporting the same error in the comments here when passwords are changed in AD I’ll play with it again later today.
Hey yes Carl sounds exactly like what’s happening for my setups as well. Out of interest, does it actually do the sync if you OK the error and sync the passwords? Mine does, but gives the error anyway
I just tested and if I change the local password it does NOT sync it from the Menu Bar App (after the error message). However, if I logout and do a JCL login then after the password verification it states that the local password is not in sync and asks for it. After entering the local password, it does sync the passwords.
So for me it only syncs the passwords if I do a JCL login, not from the Menu Bar App.
Hi Carl, Hi Matt!
As promised, I’ve been testing. Moved it to the night time as there are moments, especially weekends, where I try to step away from the Mac from time to time.
The good news is that I found what is wrong!
If you configure the plist yourself, and you write it yourself in a text editor, all is good (if you put the keys correct as they should, without copying wrong things like I did).
If however you create the plists with the Configuration tool… that’s where the problem is. Even if you put ROPG Provider to Custom, the tool still writes it as ‘Azure’ in the XML. I noticed this by, as motivated as I was to confirm there is no ADFS issue, getting the error on my first attempt.
I checked the preferences in the Menu bar app… and I saw my ADFS config but with the provider set to Azure…. Next I checked my configuration tool which I still had open, and confirmed the ROPG Provider for Login was set to Custom. However, when I checked the XML/plist for Connect (menu bar app) I noticed that “provider’ still said Azure. There is no button or selection in the GUI to change that.
So, if you created the plist with the Configuration tool, have a look in Jamf Pro and check what the xml summary of the plist in your profile says. Azure? Custom?
Check the plist, and manually change it to Custom if needed.
Next I did the full test again:
– JCL: No problem at all
– JC Menu bar app: Login OK, changed my password in AD, logged in again -> JC notices the mismatch, asked for the current local password, boom all OK
Let me know what your plist value for “Provider” really says (check the file, not the config tool GUI)
I really appreciate all your efforts in helping us.
Sadly this is not the issue in our case. I noticed the issue with the xml generated by the config tool when I started testing and manually corrected the Provider value to Custom.
Ok, forgot to mention one thing. After noticing the issue with the provider I created a new Plist (or actually changed the value to custom) and updated the config profile. Hit save and I selected “distribute to all”. Checked the logs and confirmed it was completed on my test device. Closed the menu bar app, launched it again… same issue. Ok, closed the menu bar app, unscoped the profile, confirmed on the mac that the config profile was gone, launched menu bar app to confirm the settings were gone too… scoped the profile again-> all good
Also, don’t reupload a plist over an existing plist in the profile. Remove the payload and upload again. This has tricked me multiple times in the past. However here It seems I had to really unscope, save, rescope to make the menu bar take the new settings.
Brilliant, thank you will check this in the morning, though I have seen this even when not using a plist and inputing ids directly into the jamf connect menu app but am going to check the plist settings tomorrow, thanks 🙏
Let’s hope you get the same behavior as me now!
Well, I think you cracked it! Something in the plist created in the config tool must have been the culprit. Even though I had tried not deploying a plist before, and doing the config directly into the menu tool.
I downloaded your plist from the page you published last night. Edited them to make them azure, and add my ids, uploaded and deployed and it worked! no errors!
So, slowly started adding back my other configs. As soon as I added this in, it started erroring again :SignIn
AutoAuthenticate
RequireSignIn
Took it out and its one again. I had tried removing that previously too.
So a combination of using your plist, and not having that entry seems to be working! (not 100% sure what that entry does – it was in my v1 setup)
Thanks for looking at this, it had me baffled.
Matt
Awesome! Well, I’ll definitely check those additional keys as well, you never know. But I have a feeling that there might be something with changing the profile without really unscoping it, saving the profile (checking the settings are gone in the mac) and redeploying which is fooling JC to not take the correct updated settings.
I had some behavior like this, and indeed also when manually configuring it after pulling the profile. Maybe there is something stuck although I rebooted etc.
But yeah to me it’s definitely not ADFS breaking it. So yeah try the quit app, unscope, save, change, rescope approach and don’t hesitate to contact support when needed. I also continue testing.
I also tried all the tips you listed, but it didn’t solve the issue. Tried to recreate the plist, unscope the profile, recreated profile. I also downloaded the plist you published and edited it, but everything ends in the same error.
One thing I noticed is that the error message you mention on your new page differs from what I am seeing. Both you and Matt have an error message that ends with 400, however mine ends with 403. As a side note, we have PHS enabled. Just noticed it was disabled on the screenshot you published.
I tried with PHS enabled first. Forgot to disable that. It worked but it was only when taking the screenshot I realized it was still enabled. But I tested again and that resulted in the blog with that new screenshot to be sure it worked in a pure federated tenant. But it works with PHS too. That said, it should actually not mater if PHS is enabled or not, because you are pointing ROPG to the adfs discovery url so there is no Azure hash in the mix… you are talking to adfs directly.
So, if it works in JCL and it works in the config tool, there must be something else going on. Only logs will tell at this stage:
https://docs.jamf.com/jamf-connect/2.0.0/administrator-guide/Jamf_Connect_Logs.html
But I’m confident that it is not Jamf Connect failing to do ROPG against ADFS.
Error 403… forbidden… ? We’ll need the logs and maybe also worth checking adfs trace logs.
Compared to Error 400… bad syntax…
One additional thought, what happens if you put the discovery URL in a browser? Maybe compare it with mine (it’s in my plist).
Good news, I was able to resolve the issue. After pointing out that I was actually seeing error 403, it got me thinking. We have Azures Web Application Firewall in place and I don’t know what has changed behaviorwise between Jamf Connect Verify and the new Menu Bar App, but Azures WAF detects the new Menu Bar Apps request as a threat and blocks it.
I really appreciate all your hard work on the matter. Without your help I would still be waiting for Jamf to fix a non-existing problem.
Haha.. good news Carl
Matt, are you still getting the error if you deliberately enter the wrong password? Everything is fine for me as long as I enter the right password in the menu bar app, but if I enter a incorrect password then I get the error 15 (400).
Hey.. yes I do. Not the most friendly ‘wrong password’ message I have ever seen. No idea how to fix that
Something to be look at indeed. I’ll investigate further tomorrow morning.
Thanks Matt for confirming you are getting the same error and TTG for looking into this, really appreciate it.
This is luckily not a showstopper, but from a user’s perspective a more informative error message would be nice.
Carl, Matt,
Seems to be expected per design change in 2.0. If you want to see that reverted, I’d advise to open a feature request on Jamf Nation. If you do, let me know and I can personally back it.
Ok, this seems like a very odd design choice by Jamf. Jamf Connect Verify had a clear message to the user that either the username or password is incorrect. This new error message gives no information to the user regarding what is going on.
I just created the feature request.
Thank you. I voted it up. Will ask people to do the same as, and please understand this is my personal opinion, I agree.
Thanks, I also created another feature request to give us the option to define separate SignInLogo images depending if the user has light or dark mode enabled. The feature is currently there for the menu bar icon, but not SignInLogo
Happy to see all is good now Carl! Yeah, lesson learned here as well, it’s all in the details of the error message.
Hi,
Thanks for the update. I can see it may not only be me, but something confuses me regarding the JCL login
If I install basic jamf connect 2.0 package – it does not change the auth
If I install jamf connect login plist file – it does not change the auth
In the plist how is it even possible to add the JCL login window ?
I know by script it works like this below – but as I can read from the manual it seems like plist etc should also be able to modify the auth.
/usr/local/bin/authchanger -reset -OIDC -preAuth JamfConnectLogin:RunScript,privileged JamfConnectLogin:Notify
Hi Kim, with 2.0 you don’t need anything else than the plist with OIDCProvider, but you need to make sure that the plist is installed before you reach the login window. So if you are doing automated enrolment make sure to add the config in the prestage and scope the profile on it own correctly. If no script or terminal command or authchanger plist has been added JC 2.0 will read from it’s own plist and use the OIDCProvider key to change the authchanger.
Are you referring to prestage enrolment or already deployed devices?
Right now I am deploying to already installed clients where Jamf connect is not installed. And If I just deploy jcl package and plist it works fine and the login windows stay as OS default which is fine
In pre-stage I use same plist, and custom package with jcl PKG, and in post script I reset auth to jcl and it run depnotify and do package enrollment. End of enrollment I in script reset the auth to default again
Should that be ok ?
“And If I just deploy jcl package and plist it works fine and the login windows stay as OS default which is fine” => if the plist for JC Login is installed (which has the OIDCProvider key in it normally), the authchanger should execute the flip to JCL window.
“custom package with jcl PKG” => are you using a Cloud Distribution point? And is the custom package signed correctly by a publicly trusted CA (or the Jamf Pro internal CA). Both are mandatory for prestage packages. A normal SMB fileshare can not be used. HTTPS fileshare should be ok, but I’ve seen issue with that. The question is, is your custom package really installed or not? “which authchanger” command can show you the path if it installtd correclty, or the jamf.log file on the system
hmm – I have the OIDC provider key added in the plist.
I actually tried on a clean mac with no MDM installed just to install basic JCL pkg and jamf login plist file and work fine. Also if I restart it stay with native OS login window
What confuses me here is that you say “and work fine” versus “it stay with native os login window”. Also, with no MDM… where are you putting that plist? And what is the name of the file? Finally, when doing MDM, you have the custom domain set correctly? As I’m taking a break away from my Mac this evening, open a support ticket and provide the plist and above info.
What are the correct authchanger parameters to add to the postinstall script in the custom signed JCL2.0 package (for ADE) if you choose to enable Notify?
In your blog you have a screenshot of your custom package where you have:
/usr/local/bin/authchanger -reset -preAuth -JamfConnect:RunScript,privileged
However, the documentation states:
/usr/local/bin/authchanger -reset -NewLogin -preAuth JamfConnectLogin:RunScript,privileged JamfConnectLogin:Notify
I have not been able to get this to work with the information in the documentation and I got a bit further with the parameters you mentioned. We have Enrollment Customization against Azure and with your authchanger command I was able to get as far as Jamf Pro forwarding the user info to JCL and it asking for password verification. After this I would like to run the script and notify.
Hi Carl, time permitting I’ll test that as well. However, I’ll need to go through setting up a new Notify config etc so that will take time. Your fasted path to resolution for this will be support ticket. Hope you understand. But’s it’s on my todo list.
No problem, I just wanted to check if you have more information about what the correct parameters for authchanger is.
I’ll open a support ticket and see what they say.
Support seems also bit uncertain on this.
If I look at your “configure authchanger” section in your blog there is 1,2,3 and 4.
I have not done 1,2 and 4. But if I look at number 3 I have the com.jamf.login.plist in /library/managed preferences (deployed through jamf) and in this plist I also have my OIDC provider.
So if I deploy basic jamfconnect.pkg with that plist it should show the JCL window as far I can understand the documentation. Above has nothing to do with pre-stage, just normal deployment to existing mac´s
com.jamf.login is not the correct domain. It’s com.jamf.connect.login
Can you crosscheck that?
Sorry – yes if I check the name is com.jamf.connect.login
Ok, then there is something wrong with the plist or something else unknown going on. Send the plist to support to validate it. I justed tested again. Mac enrolled in Jamf, no JC installed.
Pushed my profile.
Installed 2.0
Logged out
=> JC login window immediately
No terminal commands / scripts or additional authchanger plist.
So I’m sure it must be the plist.
yes sorry – it is com.jamf.connect.login. Just mistyped it in here
hm – don´t think there can be much wrong ?
AllowNetworkSelection
CreateAdminUser
CreateJamfConnectPassword
DenyLocal
LocalFallback
OIDCClientID
xxxxxx-xxx-xxx-xx-xxxx
OIDCIgnoreAdmin
OIDCProvider
Azure
OIDCROPGID
xxxxxx-xxx-xxxx-xxx-xxxx
ROPGClientSecret
vxxxxxxx_
ROPGProvider
Azure_v2
ROPGTenant
xxxxx-xxxx-xxxx-xxxx-xxxxx
Yeah, the blog comments don’t play nice with the plist structure. I’ll assist internally to check it with support.
hmm – bummer. Think it is my VM that makes crazy stuff. Just tried on another mac whith exact same plist and there it works.
However, if i remove the login plist again and log-out it still shows the JCL window. If the plist is not there anymore it should reset to default login or ?
Oh!!! Yeah I stepped away from testing JC on VM! Too much inconsistent results. VM’s became weird with Catalina! To disable you need to run the authchanger reset command it seems indeed.
Yes — it is not the first time VM drive me crazy, specially about DEP enrollment you cannot trust anything
hmm – just tried to reset auth – remove jamf package.
Installed jamf package and added the plist file again – and now it still stay at the native OS window. This is driving me crazy
Expected. As from the moment you do anything with the command line, you are in “option 1… if a command is executed it ignores profile”.
So if you disabled with command line, you need to re-enable with command line.
authchanger -rest -jamfconnect
Think I just have overcomplicated this – but now at least i know how it works.
If I don´t want JCL window login on existing mac, then why not just deploy standard jamfconnect.pkg file with no jamf login plist and just use jamf connect plist, so the jcl client will work with password change etc
Yeah, or even better… repackage only the menu bar app and do not deploy the login app 🙂
OK seems I got it. When you install jamf connect the plist have to be there. If first jamf connect and then add the plist it will stay at native os login.
For reset yes – only manually auth command is needed
Hey, Thanks for this guide, as always its great.
But still having issues with the verify section. Using Password Hash in azure. The config tool gives us success, however, when in action it fails.
Not sure what we are missing. Notice we are having the same errors as others in your comments
Error from request to URL: https://login.microsoftonline.com/tennant-id-number/oauth2/v2.0/token, ERROR: The operation couldn’t be completed. (JCAuthentication.JCAError error 15.), STATUS: Optional(400)
Hi Rick. Is your Azure ADFS federated? As in “Federated Enabled + PHS”? If yes, make sure to check the Jamf Connect Menu Bar App plist so that the Provider key is set to custom. Known issue with the Config App. Change it manually before uploading to Jamf. And make sure the discoveryURL etc… is set correctly. If you did not configure it with ADFS discoveryURL etc when “Federation = enabled” it will not work. So yeah, to answer your question I’d need to know if your Azure is federated and see the plist. Don’t add the plist as text in the comment, blog does not play nice with it, add a screenshot or send me the plist via macAdmin Slack channel.
What is your recommendation for using only jamf connect in DEP enrollment. As I can read smart groups is not good, in case they are not updated fast enough, so JCL windows will not kick in when enrolling
I can scope it to all computers, but then I also will hit existing running mac´s , where I don´t want the JCL window to appear.
It would be easy if no config profile was needed and it could be build into package – but seems that config profile is a must as I can read
Hi John, you’re right on the Smart Groups. It depends the speed of the Jamf Binary download and smart group calculation. However, you can use a Smart Group linked to the prestage you used as that info is immediately available at first contact and does not require an inventory update. Next, I’d run a Jamf Pro policy with files and processes payload to disable the JCL window. Challenge here is to identify a point in time where you can be sure that the user went through the user creation with Jamf Connect. Finding the best trigger to do that depends your deployment. There might be something running or installing on the device which assure you that the enrolment and user creation is complete.
Alternatively and maybe preferred is to use the Notify script process and disable JCL window at the very end of the Notify process.
I am actually using depnotify
So first step is to assign jcl login plist config to pre-stage computers (But then existing clients that have been pre-stage enrolled will also be hit – so don´t I risk that the existing clients they will switch to JCL window) ?
I could of course run a policy on existing pre-stage clients that it will reset auth to default – but cannot understand how the config profile will then not apply. How can the config profile know that this command that has been run ?. Normally config profiles rules over any things done by command line
Maybe it is me that cannot just see it. :-/ ?
Yes, if command line has been used, it ignores the profiles. It is the authchanger deciding what to honor and if the command line has been used, it knows.
Keeping the profile on the Mac does bit bring it back to what is in the profile. If you disabled via command line, you need to re-enable via command line.
Authchanger -reset -Jamfconnect brings it back to honoring what is in the profile.
OK – got it, that it is authchanger binary that decides what to do.
Actually I could just remove the jamf connect binaries on the mac´s that has been pre-stage installed(being sure that native logon is active), If no binaries are there, then the configprofile will never do any harm
Indeed! Yeah, there are so many workflows depending the exact goal, so things can get complicated. It’s always easy for me: test Jamf Pro server with 1 test mac => walk in the park. The real world is another story indeed.
Just an additional question
Just had a test machine(not VM) installed jamf connect pkg and then added jamf connect login plist. For some reason, it still does not show the JCL window and to my knowledge I have not run any command line to reset the authchanger
Is there a way to see current status of the authdb, and if there has been any changes etc? – so I can see what the reason is that it does not show the JCL as it should