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:
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:
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
- 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!
Or via Terminal:
productsign --sign "[Signing Certificate]" ~/Desktop/example.pkg ~/Desktop/signed-example.pkg
Create 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
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!