High Sierra Mobile Accounts

[morgan_sd51]

Is anyone else having issues logging into mobile accounts on High Sierra?

We are not able to login to any of our AD accounts with "Create mobile accounts at login" enabled

whenever we log in we get the message, "You are unable to log in to the user account "morgan" at this time. logging in to the account failed because an error occurred"

Anyone have any ideas or is anyone experiencing the same issue?

[Aziz]

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

[steve_summers]

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.

[danny_gutman]

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.

[dan-snelson]

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

[TomDay]

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:

[duffcalifornia]

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

[smcmjeff]

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.

[whaking2k]

Anyone test this with the latest beta release?

[morgan_sd51]

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

[morgan_sd51]

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

[GregE]

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?

[ashbrook]

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?

[GregE]

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

[morgan_sd51]

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

Thanks

[isterling_goaaa]

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.

[steagle]

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?

[jconte]

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.

[steagle]

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.

[mike_paul]

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

[steagle]

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.

[jconte]

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

[steagle]

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

[steagle]

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

[jconte]

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

[alexjdale]

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.

[Lalu]

Hi all,

After successfully logged in using mobile account on OS Sierra 10.13.2, does the mobile home sync to user home folder work?
Has anyone try it? any comments or answer will be much appreciated.

[steagle]

Thanks for the feedback @jconte & @alexjdale - unfortunately, these fixes do not work in our environment. As a reminder, we are not using AD. We use FreeIPA, which is an open source Linux adaptation of LDAP. It works fundamentally the same as AD, but AD uses its own proprietary version of LDAP. Clearly, the two platforms do not handle user authentication the same exact way.

To reiterate what is happening:
- A Mobile Account user has our FreeIPA directory server defined in Directory Utility on their laptop and can authenticate to it while inside our network. I.e., network login is working correctly.
- That same user cannot log into their account when outside of our network. I.e., macOS is not caching their network credentials for local login when it can't see the directory server. This local login worked fine prior to 10.13.x.

Does anyone here use a LDAP product like FreeIPA that has been able to solve this problem?

[steagle]

Anyone? Bueller? ;)

[jm_peterson]

@steagle Did you ever find a resolution to this? We are also using FreeIPA over here and have started to experience similar issues.

[bmcdade]

@jm_peterson I work with steagle and we don't currently have a solution for this. What version of FreeIPA are you running, a current version? As we haven't tested latest current builds yet.

[jm_peterson]

@bmcdade I apologize for just getting to this, never saw a notification. We are running 4.5.4 and still experiencing the issue. I've found a couple commonalities in the machines where this error occurs in /var/log/opendirectory.log which is interesting given that we do not use that. 93.3656, Module: ldap - failed to retrieve LDAP server schema - LDAP error - 48
93.4181.4182 - Client: opendirectoryd, UID: 0, EUID: 0, GID: 0, EGID: 0
93.4181.4182, Node: /LDAPv3/freeipa.org.com, Module: ldap - __odnode_copy_record_block_invoke: 4101 No predicates provided and in /var/log/krb5kdc.log
WARNING Found KDC certificate (O=System Identity,CN=com.apple.kerberos.kdc)is missing the PK-INIT KDC EKU, this is bad for interoperability.
These errors are only present in machines that have had the network accounts issue.

My best guess at this point, based off the LDAP 48 error, is that the machine is not passing the correct credentials or does not have access to authenticate against the cached credentials when there is no network connection.

[bmcdade]

@jim_peterson - Thanks for the update.

Oddly enough I don't have either the krb5kdc.log or the opendirectory.log files on my bound machine. I can bind to the LDAP (FreeIPA server) and it does allow network login but however no matter what I do, I can't create those local/mobile accounts with a valid password. I guess we may now looking at migrating over to Jamf Connect + Okta, where our Okta account is bound to the FreeIPA server, it's a bit of a run around but if it works and we can get account management control for both on and off network, then we are more then happy to go that route.

[latorrep]

Hi @morgan.sd51 , I have seen this error before and its related to the home folder, if you remove the homefolder from Active Directory on the allocated space (Ex: yourdomain.localsharedspaceusers%username%) and replace it to the local path you will be able to login the user. Once the user has logged in, you can add back the shared space.

Cheers!

[macsysadminjamf]

came in just to post that I miss 10.6.8 when everything worked pretty well.......

[aprild]

@latorrep your comment has resolved my issue! I remembered seeing the error in the past when trying to create a new user but an existing home directory was named with the corresponding account name. However I have very little Active Directory experience and would never have known to look there. Thanks!!

[kwaber]

@bmcdade @steagle did you ever manage to get a mobile user to log in when off network? I also run FreeiPA and tried it on High Sierra and Mojave and both present the same problem. While online mobile accounts can log in no problem. Tried the suggestions in this thread wrt to securetoken, as well as removed sqlindexes from /var/db/dslocal/nodes/Default but still no success. Thank you in advance for your answer

[bmcdade]

@kwaber We still have the issue with FreeIPA and Mobile accounts on High Sierra and Mojave. We are now looking at using Nomad Login+Okta as a solution. It seems that Apple really killed the LDAP binding in High Sierra and later and haven't found a solution.

[Tophernad]

@bmcdade @steagle We are using AD with an LDAP plugin. We are having a similar issue where the computer logs in fine if they are on network but doesn't cache their credentials. Any luck in figuring out the issue?

Thanks!

Topher Nadauld

[WellsJtech]

@Tophernad Anytime I had issues with our AD bound Macs it was resolved by unchecking “use UNC path from Active Directory” option in Directory Utility. No changes on AD needed.