Local User name same as network user name

Bhughes
Contributor

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!

1 ACCEPTED SOLUTION

Bhughes
Contributor

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 solution in original post

15 REPLIES 15

AVmcclint
Honored Contributor

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.

Niels_Illem
New Contributor II

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

andrew_nicholas
Valued Contributor

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.

Bhughes
Contributor

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

Bhughes
Contributor

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

rtrouton
Release Candidate Programs Tester

jillhughes
New Contributor III

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

Bhughes
Contributor

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.

Bhughes
Contributor

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

Bhughes
Contributor

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

Bhughes
Contributor

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

rtrouton
Release Candidate Programs Tester

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

Bhughes
Contributor

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

Bhughes
Contributor

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

Bhughes
Contributor

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