Users from a Group in Active Directory do not match their Group defined in the ProxySG's Web Access Layer

book

Article ID: 169425

calendar_today

Updated On:

Products

ProxySG Software - SGOS

Issue/Introduction

Users from a Group in Active Directory do not match their Group defined in the ProxySG's Web Access Layer.

 

Cause

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:

  1. Obtain LSA Debug log as per KB article: TECH243203
  2. 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:

  1. Remote Desktop in to the Domain Controller used by the 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                                          
BLUECOAT\MyGroup      Group     S-1-5-21-1111111111-222222222-333333333-97531 Mandatory group, Enabled by default, Enabled group

 

Resolution

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:

#(config security windows-domains)group-cache [enable | disable]