ADUC v dsget inconsistentcy

I'm trying to enumerate the member of an AD security group with dsget so I
can audit it regularly. The command runs great and I get a nice list of
DNs. However, if I then use ADUC to look at the members, I get a superset
of the list from dsget. Seems like dsget consistently reports only 27 of
the 32 group members and the same are missing every time.

As a check, I also ran SysInternals' ADExplorer and got the same results as
dsget.

Any thoughts?

\\Greg

"Martin, Greg (RTIS)" <> wrote in message
news:...
> I'm trying to enumerate the member of an AD security group with dsget so I
> can audit it regularly. The command runs great and I get a nice list of
> DNs. However, if I then use ADUC to look at the members, I get a superset
> of the list from dsget. Seems like dsget consistently reports only 27 of
> the 32 group members and the same are missing every time.
>
> As a check, I also ran SysInternals' ADExplorer and got the same results
> as dsget.
>
> Any thoughts?
>
> \\Greg

Most methods reveal direct members of the group that do not have the group
designated as their "primary". ADUC is the exception, it shows members even
if the group is their "primary". Hopefully this accounts for what you see.
All of the missing members have the group designated as their "primary"
group.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

I think we're seeing it the other way. dsget is only listing members who's
primary group is the group I'm enumerating. Any idea why it works that way?
Seems a bit flawed.

Oh, and here's some new information. If you load the command-line tools
that are part of Windows 2008 R2 RSAT tools on Windows 7, this appears to be
"fixed".

\\Greg

"Richard Mueller [MVP]" <rlmueller-> wrote in
message news:...
>
> "Martin, Greg (RTIS)" <> wrote in message
> news:...
>> I'm trying to enumerate the member of an AD security group with dsget so
>> I can audit it regularly. The command runs great and I get a nice list
>> of DNs. However, if I then use ADUC to look at the members, I get a
>> superset of the list from dsget. Seems like dsget consistently reports
>> only 27 of the 32 group members and the same are missing every time.
>>
>> As a check, I also ran SysInternals' ADExplorer and got the same results
>> as dsget.
>>
>> Any thoughts?
>>
>> \\Greg
>
> Most methods reveal direct members of the group that do not have the group
> designated as their "primary". ADUC is the exception, it shows members
> even if the group is their "primary". Hopefully this accounts for what you
> see. All of the missing members have the group designated as their
> "primary" group.
>
> --
> Richard Mueller
> MVP Directory Services
> Hilltop Lab - http://www.rlmueller.net
> --
>
>

I tested again in my W2k3 domain and confirmed that members are never
revealed if the group is their "primary". The only way I know to find users
that have a given group designated as their primary is to find users whose
primaryGroupID attribute (an integer value) matches the primaryGroupToken
attribute of the group. For example, the primaryGroupToken attribute of the
"Domain Users" group is 513. To find all users that have this group as their
primary use the filter:

(primarGroupID=513)

To find all users that have some other group as primary:

(&(objectCategory=person)(objectClass=user)(!prima ryGroupID=513))

You can use these filters in Joe Richards' adfind utility, or in a VBScript
program that uses ADO to search AD.

The reason most methods fail to reveal primary group membership is that this
group is never included in the "memberOf" attribute of user objects. Also,
the "member" attribute of group objects never includes members that have the
group designated as their primary. The same goes for the Members method of
user objects and the Groups method of group objects.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

"Martin, Greg (RTIS)" <> wrote in message
news:%...
>I think we're seeing it the other way. dsget is only listing members who's
>primary group is the group I'm enumerating. Any idea why it works that
>way? Seems a bit flawed.
>
> Oh, and here's some new information. If you load the command-line tools
> that are part of Windows 2008 R2 RSAT tools on Windows 7, this appears to
> be "fixed".
>
> \\Greg
>
> "Richard Mueller [MVP]" <rlmueller-> wrote in
> message news:...
>>
>> "Martin, Greg (RTIS)" <> wrote in message
>> news:...
>>> I'm trying to enumerate the member of an AD security group with dsget so
>>> I can audit it regularly. The command runs great and I get a nice list
>>> of DNs. However, if I then use ADUC to look at the members, I get a
>>> superset of the list from dsget. Seems like dsget consistently reports
>>> only 27 of the 32 group members and the same are missing every time.
>>>
>>> As a check, I also ran SysInternals' ADExplorer and got the same results
>>> as dsget.
>>>
>>> Any thoughts?
>>>
>>> \\Greg
>>
>> Most methods reveal direct members of the group that do not have the
>> group designated as their "primary". ADUC is the exception, it shows
>> members even if the group is their "primary". Hopefully this accounts for
>> what you see. All of the missing members have the group designated as
>> their "primary" group.
>>
>> --
>> Richard Mueller
>> MVP Directory Services
>> Hilltop Lab - http://www.rlmueller.net
>> --
>>
>>