Active Directory User vs. MacOS 10.8.4
Redphex 05.09.2013 - 09:17 1274 7
Redphex
Legend RabbitOfNegativeEuphoria
|
Hellau
Wir haben ein historisches Active Directory, mit Useraccounts unterschiedlicher Epochen.
Uralte Useraccounts, die in etwa vor 2005 angelegt wurden, können sich nicht auf Maschinen mit 10.8 anmelden, bei 10.7 geht's mit allen Accounts problemlos.
Hatte vielleicht jemand auch dieses Problem und eine Lösung abgesehen von AD-User löschen und neu anlegen?
|
userohnenamen
leider kein name
|
welchen funktionellen level hat das AD? eventuell würde ein raise auf ein höheres level global was bringen?
|
Redphex
Legend RabbitOfNegativeEuphoria
|
bevor ich in dem Fall im gesamten AD rumbau, leg ich lieber die User neu an
|
userohnenamen
leider kein name
|
was heißt umbauen? das sind 3 mausklicks unter der vorraussetzung das es halt geht von den Domaincontrollern und Exchangeservern aus gesehen  aber klar, ist natürlich ein gröberer eingriff von dem her
|
spunz
ElderElder
|
UPN zwischen einem alten/neuen Account vergleichen.
|
Redphex
Legend RabbitOfNegativeEuphoria
|
Hab mitn Adsiedit die Accounts verglichen und keine unlogischen Unterschiede gefunden
|
HP
Legend Legend
|
("UserA", "UserB") | %{Get-ADUser $_ -Properties *} | export-csv Filename1
What you get?
|
HP
Legend Legend
|
Hab mitn Adsiedit die Accounts verglichen und keine unlogischen Unterschiede gefunden Und diese Lösung hat mir vor kurzem weitergeholfen: We ran into this issue today with a Mac user. I stumbled across this post and just thought I'd share what fixed it for us.
Issue: When logging into a Mac (10.7.5 or 10.8.2) with User1, login would not prompt to create mobile account, or would just act like the password was wrong. With User2, it always worked as expected.
After reading through this entire thread and trying a few extra steps, here's what we found.
When running this command (run on a domain joined mac) we could get all the info on User1 and User2.
Substitute YOURDOMAIN for whatever domain you are joined to and having issues with.
dscl /Active\ Directory/YOURDOMAIN/All\ Domains -read /Users/user1
dscl /Active\ Directory/YOURDOMAIN/All\ Domains -read /Users/user2
Looking at the returned properties we noticed that User1 also had a sub-domain account in the forest appearing in output:
Domain\User1
sub.Domain\User1
and User2 (works) did not:
Domain\User2
What fixed it for us was to do one of the following solutions.
Solution 1: Rename the Sub-domain user. Apparently Unix uses this username forest-wide, so when we joined the domain the default search policy would try "All Domains".
This would result in the Sub.Domain user registering a "badPwdCount" property and eventually locking out the Sub.Domain\User1 account when logging into the mac as Domain\User1.
The account would log in, but to a half-created home folder, and never prompt to create a mobile account.
Once the Sub.Domain account was gone, the user immediately worked. You may need to wait for replication in a large Active Directory environment.
Solution 2: Change the Search Policy in OSX to use one domain (instead of default All Domains).
You have to un-check the "Allow authentication from any domain in the forest", apply, then go to Search Policy and specify the desired domain, and then remove "All domains"
Either of these solutions resolved our "some users always work and other users always don't work" issue.
Until today we hadn't figured out why it was happening to only a small number of users. It was isolated to users with the same User1 account in multiple domains in the forest.
Hopefully this saves someone time .
|