Negated user or group conditions aren't matched for unauthenticated users on ProxySG

Products

• ProxySG Software - SGOS

Issue/Introduction

Your ProxySG's policy contains a rule (or rules)  which should only match for users who do not belong to a particular AD group, or for all users except a specific named user or users. To achieve this, the rule contains a source-object which is defined by first matching the stated group or user-name, and then negating the condition.

When users who aren't authenticated connect through the proxy, the action for the rule isn't applied, and a policy trace marks the rule with 'n/a', rather than 'MATCH' or 'miss'.

Resolution

This behaviour is by design. When authentication is bypassed for a given transaction, all AD user information remains unknown to the proxy, and as a result membership or non-membership of a given group cannot be evaluated one way or another. 

 

Work-around:
Policy should either be written in such a way that authentication is always enforced for traffic which will need to be filtered through the layer containing the negated group-condition, or in such a way that a positive group-membership test can be applied instead which will exclude or include the relevant AD users as required.

 

Examples:

1. Negated group-condition as guard-rule for a Web access layer

In the following policy, rule 1 in the Web Access layer is intended to block only users who aren't members of the AD group 'bad_group'.

 

 

 

However, since users connecting from the subnet 10.91.17.0/24 won't be authenticated, the negated group-condition in the guard layer will evaluate as 'n/a', so those user will also be blocked.  To prevent this from happening, the policy could be re-written as follows:

 

 

2. Negated user-condition within a policy layer

In the following policy, all users except 'bad_user' are intended to be denied access to sites in CombinedDestination1. However, since users connecting from the subnet 10.91.17.0/24 won't be authenticated, all users connecting from this subnet would in practise also be blocked, because the source-condition in rule 2 would evaluate as 'n/a', and only the destination condition would be matched  (user 'bad_user'  would also be blocked, as intended, if he connected from a subnet other than 10.91.17.0/24).

 

An alternative method of writing this policy would be as follows: