Skip to main content
Solved

Local User name same as network user name


Forum|alt.badge.img+7

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!

Best answer by Bhughes

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

View original
Did this topic help you find an answer to your question?

15 replies

AVmcclint
Forum|alt.badge.img+21
  • Esteemed Contributor
  • 1043 replies
  • November 20, 2015

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.


Forum|alt.badge.img+4
  • Contributor
  • 23 replies
  • November 20, 2015

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


Forum|alt.badge.img+13
  • Honored Contributor
  • 365 replies
  • November 20, 2015

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.


Forum|alt.badge.img+7
  • Author
  • Contributor
  • 72 replies
  • November 20, 2015

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


Forum|alt.badge.img+7
  • Author
  • Contributor
  • 72 replies
  • November 20, 2015

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


Forum|alt.badge.img+31
  • Employee
  • 920 replies
  • November 20, 2015

Forum|alt.badge.img+2
  • New Contributor
  • 11 replies
  • November 20, 2015

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


Forum|alt.badge.img+7
  • Author
  • Contributor
  • 72 replies
  • November 20, 2015

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.


Forum|alt.badge.img+7
  • Author
  • Contributor
  • 72 replies
  • November 20, 2015

@jillhughes this looks good, however I was hoping to find a solution that could be scripted/automated/minimum interaction with the end user.


Forum|alt.badge.img+7
  • Author
  • Contributor
  • 72 replies
  • November 20, 2015

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


Forum|alt.badge.img+7
  • Author
  • Contributor
  • 72 replies
  • November 20, 2015

@jillhughes this looks good, however I was hoping to find a solution that could be scripted/automated/minimum interaction with the end user.


Forum|alt.badge.img+31
  • Employee
  • 920 replies
  • November 20, 2015

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


Forum|alt.badge.img+7
  • Author
  • Contributor
  • 72 replies
  • November 22, 2015

@rtrouton Thanks! I didn't even notice that! I am going to try this tomorrow. It looks like what I need!


Forum|alt.badge.img+7
  • Author
  • Contributor
  • 72 replies
  • November 23, 2015

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


Forum|alt.badge.img+7
  • Author
  • Contributor
  • 72 replies
  • Answer
  • December 3, 2015

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


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings