Users from a Group in Active Directory do not match their Group defined in the ProxySG's Web Access Layer.
This usually happens when an existing Group is deleted or renamed in the Active Directory and a new Group with the same name is created, thus resulting in a different Security Identifier (SID).
To verify if a group-of-interest (GOI) has different SIDs, compare the SID of the affected GOI in the ProxySG against the one in Active Directory.
To determine the SID of the affected GOI on the ProxySG appliance:
Obtain LSA Debug log as per KB article: TECH243203
Look for the SID of the affected GOI as shown in the following example:
9134.821 Group cache: Domain BLUECOAT.COM. Done looking up groups. ..... 9134.821 Group cache: Group found in cache: bluecoat\MyGroup, SID: S-1-5-21-1111111111-222222222-333333333-12345
To determine the SID of the affected GOI in Active Directory:
Remote Desktop in to the Domain Controller used by the ProxySG with Microsoft Terminal Services Client.
Log in with an affected user's account.
Open a command prompt and run "whoami /groups". The following result or something similar should be displayed :
Group name Type SID BLUECOAT\MyGroup Group S-1-5-21-1111111111-222222222-333333333-97531 Mandatory group, Enabled by default, Enabled group
In some environments, group lookups can take a long time and delay processes such as policy compilation. To help prevent this behavior, Symantec implemented the Active Directory group cache feature to allow you to avoid doing these group lookups whenever possible. The group cache is not persistent.
To resolve the issue of different SIDs, do one of the following:
In the CLI, disable the cache and then re-enable it using the #(config security windows-domains)group-cache [enable | disable] subcommand.
From the SGOS 18.104.22.168 Release Notes:
A new CLI subcommand has been added to control caching of name-to-SID mappings for each group-of-interest: