Troubleshooting Windows SSO


Article ID: 167030


Updated On:


ProxySG Software - SGOS


 When using Windows SSO, authentication intermittently fails and displays the following error:

“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 ProxySG appliance will not show anyone as logged in via Windows SSO:

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


This happens even though the user is actually logged in to the domain. 



Windows SSO has two modes: Domain Controller Query (DCQ) and Client Query (CQ). This problem occurs when you are using DCQ only due to a problem with the Windows API that is used to return user login information to BCAAA.


DCQ uses an API provided by Microsoft. Even though the user is logged in, BCAAA does not see the user as logged in because this API does not see the 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:

This tool uses 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 : /articles/Solution/HowdoIenableBCAAAdebuglogging for more information on the SSO debug logs) we also see the correct user:

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

-          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” setting. This setting is controlled in the sso.ini file:



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 Windows SSO, BCAAA does not use the same Windows API, but actually does try to logon to the domain controller (using a different API).


What can be done to mitigate this:

-          Enable both DCQ and CQ.

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). 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 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:


If all the above conditions are met, PSloggedon will show:


If multiple users are logged in you will see multiple users under “users logged on locally” and the proxy will throw an error.


Some other useful links when troubleshooting BCAAA SSO:

Single sign-on failed due to Appliance Error (configuration_error)

Window SSO realm authentication failed, browser may received error message "The user could not be determined by the Single Sign-on agent."