How do I troubleshoot the problem where only certain users in Microsoft Active Directory group fails authorization with IWA ?

Products

• ProxySG Software - SGOS

Issue/Introduction

Example:

You have user 'root' that is a member of 'Internet Users' in your Microsoft Active Directory.

However, a policy trace on the ProxySG shows that the user is not part of the 'Internet Users' group. BCAAA Debug logs show the following :

2011/03/25 03:16:03.099 [5236] UTF-8 user name (hex) is:KLDEV\root (KLDEV\root)
2011/03/25 03:16:03.099 [5236] Performing NTLM Group-of-Interest Auth for: 'KLDEV\root'
2011/03/25 03:16:03.099 [5236] SSPICheckGroupsOfInterestIwa: lpUserName='KLDEV\root' phContext=0xFBC27E80014E8B8 .....
2011/03/25 03:16:03.099 [5236] MutexName='_' GroupName='KLDEV\Internet Users'
2011/03/25 03:16:03.099 [5236] MutexName='_' GroupName='KLDEV\Bluecoat for Group A'
2011/03/25 03:16:03.099 [5236] MutexName='_' GroupName='KLDEV\Bluecoat for Group B'
2011/03/25 03:16:03.099 [5236] MutexName='_' GroupName='KLDEV\Bluecoat for Group C'
2011/03/25 03:16:03.099 [5236] Group Membership:
2011/03/25 03:16:03.099 [5236] Group no: 0: no                      <<<<< Does not belong to 'KLDEV\Internet Users'
2011/03/25 03:16:03.099 [5236] Group no: 1: no                      <<<<< Does not belong to 'KLDEV\Bluecoat for Group A'
2011/03/25 03:16:03.099 [5236] Group no: 2: no                      <<<<< Does not belong to 'KLDEV\Bluecoat for Group B'
2011/03/25 03:16:03.099 [5236] Group no: 3: no                      <<<<< Does not belong to 'KLDEV\Bluecoat for Group C'

How do I proceed further?

When BCAAA does authorization for IWA, it just compares the SIDs (Security Identifiers) in the user's access token against an ACL (Access Control List). BCAAA creates a mutex for each GOI (Group-Of-Interest), and places each group's SID in the ACL for its corresponding mutex. Since group members are the only ones that will have rights to each mutex, BCAAA can check group membership by impersonating the user and attempting to open each mutex.

Therefore, it's likely that the user's access token doesn't contain SID's for the missing groups for some reason.

You can verify that the SID's are missing by logging on to the BCAAA server as one of the affected users and running "whoami.exe /groups". This will display all the groups in the user's access token. If these groups really are missing from the token, then this should prove to your customer that they're dealing with an AD problem.

C:\Windows\System32>whoami /groups

GROUP INFORMATION
-----------------

Group Name                                                                           Type                               SID                                                                                                     Attributes

========================================== ================ ============================================== ===============================================================
Everyone                                                                                  Well-known group      S-1-1-0                                                                                              Mandatory group, Enabled by default, Enabled group
.....
KLDEV\Internet Users                                                          Group                            S-1-5-21-1901577163-1026016356-1644633413-1123       Mandatory group, Enabled by default, Enabled group     <<<<< Verify if this group is present

If the affected group does not show up in "whoami /groups" then you need to investigate your Microsoft Active Directory further. If it shows up, please contact Blue Coat Support to investigate further.

 

Notes:

Whoami.exe is part of the Windows Resource Kit.

Related article: /articles/Solution/TroubleshootingActiveDirectoryBCAAAgroupnamemembershipproblemsusinggetsidexe