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!

</sarcasm>

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?

Hi guys

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:

Hello,

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).

1. Upgraded test machine to macOS 10.13.1 (17B25c)


2. Logged into an Active Directory Mobile Account


3. Updated password via System Preferences > Security & Privacy > General > Change Password …


4. Rebooted


5. FileVault still requires password in affect when encrypted

@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).

Hi All,

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.

Thanks,
Grant

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