Users from a Group in Active Directory do not match their Group defined in the EdgeSWG (ProxySG) 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 EdgeSWG (ProxySG) against the one in Active Directory.

To determine the SID of the affected GOI on the EdgeSWG (ProxySG) appliance:

1. Obtain LSA Debug log as per KB article: 171951
2. Look for the SID of the affected GOI as shown in the following example:

To determine the SID of the affected GOI in Active Directory:

1. Remote Desktop in to the Domain Controller used by the EdgeSWG (ProxySG) with Microsoft Terminal Services Client.
2. Log in with an affected user's account.
3. Open a command prompt and run "whoami /groups". The following result or something similar should be displayed :

Group name                    Type      SID                                          
DOMAIN\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 6.5.7.7 Release Notes:

A new CLI subcommand has been added to control caching of name-to-SID mappings for each group-of-interest: