Cannot see the JAMF Connect splash screen after restart

[Frank_Sonder]

I want to install JAMF Connect on Macs that will have Multi-User. FileVault is enabled, we use Okta as our IDP, I tried every possible key and attribute and the JAMF Connect screen only appears after someone logged in from Local then JAMF Connect appears or when someone Log Off. It defeats the whole purpose of having JAMF Connect. I mean we want anyone to login into the computer even tho they never logged in before and for that we need JAMF Connect to show up after restart but it doesn't.

Any solution please??

[SGill]

The solution is to stick with AD binding for now for shared environments until something changes.  Jamf Connect can only sync existing account data, not generate accounts the way AD can.  We use AD binding for that as it stands now and have been told not to change anything for the time being for shared environments.

[Frank_Sonder]

I get it but we don't have an AD environment. Plus if I pre-enroll my Mac or log off from the already user then yes I can login with any Okta credentials and it will create the local account while syncing with Okta. But I want to avoid that and just people login in whenever the machine has been rebooted or powered off.

[howie_isaacks]

By "splash screen" you mean that your Macs are showing the standard macOS login screen instead of a login screen generated by Jamf Connect? If so, the answer is likely with how you have Jamf Connect configured. For our deployments we used the Jamf Connect Configuration app to generate plist files. The plists were placed in configuration profiles for the Jamf Connect login, the menubar app, and the Jamf Connect license.

[Frank_Sonder]

By splash screen yes I mean the first screen that shows up when you restart your Mac. I'm on Monterrey latest version. Oh yeah I configured it as you said, got my plist generated from JAMF Connect Configuration and everything. Still doesn't work.

Do you mind sending me that plist, perhaps I can replicate it or see what am I missing and hopefully that could work.

[howie_isaacks]

Here's the plist. We are using Azure as our IDP so the plist may be different. I used a fake client ID in this example so I'm not posting our actual plist.

<?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>AllowNetworkSelection</key>
	<true/>
	<key>CreateAdminUser</key>
	<true/>
	<key>CreateJamfConnectPassword</key>
	<true/>
	<key>DenyLocal</key>
	<true/>
	<key>DenyLocalExcluded</key>
	<array>
		<string>f1techadmin</string>
	</array>
	<key>LocalFallback</key>
	<true/>
	<key>Migrate</key>
	<false/>
	<key>MigrateUsersHide</key>
	<array>
		<string>admin</string>
		<string>f1techadmin</string>
	</array>
	<key>OIDCAdmin</key>
	<array>
		<string>Admin</string>
	</array>
	<key>OIDCAdminAttribute</key>
	<string>roles</string>
	<key>OIDCClientID</key>
	<string>3a1d70c3-2f19-4c44-bfe9-87fa6449e560</string>
	<key>OIDCNewPassword</key>
	<false/>
	<key>OIDCProvider</key>
	<string>Azure</string>
	<key>OIDCROPGID</key>
	<string>3a1d70c3-2f19-4c44-bfe9-87fa6449e560</string>
	<key>OIDCRedirectURI</key>
	<string>https://127.0.0.1/jamfconnect</string>
	<key>OIDCUsePassthroughAuth</key>
	<true/>
	<key>ROPGRedirectURI</key>
	<string>https://127.0.0.1/jamfconnect</string>
</dict>
</plist>

[Frank_Sonder]

Thank you sir!

Will keep you posted after the results.

[howie_isaacks]

I helped someone with an Okta and Jamf Connect setup recently. I looked at their plist compared to ours. The Okta plist was shorter than our Azure plist. That said, I'm pretty sure your issue is that the settings that Jamf Connect needs to be there are not there.

[Frank_Sonder]

Tried again with your plist and that doesn't work.

No JAMF Connect screen after restart.

Are you Filevault and Monterrey 12.3.1 ?

[merps]

After restart, meaning at the FileVault screen? Jamf Connect can't work there.

It seems the closest thing you could do would be to set DisableFDEAutoLogin to true and Jamf Connect should show up after the FileVault unlock.

[Frank_Sonder]

Exactly! DisableFDEAutoLogin works but it defeats the whole purpose that an already created user has to log in first so that a new user can log in and create an account. I guess I'll have to create a bogus account so that people can log into it to create a new user...

[tjhall]

Don't think there's an easy way around it. If you are using Filevault then the first admin account gets the securetoken which is  passed on to subsequent accounts but as you mentioned, you still need to get past the FV login. Option is possibly to leave it on the Jamf Connect screen in sleepmode (instead of shutting it down).

[Frank_Sonder]

I'm on JAMF Connect 2.11 too

[tjhall]

Is this after the Monterey uprade. I believe you sometimes have to re-apply the Jamf Connect authentication after major upgrades. We have a policy that runs this process once (based on Monterey and Jamf Connect installed) : /usr/local/bin/authchanger -reset -jamfconnect

[CCATech]

This worked for me. Thank you.

[gabester]

@Frank_Sonder Hey this first macOS login screen you see, at the bottom, does it have

2 buttons =  Restart | Shut Down 

3 buttons =  Sleep | Restart | Shut Down 

If you're only seeing two buttons, then what you're actually looking at is the FileVault screen to unlock your disk. This is, unfortunately, functioning as intended. Once a user that is enabled for FileVault on the Mac enters their password to unlock the disk, the Mac boots up and either logs in the user authenticating to unlock FileVault, or if you change some settings, presents the login window (either native macOS with 3 buttons or Jamf Connect depending on exactly how you have things configured.)

If you need a multi-user Mac that anybody can walk up to and try to log in at, then your choices are not great - either have some default / shared account that everyone knows which can unlock the disk (but could be prevented from logging in to use macOS); but if you're going to do that you might as well disable FileVault. There may also be some 3rd party disk encryption solutions that have utility here, but nothing about this experience is very "it just works" Apple-like...

[smdaniel]

Thank you so much. You saved me so much. Ahh. I was pulling my hair out. Thank you haha.

[MikeyK]

I believe what @Frank_Sonder is referring to is the FILEVAULT lock screen, the short answer is...you will not be able to get the Jamf Connect login window to appear after a restart with filevault enabled.

Jamf Connect replaces the login screen, filevault encrypts the hard drive, you need to unlock the hard drive first to get to the os/login screen....and filevault unlock. 

You will need to decide if your business is okay without using filevault..if you lose a laptop, data etc. 

What are your options?
- dont enable filevault
- generic account with or without LAPS? (give it to the user to bypass filevault screen, then allow the user to create an account)
- take the device to IT or have a user who has logged in before to bypass filevault and then create their account. 

I might be wrong but that's how I see the problem. 
The major benefit of Jamf Connect is allowing IT to zero touch a device or send a device to a user and have them log in.  :)

[Frank_Sonder]

Thanks guys for those great tips and solutions!

So I do have to disableFDEautologin to see JAMF COnnect after the FV login. That works.

Is there a way to create a - generic account (does it has to be admin?) to that any new users can use that account to unlock FV and then login with their credentials in JAMF Connect? I tried in JAMF Pro to create the account but cannot enable FV (Beginning with macOS 10.13, you cannot use this method to enable a user for FileVault.) Any scripts for that?

[KatMaerz517]

What was your outcome? My situation is identical.. and I'm told to disable FileVault.. which is making zero touch impossible for shared devices

[Frank_Sonder]

In the end, I disabled FV so that anyone can go to the computer and enter their credentials from JAMF Connect to log in. So new users that log the first time on the machine don't need to ask an already logged user or admin to log in FV first.

[tjhall]

Would it work to apply FV after the user has logged in?

We apply FV via a config profile on DEP level but, the FV encryption is theoretically there to protect data and there's no data to protect until the users has logged in and uses the Mac.

So, in theory the FV could be applied once the user has been logged in the first time. The problem is to ensure that FV is actually enabled (since we don't want any rogue Mac's with iFV disabled). I know can run reports and alerts to find them but I worried it creates more work.