Posted on 11-20-2015 04:35 AM
Situation: we are right in the middle of rolling out JAMF enrollment to existing mac users in our environment. We rant into something yesterday. A local user has a account name that is the same as his network account name. When domain joined, he cannot log on to the network account because it’s seeing his local account with the same name. I looked around on the web and can’t find anything that’s not super intensive with perms and the home directory…. Does anyone have any thoughts on this?
Thanks in advance!
Solved! Go to Solution.
Posted on 12-03-2015 09:12 AM
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
Posted on 11-20-2015 04:49 AM
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.
Posted on 11-20-2015 04:49 AM
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
Posted on 11-20-2015 05:08 AM
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.
Posted on 11-20-2015 05:14 AM
@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).
Posted on 11-20-2015 05:28 AM
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...?
Posted on 11-20-2015 05:55 AM
I have a script that may help with this situation:
Posted on 11-20-2015 06:31 AM
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
Posted on 11-20-2015 07:37 AM
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.
Posted on 11-20-2015 07:43 AM
@jillhughes this looks good, however I was hoping to find a solution that could be scripted/automated/minimum interaction with the end user.
Posted on 11-20-2015 10:24 AM
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
Posted on 11-20-2015 12:30 PM
@jillhughes this looks good, however I was hoping to find a solution that could be scripted/automated/minimum interaction with the end user.
Posted on 11-20-2015 12:49 PM
@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.
Posted on 11-22-2015 01:12 PM
@rtrouton Thanks! I didn't even notice that! I am going to try this tomorrow. It looks like what I need!
Posted on 11-23-2015 06:16 AM
@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...
Posted on 12-03-2015 09:12 AM
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