Using PSloggedon to troubleshoot BlueCoat Single Sign On (SSO)

I won’t go into an introduction of what SSO is and Bluecoat’s implementation of it, there are some good KB articles on this subject. The following article (hopefully to be published soon on the bluecoat KB) explores how SSO interacts with windows and how to use the sysinternals PSloggedon tool to troubleshoot this.

Symptom:

When using Windows SSO, authentication intermittently fails with:

“Last Error: The user could not be determined by the Single Sign-on agent.”

FTP clients will show the following error:

A policy trace on the proxy will show the same error:

“Last Error: The user could not be determined by the Single Sign-on agent.”

The proxy will not show anyone as logged in via SSO

(https://a.b.c.d/Auth/User-Logins/Summary/Realm/ ):

This happens even though the user is actually logged into the domain.

Explanation and troubleshooting:

The reason this is happening is actually down to the inner workings of windows. SSO has two modes: “Domain Controller Querying” (DCQ) and “Client Querying”.

DCQ uses an API provided by Microsoft called “NetSessionEnum”. Even though the user is logged in, BCAAA does not see the user as logged in because this API does not see my user as logged in.

A useful tool you can use to check what users the API is returning is “PSloggedOn”, a Microsoft tool available from their website:

http://technet.microsoft.com/en-us/sysinternals/bb897545

This tool utilises the same API that BCAAA does when checking the users logged in on a server remotely (hence the heading “resource shares in the screenshot below). In this particular example, we see that the tool returns the following:

Note that Psloggedon must be run using the same user BCAAA uses and should be run on the domain controller, without any arguments.

From the client PC, we then access a shared folder on the domain controller, and run the tool again on the Domain Controller:

Now we check the proxy and we see the users logged in correctly:

If we check the BCAAA debug logs (see : https://kb.bluecoat.com/index?page=content&id=KB2934 for more information on the SSO debug logs) we also see the correct user:

2011/04/14 09:30:41.034 10.91.25.58 DAVVAS CHILD 10.91.25.1

– Why is the issue intermittent?

The windows API does not always return the user. It seems like after a period of inactivity, the API “times out” the user. BCAAA mitigates this by using a “time to live”. This setting is controlled in the sso.ini file:

ValidTTL=86400

But if the TTL expires and the API still does not return the username, the error is displayed.

– Why does it work more reliably when using IWA?

When using IWA, not SSO, BCAAA does not use the same windows API, but actually does try to logon to the domain controller (using another API – NetLogon)

What can be done to mitigate this:

– Enable both Domain Controller Querying and Client Querying.

To do this, you need to first change the ProxySG configuration > Authentication > Windows SSO > Agents:

This will cause BCAAA to not only rely on that API we spoke about previously, but also to check who is logged in on the client (using yet another API – NetWkstauserEnum). There are a couple of pointers here:

Advantages

– More current data than DCQ

Disadvantages

– Workstations must have port 445 open (possible security risk)

– Remote registry service should be enabled (disabled by default on Vista and later)

– BCAAA service must run as a domain user / admin that can query the clients.

– Client query will fail if the workstation reports that more than one user is logged in

Again, PSlogged on uses the same API. To test, run PSloggedon on the domain controller, using the same BCAAA user and adding the \\w.x.y.z as an argument (where w.x.y.z is the client IP)

If any of those requirements are not met, PSloggedon will show: