Login hanging after Monterey Upgrade - FileVault issue T1 MacBook Pros

[JustGoogleIt85]

Ok so we have a very weird issue here in my org and I wanted to see if anyone else has ever run into this. On some of our late-2016 and mid-2017 15" Pros, users are having login issues post Monterey upgrade (12.1 and 12,2). When they attempt to login to their account it accepts their password but then just sits there with the progress bar and never logs in. Sometimes the account will let you in, but the users have no menu bar, extremely limited access to the keyboard, and it just never really logs in all the way. But you can use the keyboard shortcut to logout and then log back in with no issues. So given these experiences and after troubleshooting further, we have pinpointed that this issue is with FileVault. We can also go through a password reset with the recovery key, but never change their password, and the users can login with no problem; they can also login fine if we turn off FV and decrypt the drive. But then as soon as we turn FV on again and the drive encrypts the issue is back after the next reboot. We have almost 40 of our 2018 and newer MacBook Pros on Monterey with no issues at all but out of the 16 of the 2016/17 models we have had 6 experience this...Its scary because 200 of our Macs are one of these 2 models so we paused our upgrade rollout until we can figure this out.

We also have a ticket open and are working on this with Apple but I figured I would throw this out here in case anyone else has run into this. I am waiting for their support to get back to me with more troubleshooting. Anyone have any ideas of stuff to try while I wait to hear back from them? So far they've had us verify that the FV/user password are synced, and that the user has a secure token and its enabled for their account. 

[ianatkinson]

We have tested this here and found it to be working however the additional step that @OhMyGlosh has mentioned of deleting the mobile account seems necessary, however we don't think it's necessary to remove the local home folder.

So the steps working for us are

1. untick the use UNC path option

2. delete mobile account (leave home folder)

3. re-create mobile account

you would think Apple could fix this now given that it's narrowed down to that option but I won't hold my breath!

[ianatkinson]

Soooo interestingly after thinking this was affecting 2015-2017 models and Monterey we had a user this week upgrade from Big Sur to Ventura on a 2019 MBP and the exact same issue occurred. The fix also worked (turning off use UNC path and re-creating MDM account) but this seems more widespread than we thought.

[jac807]

I think it has to do with the UNC path trying to hit AD and map and it never is able to, it should time out and login but it does not and gets stuck.  We only had a handful of devices do this and since changing our AD bind options this appears to have went away all together for us.  I have yet to open a ticket with Apple about it as I know there stance on binding to AD (they do not recommend) but we are stuck with this option for certificates right now until infrastructure gets in line.

[ianatkinson]

We've decided to just get rid of the UNC setting since it's being such a pain, as others have said people can make a shortcut to their network home if needs be.

Having done some testing is seems as though you can disable the setting and then remove the home folder properties from any mobile accounts without needing to re-create the accounts or delete anything. I think this is useful since it can be done in a policy without recalling staff or machines.

This little script may be of use to others it should achieve both things:

#!/usr/bin/env zsh

echo "disabling option"
dsconfigad -useuncpath disable
echo

for i in $(ls /Users | egrep -vi "(admin|jamfmgmt|shared|^\.|deleted)") ; do 
   echo "clearing properties on $i"
   dscl . delete /Users/$i SMBHome
   dscl . delete /Users/$i OriginalHomeDirectory
   dscl . delete /Users/$i OriginalNFSHomeDirectory
   dscl . delete /Users/$i dsAttrTypeNative:original_smb_home
done

[OhMyGlosh]

We have tested what is posted above and it seems to work well for us. Just want to note that others will want to modify the accounts that are ignored in the "for i" line. 

[ianatkinson]

glad that was of use, it was a bit hastily cobbled together and also wasn't handling spaces in names I think this was the final version it ended up at (still hasty but it's a one time fix so doesn't need to be super pretty)

#!/usr/bin/env zsh

echo "disabling option"
dsconfigad -useuncpath disable
echo

OLDIFS=$IFS
IFS=$'\n'

for i in $(ls /Users | egrep -vi "(admin|jamfmgmt|shared|root|^\.|^_|deleted)") ; do 
	echo "clearing properties on $i"
	dscl . delete /Users/$i SMBHome 2>&1 | egrep -vi "(invalid path|unknown)"
	dscl . delete /Users/$i OriginalHomeDirectory 2>&1 | egrep -vi "(invalid path|unknown)"
	dscl . delete /Users/$i OriginalNFSHomeDirectory 2>&1 | egrep -vi "(invalid path|unknown)"
	dscl . delete /Users/$i dsAttrTypeNative:original_smb_home 2>&1 | egrep -vi "(invalid path|unknown)"
  done

IFS=$OLDIFS