Skip to main content

In testing, everything worked great for us. After that phase, we rolled it to a couple users in production and now all machines including our test ones don't work so great.



I take a machine that is bound to our AD domain and add a 802.1x profile so that the device connects via Wi-FI adapter. This works great. I then enable "create a mobile account at login" and logout. I login as an administrative AD user, and as expected the Mac creates a local account. I then enable file-vault and reboot.



At this point, the Mac sits at the un-encrypt login prompt (as is normal for a FV machine) with the AD user I just created the mobile account for. I authenticate, and the machine begins to boot. Once I get to the user's desktop, I am not connected to my 802.1x specified network, and as such I'm not connected as an AD user. My local user no longer has admin privileges (since it is derived from AD group membership). To make it work, I logout from this failed session (not rebooting), and wait a minute. After this point, I re-authenticate as the same AD user and now I'm connected to my Wi-Fi network as per my 802.1x profile, and have all my AD related stuff including shares.



My 802.1x profile is configured with certificates, my 802.1x network SSID, and is set to authenticate to this network as the user at the login window.



What seems to be happening is that the Mac has my AD user/pass locally stored (obvious since it unlocks the disk). At some point during bootup, the Mac enables the Wi-Fi adapter, but is either tossing the 802.1x profile aside since the profile is configured to work at the login-window, or it is failing and skipping since the Wi-Fi adapter is being enabled during the un-encryption phase at which point the user is already logged in for.



Even without FV, this would seem to be an issue where the machine will boot up to a login window and if the user tries to authenticate with an account that exists as a mobile user on this box, the Mac may allow them to login as the local user if the network isn't ready yet. Alternatively, if the user booted the Mac and paused at the login prompt to allow the network to catch up, their AD credentials might work for them instead.



I don't see any reliable way to distinguish if the user will login as a network user or a local user in this scenario. Is there a way to introduce a delay or reconfigure the 802.1x profile in the FV scenario so that the Wi-Fi will attempt to connect to my specified SSID with the currently logged in user? If that isn't possible, is there a way to have an AD user with mobile account login to a FV enabled machine and connect to a 802.1x network (and be logged in as an AD user) without having to logout/login again after unlocking the disk? Is it possible for a FV enabled machine to allow a user to unlock the disk and simultaneously connect to a network (Wi-Fi or ethernet) as an AD user?

I've not had to experience this but I image it's the FileVault 2 authentication-passthrough that skips the traditional login page (where it would wait potentially for an AD connection, thereby giving you what you need).



I guess you could try to disable the FileVault passthrough using the following command:



sudo defaults write /Library/Preferences/com.apple.loginwindow DisableFDEAutoLogin -bool YES


https://support.apple.com/en-au/HT202842



But that would require your users to login twice: Once at the FV2 pre-boot screen and again at the login window.



I hope that helps!



Darren

Darren, this is exactly what I'm looking for. Thank you sir!

HI Darren, thanks for the info.



I am trying to run this on a system that has already been locked out (cannot load the OS)



I tried it in SUM and I received a "cannot write" error.



Next, I tried booting in to recovery mode and using the terminal available there and received a "command not found" error.



Any suggestions on where else I can run this from on a system that was already been locked out?

For Single User Mode (I'm assuming that's what you mean by SUM) you'll likely need to mount the system first. It should tell you the commands to run when you boot into it.



To run the command from the recovery Partition, /Library won't work as it'll refer to the Recovery HD's library. You'll need to use something like "/Volumes/[boot drive name]/Library/...."



If the volume is encrypted, you'll need to unlock it first.



To be honest, I've no idea if the command will work once your device starts having the issue, but I can't think why not.



Hope that info helps!



Darren

Just to put it out there, we experienced this issue as well and I found some Apple documentation around it. Darren's recommendation is one of three options and frankly, the one we currently use.



With that said, the attached link explains the other two options:



https://support.apple.com/en-us/HT200093

@jyergatian I think it's worth knowing the other two options for your support staff at the very least, as a means of troubleshooting without changing configurations (there are other situations that I can imagine where it's useful to request a new TGT). However, from a standard config perspective, the auto-login disable is the most reasonable approach. It's a minor inconvenience to have to enter the password twice.

Terms & ConditionsCookie settings