ATT: MICROSOFT - Bug in Implementation or Error in Documentation for memberOf property
Joe Richards
in some of the groups lately and I was hoping to catch one who could give me
an answer on this or if someone else has an answer that is cool.
The memberOf attribute documentation in sdk/msdn libraries for user objects
specifically says
<quote>
memberOf
The memberOf property is a multi-valued property that contains groups of
which the user is a direct member, depending on the domain controller (DC)
from which this property is retrieved:
At a DC for the domain containing the user, memberOf for the user is
complete with respect to membership for groups in that domain; however,
memberOf does not contain the user's membership in domain local and global
groups in other domains.
At a GC server, memberOf for the user is complete with respect to all
universal group memberships.
If both conditions are true about the DC, both sets of information are
contained in memberOf.
Note that this property lists the groups that contain the user in their
member property-it does not contain the recursive list of nested
predecessors. For example, if user O is a member of group C and group B and
group B were nested in group A, the membersOf property of user O would list
group C and group B but not group A.
This property is not stored-it is a computed back-link attribute.
</quote>
Now reading that one would think that by enumerating the memberOf group of a
user in a single domain forest that has a single DC (so it is also a GC) you
would get a listing of every group that a user was directly a member of that
was part of the domain ... You would be incorrect because the memberOf
attribute doesn't have an entry for the user's Primary Group!!!! Every group
is represented except those that the user is a member of through nesting
(which is proper and expected) and the user's primary group.
Now I took this in stride when I wrote code to enumerate groups for a user
(including the nested ones) using the LDAP API and figured I would just have
the code "throw in" the Primary group (and its associated nested groups) but
I don't like the fact that this is a bug that might be corrected and then I
am doing something I don't need to be doing.
So anyway... Is the implementation of the memberOf attribute for the user
object incorrect or is all of the documentation about the attribute
throughout MSDN/Platform SDK incorrect or am I missing something?
Oh if you want to see what I am talking about either use ADSIEDIT to look at
the properties of a user or grab my memberof tool off my website or use ldp
or Netscapes ldapsearch.
thanks, joe
--
---
Joe Richards
humore...@hotmail.com
Opinions expressed are, as always, Joe's and probably insulting to someone
somewhere so just relax. =)
http://www.joeware.net
Mike
present in the previous Message.
The memberOf property is a multi-valued property that contains groups of
which the user is a direct member
It would seem to me that unless the user is a direct memeber of the group
then MemberOf would not list the user if it was a member of a group only by
Way of Nested groups. This would make sense since the only way you can have
nested groups other thatn GG -> DLG is to have the domain in Native mode.
Unless I have missed something it sounds like it is working as documented
Mike
"Joe Richards" <humore...@hotmail.com> wrote in message
news:uS3M3viIBHA.512@tkmsftngp03...
Joe Richards
Primary, they need to be a direct member of that group.
--
---
Joe Richards
humore...@hotmail.com
Opinions expressed are, as always, Joe's and probably insulting to someone
somewhere so just relax. =)
http://www.joeware.net
"Mike" <mste...@hotmail.com> wrote in message
news:iAle7.26993$xj.44...@typhoon.southeast.rr.com...
Mike
is basically there to support the POSIX subsystem. Win32 does not use this
group for any significance. I will try to repro this and see if I can get
the same results.
Mike
"Joe Richards" <humore...@hotmail.com> wrote in message
news:u7wKJyUJBHA.1344@tkmsftngp05...
Joe Richards
will explain what he told me farther down.
Primary groups are used both for UNIX and MAC clients. However, I wasn't
trying to use the primary group member, I was enumerating all the user's
groups and I was using member of to do that enumeration. When I would run
the code the user's primary group (and resulting groups nested through that
group) would never show up. I opened up adsiedit.msc and was quick to find
that the memberOf attribute didn't contain the primary group in it even
though to be in a primary group you had to be a direct member of the group.
While I could use the tokenGroups attribute to enumerate user's groups as
well and that does contain the primary group and all nested groups it is
also based on SIDS which don't convert nicely to DN's but to Domain\Group
structures which would then require one LDAP search per group to find the DN
or a large LDAP search to pull all groups. Neither way is as efficient as
using memberOf and only using additional LDAP searchs to dig down through
the nested groups.
Anyway, here is how it was described by the MSCS guy and it makes sense in
terms of AD implementation. He also indicated that it should be documented
and will work on getting that corrected.
A design decision was made by MS that users who had a primary group of X
would not be in the member attribute of X. This was done to cut down on the
replication of that group as most implementations of AD would have most
users if not all users within one Group as their primary group, that group
being Domain Users.
Once I read the reasoning it made sense from many standpoints.
The memberOf attribute is a generated attribute that is built based off of a
user's direct memberships. By definition a user's primary group is a direct
membership, but because of the implementation of primary groups being such
that the user is not added to the member attribute of the primary group it
won't be found when the memberOf attribute gets generated since the memberOf
attribute would be generated by a simple search of the member attributes of
all the groups of a domain partition for the user in question. From that it
also follows that you can't determine a Universla/Global group's membership
via LDAP unless you grab both the group's member attribute plus do an
additional LDAP search for all users who have the attribute primaryGroupID
equal to the groups attribute primaryGroupToken. This is something else that
would need to be heavily documented so that people writing LDAP Apps will be
aware of the issue.
The reason behind MS implementing this way makes sense when you consider how
groups are replicated in Active Directory under Windows 2000. The member
attribute of a group is a multivalued attribute and in Windows 2000
multivalued atributes are replicated as one. If you had a domain of 70,000
users and assuming a normal domain you would have to figure that all user's
would probably have a primary group of Domain User's which means 70,000
users would have to be in the members attribute of the Domain User's group.
In the Res Kit it clearly states that MS has only tested group membership
replication to 5000 users and recommends not exceeding that value because
the attribute would have to be able to be updated in a single transaction or
else it won't replicate.
In Whistler (aka .NET server) the replication of multivalue attributes is
supposed to change so that they are replicated piecemeal (i.e. each
individual value in a multivalued attribute will be sent around as a
separate transaction (I think from what I have read in the propaganda) which
means that Microsoft could correct this problem. It would require changing
how groups are handled and could break any existing apps that have already
been built with this workaround but I think that is ok as I don't think many
apps have been built that workaround this or else we would have seen some
documentation referencing this. I hope they change it.
joe
--
---
Joe Richards
humore...@hotmail.com
Opinions expressed are, as always, Joe's and probably insulting to someone
somewhere so just relax. =)
http://www.joeware.net
"Mike" <mste...@hotmail.com> wrote in message
news:naHe7.123942$J37.30...@typhoon.southeast.rr.com...
Mike
research this and follow up as I am bringing this from memory however I
recall reading that Security Group Memberlists are incrementatlly Replicated
However the Universal Group Membership List Performs the eactly as you
described in that if you make a change to Membership List that the whole
list would replicate and just the change. Not all Multivalued attributes
perfomr block Replication ... most are Incremental with the exception of the
Unviersal Group. This was partially because this attribute is stored in the
GC and would replicate to all GCs within the Forest. That has changed in
Windows.Net as I have tested it. Additionaly some other things that has
change as weill is that anytime an attributew as added to the GC it would
cause a full replication of all GCs. That has gone away as well in
Windows.Net.
Again, This is from memory however I will attempt to support it with
some documentation. But indeed this is great information
Mike
"Joe Richards" <humore...@hotmail.com> wrote in message
news:uGurWNlJBHA.1720@tkmsftngp07...
Joe Richards
a whole. This was one of the big gripes Novell threw out there because if
you had two admins changing group membership at the same time on two
different DC's one of the admins changes could possibly be thrown out in the
collision. This is one of the big enhancements of .NET Server to replicate
changes in a multivalue attribute separately versus sending the whole list.
This is from the res kit
"It is recommended that you limit group size to 5,000 members, because the
Active Directory store must be able to be updated in a single transaction.
Because group memberships are stored in a single multivalue attribute, a
change to the membership requires the whole membership list to be replicated
between domain controllers and updated within a single transaction.
Microsoft has tested and supports group memberships up to 5,000 members."
This is from docs I saw a while back about whistler
"3) changing how multivalued attributes (such as group memberships) are
handled - eliminating the 5,000 member limit, and replicating changed
members only (as opposed to the entire list, which consumes bandwidth and
can cause loss of membership changes);"
joe
--
---
Joe Richards
humore...@hotmail.com
Opinions expressed are, as always, Joe's and probably insulting to someone
somewhere so just relax. =)
http://www.joeware.net
"Mike" <mste...@hotmail.com> wrote in message
news:Nvjf7.133586$TM5.23...@typhoon.southeast.rr.com...
Mike
Mike
"Joe Richards" <humore...@hotmail.com> wrote in message
news:eCilzi5JBHA.860@tkmsftngp02...