Auth Connector: Unauthenticated users with no WSSOAuthenticateRequest in BCCA debug log.
search cancel

Auth Connector: Unauthenticated users with no WSSOAuthenticateRequest in BCCA debug log.

book

Article ID: 165367

calendar_today

Updated On:

Products

CDP Integration Server

Issue/Introduction

Using the IPsec (firewall/VPN) access method to connect to the Cloud service, but users are showing as: "Unauthenticated user"

Auth Connector (BCCA) service is up and running, but users are still "Unauthenticated"

In the BCCA debug log, there is no "WSSOAuthenticateRequest" message.

 

Resolution

If the Auth Connector (BCCA) service is successfully running, but users are still showing as an "Unauthenicated user", then look in the BCCA debug log (make sure the BCCA debug settings are enabled) to see if there are any lines with the following request: 

WSSOAuthenticateRequest

 

The "WSSOAuthenticateRequest" is logged by BCCA after the data-pod(s) sends a request to the BCCA for an "IP address to username" match request.

A common reason that the "WSSOAuthenticateRequest" is NOT in the BCCA log, is if the firewall/VPN is NAT'ing traffic into the IPsec tunnel.

In other words, Source NAT is enabled for HTTP/HTTPS traffic that is being sent into the IPsec tunnel.

Source NAT must be DISABLED for traffic placed into the IPsec tunnel.

 

An easy way to test this, is to have a user browse to the BLOCKED page/category.

When the user hits a BLOCKED page, they will be presented with the Cloud "Access Denied" page.  Click on the "more" link to bring up more information about the user's session.

 

The "Username" field would show: "Unauthenticated user"

The "Client IP" field would show a PUBLIC IP address (in this broken case)...likely the public egress IP address of the firewall.

The "Client IP" field should, instead, show the PRIVATE, non-NAT'd IP address of the client workstation.

 

SOLUTION: Modify the firewall/VPN configuration to DISABLE Source NAT.