search cancel

URLs are not getting blocked even after they are in Blocking list

book

Article ID: 215007

calendar_today

Updated On:

Products

Web Security Service - WSS

Issue/Introduction

Users accessing WSS using WSS agent access method

General browsing working fine

Certain users allowed to access URLs that should be getting blocked.

Blocking rule is based on users group membership, and the users experiencing issues are members of blocked groups

Cause

Auth Connector communication into AD LDAP server not returning expected results

Environment

WSS agent 7.2.1 (although would occur for any version)

Auth Connector used to retrieve authenticated users group information and send back to WSS Proxy

Resolution

Restarted Auth Connector

Additional Information

HTTP logs or forensic reports on failed query indicate that the same user has a valid group when the deny is triggered; but has no groups when all works fine

 

The Proxy must retrieve the users groups via communication with the Auth Connector. 

Running Symdiag on the Auth Connector when the issue happens, we can track the group query from WSS, as well as look at the LDAP and Kerberos communication on the AD side. We can see that the Auth COnnector comms into LDAP were partly successful but did trigger an error 0x8007052e

 

2021/04/23 10:08:30.397 [1968] FindUserLogonNames() ADSI lookups took 6 milliseconds.
2021/04/23 10:08:30.397 [1968] FindUserLogonNames() returning 0x8007052e ***************************** Not returning 0 status
2021/04/23 10:08:30.397 [1968] FindUserUPNName() called, user name [NC\neil]
2021/04/23 10:08:30.397 [1968] FindUserLogonNames() called, user name [NC\neil]
2021/04/23 10:08:30.397 [1968] DN_manager::FindDnsName() called.
2021/04/23 10:08:30.404 [1968] GetGCSearch() called, path [LDAP://uk.domain.com], result 0x8007052e
2021/04/23 10:08:30.404 [1968] FindUserLogonNames() ADSI lookups took 7 milliseconds.
2021/04/23 10:08:30.404 [1968] FindUserLogonNames() returning 0x8007052e
2021/04/23 10:08:30.404 [1968] FindUserUPNName() returning 0x8007052
2021/04/23 10:08:30.404 [1968] Performing s4uLogon Auth for: '(null)'
2021/04/23 10:08:30.404 [1968] FindUserUPNName() called, user name [NC\neil]
2021/04/23 10:08:30.405 [1968] FindUserLogonNames() called, user name [NC\neil]
2021/04/23 10:08:30.405 [1968] DN_manager::FindDnsName() called.
2021/04/23 10:08:30.412 [1968] GetGCSearch() called, path [LDAP://ldap.nc.com], result 0x8007052e
2021/04/23 10:08:30.412 [1968] FindUserLogonNames() ADSI lookups took 7 milliseconds.
2021/04/23 10:08:30.412 [1968] FindUserLogonNames() returning 0x8007052e
2021/04/23 10:08:30.412 [1968] FindUserUPNName() returning 0x8007052e
2021/04/23 10:08:30.412 [1968] s4uLogon() took 8 milliseconds.
2021/04/23 10:08:30.412 [1968] [4632:1968] Failed S4U s4uLogin for user: ''; status=8636:0x21bc:The User Principal Name (UPN) is invalid.

 

The error code returned indicated an issue with the LDAP bind failing. The Auth COnnector uses underlying WIndows calls to talk to AD and get the info we needed.

To address the issue, we restarted the Auth Connector to recreate the LDAP connections into AD and this fixed the issue.

 

 

Attachments