Currently Being ModeratedJun 26, 2013 1:40 PM (in response to chrisale2)
Just an update.
We are on a multi-domain AD infrastructure. So we have also tried unbinding it from the domain, destroying the open directory and then joining it to a different domain and recreating everything. The same results persist.
Even with a generic "Domain Users" AD group added to the local network group, some users are reported by dseditgroup as 'members' of the local network group, and some are not. Always the same ones are or are not.
Our system has thousands of users, so it isn't practical to go through all of the users to see who and who is not reported as a 'member' and working. But we have not been able to determine any correlation between those who can and cannot.
I am now spinning up a second 10.8 server to see if I can replicate the problem on two machines or whether it is specific to the machine we are using.
Currently Being ModeratedJun 27, 2013 8:44 AM (in response to chrisale2)
Upon further investigation we have discovered:
a) the main behaviour that is causing the problem is best described as AD users that are added to a Local or Network OS X group... either individually or through a Domain group.... are not actually recognized as members of that OS X group even though the GUI or CLI tool have added them and acknowledge them as being in the list.
b) This is NOT limited only to MacOS X Server 10.8. The same behaviour is occuring on a long-running 10.6 server as well.
c) The problem remains whether we nest AD groups to capture a large bunch of users, or add users individually. If the user is part of the mysteriously denied set, how they are added to the OD or local group is irrelevant, including if added from the command line.
d) Which users are allowed and which are not is unclear and appears generally random. We have found 3 'classes' of users:
1 - those that are successfully becoming members every time.
2 - those that are intermittent members. Members on one server or another, or in one case even go from being reported as a member (by dseditgroup), to not being a member, to being a member again within the span of only a minute or two.
3 - those that are never successfully admitted as a member.
So the problem is both Apple's and Windows in that:
Apple: Is allowing a group and/or user to be added and implying then membership in the group even though that membership is not being honoured in some way and there is no feedback or communication of that fact aside from generic 'denied' or 'illegal user' errors.
Windows: Is passing along membership through its groups and users, but not completely, for reasons that are, at this point, a mystery.
Really hoping people have some ideas on this. This system of nested groups or individual user access is something we have of course being using for many years. So this is a major setback.
Currently Being ModeratedJun 28, 2013 11:40 AM (in response to chrisale2)
After yet more investigation of this problem I have uncovered a simpler way to ask, and address this.
When I use the command line too "id" as in:
id -p workinguser1
If I do it for one of the users that is able to work properly as expected I get:
id -p workinguser1
groups *blah blah blah snip*
In other words I get a proper result.
When I query for a bad user I get:
id -p baduser1
id: gillespij: no such user
And I small animals cry.
Yet when I query the Active Directory as a whole for a list of users with this command:
dscl /Active\ Directory/OURDOMAIN/ousr.place.dc.ca -list /Users
It returns the full llist successfully.
So what gives?
What would cause one user in the director to be able to be queried, but not another?
Currently Being ModeratedJun 28, 2013 11:42 AM (in response to chrisale2)
THIS QUESTION IS NOT SOLVED. I mistakenly pressed the solve instead of the 'helped' button and now I can't go back. Doh!
Currently Being ModeratedAug 22, 2013 1:47 PM (in response to chrisale2)
The REAL answer to this question I just found out today. It is in this thread:
I had to unbind the server first, simply setting the new setting in Directory Utility was not enough.
Using Apple Directory Utility, Advanced Options, Mappings
Check Map user GID to attribute primaryGroupID
It does not make sense to me to map user GID to primaryGroupID but it seems to work for ALL users, not just some as before.