How to gather Cloud Auth Connector debug logs for Web Security Service.

Products

• Web Security Service - WSS

Issue/Introduction

Web Security Service (WSS).

Auth Connector debug logs are required to troubleshoot specific situations. An example would be a scenario such as "Unauthenticated User" shown in reports.

The Auth Connector logs (BCCA logs) are a record of the agent's activity. This information is valuable for finding the root cause of a problem that is related to authentication or connectivity between the Auth Connector and the WSS.

These logs are important for the detailed insight they contain on the inner workings of BCCA. Alternatively, you can configure the reporting of live debug events to have a preliminary view of authentication and debug events. However, these are not as complete, and quickly populate your Event Viewer log. Only use live debug for live troubleshooting sessions.

ACLogon not connecting.

 

Resolution

1. STOP the BCCA service.

 

In the directory: C:\Program Files\Blue Coat Systems\BCCA 

...(where the "bcca.exe" file resides)... 

 

2. DELETE logs named: 

(You might not have some of these)

 

bcca-xxxx.log 

debug_dcq_primary_full.sso 

debug_dcq_primary_inc.sso 

dcq_primary_full.sso 

dcq_primary_inc.sso 

 

3. Enable DEBUG logging for both BCCA and SSO: 

 

Edit the BCCA.ini file and add or enable the following lines: 

 

[Debug]

DebugLevel=0xFFFFFFFF

 

It will look like this in the log file.

 

 

Edit the SSO.ini file and add or enable the following line: 

 

3.1 For DCQ:

 

[DCQSetup]

DCQDebug=1

 

It will look like this in the log file.

 

 

3.2 For ACLogon:

 

[CLSetup]
CLDebug=1

 

It will look like this in the log file.

 

 

4. RESTART the BCCA service.

 

5. Let service run for 20+ minutes...then STOP the BCCA service.

 

NOTE: During this 20-minute time, do the following:  

• With a SPECIFIC USER, map a drive to the AD server running the AuthConnector.
• At minute 5, hit a blocked page and click "More" (to see if the user is "Unauthenticated").

 

• At minute 20, hit a blocked page (with the SAME USER). Is the user authenticated now?

Be sure to record the USERNAME and IP address of the workstation here (send this info to Support).

 

6. Collect the following logs, and send to Support: 

 

bcca-xxxx.log 

debug_dcq_primary_full.sso 

debug_dcq_primary_inc.sso 

bcca.ini 

sso.ini 

 

...but NOT these logs (don't collect the following; these are binary logs): 

dcq_primary_full.sso 

dcq_primary_inc.sso 

 

7. Disable the debug settings above, and restart BCCA.

 

 

---

Live debugging guide:

1. Stop the BCCA Service, named Symantec WSS Client Authenticator.
2. Edit the bcca.ini file, and edit it as follows:
   • Before: 'LogEventMask=1'
   • After: 'LogEventMask=3'
     • This will make it so authentication events, and debug events are logged into the server's event viewer.
3. Start the service again.
   • This will start logging of most, but not all, the errors you see on a common debug log.
4. After troubleshooting is over, revert the changes, otherwise you risk consuming disk space on now-useless logs.

Now that we have enabled the live debug, we can go to the event viewer to check for useful events.

Under Windows Logs > Security, we may find logon events such as the one displayed here. The subject is our BCCA user name (such as CONTOSO\srv.bluecoat). And the new logon is our user authenticating (such as CONTOSO\pam.receptionist).

You may choose to search for a particular user name and see if the logon was captured under the service's user name. Searching for CONTOSO\ladmin would yield us a record very similar to this one.

Events such as these will be visible at Windows logs > Application, you can use the event viewer to diagnose them as you go.

These logs are no substitute for the real debug logs. They are helpful if you are working on a WebEx or have limited time to work on a server.