On request (thanks for the lead David), and because I indeed see recurring questions on the matter, I hereby want to dedicate today’s post to the following topic:
Understanding the different authentications through the FileVault screen, the native macOS Login Window and Jamf Connect, as well as discuss some behaviour when changing passwords.
- FileVault Screen versus the native macOS Login Window
- Understanding authentication flow with FileVault
- Understanding authentication flow with Jamf Connect
- Understanding authentication flow with Jamf Connect AND FileVault
Let’s start with the basics.
FileVault Screen versus the native macOS Login Window
This might be obvious for some, but it seems that this is still causing some confusion for others. Let’s first have a look at the following scenario. My test Mac has just been deployed, and nothing special has been done to it. FileVault is not yet enabled, so if I reboot my Mac, I’ll see the Apple Logo, the loading bar and the following Login Window:
As you can see, I only see my account, being presented with an icon to click on, and the ‘Other’ icon I can click to authenticate with another user:
I also see the clock, Wifi symbol and battery info in the top right corner, and the Sleep, Restart and Shutdown buttons at the bottom.
As you can see, I do not see any other account presented with an icon at the Login Screen, however, I do have a ‘jamfadmin’ account on the Mac. This is my “Managed Administrator” which I configured in the prestage. Because I selected this account to be hidden, it does not show up at the Login Screen, or in the System Preferences:
I do see it in Directory Utility of course:
If I bind my Mac to Active Directory, or push a Configuration Profile to change the Login Window to “Name and password text fields”, the Login Window would look like this:
Name and password text fields:
Active Directory Binding:
As you can see, the Login Window with an AD bind looks the same like when you set it to “Name and password text fields“. However, you might briefly see a red dot in the top right corner when the Mac is contacting the Domain Controller. When the red dot stays, the Mac is unable to reach the DC.
Now, like I said, FileVault has not been enabled yet, and this is why we see the macOS Login Window rebooting the Mac.
Let’s now have a look at FileVault, and first of all, our Secure Token holders.
As you can see I only have 1 SecureToken holder (‘ttg’) and Bootstrap enabled on this Mac. The ‘jamfadmin’ account which I showed you earlier, does NOT have a SecureToken (yet).
Let’s now enable FileVault, via a Config Profile, so the account I’m currently logged in with (‘ttg’ which has a SecureToken), enables FileVault at logout.
Let’s logout, and confirm FileVault is enabled after logging in again:
FileVault is enabled but I still only have 1 SecureToken holder (‘ttg’). Yes, I also have Bootstrap enabled but my ‘jamfadmin’, my ‘Managed Administrator’, did not get a token yet because I haven’t logged in with that account through the Login Window yet. I used it for ‘sudo’ but that does not leverage the Bootstrap to give it a SecureToken.
Let’s now REBOOT the Mac and see what happens.
Rebooting the Mac with FileVault enabled, presents us the FileVault Screen, which is NOT the macOS Login Window. Yes, it does look similar, but there are some differences. As you can see in the top right corner, we don’t have the Wifi icon for instance, which makes total sense as the OS is NOT loaded yet.
You also see that the ‘jamfadmin’ account is not presented either, just like at the Login Window earlier. However, the reason why it does not show is different. At the login window, the account is not shown because the account was created as HIDDEN. But the reason why it does not show at the FileVault Screen, is because the account does not have a SecureToken, hence it’s not enabled for FileVault. Let’s proof that by giving the account a SecureToken.
As this ‘jamfadmin’ account is my ‘Managed Administrator’, I can easily give it a SecureToken via Bootstrap, so let’s log in with ‘jamfadmin’ through the Login Window.
And let’s check our SecureTokens again:
Now that our ‘jamfadmin’ has a SecureToken, let’s check the Login Window again (by just logging out):
Yes, I had to push a config profile to flip the Login Window back to “List of users able to use these computers” instead of “Name and password text fields“, because even after unbinding the Mac from AD it kept the name and password look. However, because the ‘jamfadmin’ account is hidden, it does NOT show at the Login Window. Even if it has a SecureToken.
Now let’s REBOOT the Mac without further changes:
And there it is! ‘jamfadmin’ in the list of users, even when the account is created as ‘hidden account’! This is entirely expected as the FileVault Screen presents ALL users which have a SecureToken. There is NO way of disabling that, apart from removing the SecureToken from the account you want to hide at the FileVault Screen.
I hope this clarifies the first piece of confusion which some Mac admins are facing.
I know, a long journey through this topic already, but let’s now have a look at the second part of this post which I want to elaborate: understanding authentications flows. I’ll split this up in 3 sections:
- Only FileVault
- Only Jamf Connect
- Jamf Connect AND FileVault
Understanding authentication flow with FileVault
With the discussion about the differences between the FileVault Screen and the Login Window off the table, let’s now have a look at what this means for authentication.
If we do NOT have FileVault enabled, and you reboot the Mac, you get the Login Window as discussed above. You log in and you get to the Desktop. Pretty straight forward.
However, as we discussed, if FileVault IS enabled, you get the FileVault Screen. But what really happens there exactly?
Well, as we discussed, only (and ALL) SecureToken users are presented. If you authenticate, you unlock the drive and the FileVault encryption. But the authentication flow doesn’t end there. What really happens next is that the FileVault process is then trying to pass the authentication (if successful) to the next step in the Boot sequence: loading the OS and presenting the Login Window.
If the FileVault credentials are in sync with the actual local (or Mobile) account on the Mac, the Login Window process running in the background, receives the credentials and authenticates the user silently. In that case the user goes straight to the desktop.
If however, the FileVault password of the user is out of sync with the local account (or DisableFDEAutoLogin has been set on the Mac), the passed credentials fails against the Login Window and the user gets the Login Window presented.
But wait a second, FileVault Password out of sync? How? Well, there are multiple reasons for this which are a bit outside the scope of this already long post, but the main reasons for this to happen would be:
- a badly scripted password change of the local account password
- an AD password changed outside the Mac
- a problem with a demobilised account
So yes, it is possible to break the sync between the local password with FileVault depending the way you change passwords. Remember that the FileVault Screen is a step in the boot sequence where the OS is not fully loaded yet, with no network communication, etc…
This means that if, for instance, you change the password of a mobile account outside of the Mac (~ directly in AD), or if you break the sync between FileVault password and local account password, the end user will need to know the OLD password in order to boot the Mac and get passed the FileVault Screen. Yes, I hear you thinking, the reason to change a mobile account password directly in AD is probably because the end user forgot the password… and if the sync between the passwords is broken, the user will probably not remember the old password.
Yes, if FileVault was already unlocked, by another user or if the current user who forgot the password logged out without a reboot, the mobile account would be able to login in with any NEW AD password. The same applies to local accounts with the FileVault password out of sync. As long as they only log out, they can continue to log in again with their ‘known local password’.
But if a reboot happens, this is NOT possible anymore. You simply can NOT get into the Mac, unlock the drive and load the OS, if the FileVault password is not known.
In those cases and Admin intervention (with a SecureToken enabled admin account) will be needed to unlock FileVault, or the Recovery Key will need to be used.
Understanding authentication flow with Jamf Connect
Now let’s add Jamf Connect Login into the mix and see what JCL can bring as fix to this roadblock.
Let’s start with the main purpose of Jamf Connect Login and Jamf Connect Verify/Sync: keep local passwords in sync with AD/iDP.
Also, let’s keep FileVault out of the equation for now. I know, a long post, but trust me, we are building up the story to reach the ultimate goal of understanding the full authentication flow. Just stay with me here.
When we provision a Mac with Jamf Connect Login, and Verify/Sync, it keeps the passwords in sync while the OS is loaded. This means that if a user is at the Login Window, here replaced by the Jamf Connect Login window, we first authenticate to the iDP. This via OIDC in the secured web app. Next (unless we are using the Okta API), a second prompt is presented to validate the password again. Why?
Well, although this is not a pure Jamf Connect post, let’s quickly review the matter. When configuring Jamf Connect Login, you can define the key <OIDCNewPassword> and set it to true/false (defaults to true if not set). If we keep it set to ‘true’, then Jamf Connect Login will ASK the end user which password he/she wants when initially setting up the account. JCL will then just use that password to configure the local account, which could, in se, be different from the OIDC password the user used to authenticate in the OIDC web app.
As said, the user is here choosing a password, which will NOT necessarily be the same as the password in the iDP. On subsequent logins, the end user will again authenticate against the iDP via OIDC in the web app…
… but because the local account already exists, JCL will prompt the user to enter the password again:
As we have <OIDCNewPassword> set to ‘true’, this is not to validate the password against the iDP, but just to log in into macOS. Remember that JCL can not read the password during the OIDC web app authentication, and it needs the password to log in… obvious no?
If the user enters another password, different from what the current local password is, the following will happen. Pay attention to the clue ‘incorrect local password’.
But wait a second, we changed the password in the iDP, the user authenticated with the password in the OIDC web app and now JCL is asking to enter the password again and the user needs to enter another password? How does that fit into ‘keeping passwords in sync’?
Well, think about it. You changed the password outside of the Mac, somewhere in an obscure part of the internet… the iDP. You then try to log in into the Mac and macOS has no clue that the password in the iDP changed. Yes, the user is authenticating with the new iDP password through the OIDC web app… but JCL can not read the password in the protected realm of the web app. You also disabled ROPG by setting <OIDCNewPassword> to ‘true’. Hence there is no validation of the new password against the iDP which JCL can read… so how do you think JCL could possible use the new iDP password…. Indeed, it can NOT.
And yet, it needs a password to do the login, so it prompts to the user again for the password. As there is no ROPG validation, it does not check it with the iDP and just tries to log in with that password. As there is no magic or Jedi-style-force which could have changed the local password in the background, the current / old local password needs to be provided!
The same scenario would happen if we change the local account password manually (without using Verify/Sync) on the Mac via the System Preferences. In this case the password will also not match the iDP password… think about it…
Makes sense right?
So how do we avoid this? Well, first of all, by setting <OIDCNewPassword> to ‘false’ and by doing so enabling the ROPG check when we create the user account, and use Jamf Connect Verify/Sync to keep the passwords in sync when passwords (either locally or in the iDP) are changed.
When initially creating the account, the user authenticates in the web app…
Without a valid password the user will obviously already hit a roadblock here. I guess that makes sense.
But after successfully authenticating in the web app the user gets the second prompt to validate the password via ROPG again. Pay attention to the difference with ROPG disabled, it does not show the 2 input fields to choose and confirm a local password.
Now JCL contacts the iDP again via ROPG and checks if the password is good. If not, the user is immediately presented with the following error:
The same error could appear when ROPG is not enabled correctly in the iDP (remember that Google iDP does not support ROPG).
When initially creating the account, with ROPG correctly enabled in the iDP, this error most likely means the user made a typo at the second authentication prompt.
During subsequent logins, the same 2nd authentication will always be presented as well. However, the difference with a setup where <OIDCNewPassword> set to ‘true’, is that JCL is not only presenting this second prompt to get the password to login into the local account. It also checks it against the iDP at every login. If that password is correctly validated, but differs from the actual local password, the following will happen:
The password passed the ROPG check and JCL tried to use that password to login. The login failed, and JCL informs the user about the mismatch. At this point, just like when <OIDCNewPassword> is set to ‘true’, the user needs to know the current / old LOCAL password. With <OIDCNewPassword> set to ‘false’, JCL does need that current / old local password to change it, bring it back in sync with the iDP and log the user in with the NEW password from the iDP.
Still following? All OK? If so, let’s move on, but before we continue, a quick a very important statement as a recap of all the above:
There will ALWAYS be 2 authentications in Jamf Connect Login, regardless of enabling the ROPG check or not !
If the local password does not match the iDP password, the user must always know the ‘current’ LOCAL password! Again, regardless of ROPG.
But wait a second, what if the user forgot the local password? Well yes, if you enabled ROPG, and enforce password sync through both Jamf Connect Login and Sync/Verify, the local password should be the same as in the iDP. So your first reaction would be to reset the password in the iDP and let the user login again. Still keeping FileVault out of the equation here, the user will be able to authenticate against OIDC in JCL at the first authentication, but as discussed above, even if the ROPG check succeeds, the user will still be prompted for the ‘current / old’ local password!
So a second very important statement I want to add to the recap so far:
Jamf Connect is a tool to facilitate the sync between iDP and local password. It is NOT a black magic tool which fixes the limitations of the human brain. A forgotten local password = forgotten, and if you do not know the password of the local account and you can’t provide it to Jamf Connect Login… it can not pull some sorcery to bypass how computers work. No password, no candy.
I hope I was able to clear this confusion off the table, because we still need to add another layer to this: FileVault! But before we do so, let’s quickly check out Jamf Connect Verify/Sync.
While Verify uses ROPG, and Sync uses Okta API and/or Kerberos, the idea behind both apps is the same. When a user logs in into the Verify or Sync app, it checks the password with the iDP and keeps it in sync with the local password. If the password validation against the iDP succeeds, and it matches the local password, nothing happens.
If the iDP password fails the user will be asked to try again.
If the iDP password succeeds, but it does not match the local password, the app will ask the user for the CURRENT local password to re-sync it.
So it there is a mismatch, just like with JCL, the end user needs to know what password is currently set on the local account.
Please keep in mind that the sync always happens FROM iDP TO local password. Or to say it differently, it will always change the local password to the validated password in the iDP. Never the other way around!
But what happens if the user changes the password via Verify or Sync? Well for Verify, this will re-direct the user to a ‘change password URL’, where the user will change the password in the iDP. And I hope you already guessed it, because the password is then changed in the iDP… it won’t match the local password. The user will need to log in into the Verify app after changing the password in the iDP…
Yes… to sync the local password the user will be asked for the OLD / current local password. Hence the message you can configure to tell the end user to sign in again:
Jamf Connect Sync works a bit different (unless you configure it to use OIDC, which is not recommended), because it can change passwords either via Kerberos or via the Okta Dashboard. However, in both cases the current / old local password needs to be known, either to authenticate for Kerberos or when signing in into Jamf Connect Sync again after changing the password via the Okta Dashboard (required).
To change the password via Jamf Connect Sync / Verify the old/current password must be known! Just like JCL, it does not offer any black magic or sorcery to bypass the design of how local passwords work!
So, taking all the above into consideration:
If the local password is really forgotten, even if FileVault is not enabled yet, Admin intervention will be required to RESET the local password for the user.
Yes, this will break the keychain, and please remember that, even without FileVault, you need an admin account with a SecureToken, to reset the password of an account with SecureToken!
Regarding that SecureToken requirement, let’s quickly proof that as well. As you can see, I created a ‘testadmin’ which has no SecureToken, and trying to use this admin account to reset the password of ‘std_user’ who has a SecureToken fails:
This is also the reason why the ‘Reset password’ functionality in a Jamf Pro policy does not work when trying to reset the password of SecureToken-enabled user!
Understanding authentication flow with Jamf Connect AND FileVault
Finally we come close to the actual end goal of this post: understand the full authentication flow with Jamf Connect, when FileVault is enabled.
Well, I hope it doesn’t come as a surprise, but it’s actually nothing more than a combination of everything we discussed so far.
Let’s start with the following assumption:
- FileVault is enabled
- iDP password is in sync with the local password
- the FileVault password is not out of sync with the local password
- the user of the Mac has a SecureToken
If we reboot a Mac which is in this situation, the following flow of authentication applies:
- The user is presented with the FileVault Screen and sees his/her account in the list of icons
- The user authenticates with its know password
- Because the FileVault password is in sync with the local password, the FileVault Screen passes the credentials to the Login Window
!!! The Login Window authenticates the user with the passed credentials SILENTLY, and the user does NOT see the Login Window.
The fact that the native macOS Login Window is in fact replaced by the Jamf Connect Login Window, does NOT change this behaviour.
4. The user goes straight to the desktop and BYPASSES Jamf Connect Login
If however the FileVault password is out of sync with the actual Local Password (whether or not it is in sync with the iDP is irrelevant here), the pass of credentials to the Login Window process FAILS, and the user is presented with the Jamf Connect Login Window.
Other reasons for seeing the Jamf Connect Login Window with FileVault enabled are:
- JCL is confined with the <DenyLocal> key set to ‘true’. This enforces the user to authenticate against the iDP, hence presents the JCL window
- Auto FileVault login has been disabled in macOS with the following setting:
sudo defaults write /Library/Preferences/com.apple.loginwindow DisableFDEAutoLogin
- FileVault was already unlocked by a previous user and the Mac is actually sitting at the Login Window and not at the FileVault Screen
So, yes it is normal and expected that rebooting a Mac with FileVault bypasses Jamf Connect Login when sucessfully authenticating with a SecureToken enabled user (at the FileVault Screen).
And now finally, the actual purpose and end goal of this post which ended up being way too long: what happens is the iDP password is changed on a Mac provisioned with Jamf Connect if FileVault is enabled?
Well, after reading all the above, it might sound funny, but I’ll try to put the answer in just a few lines. I hope I succeeded in explaining why in the long journey above.
Let’s take one of the following situations to start with:
- The Mac is sitting at the (Jamf Connect) Login Window, because the drive was already unlocked and the user logged out without rebooting.
- The user is currently using the Mac in an active session
If the Mac does NOT get a reboot, the end user will be prompted to sync the local password with the new iDP password at the next login through Jamf Connect Login or sign in into Verify/Sync
Yes, the user will need to know the ‘old’ local password (still the actual local password :-))
Doing so will update the FileVault Password and a reboot can be performed without any problem! The user will be able to use the NEW iDP password at the FileVault Screen
If however one of the following scenarios happen:
- The Mac was turned off when the iDP password was changed
- The user rebooted the Mac before doing a sign-in into Verify/Sync (forcing it to sync the new Password to the Mac) after changing the iDP password
- The user rebooted the Mac without logging in through Jamf Connect Login (forcing it to sync the new Password to the Mac) after changing the iDP password (when FileVault was still unlocked)
The end user will be presented with the FileVault Screen where the ‘old’ / ‘current’ local password will be needed to unlock FileVault!
Finally, when ROPG is not being used, the ‘old’ local password will ALWAYS be needed when changing the iDP password… as the password is never synced (with the exception of Jamf Connect via the Okta API, as that always syncs password in Jamf Connect).
So after all the above, the only thing I actually wanted to say was:
If the user forgets the ‘local password’ of his/her account, there is NO MAGIC which will fix that. Wether it is to unlock FileVault or just to login through the Login Window. The local password must always be known. Yes I know, it’s a harsh world but remembering that password you use on a daily basis should not be too hard right?
To wrap this, way too long, post up:
If FileVault is enabled and the local password is lost there are only 2 fixes:
- Use another SecureToken admin account to login into the Mac and reset the local password for the user. Give the temporary password to the end user and let him/her sync it again with the iDP password via Jamf Connect Login / Verify / Sync
- Provide the Personal Recovery Key to allow the end user to bypass FileVault and reset the local password. Next, sync it back to what is set in the iDP via Jamf Connect
Just one more thing:
If you find yourself sitting at the FileVault Screen, with the FileVault password being forgotten, the recovery key unknown and no other SecureToken-enabled admin existing on the system -> take a deep breath, cry if needed and wipe the Mac!
More careful you must be…Unknown Yedi MacAdmin
And as very last point, hereby a link with a flow chart about all the above: https://www.jamf.com/jamf-nation/articles/682/using-filevault-with-jamf-connect
That’s it, as always, if you liked this post, hit the like button, tell your friends about it and don’t hesitate to leave a comment down below!
All the best, stay safe!
(PS: This is why, in my opinion, the following Feature Request is just not possible: https://www.jamf.com/jamf-nation/feature-requests/9251/jamf-connect-forgotten-password-solution)