macOS High Sierra 10.13 issues with AD and password changes.

[osxadmin]

it looks like there's a bug/issue on 10.13 for macs that are bound to AD, when the users tries to changes their password, it seems to have changed it, but in reality it doesn't.

anyone else experiencing this issue?

[GMow]

Has anyone confirmed that all these Password issues are resolved now in 10.13.3? I've still got a block on Upgrades to High Sierra due to this in my organisation. Cheers

[nateburt]

With 10.13.3, AD, FileVault2, and changing AD password elsewhere, I experienced the same pain points as always. FV2 password updates only after the first login to macOS with the updated AD password, and the old login Keychain password needs entered to "Update Keychain Password". Thankfully, the keychain prompt no longer offers to continue - you are prompted to update, or create a new keychain; that's a big improvement, at least since Sierra.

[nwiseman]

So we just noticed an issue where changing AD passwords through our "password change portal" changes the password as planned, but does not update FileVault. I have restarted numerous times and it seems to be affecting all systems a user has. I've had some users test with only changing through System Preferences and that seems to work just fine. With one exception...that being if you've changed your password through the Portal first.

Seems like for at least us the problems from 10.13.0 and 13.1 are back again.

I have a ticket open with Apple and right now they seem confused. Seems their engineering departments and QA departments aren't quite what they used to be. High Sierra may very well be the Vista of macOS

[jason_bracy]

They are confused because they don't manage your Portal or your AD environment. There is no structure in place to change the FV password if the user changes the password somewhere else. This has always been the case.

The issue that you are seeing is that when the user restarts and the OLD password is passed through to the login window it is accepted because your Mac has not had time to make the connection to AD, and is using cached credentials. The fix that I use is:
1. Tell my users to NOT change the password via a portal, only use the System Preferences, login window or NoMAD
2. if you do need to change it via the portal for whatever reason, (i.e. you are off network when it expires) then the next time you are on network log out - don't restart - and log back in with the new password. This should display the password sync dialog box and sync your keychain and FV with your new password.

[analog_kid]

@jason.bracy Unfortunately, that's not an option for some of us-- password changes flow down from an Identity Management system to AD and other systems, so we don't allow users to change passwords from the workstation. In Sierra, password changes from our IM portal did semi-reliably sync to the client (and update FileVault) so the loss of this functionality is definitely annoying. This is something they can test for without replicating our environments IMO.

Agreed that Apple QA is squarely in the dump at the present time.

[jason_bracy]

@analog_kid , that makes sense. I was seeing the issue in 10.13.0-10.13.1, but it went away in 10.13.2. Seems to be back in 10.13.3.

I've filed a bug report with Apple. The only way I've been able to resolve the issue is to add a new FV user, remove the out of sync user, add him back in and then remove the temp user I had to do this via CLI as the System Preferences kept failing - probably due to the mismatch password: So first I created a new user called "tempfv"

#!/bin/sh
$ sudo fdesetup add -usertoadd tempfv
Enter the user name:user1
Enter the password for user 'user1': enter the password used to unlock drive
Enter the password for the added user 'tempfv':
$ sudo fdesetup remove -user user1
$ sudo fdesetup add -usertoadd user1
Enter the user name: tempfv
Enter the password for user 'tempfv':
Enter the password for the added user 'user1':
$ sudo fdesetup remove -user tempfv

It's a PITA if you would need to do this regularly, but I am only dealing with users who forget to change their password before it expires and decide to do it either via the helpdesk or the password portal. So only every now and then.

Hopefully Apple will fix it in macOS 10.13.4!

Thanks,

Jason

[abdo_iracheta]

I had that experience, so, what I do and it helped me out is going to System Preferences > Users & Groups > Login Options > Click on the Edit button, then I'll delete the AD domain, once I do this, with casper remote I can bind again the Mac, and this helps to sync passwords, hope this help you

[monaronyc]

Has anyone been able to figure out a clean way of getting the AD password and the FileVault Preboot screen password to sync? We're in 10.13.3 and it's still a problem for us. We've seen more than a million and one ways to try and fix this, but nothing seems promising. Any ideas?

[MatG]

Always change the password on the Mac in Sys Prefs> Users & Groups

Changing it external will cause Account and FV passwords not to sync.

Other option is Nomad

[monaronyc]

Changing the password in Sys Prefs > Users & Groups isn't working. At least not for us. The AD password changes successfully but not the FileVault Preboot login password. Preboot still wants the expired password. What else you guys got?

[amp3345]

I am experiencing the same issue as monaronyc... Users can change the AD pw via Users and Groups, however, it does not sync to the Preboot screen. Same issue has been reported on this post as well..

https://discussions.apple.com/thread/8279272

This is preventing us from moving to High Sierra enterprise wide. Hopefully a fix comes soon!

[xanderplooy]

Has this been resolved (natively, without workarounds/Nomad/etc) in any recent High Sierra version? Current is 10.3.5 released on 1 Jun at time of writing.

[djorgenson]

No, has not been resolved. Still happens with the latest current version of High Sierra (10.13.6).

The weird this is the work-around I've found. If I bind to AD with Create Mobile Account OFF, I can successfully login to the AD account, then go into System Preferences -> Users & Groups -> user just created, I can click on the button that says "Create Mobile Account", bam sets it up as a Mobile User and works perfectly after that.

I don't understand. Luckily we setup new machines for people ahead of times and can do that.

[tinsun]

@seann @kendalljjohnson We have the same problem. The admin accounts that we control via AD groups don't work. The fix is simple enough but a PITA: unbind AD via script, and then rebind it. Have you managed to automate this to trigger on everyone who's done an update to 10.13?

Thanks in advance.

[jrippy]

For us at least using Config Profiles for the Directory Payload AD Bind and Mobility Payload to enable mobile accounts, the AD password updates but the preboot password is still the old password for a time.
After some time logged in (we haven't been able to narrow this down to a specific amount of time yet), the Preboot password will get updated and be the current password on subsequent reboots.
This has happened on 10.13.6.