You can try having the user login as username@domain.com or ADdomainusername. I seem to remember that working for me years ago when I encountered something similar. It couldn't hurt to try anyway.
The local user database (in Directory Utility called /Local/Default) always goes before a network directory. So there is just one option, change the local user account name and home folder.
See https://support.apple.com/en-us/HT201548
There isn't really a way around that but count your blessings that the account names are the same, so if he has set any aliases or symlinks to use that path, they won't be affected. Updating the permissions is pretty easy, but you could always just delete the local account and preserve the home directory then use createmobileaccount -n [username] -h /path/home. You'll have to update the keychain but everything else should be ok.
@Niels.Illem Thanks, I was afraid that was probably the case. That's a little too involved, in my opinion to ask the user to do himself... Does anyone know if there is a scripted solution for this available? Yesterday I played around a bit, trying to figure out a good workflow... this is what I came up with thus far...
creating another local admin account, deleting that user, and leaving the home directory alone, then logging on as the network user and:
sudo chown -hR networkuser /users/user (Deleted)
That gave me access to the data... then I was trying to figure out an efficient way to transfer the data... I was thinking:
cd /users/user (Deleted)
cp –R * /users/networkuser
This seems to work, but I am not sure it’s the most logical approach. Also, this would be assuming that nothing had been created of any significance by the new user, that could get overwritten.
Weird thing I am seeing with this though, is after a reboot, it comes up to a log on prompt with only the option for “user,” it looks like it’s a file vault thing perhaps, because after I supply the password that I get a progress bar.. Then a prompt where I can enter my “networkuser" credentials and password. I log on fine, check to make sure I still have access to everything, reboot again… now I have both options for log on “networkuser” and “user,” logged in again as network user, reboot again… now just the one log in option (networkuser).
@andrew.nicholas
There isn't really a way around that but count your blessings that the account names are the same, so if he has set any aliases or symlinks to use that path, they won't be affected. Updating the permissions is pretty easy, but you could always just delete the local account and preserve the home directory then use createmobileaccount -n [username] -h /path/home. You'll have to update the keychain but everything else should be ok.
So, something like this?:
sudo /System//Library/CoreServices/ManagedClient.app/Contents/Resources/Createmobileaccount -n "networkuser" h /Users/"user" (Deleted)
I am not sure how that would help...?
We ran into this issue as well. This article I came across works and it has no terminal commands you have to run. I am terrible at terminal!!
http://community.spiceworks.com/how_to/120667-convert-local-mac-user-into-active-directory-network-user-no-terminal-tasks-required
Hope this helps
Thanks @rtrouton I did a quick test with it, and it appears to run (I am running it from SelfService... but it's just sitting there "running script." I don't see it logging anything either. It's been about 20 minutes.
@jillhughes this looks good, however I was hoping to find a solution that could be scripted/automated/minimum interaction with the end user.
So... I found this post by @spraguga :
https://jamfnation.jamfsoftware.com/discussion.html?id=10443
I have tried the scripts, but cannot seem to make it work... I created two scripts, and two policies. The first is set up in self service and set to "restart immediately." The second, is set up with the startup trigger.. am I missing something there?
I don't understand this line:
/usr/sbin/jamf policy MigrateLocalAccountToMobile
Wouldn't that policy need to be created too, and if so, what is it?
Thanks!
Ben
@jillhughes this looks good, however I was hoping to find a solution that could be scripted/automated/minimum interaction with the end user.
@Bhughes, the script I posted is designed to be run as a .command file. You edit it for your own environment's needs, copy the script locally to your Mac, double-click on it, and it walks you through the process.
@rtrouton Thanks! I didn't even notice that! I am going to try this tomorrow. It looks like what I need!
@rtrouton This works great! However, it's still a manual process, a whole lot better, but still manual..I need to figure out if there is a way to identify that the current user enrolling has account that’s named the same as our network accounts, if so, deploy the .command file during enrollment, and have it execute somehow as a different user...
Just a follow-up on this... we were able to add a policy with this script to run when enrollment is complete, then reboot:
#!/bin/sh
dscl . delete /Users/$3
mv /Users/$3 /Users/OLDUSERDATA
using the $3 variable for current logged on user, it will actually work while the local user is logged in. After a restart, the user is able to log into their network account, we they just migrate the data from /Users/OLDUSERDATA to /Users/"Networkuser_xxx"
Many thanks to @cj.krueger for working this out for us!
Hope this helps someone in the future!
-Cheers
