Troubleshooting Active Directory/BCAAA group membership problems using getsid.exe
Skipping invalid GroupName='<Domain>\<group>' MutexName='_'
 

A very useful tool in troubleshooting this type of condition is the getsid.exe utility from Microsoft. It can be found at the following URL along with a number of other AD utilities:

https://docs.microsoft.com/en-us/sysinternals/downloads/psgetsid

The original purpose of the utility is to compare the SID of an account at two different domain controllers to ensure that the information is consistent. To retrieve this information, the utility invokes the 'LookupAccountName' API in a manner similar to the BCAAA agent. When using the tool in this way, use the following syntax substituting the BCAAAServerNetBIOSName and the Group you are resolving. You will want to run this command on the system where the BCAAA agent resides that is not resolving the SID's.

getsid \\<BCAAAServerNetBIOSName> "<group>" \\<BCAAAServerNetBIOSName> "<group>"

The output of the utility will be two SID values. Most likely, given the above situation where the group is not found, you will not receive values or you will receive an error. This can be used to either further diagnose the issue or to direct the focus as appropriate the AD infrastructure.

Example:

getsid \\127.0.0.1 "group-name-in-question" \\127.0.0.1 "group-name-in-question"

This made getsid query to 127.0.0.1--BCAAA server for this information. Because BCAAA server belongs to the domain, it contacted a DC to retrieve the information.

If getsid fails, then the BCAAA server was unable to query the group, and this may indicate that the customer has a problem with their AD deployment. The error code returned from getsid should match the error code in the BCAAA debug log, and may provide a clue as to nature of the problem.

ADDITIONAL INFORMATION:

When Active Directory (AD) groups are used in policy, the ProxySG via the BCAAA agent performs a GroupOfInterest query of the AD infrastructure. This query is performed to lookup the SID (Security Identifier) of each group in the policy. The SID is a number that uniquely identifies each group in the AD infrastructure, and BCAAA uses this number to compare the user's groups with the ProxySG's GroupsOfInterest following authentication.

After turning on BCAAA debug trace, you'll see a line similar to the following when BCAAA receives a GroupOfInterest query message from the ProxySG:

2009/07/14 23:33:20.686 [4112] GOI: groups=89 length=2137

The above message indicates the SG has requested that BCAAA query 89 groups. During a successful query, you'll see the following output in BCAAA's debug log:

2009/07/14 23:33:20.686 [4112] STEP 2: Get SID for AuthGroup='<Domain>\<group>'
2009/07/14 23:33:20.702 [4112] AuthGroup='<Domain>\<group>' SID=0x123456 cbSID=28 Domain='<DOMAIN>' cbDomain=6 snu=2
2009/07/14 23:33:20.702 [4112] AuthGroup='<Domain>\<group>' Domain='<DOMAIN>'

During a failed query, you'll see a message similar to the following:

2009/07/14 23:33:20.718 [4112] STEP 2: Get SID for AuthGroup='<Domain>\<group>'
2009/07/14 23:33:20.718 [4112] [5608:4112] AuthGroup '<Domain>\<group>' does not exist; status=1332:0x534:No mapping between account names and security IDs was done.

NOTE: The status = 1332. It indicates "ERROR_NONE_MAPPED" and this means that the API was unable to locate the "<Domain>\<group>". in the AD tree. This failure may indicate that the group name was mistyped in the policy, or in more rare cases, that there is a problem with the group object in the AD infrastructure.

If BCAAA is unable to query the SID for a group, then authentication rules which reference the group may fail. Here's a debug trace sample:

SSPICheckGroupsOfInterestIwa: lpUserName='<Domain>\<username>'

MutexName='_' GroupName='<Domain>\<group 1>'
MutexName='_' GroupName='<Domain>\<group 2>'
MutexName='_' GroupName='<Domain>\<group 3>'
...
MutexName='_' GroupName='<Domain>\<group n>'

Here's the failure:

Skipping invalid GroupName='<Domain>\<group>' MutexName='_'

The above trace statement is from an authentication request and indicates that BCAAA thinks the group is invalid because it failed earlier GroupOfInterest query. As long as BCAAA thinks the group is invalid, it won't tell the ProxySG and any user is a member of the group.