We are setting up our first Macbook Pro with the new M1 chip. When we enable filevault, the user is prompted for their username and password on boot in just blank fields (one for username another for the password). The drive unlocks and then they get the login with with their badge icon and they have to log in again?
Any idea what is going on?
The only think that I have seen that sounds similar to this is when someone has their local (non-bound) user account password changed via script or a push rather than through the Users and Groups system pref, which causes FV2 to not be changed. This causes FV2 to prompt for the old password and then the normal logon prompt for the new password. Resetting the local user password in Users and Groups solves this.
I doubt this is the same issue since nobody mentioned changing a local password before seeing this - but it may be worth a shot to try to change the local password in Users and Groups (even to the same password) to see if that might re-synch the passwords (or users in some weird way) as a test to see if that has any effect. If it DOES work (which I doubt) it may point to something tinkering with the local user account/password and not doing the same to FV2.
We see something similar but not a double login.
Mac is AD bound, mobile account, with FV on.
At boot we get a black screen with progress bar for about 10-15 seconds. The login/password box, once authenticated which I assume is FDE auth it boots to the desktop as FDE details are the same as the mobile account details.
What we don't see at auth that we see on intel Mac's is the user images and then just password box.
We've been seeing this issue as well. Usually it's after all configs from Jamf have completed. Haven't found a way around it, but no passwords are being changed before we see it. So far it's been reported on one 11.1 M1, but previously we saw it on 11.0 and 11.0.1. I'm generally seeing it after a restart, then I run software updates. After that I can reboot the machine several times and don't see it asking to verify the startup disk. Since we don't have zero touch yet, I'm able to catch it before deployment, but I'd still like to see this gone.
Havent seen this so far on M1 MacBook Pro - FV enabled via config policy. Upon reboot, I get the FV enabled users (we have 2) and upon selecting the user just enter password, then we get our acceptable use policy agreement, then the desktop.
Seeing the same thing on my demo Macbook Pro M1. I was getting the list of users and the associated icons before enabling Filevault. Afterwards, I started getting the login prompt to enter a username and password. Our default configuration profile sets the login window to show all user accounts. The profile applied successfully to the Macbook M1. However, when I check User and Groups (Login Options) it is set to Name and Password and is greyed out (even after unlocking the preference pane). I removed the default profile and it allowed me change it manually to List of users. Once I applied the default config profile back, it changed it again. Only happening on the M1 Mac. All of the others successfully stay on List of Users for login options.
Isn't this behavior expected though? The machine is encrypted with FileVault. It requires authentication to boot up. Once authenticated to boot it can proceed to the login screen. This is how my checkout [Intel] Macbooks have always behaved.
Having the same here on an Intel mac with FV enabled (OS 11.2.2). It makes it look like they have to log into the same window twice. Before it was pretty clear they were logging in for FV then again for the OS, now it just looks the same.
Started seeing this now on 11.2.3 with Jamf Connect 2.3.1 (havent updated to 2.3.2 yet). Also, system hangs at the progress bar and I have to hard shut down. Sometimes a second shut down is needed for the machine to log in.
For FileVaulted Mac's the login/password boxes instead of user icons is expected as this is Apple's unified login.
The way M1's boot to Filevault authentication has significantly changed see Rich T's post:
Did some more testing... I first tried removing any config profiles that had Kernel Extensions, ran a machine fresh through the enrollment (DEP) process. Still had the issue. I then replaced my current version of NoMADLogin (v1.4) with the newer 1.5RC2, ran a machine through a fresh DEP enrollment, it was fixed! I was able to login once and it brought me straight to the desktop. I'm still very interested in what NoMadLogin 1.5 does differently on the M1 machines. Anybody have any insight? I tried looking at the config settings for NomadLogin (using authchanger -print) and I couldn't really see anything obvious.
Maybe too late to comment this, this has to do with a function called FDEAutoLogin. NoMadLogin 1.4 does not respect that, meaning you will have double login. For this reason we changed to JAMF Connect which the OS will pass the login credentials along and the users on FV login screen will go to the desktop upon entering the password.
We run this and it sets the Filevault unlock to the logo.
sudo defaults write /Library/Preferences/com.apple.loginwindow SHOWFULLNAME -bool NO ; diskutil apfs updatePreboot /
You can also check out the comments here: https://derflounder.wordpress.com/2021/01/17/filevault-login-screen-differences-between-intel-and-ap...
Anyone happen to have any updates or other workarounds for this issue? Odd that this has been the case for about a year now and there isn't a good workaround for it. The command above doesn't really seem to help in our environment. Wish the person that says they are using NoLoAD version 1.5 RC2 above would say where they got it from so we could test it, too. This is a major inconvenience now that Apple stopped selling the Intel chipsets and we're forced to purchase M1s.
I share the same thought with you, however given the route that Apple has chosen to go, either you play their games or you ditch them and go Windows. My preference has been slowing moving to the latter in the past few years of the stringent requirements from Apple and make their devices less IT friendly.
I don't even know how many nights of sleep I spent trying to get testing and researches done for various Apple issues. My work doesn't pay me to do research and development, they just want things done. You know what I mean?
I was able to obtain NoMADLogin 1.5 RC2 from the Macadmin's slack Nomadlogin group. I will warn you, version 1.5 is only suppose to work on ARM processors. For my environment I have it scripted when my Macs enroll, v.1.4 gets pushed to the Intel based machines and v.1.5 gets pushed to the ARM based machines (via Prestage Package Enrollment). The method does require some knowledge of scripting but is working fine for my process at the moment. This may not be a great solution for most users and keep in mind NoMADLogin is freeware so it only gets updated when the contributors find time.
Dude, THANK YOU. I kinda assumed it might have been on Slack, but wasn't sure. I'll tinker with it and see if I can get it to work with mine. I might use a similar script to what I use for installing Rosetta on our M1s to check the processor first.