Well, basically AD integration on High Sierra is broken. Once again, Apple apparently forgot to invite the developer who does AD integration to the OS development party for High Sierra. (example thread)
Yes, that was sarcasm, but it sure seems Apple is consistent with this on their yearly releases. They seem to break it with each new x.x.0 version.

Anyway, I think the answer will be to wait for 10.13.1 to see if they fixed these issues, with any luck. Until then, you will be banging your head against the wall, and that doesn't seem worth it.

Welp, that will do it. Thanks for pointing out what I missed!

I am not seeing this issue, but we cannot login to bound machines because our home drive mapping in AD has a $ to hide it and Apple has decided it no longer likes it. Worked fine prior, except now because of this you can't even login to the machine unless you use a local account. Fun fun Fun

I'm not seeing this issue either, I have done an In-Place upgrade on our student loan MacBooks and login is working as expected.

@retroroscoe We're experiencing the issue as well, but only on newly imaged Macs. When we do an in-place upgrade the problem doesn't exist. Maybe check it as well on a newly imaged Mac to avoid problems later.

@mm2270 wrote:

Once again, Apple apparently forgot to invite the developer who does AD integration to the OS development party for High Sierra.

Seems like it. This would have been the perfect opportunity to push Enterprise Connect. If they had bothered to test on High Sierra.

#ironNoLongerHot

No problems on our side with AD login and 10.13

If a machine is already binded so far I see no issues, it keeps them after the upgrade. Have not had a chance to bind post install or on a new install yet.

I found this issue after an upgrade I could no longer login as my network (AD) account. Had to follow the advice in another thread about logging in as a local admin account and unbinding / rebinding to AD then I could login again as my AD account. I've put the block in as per this advice. Works a treat: https://www.jamf.com/jamf-nation/discussions/25485/restricting-users-from-updating-to-high-sierra-10-13-issues

Currently blocking High Sierra with that advice as well. Don't plan on upgrading until at least 10.13.1. Thanks for the heads up!

We bind to AD and use mobile accounts. After upgrade, login with new users still works, but permissions based on an AD group are no longer honored. Rebind!

Yeah, in addition to AD passwords not actually changing, we've got users who get admin rights via AD group that don't anymore (if you bind with profiles - seems to work OK if you bind with the Directory Utility and add the group after).

Oh, and no Touch ID for mobile users.

We are not experiencing that yet. All the AD security groups are still working fine and all the AD users with admin rights can still administer the device. Would love to see how different the setups are from ours.

Upgrading now through Self Service policy or App Store to 10.13.x breaks the management groups for AD administering the Macs bound to AD. In other words, if you have specified AD groups that manage Macs, and you upgrade from El Cap or Sierra to High Sierra, these groups no longer are elevated to admin after the upgrade DESPITE the GUI showing that they are still a part of the admin group.

@jamesgreenMattel We are seeing the same issue upon upgrades starting all the way back to 10.13.0, fortunately we apply the rights via a script and I have a policy that reapplies them after the OS updates.

At the end of our OS update policy, I use this command: touch /Library/Company/Logs/HSupgradeComplete.log. then an EA reports on if the file exists and a Smart Group tallies them. I have a cleanup policy that runs based on this smart group to reinstate the rights and reset our Managed Print system.

It's definitely not pretty but it does work around the issue until Apple resolves it.

As for a resolution from Apple, your guess is as good as mine which is why i chose to work around it.

Thanks
Jeff

@jconte We are experiencing the same issue here as well. Do you ming sharing your script to apply the admin rights?

Sure no problem,

#!/bin/bash

dseditgroup -o edit -a "Domainmacsupport" -t group admin

dseditgroup -o edit -a "Domainadm" -t group admin

dseditgroup -o edit -a "DomainDesktopAdmins" -t group admin

dseditgroup -o edit -a "DomainExec_Desktopadmin" -t group admin

dseditgroup -o edit -a "DomainLAWDTADMIN" -t group admin

dseditgroup -o edit -a "DomainEngineering_Admin" -t group admin

dseditgroup -o edit -d "DomainHD_Triage" -t group admin

exit 0

@duffcalifornia , Any RODCs in the forest?

Anyway, I have described here what's happening if you have Read Only Domain Controllers in your environment.

Yes working around it is the name of the game.
I have my own policies and scripts that fix it.