Subgroup LDAP query 1

[SKSysAdmin]

Hi,

I wanted to know if someone has a way either LDAP query or other, to create a list of users based on membership to a top level group. Under this group there are several subgroups that the users are then a member of.

I have tried simple Windows LDAP query to display the list of users who are a member of a particular group but this will not enumerate the subgroups. I need to know the subgroups as well.

Thanks

Kevin.

 

[PScottC]

Take a look here: [URL unfurl="true"]http://www.rlmueller.net/freecode1.htm[/url]

I have adapted #4 to find all members (direct or indirect) of my Domain Admins group.

Good Luck!

PSC

Governments and corporations need people like you and me. We are samurai. The keyboard cowboys. And all those other people out there who have no idea what's going on are the cattle. Mooo! --Mr. The Plague, from the movie "Hackers

 

[ITPangaeaArchitect]

Yea basically you have to have a dyamic query, which you cannot do via base command line. You will have to script it out.

What comes to mind is vbscript/adsi:

enumerate the top level group
make dictionary object of all members (through the member attribute)
enumerate all groups in the dictionary
rinse and repeat above steps for each group found in there, and each level underneath

if done right, you can make a nice little map via excel, or even text, pretty easily (i use the word easily loosely)

-Brandon Wilson
MCSE00/03, MCSA:Messaging00, MCSA03, A+

 

[SKSysAdmin]

Hi,

Thanks for the responses. I was hoping there was some sort of LDAP query in order to do this in the windows users and groups MMC. The reason is that I want to be able to generate some kind of list by group rather then by user.

Althought very interesting, my scripting abilities are not that good and it appears I have to learn VB script in order to accomplish some of those examples mentioned...

I'm actually suprised that you can't see subgroup membership natively....

 

[ITPangaeaArchitect]

its likely due to limitations in attribute sizes within AD; specifically, the 5000 object limitation within group memberships. This is a huge reason why nesting is in play. To track all group information, whether via a user object or via a group object, would effectively multiply the size of the data chunk within the member and memberOf attributes, which in turn eliminates the speed, useability, and readability on the attribute itself. It would effectively mean adding code to map groups as a normal procedure. If a user belongs to 20 groups, and those 20 groups are nested inside of 50 others...our timeframe even for a query just jumped from 1 second of reading to 5 seconds of reading...

Hopefully that makes sense

You should be able to use a sequence of net group <groupname> commands to effectively create a group mapping without VB...albeit a very manual process.

For example:
net group domain admins - returns all domain admins members
we see server operators and administrators in there, so we..
net group server operators - returns all members, no groups
net group administrators-returns members with AdminUsers group (sample), so we...
net group AdminUsers

so on and so forth...you have to start at the top level, then query any groups within it, then any groups within it, and any groups within it, etc. etc.
This effectively gives you the friendly equation of your group membership token.


-Brandon Wilson
MCSE00/03, MCSA:Messaging00, MCSA03, A+

 

[SKSysAdmin]

Hi,

Thanks. I understand what your saying about the performance end of things. It makes sense.

I found another script online which does the reverse. It finds the nested groups that a particular user is set up for.

http://www.jdhitsolutions.com/resources/scripts/EnumerateForestGroups.txt

I give you a star anyways, because I feel that the information you have provided has been useful.

Thanks

 

[ITPangaeaArchitect]

there is also a utility called tokengroups that does the same (vbs I believe). I don't think that is public though.

ill see what i can find..or i may throw one together....im gonna check my tools directory for ya tonight though, as i may very well have something to do this.

The tool you referenced can do the job, but then youd have to put the data together manually, which is never good.

Automation is king

-Brandon Wilson
MCSE00/03, MCSA:Messaging00, MCSA03, A+

 

[pagy]

its likely due to limitations in attribute sizes within AD; specifically, the 5000 object limitation within group memberships

IIRC then this limit does not apply when you are running at Windows 2003 Forest functional level as linked value replication is then enabled.

Automation is king

Too bloomin right :->

Paul
MCSE 2003
MCTS:Active Directory
MCTS:Network Infrastructure
MCTS:Applications Infrastructure

If there are no stupid questions, then what kind of questions do stupid people ask? Do they get smart just in time to ask questions?
Scott Adams

 

[ITPangaeaArchitect]

very true about functional level
i was specifically referring to the physical/logical size (like bytes/kb) of the member and memberOf attributes themselves though, sorry for any confusion dang good thing to point out though as i had forgotten to mention that

-Brandon Wilson
MCSE00/03, MCSA:Messaging00, MCSA03, A+

 

[pagy]

i was specifically referring to the physical/logical size (like bytes/kb) of the member and memberOf attributes themselves though

Gotcha ;-)

Paul
MCSE 2003
MCTS:Active Directory
MCTS:Network Infrastructure
MCTS:Applications Infrastructure

If there are no stupid questions, then what kind of questions do stupid people ask? Do they get smart just in time to ask questions?
Scott Adams