Skip to main content

Hello,

I have a situation in which an executive is having password synchronization issues with FileVault 2. I'm not convinced whether this is a technical issue, or something else. I figured I'd toss this one out there to get everyone's opinions.

We have a small rollout of FileVault2... we are only targeting laptops, which is today a small group of users. Our machines are all bound to AD using the native tools in Sierra. I myself had tested it for months prior to implementing it. We are storing both the individual and institutional keys on the JSS.

This particular individual has multiple issues everytime he changes his AD password. Usually his keychain does not get updated, and FileVault does not sync the new password. In the past, he has changed his AD password via a web interface rather than from his computer. He said this last time though, he did change it when prompted on his mac.

So long story short, to fix his password sync issue with FileVault, I removed him from FileVault and re-added him... allowing him to enter his password to set that back up. The exec now tells me that his FileVault password is still his old AD password and is still not in-sync. My guess is that he entered his old password again when I helped him add his account to FV again... but I could be wrong. Thoughts?

@Kedgar Have you confirmed the execs Mac is still properly joined to Active Directory. About 90% or more of the time when I see FileVault password sync issues, especially when talking about AD cached mobile accounts, it's that the AD bind is broken. When an AD cached account changes their password on the Mac, whether through Users & Groups, some other location on the Mac or within a portal, FileVault must then sync this password to match the new one, but if that account is from AD, and it can't communicate with AD, then FV2 is unable to sync the password.

If you haven't done so, I would run through some checks to be sure it can still communicate with AD? You can do that in a few ways, but usually doing a lookup in Terminal is the best way to know. If you can do an id -u username (making sure the username you choose is not already cached on that Mac) it will error if it can't do it, or respond with the user's UID string.

@mm2270 Thanks for the idea... I will check on that the next time he is in the office. One of the fun things with Executives, they are rarely in an office; and are always traveling. I don't like one-off solutions, however maybe for this type of very mobile user, something like EC or NoMad with a local user account (no binding) would be a better option.

What OS version is involved? We are AD bound and use FileVault in my environment. It wasn't until 10.12.4 that Filevault passwords reliably updated for us with AD users. If the keychain password is not being prompted for update, I'd be highly suspect of the AD bind like @mm2270 suggests.

Here's an extension attribute script I wrote to monitor AD binds. If it reports "Current AD OU: Data source (/Active Directory/mydomain/mydomain.org) is not valid." then I know the AD bind is broken. Otherwise it prints the current OU that the computer is in.

You'll need to update the DSCL command to reflect your AD domain information.

#!/bin/bash

ADCompName=$(dsconfigad -show | awk '/Computer Account/{print $NF}')

ADOU=$(dscl "/Active Directory/<mydomain>/<mydomain.com>" read /Computers/$ADCompName dsAttrTypeNative:distinguishedName | awk -F, '{getline; print substr($0, index($0,$2))}')

echo "<result>$ADOU</result>"

so for the dscl command would it need my AD OU? or just active directory/mydomain/mydomain.com?

Checkout https://nomad.menu/
We have it deployed to approx 4000ish machines now and it has solved alot of the Keychain issues you describe.
Make sure you force users to login into it and you have the other options to check for password changes and to sync passwords back.

@anthonytji, just your domian information. For example, if your domain short name is "AD", and your full domain name is "ad.pretendco.com", you would enter "/Active Directory/AD/ad.pretendco.com" in the script.

Terms & ConditionsCookie settingsAccessibility statement