I upgraded to High Sierra at home and was unable to log back in, probably because I'm off the domain.

For your issue, give my suggestion here a shot if you have Home Drives and AD:

https://www.jamf.com/jamf-nation/discussions/24353/macos-high-sierra-first-impressions#responseChild152738

One of our pilot testers had the exact issue. He updated off the corp network, had the issue then plugged in a network cable once in the office and got right in. Something had to have corrupted his cached credentials. Still don't have a smoking gun.

So I actually had this issue on the beta of High Sierra... and I thought it was simply a corrupted installation.

Then I tried it on the public release of High Sierra, and the same thing occured... logged in fine at filevault, then you get the login fields to login with mobile account, and it doesn't take a password. I was infuriated.

Take into account, I was at home for both of these installs.

Then I stumbled on @Aziz's and @steve.summers posts here right before I was about to do a Time Machine restore...

Hopped onto VPN from the admin account, logged off, then I was able to get into my mobile account.

WHY?!?!?! I don't know, but that's the fix if it happens to you... the OS is looking to talk to the domain before letting you in.

We received the following yesterday from Apple Professional Services with regard to Enterprise Connect:

Mac systems running macOS High Sierra in your organization may be impacted by an issue that prevents Active Directory password changes from working properly.

You may be impacted if Mac systems in your organization meet both of the following criteria:
1. Mac systems are bound to Active Directory
2. Users log into their Mac systems with Active Directory accounts (mobile accounts)

If you are impacted by this issue, changing your Active Directory password will appear to succeed, but the password will not be changed. If your users log into their Mac systems with local accounts (not mobile accounts) they will be unaffected.

Any tools that can change the password for an Active Directory based mobile account will be affected. This includes Enterprise Connect and the Users & Groups System Preferences pane.

This issue will be fixed in an upcoming macOS High Sierra update.

—Apple Professional Services

I upgraded while off our network yesterday and could not log in to my AD mobile account, as well. Connected via VPN to my network while logged in as the local admin, rebind to the domain and still couldn't get in. Gave up until I was on site again today, same conditions initially, then physically connected to the network, unbind from the domain, bind to the domain, log off as local admin, log on successful with my AD mobile account.

Something we notice whenever something is wonky with the cached mobile account, the option "Allow network users to log in at login window" is missing:

This may help. I was running into an issue where we could not create AD-based mobile accounts on High Sierra - we would get the same error message as you. This seems to have solved it, though obviously we're doing more testing:

Go into Directory Utility, then click the Search Policy tab. Take note of what's there. Then go into the Services > Active Directory settings where you bind, go to Administrative, then uncheck "Allow Administration By" and "Allow authentication from any domain in the forest". Click OK, then go back to Search Policy. You should now see additional directory domain(s) in the list. Drag the newly appearing domain(s) above the one that previously appeared and click "Apply". Go back into Services > Active Directory, and recheck the two boxes on the Administrative tab. Then try to log into/create the mobile accounts in question.

Hopefully that will work for you @morgan.strohmann

This is what fixed the problem for us:
https://www.jamf.com/jamf-nation/discussions/24353/macos-high-sierra-first-impressions#responseChild153400

Although it was confusing at first. We used to have Home directories on a Windows file share, so our home drive shares had a $ sign. Newer users don't have these home drives anymore (became a Google School). Only the older users with the Windows server home drives would get the error, when trying to log in with AD credentials (and the machine was set to create a Mobile account at login). We just unchecked the box.
Hope this helps.

Anyone test this with the latest beta release?

Just tried this with the latest beta to no avail hopefully apple gets on this as it affects many users and organizations

Good News! I just installed the latest beta onto one of my Macs (10.13.2 Beta 17C76a) and mobile accounts are now functional I hope to see this in the next big update for Mac

That is good news! I called Apple support to log a ticket and they offered a solution for a $799 support fee. Maybe we could all chip in to get it fixed?

I'm running 10.13.2 Beta 4 and still have this problem where mobile accounts can't authenticate when off-network. We use LDAP, not Active Directory, for auth.

Trawling throught all the logs I can find, to no avail. Anyone got any further?

Looks like it's resolved in 10.13.2 after testing that update on a few iMac's this week.

Running it on a few Macs in our district on 10.13.2 and its now correctly caching accounts

Thanks

In @dan.snelson's post from 9/26, his apple rep stated the following:

You may be impacted if Mac systems in your organization meet both of the following criteria:
1. Mac systems are bound to Active Directory
2. Users log into their Mac systems with Active Directory accounts (mobile accounts)

I can confirm that I'm still having this issue when trying to add users to FV2 from the GUI. Adding them in via CLI afterward did fix the issue though.

I also confirm that we are still having the issue after the 10.13.2 update.

We use mobile accounts that auth to a FreeIPA server, not AD. We have a package installer available via Self Service that configures the user's directory server & search paths, and installs the necessary Kerberos, crt and pam.d files. This installer worked fine on all OS's prior to High Sierra, but now users cannot log in with their network credentials if they are outside of our network (the login screen shakes, as if it's a bad password).

My thoughts are that something fundamental changed in High Sierra's handling of Kerberos and/or LDAP. I am still searching for what exactly changed, and what I need to modify with my FreeIPA installer to make this work with High Sierra.

Anyone else using FreeIPA or another LDAP-based directory service and figured out how to fix this?

We are using AD and still having the same issue. I think it has something to do with the Secure token.

You can try these commands:

sudo fdesetup list

If the network users aren’t in this list then it’s possible they need to have the secureToken authentication mechanism enabled. You can use the following command to check whether a user has this enabled or not:

sudo sysadminctl -secureTokenStatus userName

If secureToken is not enabled you can use the following command to enable it. Be sure to run this command as a user who has secureToken enabled:

sudo sysadminctl -secureTokenOn newAdmin -password newAdminPass

It hasn't worked for me but others report it works. It's manual until they fix the OS, but it might help.

Hi jconte,
I did the fdesetup lookup, and my mobile account user is not in the list. But when I run the sysadminctl command, I get the following response: "Failed to authenticate with SystemAdministration framework." I have tried with sudo and as root as well.

Have you tried with the interactive flag? I have found in 10.13.2 I needed to start using that for a lot of these commands

This fails for me with the same error: "Failed to authenticate with SystemAdministration framework." :

sudo sysadminctl -secureTokenStatus username

If I run that command without the sudo or interactive I get:

sysadminctl[66782:12014000] sysadminctl should be run as root, or in interactive mode! (Error Domain=NSOSStatusErrorDomain Code=-60007 "errAuthorizationInteractionNotAllowed: The authorization was denied since no user interaction was possible. ")

This interactive one with the prompt was successful:

sysadminctl interactive -secureTokenStatus username

Thank you Mike, running it in interactive mode did the trick.

Unfortunately though, enabling secureToken on my mobile account did not change the behavior. It appears that macOS is not caching the network login creds for local login when no directory server can be found.

@steagle, have you tried enabling it for FV via sysprefs and restart ? Mine took 2 restarts and then it showed up.
Interestingly enough new local accounts work fine, have you tried creating one just to see if it works. As a last resort this command actually helped as well.

sudo diskutil apfs updatePreboot /

The problem I have is that I have tried so many things and have gotten the mobile accounts to work with 10.13.2, I just don't have a coherent process. On Monday, I am going to try and recreate the issue and methodicaly create a workaround if possible. If I am successful, I will post here.

@jconte that would be wonderful if you could share your results. My testing with FV produced even worse problems - for instance, after enabling FV for a mobile user and rebooting, FV could not be unlocked with that user's password. Only my standard local admin user could unlock FV. Right now, I'm trying to get mobile login working with no other layers on top. Once that functionality is restored, I'm pretty sure I can figure out the FV issue.

@jconte did you happen to have any success on Monday?

Hi @steagle - I did have success, however it wasn't on Monday because I have been swamped. Here is my workaround to the AD Mobile Accounts not being enabled for Filevault. You must be logged into an account that has SecureToken enabled for the commands to work.
Username is the account you are trying to activate.

sudo sysadminctl interactive -secureTokenStatus username

sudo sysadminctl interactive -secureTokenOn username -password -

sudo diskutil apfs updatePreboot /

After the restart the user will appear at the PreBoot screen. Additionally, we have noticed that if you enable the AD mobile account for FV in Sys Prefs all you need to run is the last command.

Hopefully this helps...

Here's what I've done to address this. During system setup, our techs go through first-run setup and create the 501 user, as usual. When our configuration policy is run by the tech (to perform AD bind, install apps, etc) I prompt for that account's password. I use that to create a hidden "token escrow" account with a unique (but algorithmically created from the serial number, since I need it again later) password for that system using sysadminctl.

After the AD user logs in, a policy will prompt the user to enter their password. The script will use that along with the "token escrow" account's secure token to grant a secure token to the AD user using sysadminctl. Then it will run a trigger policy to apply a JAMF FV configuration, forcing it on at their next login.

Once the drive is encrypted, I can get rid of the "token escrow" account since I don't want an extra admin account hanging around.

This would be a million times better if JAMF builds this into the management account.