OpenLDAP Mobile Accounts problems

hzimmerman
New Contributor III

Please excuse the length - part of this post is brainstorming for my own benefit. and part of it is documenting what all I have tried.

Environment:
10.8/10.9 client machines
10.6.8 OD servers
OpenLDAP servers
JSS 9.32
Mobile accounts with no syncing (so just local storage)

The client machines are currently bound to the 10.6.8 servers. A previous admin was using createmobileaccount scripts to create mobile accounts, and I found this was causing problems where credentials were not being cached on the client machine. I know the documentation all says that the credentials should be cached on first good login when the server is available, but I could image machines with the createmobileaccount script, log into the mobile account while connected to the network, and then be unable to log into the account if I pulled the ethernet cable.

This was resolved when I went to a Configuration Profile pushed down to the client machines. Mobile accounts were being created correctly and the credentials were being cached properly.

We would like to retire the 10.6.8 servers, and would like to move to an existing OpenLDAP system. Binding the machines to OpenLDAP has worked. Kerberos seems to work - I am able to load a Kerberos-ed web site in Safari.

The issue is that, without any other work, users end up with an empty home folder (since NFSHomeDirectory gets mapped to #/Users/$uid$/ which is nonexistent on login. So user foo knows to use /Users/foo/ but that folder is created without any contents. I would have thought OS X would fill that folder using user template, but I was incorrect.

The solution would be to use the same Configuration Profile as with OD, telling the machine to automatically create mobile accounts when any network user logs in. This instantly puts up an "Unable to create mobile account" error at the login screen and drops back to the login screen.

The next solution was to create a LaunchAgent to run createmobileaccount on user login. This did not work for some reason - the user kept ending up with an empty home folder again.

The last solution I just tried was to give up and create the mobile account at imaging. I created a script that runs createmobileaccount -u $4 and runs at imaging reboot. This works, but we run into the very first problem - the credentials are not cached, and losing network connection means the mobile account can no longer log in.

I have been testing with a 10.9.4 test machine.

1 ACCEPTED SOLUTION

hzimmerman
New Contributor III

After another two days of testing, I found the issue. Thanks to https://discussions.apple.com/thread/4136922?start=0&tstart=0 I found that I needed to map GeneratedUID to something, in this case uid. seanhansell was close with the UID suggestion.

I did not take the advice in the thread of making it the same length as the Apple provided GeneratedUID, instead just using our LDAP's unique seven digit uid.

Once I made that change the Configuration Profile for creating mobile accounts started working (so I no longer have to rely on createmobileaccount), and authentication was correctly being cached. Even better, the Kerberos TGT was being pulled down.

The next step is to start working on migrating existing users from their OD mobile account to OpenLDAP mobile accounts.

View solution in original post

6 REPLIES 6

seanhansell
New Contributor III

I think the problem might be that the UID needs to be mapped before first login. This can be done in the binding configuration, with the "Map UID to attribute" field. Enter here the name of the unique identifier field in your Open LDAP implementation, which by default should be "GUID"

- Sean

hzimmerman
New Contributor III

I configured a custom mapping for the LDAP server, with UniqueID mapped to uidNumber, and Users mapped to inetOrgPerson

dscacheutil -q user -a name foo

seems to return the correct values for user foo, including dir: /Users/foo

hzimmerman
New Contributor III

As a followup, I had been using ```
sudo /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -v -n foo
``` to create the mobile account.

Adding a '-P' (for createmobileaccount to prompt for password) does cache the password. Obviously I do not want to have to manually run the script for each machine deployment, but it is a step in the right direction. It is also not clear yet if the user changes the password will OS X cache the new password.

hzimmerman
New Contributor III

A month later, and I am still not much farther along.

The Configuration Profile route does not seem to work for whatever reason. It continues to put up the "Unable to create mobile account" error and rejects the login.

Using createmobileaccount seemed to work for a while (creating the account, creating the home directory, and caching the credentials), but I started deploying to some beta users and the cached credentials suddenly is not working anymore. I have no idea what I changed to break it again. I am now wondering if it ever worked.

The strange behavior is that when the credentials are not cached (I am guessing that is the problem), I can type in a password at the login screen. The login window then becomes unresponsive for 5 or so minutes. There is no spinning gear inside the password field (like normally occurs while logging in), but instead it remains a grey arrow.

The next step is to see if I can get it working with 10.8.5.

hzimmerman
New Contributor III

After another two days of testing, I found the issue. Thanks to https://discussions.apple.com/thread/4136922?start=0&tstart=0 I found that I needed to map GeneratedUID to something, in this case uid. seanhansell was close with the UID suggestion.

I did not take the advice in the thread of making it the same length as the Apple provided GeneratedUID, instead just using our LDAP's unique seven digit uid.

Once I made that change the Configuration Profile for creating mobile accounts started working (so I no longer have to rely on createmobileaccount), and authentication was correctly being cached. Even better, the Kerberos TGT was being pulled down.

The next step is to start working on migrating existing users from their OD mobile account to OpenLDAP mobile accounts.

AdamCraig
Contributor III

It is over 5 years later, and I am having a different problem. But I just wanted to say that this thread solved a problem i'd been banging my head against for a few days...