Skip to main content

Hey guys,



as mentioned in another discussion, we have problems when multiple accounts with the same name exists in a AD structure. Situation is the following:



The issues started when I created additional accounts in another AD forest. First, I had only one account (lets say "account123") in europe.company.com. Since two weeks, I have accounts with the same short name in china.company.com and americas.company.com too. This is the normal behavior in the customers company.
This was the beginning of the "OS X needs to repair your library" error. The home folder is created, but no settings are applied from the user template. It seems that OS X always uses the first account found in the AD structure to set the permissions of the mobile account. There is no change when I use the UPN or NetBIOS name for login. OS X always seems to use the first account found in AD.
When I open the home folder with cmd+shift+H, the home folder points to /var/empty.
When "create mobile account" is disabled in the AD binding, I can login without problems. Settings are applied from the user template, no "OS X needs to repair...". BUT, with an "ls -la" in Terminal, owner and group of the local account is another user than the logged in user.



Example 1:
- "create mobile account" is enabled
- login with "account123@americas.company.com" in the login window.
- the home folder in /Users will be created with the wrong permissions and "OS X needs to repair bla bla" will appear
- no settings from the user template are applied
- the permissions for /Users/account123 are set to account123:chinaDomain Users



Example 2:
- "create mobile account" is disabled
- login with "account123@americas.company.com" in the login window.
- a temporary home folder in /Users will be created and login works as expected
- settings from the user template are applied
- the permissions for /Users/account123 are set to account123:chinaDomain Users



This is a reproducible behavior from 10.9 up to 10.10.3. I haven't tested 10.8.



Has anyone seen a similar behavior in his environment? Any suggestions other than raising a ticket to Apple?



Thanks,
Michael

Hi Michael,



check out the -namespace verb of dsconfigad:



-namespace forest | domain
Sets the primary account username naming convention. By default
it is set to "domain" naming which assumes no conflicting user
accounts across all domains. If your Active Directory forest
has conflicts setting this to "forest" will prefix all usernames
with "DOMAIN" to ensure unique naming between domains (e.g.,
"ADDOMAINuser1"). Warning: this will change the primary name
of the user for all logins. Changing this setting on an exist-
ing system will cause any existing homes to be unused on the
local machine.


This might cause other problems down the line as changing the namespace to "forest" will result in homefolders being named "DOMAINuser".
Some apps don't like the backslash in the folder name.



Edit: It might be smarter to remove "All Domains" from the Search Path and readding them in the order you need

I would use dsconfigad with -alldomains disable and set the search domains accordingly as @Chris mentioned.



Should help with directory searching performance as a bonus!

Sorry for the late reply, we did a lot of testing on that.



@Chris , we tried to change the namespace to forest. As you mentioned, some apps doesn't work correct after that. Lync and MS Office are only two of them.



@davidacland , we tried that too. One big disadvantage of that is, that you are unable to use the accounts in one of the other domains or use the UPN or NetBIOS name for login. Setting the search order accordingly is a bit difficult, because our customer has 13 (!!) domains. It's nearly impossible to set the correct order for everyone out there.



It all ended in an support case with apple and a bug report. When you enter the UPN or NetBIOS name in loginwindow, OS X -should- respect that.



Thanks @all for your help! I will keep you up to date whats going on with the support case and the bug report.

Reply


Terms & ConditionsCookie settings