FileVault Password Out of Sync

[PI-Cloud]

I installed on a tester Mac and it did push the new password up to AD. No problem. I have MS-LAPS installed for the PCs. But FileVault retained the old password so I still have to enter that on boot up of the tester box.

I haven't been able to get it synced yet. Has anyone else had this problem?

[briend]

This is sort of related to the keychain issue. Before changing the password we need to know the previous password, and make sure we don't lose that until filevault and keychain are both updated. The very first run, this is problematic since those passwords don't exist in AD. So, maybe an optional "bootstrap" password can be provided to macOSLAPS to get it going. This is all related to issue #8 since we need to be very transactional and careful we don't end up losing the "new" password into the void somehow.

[ghost]

As far as I can see, there is no action taken at present to use the 'old' password to update Filevault or Keychain. By default, the Keychain is simply deleted; if the approriate configuration setting is applied, then the Keychain is left untouched.

Either way, on High Sierra, the macOSLAPS account 'loses' its secure token status. Sysadminctl still reports that the account has secure token enabled, but any attempt to use that account to modify FileVault will fail. If there is a second admin account to hand which has secure token, then this can be used to remove and re-add the secure token from the macOSLAPS account. The macOSLAPS account is then able to manage FileVault, but only until macOSLAPS changes the password again.

I think that this makes macOSLAPS next to useless: even if the macOSLAPS account is not filevault-enabled (i.e. because there is a filevault-enabled Standard account which is used for FV logins), the macOSLAPS account no longer has access to the full range of admin functions. It becomes necessary to keep another functioning admin account with a static password in order to re-enable the secure token on the macOSLAPS account, thereby removing the benefit of macOSLAPS.

[briend]

https://github.com/joshua-d-miller/macOSLAPS-Legacy/issues/10

I tested this a bit, and it seems to work. macOSLAPS will change the password to a new random one, and then if you change the code to use sudo to change the password again to the same thing, filevault will be updated w/ that new password. All without knowing the previous password. This was with the python version of MacOSLAPS but should be the same w/ the swift version as far as I know.

[joshua-d-miller]

So it looks like you are piping out to bash to change the password. I'm wondering if that file is open source and we can see exactly how it is changing the password for the account so that it updates FileVault as well.

[joshua-d-miller]

I have added secureToken support in the latest release. Please give it a try!

[jeolsen]

Question on this. When a system gets prepared for a user, FV2 is enabled for just that user. We have had macOS LAPS deployed for a few months now and successfully randomizing the password of our "Emergency Admin" account on each system. That account gets created with a Jamf "Local accounts" payload and has the "Enable user for FileVault 2" checkbox set.

Since we don't know the password of the regular user assigned the device, and the password for each emergency admin account is already random, will the "FirstPass" value still work? Yes, it was that value when the account first got created, but it hasn't been that value for a long time now since macOS LAPS has been randomizing it. I think i just need some clarification how this works for existing systems, and if simply setting the FirstPass value in the config to the "initial" password for that account will still work.

Thanks

[txhaflaire]

@jeolsen FirstPass means currently known password for that particular emergency admin user. So for devices that already haves randomized password this will be hard, or you script something out that will pull out that password from AD, en set that with the defaults command to -FirstPass and not via the .plist.

[jeolsen]

I've started looking at writing a script to do that. We can use DSCL to query for that attribute:

dscl -u USERID /Active\ Directory/DOMAIN -read /Computers/COMPUTERNAME$ | grep dsAttrTypeNative:ms-Mcs-AdmPwd: | awk 'BEGIN {FS="dsAttrTypeNative:ms-Mcs-AdmPwd: "} {print $2}'

That will get the value, but we need to authenticate AD for it to work since that attribute is locked down so not everyone can read it. This means i'll likely need to hard code in a service accounts password in the script. Normal user on the computer wouldn't have access i don't think. The computer account only has write access, not read access i believe.

After getting past that hurdle, we'd then need to store that value in the FirstPass key in the plist. But if one can't be found in AD (meaning it's new), then we'd set the initial password in there instead.

Is this the only way to get it done? How is everyone else doing it?

[joshua-d-miller]

The password is saved to the keychain with each run. What you could do to proactively get the other systems is create a script that prompts a secureToken user for their password to grant your LAPS admin secureToken after it has run once on the new version.