wntMemberList Problems

Question:

I have noticed a behavior when using wntMemberList that is causing me some issues. When you use that funtion on a LocalGroup it returns both users and groups that are members of the requested group. When you use that function on a GlobalGroup it only seems to return users and not nested groups.
I need to get a list of members and groups that belong to various Globalgroups any ideas?

BTW - I have looked at using ADSI instead and getting the memberOf property which does work the way I want, but I can not use it to connect to AD servers in nontrusted domains from the domain that my workstation is in. You can use the wnt functions across nontrusted domains though so that is why I need to see if there is a way to make the wntMemberList function work or something similar.

Answer:

The very same underlying Win32 API functions that are allowing you to work across untrusted domains are also incapable of distinguishing between users & global groups when reporting back the membership list for a local group. Those functions are also incapable of dealing with nested global/universal group memberships in an AD environment.

What you need to do is process each member name in the returned list and identify it as a user or a group. You can call wntUserGetDat() specifying the "flags" element and wrap the call in some error handling code. If called for a user that exists, the call is successful. If called for a group, extender error 562 is thrown and your error handling code should trap this. Alternatively, you can call wntGroupInfo() and specify request -1 as a means of testing to see if the account name is a group that exists. The function returns false if the account name is not an existing group name.

User reply:

I have a recursive function that I created that loops through the list returned by wntMemberList and does use wntGroupInfo to identify if it is a user or group. This works fine. The problem is that the list returned by wntMemberList only has users in it and not groups. So testing to see if an element in the group is a group or user is pointless.

Answer:

Well, from the point of view of the Win32 API functions that the wntMember*() and wntGroup*() functions use, only local groups can have other groups as members. Those functions don't recognize global groups as being able to have members that are anything other than users. There's some data filtering going on when the translation from AD to NT domain is being made.

If you want to access AD and fully interrogate AD group memberships, you need to natively access AD thru the ADSI/LDAP interfaces rather than thru the NT domain interfaces.

User reply:

Yes, I had already came to that conclusion as well. I am going to rewrite the code using the ADSI extender and use a config file and run it seperately in the 16 different forests that I administer and then write a seperate script to aggregate the output from each forest.

It would have been nice to hit them all from one spot but what can you do...

Answer:

Hmmm... I think that you can specify DS credentials when binding to AD with the ADSI extender. Perhaps you can do this all from within 1 script that simply iterates 16 times, once for each forest, with a separate set of credentials used for each forest.

All you can do is play by the rules that Microsoft establishes. That's how the AD -> NT domain translation works, and there's nothing that can be done to side-step those limitations.

Article ID:   W17073

File Created: 2007:07:03:14:28:06

Last Updated: 2007:07:03:14:28:06

Database Search

TechHome