+2Hi everyone,
I just finished setting up Jamf Connect with my Jumpstart call and afterwards I discovered my users have to log in twice. We are using Okta as our SSO and that is setup and connected. But when I restarted the computer, I get the Mac login screen with my user name and my password works and I immediately have to login in with my SSO credentials again. Is this normal or can I get one of these screens eliminated?
Best answer by Tribruin
You are seeing two different login screens. The first screen is the File Vault unlock screen. This screen is presented pre-boot and is the computer is not yet booted to the O/S. Authenticating here unlocks the volume to boot.
The second login screen is actually authenticating to Okta. This is where your user will authenticate against their Okta (or local) account.
You can actually turn this off, pretty easily. Set the following setting in your Jamf Connect Login plist:
<key>DenyLocal</key>
<false/>By setting DenyLocal to false, JCL will authenticate against the local account first and only check against Okta if a local account does not exist. On first boot, Apple passes the user authentication from the FileVault screen and JCL will use that to login.
Just be aware there is a slight loss of security as JCL is no longer querying Okta before allowing the user to login. You would lose the ability to lock a user from logging in by changing their Okta account.
You are seeing two different login screens. The first screen is the File Vault unlock screen. This screen is presented pre-boot and is the computer is not yet booted to the O/S. Authenticating here unlocks the volume to boot.
The second login screen is actually authenticating to Okta. This is where your user will authenticate against their Okta (or local) account.
You can actually turn this off, pretty easily. Set the following setting in your Jamf Connect Login plist:
<key>DenyLocal</key>
<false/>By setting DenyLocal to false, JCL will authenticate against the local account first and only check against Okta if a local account does not exist. On first boot, Apple passes the user authentication from the FileVault screen and JCL will use that to login.
Just be aware there is a slight loss of security as JCL is no longer querying Okta before allowing the user to login. You would lose the ability to lock a user from logging in by changing their Okta account.
+2Thank you Tribuin, I have a follow up question with this. How come at the File Vault unlock screen I can not see any of the other local accounts? If a user forgets their password, I want to be able to login under a local that is already on the computer.
Can open, worms everywhere! 😂
For a user to be able to unlock a FileVault enabled computer, they need a to have been granted a SecureToken. In most cases, the first user created in setup assistant (and logging in) is automatically granted a SecureToken. After that, who else gets a secure token depends on mulitple factors (What version of macOS is running? Is the computer MDM enrolled? Does it have a Bootstrap Token? etc.)
The easiest solution is to go in to System Preferences -> Security and Privacy -> FileVault and enable your admin user for FileVault. But, that doesn't scale very well.
I would recommend this website: https://travellingtechguy.tech/ for lots of good blog posts about FileVault, Secure Tokens, and Jamf Connect (and some good recommendations about how to use them all together.)
+7You are seeing two different login screens. The first screen is the File Vault unlock screen. This screen is presented pre-boot and is the computer is not yet booted to the O/S. Authenticating here unlocks the volume to boot.
The second login screen is actually authenticating to Okta. This is where your user will authenticate against their Okta (or local) account.
You can actually turn this off, pretty easily. Set the following setting in your Jamf Connect Login plist:
<key>DenyLocal</key>
<false/>By setting DenyLocal to false, JCL will authenticate against the local account first and only check against Okta if a local account does not exist. On first boot, Apple passes the user authentication from the FileVault screen and JCL will use that to login.
Just be aware there is a slight loss of security as JCL is no longer querying Okta before allowing the user to login. You would lose the ability to lock a user from logging in by changing their Okta account.
thanks for your solution
+7You are seeing two different login screens. The first screen is the File Vault unlock screen. This screen is presented pre-boot and is the computer is not yet booted to the O/S. Authenticating here unlocks the volume to boot.
The second login screen is actually authenticating to Okta. This is where your user will authenticate against their Okta (or local) account.
You can actually turn this off, pretty easily. Set the following setting in your Jamf Connect Login plist:
<key>DenyLocal</key>
<false/>By setting DenyLocal to false, JCL will authenticate against the local account first and only check against Okta if a local account does not exist. On first boot, Apple passes the user authentication from the FileVault screen and JCL will use that to login.
Just be aware there is a slight loss of security as JCL is no longer querying Okta before allowing the user to login. You would lose the ability to lock a user from logging in by changing their Okta account.
Are we are able just user login with okta not the local account created by Okta and jamf connect
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.