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


Article ID: 166722


Updated On:


ProxySG Software - SGOS


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'.


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. 


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.



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 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 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


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