Question
Joe,
I’m trying to use AdFind to find members of a specific group. Can I do
this (I haven’t been able to get it to work thus far)?
Thanks
Reply
Yes, the basic form would be
adfind -default -f name=groupname member
This doesn’t take all sorts of things into account but there is no simple LDAP query that will handle every case of enumerating group membership authoritatively and adfind is an LDAP query tool, not a “get me the authoritative answer to this or that question” tool. Depending on what is needed, it might be authoritative, but it completely depends on what is being asked and how the specific functionality you are wondering about is implemented under the covers. Groups just happen to be a massively painful area.
Want to read more? Use google, I have written on this topic in various forums so much my brain hurts from it.
joe
Regarding simple LDAP query – I think that after Windows 2003 Sp2 or with hotfix for SP1 LDAP_MATCHING_RULE_IN_CHAIN might be a little helpful here.
Ryan has covered it here:
http://dunnry.com/blog/TransitiveLinkValueFilterEvaluation.aspx
I have examples on my Polish blog but probably most of your blog readers doesn’t read in Polish :), so I will just copy one here:
adfind -b dc=w2k,dc=pl -s subtree -f “(&(objectClass=user)(objectCategory=Person) (memberOf:1.2.840.113556.1.4.1941:=CN=TestGroup,OU=Location1,OU=E
mployees,DC=w2k,DC=pl))”
If I’m not mistaken this will find all users from domain which are members of TestGroup. Even if this account is a member of this group through other nested groups.
Maybe not a fastest query You can execute but might become helpful here.
Hey Tomek, it is better but still not great. Still have primary group membership to worry about and the in_chain rule won’t cross over to other DCs to do complete expansion just like with Attribute Scoped Queries. Basically caveats exist and you have to be pretty aware of the implementation to do things properly or else your assumptions could kill you which is bad for something so critically important to security.
Yes, You are right – and as You wrote:
(…)
Depending on what is needed, it might be authoritative, but it completely depends on what is being asked and how the specific functionality you are wondering about is implemented under the covers
(…)
Still this might help a little in implementation. The original question was about finding the members of particular group – not how to approach more general topic which is how to audit group membership \ control access based on groups etc.
BTW – if we are on answering ADFind realted questions – some time ago I’ve sent You an e-mail with question if You have considered adding DirSynch support to adfind – for example to allow queries for changes in membership etc.
Tomek: But the problem is, you still can’t guarantee you have given the full membership of the group, that is what I am saying. You won’t have any members which have the group as the primary and you won’t get any members that are nested across NCs that would require a trip to another DC to resolve. That means you can’t even fully trust the results in terms of whether someone is or isn’t in a group since it may or may not have everything.
I just brought up the more general topic because having a correct/accurate listing of group membership is critical to that function.
RE AdFind and DirSync, I responded to that, must have gotten caught up somewhere. It is something that I have added to the list of possible capabilities for a V2 version of adfind when I get to write it. The current framework would be very difficult to fit that in. Of course I said that about CSV and then figured out how to get it in there anyway just with about perf hit to overall speed.