Secure Global Desktop Administration Guide > Users and authentication > Users experience problems with web server authentication

Users experience problems with web server authentication

Common problems users experience when they log in to Secure Global Desktop using web server authentication include:

Web server authentication fails
Users keep getting the standard Secure Global Desktop login page
The Java™ Plug-in keeps prompting for passwords
Users get the wrong webtop

To help diagnose and resolve some of these problem, add the following log filters on the Array Properties panel in Array Manager:

server/login/*error:log_file_name%%PID%%_error.jsl
server/login/*error:log_file_name%%PID%%_error.log
server/login/*info:log_file_name%%PID%%_error.jsl
server/login/*info:log_file_name%%PID%%_error.log

Web server authentication fails

If a user fails to authenticate to the web server, they may see a message such as "401 Authorization Required". This indicates that either there is a problem with the username/password the user is typing or there is a problem with the web server configuration.

Check:

does the user have an entry in the web server password file?
is the web server configured to use the correct password file?
if you are using the Secure Global Desktop Web Server, is the password file accessible by the ttaserv user? If this user can't read the password file, web authentication will fail.

Users keep getting the standard Secure Global Desktop login page

If web server authentication is not set up correctly or it fails for any reason, Secure Global Desktop displays the standard login page. The following table lists the things you may need to check.

What to check	More information
Is the right Secure Global Desktop directory/URL protected?	You must set up your web server to protect: the `tarantella/cgi-bin/secure` directory for the classic webtop. the `/sgd` URL for the browser-based webtop.
Is Tomcat configured to "trust" the web server authentication?	For the browser-based webtop, the Tomcat component has to be configured to trust the web server authentication. On each array member, edit the `/opt/tarantella/webserver/tomcat/version/conf/server.xml` file. Add the following attribute to the connector element (`<Connector>`) for the Coyote/JK2 AJP 1.3 Connector: `tomcatAuthentication="false"`
Does the user have an ENS person object?	If your configuration of Secure Global Desktop relies on users having ENS person objects and you have not enabled one of the fallback profile objects, users may not be able to log in. If this happens and you have enabled the additional logging, search the log file for messages that indicate that Secure Global Desktop could not match the authenticated user to an ENS object. Either create an ENS person object for the user or enable one of the fallback profile objects, see web server/third party authentication for more details.
Is the user a Secure Global Desktop Administrator?	By default, the browser-based webtop will not allow Secure Global Desktop Administrators access if they have been authenticated by a web server. To change this behavior, run the following command: `tarantella config edit --tarantella-config-login-thirdparty-allowadmins 1`
Have you changed the trusted user?	For the browser-based webtop only, if you have changed the username and password of the trusted user, have you verified that the new user works? See security considerations of using web server authentication for details.
Are the tokens timing out?	For the classic webtop only, check that the tokens are not timing out. If you have enabled the additional logging, search the log file for messages beginning `invalidToken`. Increase the web token validity period and try logging in again.
Is the web server username correct?	For the classic webtop only, check that the web server username configured in Secure Global Desktop matches the user that owns the web server processes. For the Secure Global Desktop Web Server this is `ttaserv`. This user is required to validate web server authentication tokens.

The Java™ Plug-in keeps prompting for passwords

For classic web server authentication to work, the tarantella/cgi-bin/secure directory must be protected on your web server. If you protect any other Secure Global Desktop directories (for example /tarantella or /tarantella/cgi-bin, browsers that use a plug-in virtual machine for the Java™ platform ('Java virtual machine' or 'JVM') will prompt users for their username and password. This happens because the JVM and the browser do not share authentication information.

Make sure you only protect the tarantella/cgi-bin/secure directory.

For the browser-based webtop, you may need to upgrade your plug-in version or arrange a workaround, see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4943729.

Users get the wrong webtop

Web server authentication does not support ambiguous users. This means users get the webtop of the first matching login profile.

If you have enabled the additional logging, search the log file for messages that indicate an ambiguous user.

To resolve the situation, you can either:

accept the first match;
attempt to manually resolve the ambiguity, for example by creating or amending person objects; or
disallow ambiguous logins (classic web server authentication only).

To disallow ambiguous logins for classic web server authentication, run the following command:

tarantella config edit --com.sco.tta.server.login.webauth.WebLoginAuthority.properties-takeFirstMatch false

You must restart the Secure Global Desktop server after making this change.

Related topics
Introducing web server authentication Enabling web server authentication for the browser-based webtop Enabling web server authentication for the classic webtop Login authorities Secure Global Desktop Login properties (array-wide)