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?
Yes, I got an email from Apple yesterday.
have you received a notice on any estimated time when they will release a fix?
Lets remember that Apple took THREE dot versions of Sierra to eliminate the hideous badpasswordattempt bug which saw many MANY AD users locked out of their accounts. They don't seem to be QA'ing AD much if at all, and have tried to outsource their enterprise QA to their customers. Sorry Apple, but you don't pay me (or seemingly anyone) to QA the enterprise features of your product.
@jason_d wow even Enterprise Connect broke. What the heck is happening at Apple. Must be PTSD....
@osxadmin Apple almost never provides advance notice on updates/fixes.
Personally, I am surprised this type of issue made it out of Beta or GM into Zero Day release...unless it was not in Beta or GM? Pure speculation on my part.
Wait! Are you saying a 10.xx.0 release of OS X broke Active Directory integration?? Well, blow me down! That's never happened before!
So, I'm having the exact same issue with our Macs which are bound to Apple Open Directory. So they really messed this one up. Hope the fix will follow quickly.
Historically, the OS updates come out about every 6 weeks (+/- 1 or 2)I wouldn't expect 10.13.1 until end of October-ish
And, it wasn't until 10.12.3 in late January that we got the crippling iCloud AD account lockout bug fixed.
Just discovered another potential issue...
While it is just my first test case, upgrading from 10.12.6 to 10.13.0 broke the administrative privileges set in our Directory Bindings via JAMF.
We have groups in AD setup to "Allow administration by" and after updating to 10.13 those accounts would not work to elevate. If I unbound and rebound with our Binding policy the group regained admin privileges.
@kendalljjohnson Yes we've seen the same thing. Local accounts with admin privs aren't affected though, only AD groups granted admin access have this issue.
Makes sense if AD integration is broken. It sounds all around like Apple really bunged up the AD piece here. But what else is new? They are consistent on this issue if nothing else.
"Why are you using a core business service like Active Directory? You should let everyone use local admin accounts of their choice! IBM does it! Or use Enterprise Connect! Wait! That is broken too! Switch your Macs out for iPads!" -Apple
anyone else seeing an issue with AD bound computers having issues with users not being able to log back in if they do the upgrade off site? i have 6 users who have upgraded while traveling and now they are unable to login to their computer.
@shunt Yes, we have at least one user who upgraded off-site and couldn't login local post-upgrade to macOS High Sierra 10.13.0 (17A365).
(And the release notes for macOS High Sierra 10.13.1 beta (17B25c) don't seem too promising.)
I have run across this behavior. If I take a 10.12 machine which is bound to our AD and upgrade it to 10.13, everything works just fine, the user can log in.
However, if I try a clean install of 10.13 and bind it to AD with mobile accounts turned on, it will not login, just gives a generic error message saying something went wrong.
If I setup a new machine with local accounts on, everything works fine, can login to the same AD account that would not work using mobile accounts.
Go figure. Anyone have any ideas, or do I skip building new 10.13 loads for now?
we had an Apple System Engineer came on campus yesterday, and he did confirmed late bug issue with High Sierra and AD/Mobile accounts/changing passwords etc..
His advise was to hold off upgrades...
Apple Professional Services emailed this morning:
Just a quick update regarding the issue with password changes while bound to Active Directory and logged into your Mac with an Active Directory account in macOS High Sierra.
If your organization is impacted by this issue and you have a paid Apple Developer Program account or Apple Developer Enterprise Program account, please test macOS High Sierra 10.13.1 beta seed 17B25 or later, which includes a fix for this issue.
In my limited testing, this issue is NOT resolved in macOS 10.13.1 (17B25c).
@shunt @dan.snelson - Yes! So glad we arent alone in finding the locked out after installation issue!
We have found that logging in with a local admin account and re-binding the machine does allow AD accounts to log in, then we have to re-sync the login/FV password in System Preferences > Security & Privacy > FileVault - Enable Users. Oddly, it still shows that the user who just clearly unlocked the drive cannot unlock this.
@shunt Yep, got hit by this personally and had to drive back to the office to be able to login with my network account. ;(
@dhorsfall We've noticed in our environment (AD Mobile accounts) that you don't have to re-bind, just authenticate the user in System Preferences from a local admin account (i.e. click on the Unlock icon and have the user login with their credentials). They have to be either on the network or VPN'd in, and have to be admins on the computer. Saves the effort of having to unbind and rebind. (we also had to have remote employees create a tempadmin account with the fancy Single User Mode trick of removing /var/db/.applesetupdone).
We've also experienced this issue. Somewhat related, using an AD account, I am not able to turn on FileVault at all with a brand new fresh install of High Sierra. I get the following error: "Authentication server refused operation because the current credentials are not authorized for the requested operation." but I am able to continue setting it up with a local account. The problem with enabling it on the local account is that it's our IT account and so my worry is that every time the machine reboots, I need to enter the IT account password to decrypt the drive instead of the AD user account. Then of course if this is true, then password changes required on the AD account side won't be cascaded to FileVault.
Does anyone know if NOMAD is working correctly?
i have now had users unable to login after the upgrade onsite but some of the users who have upgraded at home were fine. The user who was onsite, we just had to unbind the computer from AD and bind it back and she was able to login again. Apple still has not told me if they have came up with a fix yet or not. the only thing i have gotten out of them is that there might be a resolution to this issue in the next patch.
@jrepasky looks like Joel released a NoMAD update today to fix the pw change issue through NoMAD, link to post here:https://macadmins.slack.com/archives/C1Y2Y14QG/p1506968465000424
Once I found some clients could not log in using their ID and password that were using AD it wasn't necessary to unbind and re-bind. Have them use their regular ID and password but have them use an ethernet cable that is connected to the domain to log in. Disconnect the ethernet cable after and they're good to go. I understand that this is an okay work around if you have clients that are onsite and your team can run around with cables and adapters to resolve.I did try making the user an admin in sys pref but that did not work. Maybe something to do with how the profile was originally set up as a mobile/managed account?
Unfortunately in two instances so far I have found the computer name to be changed so that will need to be edited and re-binded but I will need to test this more. I hope not otherwise EPO will be a nightmare.
I can confirm this behavior, did anyone test with 10.13.1 to see if it is fixed?
I have installed the 10.13.1 Beta on a test machine. I can confirm that it did fix the issue with not changing the password in AD, but that is the only thing that it changed apparently. FileVault password and Keychain password did not change. I tried on multiple occasions changing the password on a test AD account and saw the same results each time. I have to turn off FileVault and turn back on in order for the new password to be set. I also have to create a new KeyChain in order to prevent annoying pop-ups asking for old password.
AD bound computers having issues with users not being able to log back in if they do the upgrade off site?
We've had one so far. User returned to campus with laptop, plugged in, and within 30 seconds, account authenticated.Not everyone will be this close....
Odd, when running the High Sierra Beta versions, no issues whatsoever.
Just upgraded off-site and could not log into AD account. But logged into local admin account, connected to VPN, fast user switched and all was fine. Really odd. but its seemingly clear Apple really has no interest in AD (not that I ever cared), but it will definitely trip up a lot of unsuspecting users.
On 10.13.1 GM we are still seeing issues with FV passwords for mobile AD accounts not getting updated.
Users changes their password, on next reboot the FV password is the old password but the user account is the new password.
Is this still a known issue with 10.13.1?
@MatG - we are still seeing this behavior on 10.13.1 clients, yes
yes still an issue with 10.13.1
Found on Slack:
We were see more issue in 10.13.1 with AD accounts and FV password sync issues. Apple have informed me:
“it appears there is an issue in 10.13.0 and10.13.1 where as long as the password is only updated from the Users & Groups pane, the FileVault password will get updated after rebooting and unlocking the volume with the old FileVault password ... but if the AD password is ever changed away from the client from the AD server, from a website, etc), the passwords do not get synced again, even after changing it again from the Users & Groups pane. This behavior has been reported to Apple and is being targeted for a future update."
Also.. NoMAD has a pref (hicFix) that resolves this on 10.13
Version 10.13.2 just came out and promises to fix some AD problems.
I'm running 10.3.2. I cannot enable fileVault as a domain account. I receive an error. Account "username" cannot be used to manage encryption on this Mac. Click lock to prevent further changes, then select another administrator account, and try again.
I have a test Mac here that I was running 10.13.1 on and I experienced the problem of the FileVault Password not syncing up with Active Directory after a password change no matter how long I let it sit. I just updated it to 10.13.2. After the update, I let it sit for a few minutes at the desktop then I restarted it. It now takes the password I changed it to a couple weeks ago.
It sucks that these really stoopid bugs are surfacing in High Sierra, but I am glad Apple is making progress on fixing them.
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
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.
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
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 NoMAD2. 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.
@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.
@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"
$ 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!
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
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?
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
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?
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..
This is preventing us from moving to High Sierra enterprise wide. Hopefully a fix comes soon!
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.
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.
@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.
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.