Skip past navigation linksSecure 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:

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

Skip past command syntax or program codeserver/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:

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:

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

Skip past command syntax or program codetarantella 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