| Author | Messages | |
SaucyWrong
Posts:54
 | | 06/10/2010 10:23 PM |
| Does anybody on the list know why the ds* commands don't spit out the member
attribute a group with a large membership? For example, a group called
Exempts in our environment has several thousand members, and the output from
the ds* tools is NIL:
C:\>dsget group "CN=Exempts,OU=AutoGroups,DC=corp,DC=company,DC=com"
-members
C:\>dsquery * "CN=Exempts,OU=AutoGroups,DC=corp,DC=company,DC=com" -attr
member
member
Adfind behaves correctly (of course), so I've converted over to that tool,
but I'm curious if anybody on the list knows why the ds* tools behave this
way?
Thanks,
Matt
| | | |
| skradel
Posts:177
| | 06/10/2010 10:51 PM |
| It's probably because very large group membership list retrievals in
LDAP require attribute range tags; i.e., you have to search for
"member;range=0-*" the first time, examine what the AD DSA returned,
ask for the next range of values in a new search, etc. It's rather
onerous because you have to know ahead of time to treat certain
attributes specially, and a regular search response to a request the
"member" attribute will not indicate that the results are truncated.
Most of the time, these will be linked values anyway, so it's easier
to search the backlink attr.
IMHO this was not the best design decision that the DS team ever made.
--Steve
On Thu, Jun 10, 2010 at 5:22 PM, Matt Quinn <saucy.wrong@gmail.com> wrote:
> Does anybody on the list know why the ds* commands don't spit out the member
> attribute a group with a large membership? For example, a group called
> Exempts in our environment has several thousand members, and the output from
> the ds* tools is NIL:
> C:\>dsget group "CN=Exempts,OU=AutoGroups,DC=corp,DC=company,DC=com"
> -members
>
> C:\>dsquery * "CN=Exempts,OU=AutoGroups,DC=corp,DC=company,DC=com" -attr
> member
> member
> Adfind behaves correctly (of course), so I've converted over to that tool,
> but I'm curious if anybody on the list knows why the ds* tools behave this
> way?
> Thanks,
> Matt
| | | |
| SaucyWrong
Posts:54
| | 06/10/2010 11:20 PM |
| That definitely makes sense, Steve, and I suspect if I look at traces of
adfind versus dsget I would see something to that effect. I didn't have
time to trace the query though. That's a job for tomorrow.
Thanks!
Matt
On Thu, Jun 10, 2010 at 5:49 PM, Steve Kradel <skradel@zetetic.net> wrote:
> It's probably because very large group membership list retrievals in
> LDAP require attribute range tags; i.e., you have to search for
> "member;range=0-*" the first time, examine what the AD DSA returned,
> ask for the next range of values in a new search, etc. It's rather
> onerous because you have to know ahead of time to treat certain
> attributes specially, and a regular search response to a request the
> "member" attribute will not indicate that the results are truncated.
>
> Most of the time, these will be linked values anyway, so it's easier
> to search the backlink attr.
>
> IMHO this was not the best design decision that the DS team ever made.
>
> --Steve
>
> On Thu, Jun 10, 2010 at 5:22 PM, Matt Quinn <saucy.wrong@gmail.com> wrote:
> > Does anybody on the list know why the ds* commands don't spit out the
> member
> > attribute a group with a large membership? For example, a group called
> > Exempts in our environment has several thousand members, and the output
> from
> > the ds* tools is NIL:
> > C:\>dsget group "CN=Exempts,OU=AutoGroups,DC=corp,DC=company,DC=com"
> > -members
> >
> > C:\>dsquery * "CN=Exempts,OU=AutoGroups,DC=corp,DC=company,DC=com" -attr
> > member
> > member
> > Adfind behaves correctly (of course), so I've converted over to that
> tool,
> > but I'm curious if anybody on the list knows why the ds* tools behave
> this
> > way?
> > Thanks,
> > Matt
>
>
| | | |
| aansari
Posts:67
| | 06/11/2010 6:01 AM |
| For something like this, I would highly recommend using Joe' Adfind.exe
which works very fast and very nice.
http://www.joeware.net/freetools/tools/adfind/index.htm
Or Quest's Get-QadGroup
http://wiki.powergui.org/index.php/Get-QADGroup
<http://www.joeware.net/freetools/tools/adfind/index.htm>Cheers,
Adeel
On Thu, Jun 10, 2010 at 5:18 PM, Matt Quinn <saucy.wrong@gmail.com> wrote:
> That definitely makes sense, Steve, and I suspect if I look at traces of
> adfind versus dsget I would see something to that effect. I didn't have
> time to trace the query though. That's a job for tomorrow.
>
> Thanks!
> Matt
>
>
> On Thu, Jun 10, 2010 at 5:49 PM, Steve Kradel <skradel@zetetic.net> wrote:
>
>> It's probably because very large group membership list retrievals in
>> LDAP require attribute range tags; i.e., you have to search for
>> "member;range=0-*" the first time, examine what the AD DSA returned,
>> ask for the next range of values in a new search, etc. It's rather
>> onerous because you have to know ahead of time to treat certain
>> attributes specially, and a regular search response to a request the
>> "member" attribute will not indicate that the results are truncated.
>>
>> Most of the time, these will be linked values anyway, so it's easier
>> to search the backlink attr.
>>
>> IMHO this was not the best design decision that the DS team ever made.
>>
>> --Steve
>>
>> On Thu, Jun 10, 2010 at 5:22 PM, Matt Quinn <saucy.wrong@gmail.com>
>> wrote:
>> > Does anybody on the list know why the ds* commands don't spit out the
>> member
>> > attribute a group with a large membership? For example, a group called
>> > Exempts in our environment has several thousand members, and the output
>> from
>> > the ds* tools is NIL:
>> > C:\>dsget group "CN=Exempts,OU=AutoGroups,DC=corp,DC=company,DC=com"
>> > -members
>> >
>> > C:\>dsquery * "CN=Exempts,OU=AutoGroups,DC=corp,DC=company,DC=com" -attr
>> > member
>> > member
>> > Adfind behaves correctly (of course), so I've converted over to that
>> tool,
>> > but I'm curious if anybody on the list knows why the ds* tools behave
>> this
>> > way?
>> > Thanks,
>> > Matt
>>
>>
>
--
Adeel Ansari
| | | |
|
|