Heres the scenario:
- A user creates a local account within Macbook. Let's say the name is "John"
- We have now domain joined this Macbook so users can log on with the AD account
- When this person, who's domain account name is John, tries to log onto the Macbook, it does not create a new profile. Instead, it thinks it's already found "John" locally, and therefore does not create the domain account within the Macbook.
At any rate, I'm suspecting that only John's local account password works, not the domain account. I believe that local accounts are matched first, and then domain accounts. You might be able to edit the search order in the Directory Utility application, but don't quote me on that.
You can try asking the user to specify the domain as part of his login name: domainjohn, john@domain, etc. This might not be ideal for the user, but at least you can verify that the domain account actually works. Assuming there's no problem with the user's home directory because there is a "john" account in multiple domains, that is!
Yes, this makes sense. The way logins work is that the Mac will always default to the local node for an account login, then to external domains, like AD. If you have an account with the same name, there isn't a way for the OS to know by simply typing in "John" in the username field that you mean "John from AD" not "John in the local node" Since it found "John" in the /Local/Default node, it logs in to that account.
Off the top of my head, I can't really think of a way to fool the OS into logging in with an AD account if they are named the same. You're probably going to have to rename the local account to something else I think. Maybe someone else has a better idea though.
Yes, it's only allowing me to log in with the local account's password. When trying the domain account password, it gets rejected. hmmmm.... My task is to migrated everyone off their local account and onto their domain account. This is going to be a blocker.
@Bernard.Huang It's possible to do what you're looking for, but you're likely going to have to script something, and maybe even make use of a one time LaunchDaemon.
The solution to this issue is that the local account needs to be deleted from the local domain (the home folder will not be touched) and then the AD account needs to be created using the createmobileaccount binary. When accounts are created with that binary they come from Active Directory, so they understand they are paired up with a directory account, not from the local node.
You can, in a script, pair up the user's existing home directory with their AD cached mobile account and when they log in that same home folder will get used.
If you need some guidance on how you might accomplish all this, post back and I can see about putting together a framework for this.
You could also do some searches on migrating from local to domain accounts here as I'm almost certain there are a couple of existing threads that talk about the process. One of them may give you the start you need.
Jamf's purpose is to simplify work by helping organizations manage and secure an Apple experience that end users love and organizations trust. Jamf is the only company in the world that provides a complete management and security solution for an Apple-first environment that is enterprise secure, consumer simple and protects personal privacy. Learn about Jamf.
This site contains User Content submitted by Jamf Nation community members. Jamf does not review User Content submitted by members or other third parties before it is posted. All content on Jamf Nation is for informational purposes only. Information and posts may be out of date when you view them. Jamf is not responsible for, nor assumes any liability for any User Content or other third-party content appearing on Jamf Nation.
We are trying to setup two different accounts for the same user, so that we can use one for customer facing application and the other for back-office application. The user has only one email and if we use dummy email, user may not get the email notifications.
Most likely your org does not have the feature @erik is alluding to which is enabled when self-service registration is enabled in an Org. This allows the login/username and the primary email to differ.
Email addresses are created with initials and lastname, followed by a 3 digit number. This gives the freedom to create 999 email addresses with the same initials and lastname before we get into trouble.
you just have make sure in AD you put there middle initial,and make sure you list their title/locations/departments in too. So your GAL shows this info and the end users can decipher the correct person they need to email .
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"
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...
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.
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?
@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.
Glad you got your resolution. The UPN problem might be more specific to hybrid situations - which we were - so making an account it would not allow duplicate UPNs to sync and I seem to recall O365 or something would sometimes assign extra numbers but it would not match the email format for the user either. Something to keep in the back of your head if ever find yourself faced with that.
Cheers!
Thanks for the reply Rich, much appreciated.
I just solved the issue a slightly different way by setting up a temporary new user called 'apple' and reinstalled and it opened and gave me the opportunity to change the folder path in preferences.
Did this post help you? If so, give it a Like below to let us know.
Need help with something else? Ask me a question!
Find Tips & Tricks Discover more ways to use Dropbox here!
Interested in Community Groups? Click here to join!
Hello there. Im trying to create a user in Nprinting. But i cant since there is already a user with the same Name.
When i try to add the user i get: "Firsname Lastname' is already a user or a group".
Can this really be as simple as "you cannot have two users with the same name"? That seems to be a huge flaw in the design? Of couse they have diffrent emal adresses. They just hapopen to have the same firstname and lastname. In large organizations its not uncommon for two people to have the same firsname and lastename.
However its not hard to reproduce.
I have a User in NP with the name "Emma Svensson" and the emailadress "
emma.s...@copany.se". I now have a new user whos name is also "Emma Sevnsson" but with the email adress "
emma.b....@copany.se". Two totally different users who just happen to have the same first and last name. But when i try to create the secound user i get the error: "Firsname Lastname' is already a user or a group".
I see where you are coming from but at the same time when you are going to lets say assign user to group or task then you will not know which user you are assigning it to given that it will have exactly the same look. This requirement will prevent you from doing such mistake.
3a8082e126