WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

WinBatch
Networks - Servers
Microsoft Client
wNT
plus
Services

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

wntMemberGrps() returns 0 on DC Running Active Directory 

Keywords: 	 wntMemberGrps() AD Active Directory  NetUserGetGroups

Question:

I have a compiled WinBatch program using the call wntMemberGrps(DC,User,@GLOBALGROUP,0) where DC is set to the domain controller that authenticated that session's logon. The program runs on a Terminal Server in a large Win2K AD forest and works fine except for a couple of users in one particular domain.

In those two cases, wntMemberGrps() returns "0" instead of the list of groups the user belongs to.

I discovered this only happens when one particular DC has authenticated the users. Any of five other DC's in that domain work fine if I hard-code them in place of the authenticating DC.

So far the AD admins tell me the questionable DC looks fine.

Here are the results of WWW-BATCH.INI: 

[Error Reporting]
3052=regversionvalue
[WWWNT34I]
LastError=53 (NetUserGetGroups() : extender wntMemberGrps())

Answer:

From the MSDN Platform SDK, some notes about the NetUserGetGroups() function:

NetUserGetGroups

The NetUserGetGroups function retrieves a list of global groups to which a specified user belongs.

Security Requirements

Windows NT: No special group membership is required to successfully execute the NetUserGetGroups function.

Windows 2000: If you call this function on a domain controller that is running Active Directory, access is allowed or denied based on the access-control list (ACL) for the securable object. The default ACL permits all authenticated users and members of the "Pre-Windows 2000 compatible access" group to view the information. By default, the "Pre-Windows 2000 compatible access" group includes Everyone as a member. This enables anonymous access to the information if the system allows anonymous access.

If you call this function on a member server or workstation, all authenticated users can view the information. Anonymous access is also permitted if the RestrictAnonymous policy setting allows anonymous access.

Windows XP: If you call this function on a domain controller that is running Active Directory, access is allowed or denied based on the ACL for the securable object. To enable anonymous access, the user Anonymous must be a member of the "Pre-Windows 2000 compatible access" group. This is because anonymous tokens do not include the Everyone group SID by default.

If you call this function on a member server or workstation, all authenticated users can view the information. Anonymous access is also permitted if the EveryoneIncludesAnonymous policy setting allows anonymous access.

From the MSDN Platform SDK, a definition for error #53: 

53
The network path was not found.
ERROR_BAD_NETPATH
The first two things that come to mind would be some sort of corrupted security policy on the DC in question, or perhaps some sort of intermittent network problem that makes the DC unreachable at certain times.

Question (cont'd):

Turns out there's a WINS replication issue here and the /unqualified/ (NetBIOS) names of a few remote servers were not resolving locally. Resolution via FQDN's and the connectivity itself was fine, which is why the issue didn't manifest itself conspicuously elsewhere.

Until the WinBatch Win32 network extender is updated to return fully qualified data this will continue to be a problem. Meanwhile I've added code in my script so that a failed call to wntMemberGrps() results in enumeration of all possible DCs in that domain and queries against each until the call succeeds.

Answer:

The Win32 network extender is dependent upon Windows networking name resolution being functional and properly configured. It uses "legacy" API functions that don't return FQDN values at all.

If you're in an AD environment and you want to use FQDN values to identify servers, then using the ADSI extender to directly query AD is a better solution. 

Article ID:   W15564

File Created: 2003:05:13:11:28:56
Last Updated: 2003:05:13:11:28:56