Hi all!

First of all I wish you all the best for 2021!

2020 has been a special year in general, and without doubt, full of challenges for MacAdmins supporting colleagues working remotely.

That said, let’s get the ball rolling on this blog for another year! I’ll start with a ‘short’ topic: the Jamf Connect Authchanger.

Official documentation can be found here.

So, first of all, what is the Authchanger?

Well, it’s one of the pieces of the Jamf Connect product family, and more precisely a part of Jamf Connect Login. One of the main features of Jamf Connect Login is to replace the native macOS Login Window with the well known Jamf Connect Login Window and it’s iDP webapp authentication.

When we think of Jamf Connect Login, we typically visualise a Mac where the user authenticates against an iDP webapp instead of the default macOS username (or icon) and password screen:

The authchanger is the binary used to decide which login window is presented, and is installed by the Jamf Connect Login installer (it’s part of Jamf Connect and not native to macOS).

Important to know is that this authchanger can be configured in different ways, which means that installing Jamf Connect Login does not mean that you, per se, have to use the Jamf Connect Login window! Jamf Connect Login includes functionality, like demobilising Mobile Accounts, which can be executed through the native macOS Login Window as well. All subject to how this authchanger is being executed.

Important to understand as well is that the authchanger is not something which is constantly running! It’s a binary (application or program) which needs to be executed, and only when executed it is able to make changes to the login window. Makes sense right? A binary which is not running can’t do much… But this is very important in order to understand the reason why you may or may not see the Jamf Connect Login Window, even if Jamf Connect Login has been installed!

Let’s discuss this a bit more into detail, and for those who have been around before Jamf Connect 2.x was released, let’s starts by having a look at the Jamf Connect Login 1.x installer pkg:

As you see in the screenshot above, the installer package installs a bunch of awesome code, including the authchanger and the Jamf Connect Login binary.

But on top of that the installer also includes a post-install script:

In early versions of Jamf Connect 1.x, we had to run the authchanger manually again after installing Jamf Connect (or via a script / Jamf Pro Policy) to tell Jamf Connect that we want to use Okta instead of OIDC (Azure for instance). In later updates of Jamf Connect this was automated based on the filename of the installer. Just by renaming the installer, and adding ‘okta’ in the filename, the authchanger would automatically understand that you will be using Okta as iDP.

But more important is the fact that, for both Okta as OIDC, the authchanger is being executed at the end of the install process with arguments.

/usr/local/bin/authchanger -reset -Okta
/usr/local/bin/authchanger -reset -OIDC 

This means that, regardless of whether or not you have installed a configuration profile to configure Jamf Connect Login, the post-install script by default assumed that you want to use the Jamf Connect Login Window instead of the native macOS Login Window.

This also means that if you would install Jamf Connect Login 1.x without a configuration profile to configure the iDP settings, you would end up with an error at the login screen saying it can not load the iDP webapp. Or when using Okta, the authentication would fail because Jamf Connect has no clue which Okta instance it needs to authenticate against.

But even without a configuration profile for Jamf Connect Login, the native macOS Login Window was replaced just by installing Jamf Connect.

This changed in Jamf Connect 2.x. Let’s have a look at the post-install script of 2.x:

As you can see, it does indeed run the authchanger, but without arguments! Ok it runs the authchanger with the -reset argument, just to make sure that Authentication Database is reset to default (for instance if you re-installed Jamf Connect after doing some tests):

/usr/local/bin/authchanger -reset

But after that, it runs the authchanger again, without arguments:

/usr/local/bin/authchanger

This means that installing Jamf Connect is not replacing the native macOS Login Window at all!

Note: The Jamf Connect 2.x installer includes both Jamf Connect Login and Jamf Connect Menu bar (which replaces Jamf Connect Sync and Verify)

So how to we tell Jamf Connect, or more precisely the authchanger to flip the Login Window to Jamf Connect? Well, by running the authchanger again with arguments, by configuring the authchanger itself with its own plist, or by configuring Jamf Connect Login!

Note: Yes, we could also change the post-install script in the Jamf Connect installer, but doing so we would need to re-sign the package for automated enrolment and do this each time there is an upgrade. Not handy, not very efficient, so let's not do that.

If we look at the admin guide, we see that the authchanger has the following logic built in to check for arguments in a very specific order:

Jamf Connect will look for authchanger arguments in the following order after the login window is installed:

  1. 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.
  2. Preferences found in a configuration profile written to com.jamf.connect.authchanger
  3. The Identity Provider (OIDCProvider) or Auth Server (AuthServer) preferences written to the com.jamf.connect.login domain. These pass the -JamfConnect argument to automatically enable OpenID Connect or Okta authentication.
  4. If no arguments or preferences are found, the default loginwindow mechanisms will remain unchanged.

What does this mean exactly?

First of all, like I mentioned before, it means that the authchanger will only do something when it is being executed, for instance as part of the installer via the post-install script.

However, we just mentioned that the post-install script does not, by default, pass any arguments to the authchanger. This means that the first point in the order above is not happening. When the post-install script is executing the authchanger, no arguments are passed ‘by command-line’ so the autchanger needs to look for preferences set by a configuration profile.

The first source of preferences it will check (item 2 above) is the com.jamf.connect.authchanger domain, which needs to be configured by pushing a configuration profile with a plist (or scripted via ‘defaults write’).

For instance (check the Jamf Connect admin guide for more advanced options):

<?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>

If the authchanger finds the com.jamf.connect.authchanger preferences, it will honor the arguments and configure the Login Window accordingly. In the example of the plist above, it will reset the Authentication Database and enable the Jamf Connect Login Window.

If no preferences can be found for the com.jamf.connect.authchanger domain, it will continue its search and look for either the Identity Provider (OIDCProvider) or Auth Server (AuthServer) in the com.jamf.connect.login domain. So basically checking if there is a Jamf Connect Login configuration profile installed or not. If it can find the ‘OIDCProvider’ or the ‘AuthServer’ key in the preferences, the authchanger will enable the Jamf Connect Login Window.

So looking at all the above, this means that if you want to enable Jamf Connect, and tell the authchanger to do anything else then the basic ‘reset’ of the Authentication Database included in the post-install script, you need to push a profile with settings prior to installing Jamf Connect. A profile for either the com.jamf.connect.authchanger or the com.jamf.connect.login domain, depending your needs.

In most cases that will just be pushing a Jamf Connect Login configuration profile, but you need to do so prior to installing Jamf Connect.

REMEMBER, the authchanger is not something which constantly runs. It is also not being executed during a login through Jamf Connect. So, if you installed Jamf Connect 2.x on a clean mac, without pushing a profile (Authchanger or Jamf Connect Login), the native macOS Login Window will remain untouched!

So how do we fix that? Well, if this happens during testing, or because you forgot some scoping of the profile, just run the authchanger again! Either manually or via a script in a Jamf Pro policy and pass the required arguments (-reset -JamfConnect).

But what about upgrading from 1.x to 2.x? You may be thinking “well, I just installed Jamf Connect 2.x on a Mac which had 1.x installed, and the Jamf Connect 2.0 Login Window appeared just fine’.

Indeed, because this Mac was already configured for 1.x, it most likely has the Jamf Connect Login profile for 1.x installed, and the keys for OIDCProvider or AuthServer did not change. Running the the order of check above, the authchanger detected the preferences set by the 1.x profile in com.jamf.connect.login domain and flipped the Login Window to Jamf Connect.

NOTE: review your Jamf Connect Login plist as well as the new Jamf Connect Menubar plist as there are some changes! Also, review the workflow on how to upgrade Jamf Connect to 2.x or check my previous post on the matter!

Finally, remember that the authchanger can do more than just flipping the native macOS Login Window to Jamf Connect and vice versa. Have a look at the admin guide for more complex functionality.

One example I do want to highlight however is the demobilisation of mobile accounts via the native macOS Login Window (instead of enabling the Jamf Connect Login Window for that purpose). Executing the authchanger with the arguments below keeps the native macOS Login Window enabled, but runs a demobilisation process for mobile account in the background upon the next login:

sudo authchanger -reset -preAuth JamfConnectLogin:DeMobilize,privileged
This allows users to login using the default macOS login window while Jamf Connect converts the mobile account into a local account on the Mac in the background.

Oh yeah, one more thing, talking about Login Windows… don’t forget to review my previous post regarding the difference between the FileVault Unlock Screen and the Login Window, as well as the authentication flow with Jamf Connect!

That’s it! I hope this was useful for a first post in 2021!

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

Brgds,
TTG

Looking for a great screen protector with blue light filter for any of your devices? Have a look at Ocushield! I personally love it!