Troubleshooting Active Directory BCAAA group name membership problems using getsid.exe
Troubleshooting Active Directory/BCAAA group membership problems using getsid.exe
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:
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 \\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.
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.
2009/07/14 23:33:20.686  GOI: groups=89 length=2137
Rate this Page
Please take a moment to complete this form to help us better serve you.