Use the information in this section to troubleshoot problems when users log in to SGD.
To help diagnose problems with Secure Global Desktop authentication, use one or more of the log filters shown in the following table to obtain more information.
Log Filter | Purpose |
|---|---|
| Information about authentication mechanisms that use directory services. Applies to Active Directory, LDAP, and third-party authentication. |
| Information about what happens when users attempt to log in. Applies to all authentication mechanisms. |
| Information about connections to RSA Authentication Manager. Applies to SecurID authentication. |
For information about setting log filters, see Section 7.4.3, “Using Log Filters to Troubleshoot Problems With an SGD Server”.
SGD Administrators can enable a login failure handler so that users are denied access to SGD after three failed login attempts. See Section 2.10.2.1, “Enabling the Login Failure Handler”. This additional security measure only works if users have their own user profile objects in the local repository. It does not work for the default profile objects in the System Objects organization.
The number of login attempts is configurable, see Section 2.10.2.2, “Changing the Number of Login Attempts”. By default users get three attempts. The number of login attempts is local to each SGD server and is not copied across the array. Only when the login limit is reached on a server, is the user denied access across the array.
For example, a user could try to log in on each SGD server two times, but only when they fail for the third time on a server are they denied access to the other members of the array.
If a user is denied access, they are only denied access to SGD. They are not denied access to the host on which SGD is installed
When a user is denied access, SGD deselects the
Login check box on the
General tab
(--enabled false) for the
user profile object in the Administration Console. To give a
user access again, you must select the check box
(--enabled true).
For security reasons, users are not given any indication that their account is disabled. They see the same message as if they had entered an incorrect password.
You can only enable the login failure handler from the command line.
Use the following command:
$ tarantella config edit \ --tarantella-config-components-loginfailurehandler 1 \ --tarantella-config-components-loginfailurefilter 1
Ensure that no users are logged in to the SGD servers in the array and that there are no running application sessions, including suspended application sessions.
Log in to the primary SGD server as superuser (root).
Stop the primary SGD server.
Set the number of login attempts.
Use the following command:
# tarantella config edit \ --com.sco.tta.server.login.LoginFailureHandler.properties-attemptsallowed
numStart the primary SGD server.
Do a warm restart of all secondary SGD servers.
Use the following command:
# tarantella restart sgd --warm
This section includes troubleshooting information for some common problems that users experience when they log in to SGD using web authentication.
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 user name and password, or there is a problem with the web server configuration.
Check the following:
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 SGD web server, is the password file accessible by the
ttaservuser? If this user cannot read the password file, web authentication fails.
If web authentication is not set up correctly or it fails for any reason, SGD displays the standard login page. Use the following checklist to resolve the problem.
Questions
2.10.3.2.1: Is the right SGD URL protected?
2.10.3.2.2: Is Tomcat configured to trust the web authentication?
2.10.3.2.3: Does the user have a user profile in the local repository?
2.10.3.2.4: Is the user an SGD Administrator?
2.10.3.2.5: Have you changed the trusted user?
Questions and Answers
2.10.3.2.1: Is the right SGD URL protected?
For the workspace, you must set up your web server to
protect the /sgd URL.
2.10.3.2.2: Is Tomcat configured to trust the web authentication?
The Tomcat component of the SGD web server has to be configured to trust Apache web server authentication.
On each array member, edit the
/opt/tarantella/webserver/tomcat/tomcat-version/conf/server.xml
file. Add the
tomcatAuthentication="false"
attribute to the <Connector>
element for the AJP 1.3 Connector.
2.10.3.2.3: Does the user have a user profile in the local repository?
If your configuration of SGD relies on users having user profile objects in the local repository 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 logging, search the log file for messages that indicate that SGD could not find a match for the authenticated user.
Either create a user profile for the user or enable one of the fallback profile objects. See Section 2.6.1, “How Third-Party Authentication Works” for more details.
2.10.3.2.4: Is the user an SGD Administrator?
By default, SGD Administrators cannot access SGD if they have been authenticated by a web server. To change this behavior, see Section 2.6.8, “SGD Administrators and Third-Party Authentication” for details.
2.10.3.2.5: Have you changed the trusted user?
If you have changed the user name and password of the trusted user, have you verified that the new user works? See Section 2.6.9, “Trusted Users and Third-Party Authentication” for details.
With web authentication, SGD performs a search to establish the user identity and login profile. The first matching user profile found is used.
Search the SGD log files for messages that indicate an ambiguous user. This indicates that more than one user identity matched the user.
To resolve the situation, you can do either of the following:
Accept the first match
Attempt to manually resolve the ambiguity, for example by creating or amending user profiles
If all users, including the UNIX system root user, cannot log in to any SGD server, this may be caused by either of the following:
All authentication mechanisms are disabled
User logins to all SGD servers are disabled
To check whether all authentication mechanisms are disabled, use the following command:
$ tarantella config list | grep login
If all authentication mechanisms are disabled, enable the UNIX system authentication mechanism from the command line, as follows:
$ tarantella config edit --login-ens 1
Once the UNIX system authentication mechanism is enabled, you can log in to the Administration Console with the user name Administrator and the UNIX system root user's password. You can then reconfigure authentication.
To check whether user logins are disabled for an SGD server, use the following command:
$ tarantella config list --server serv... --server-login
If user logins to all SGD servers are disabled, use the following command to enable user logins:
$ tarantella config edit --array --server-login 1
SGD enables more than one user to log in using the same user name and password, for example to share an account for guest users.
Anonymous users are always treated as using a shared account, see Section 2.3, “Anonymous User Authentication”.
Users that share a user profile object share the same application server passwords. Guest users cannot add or change entries in the password cache. This means that, unless an SGD Administrator has cached application server passwords for them, guest users are prompted for a password every time they start an application. Use the Administration Console or the tarantella passcache command to manage application server passwords for guest users.
The Ambiguous User Name dialog box is displayed only for users who share person object attributes and also have the same password.
For example, there are two users with the name John Smith (cn=John Smith) and they have chosen the same password. Their email addresses and user names are different. If they log in with the name John Smith, SGD displays the Ambiguous User Name dialog box which asks them to provide either an email address or a user name. The dialog box displays because the credentials they supply match more than one user. If they log in using an email address or a user name, they are logged in.
The Ambiguous User Name dialog box is displayed only if you are using LDAP authentication or UNIX system authentication that searches for the user ID in the local repository.
The solution is to ensure that users have unique passwords.
Alternatively, configure the user profiles to have unique
attributes. SGD uses the Name
(--name), Login Name
(--user) and Email Address
(--email) to identify and
disambiguate users.
The following topics may help you to diagnose and fix issues with SecurID authentication.
The rsa_api.properties properties file
defines the location of the RSA Authentication Manager
configuration file sdconf.rec on the
SGD host. By default, the
rsa_api.properties file is located in the
/opt/tarantella/var/rsa directory.
If your SGD deployment requires that the properties file is located elsewhere, use the following command on each SGD server to set the path to the properties file:
# tarantella config edit --tarantella-config-server-securidpropdir props-dir
where props-dir is the directory
path for the rsa_api.properties
properties file.
Ensure that the properties file is readable by SGD. For example:
# chmod 444 rsa_api.properties
The SecurID authentication timeout controls how long SGD waits for a successful authentication.
If you see log messages about login timeouts, use the following command to increase the SecurID timeout value for the array:
# tarantella config edit --tarantella-config-array-securidtimeout secsThe default timeout value is 3000 seconds (5 minutes).
This section includes some troubleshooting and advanced configuration topics for single sign-on authentication.
Single sign-on users are automatically given the workspace
associated with the default third-party user profile object,
System Objects/Third Party Profile.
Additional workspace content, such as application objects, can
be assigned to all single sign-on users by direct assignment
to the default third-party user profile.
To assign an application to a specific user or group, use the
LDAP Search (--ldapsearch) attribute for the
application object. This is an LDAP search filter which can be
compared to the data returned from Oracle Access Manager in the string
OAM_DATA.
For example, if OAM_DATA is configured to
return group data in the form
group=,
a search filter of group-name"(group=marketing)"
assigns the application object to all users in the Oracle Access Manager
group, marketing.
The Oracle Access Manager session always terminates automatically when a user logs out of SGD. This applies whether the user authenticated using single sign-on before or after logging in to SGD.
Oracle Access Manager sessions automatically timeout if they are idle for 15 minutes. Single sign-on users may need to resubmit credentials in this case.
See the Oracle Access Manager documentation for more information on session timeouts for Oracle Access Manager.
Automatic provisioning (autoprovisioning) enables all single sign-on users to authenticate to an application server using a common user account, called a base user. This removes the need to map single sign-on accounts on Oracle Access Manager to application server accounts and means that users are not prompted for credentials when they start an application.
Autoprovisioning of application server users is available for X applications running on a UNIX or Linux platform application server. The application must use the Firefox browser.
The Firefox browser runs as the base user and uses a temporary Firefox profile, which is deleted when the application is closed. Credentials for the base user are added automatically to the SGD application server password cache, so that users are not prompted for credentials when they run the application.
Autoprovisioning for Windows application servers is not available.
To use autoprovisioning, do the following:
In the Administration Console, go to the Launch page for the application object and select the Enabled with Auto Provisioning option for the Single Sign-On attribute.
Select the Application Server that hosts the application.
Enter credentials for the base user. The base user must have an account on the application server and must have the required permissions to run the application.
You can also use the following command line to enable autoprovisioning for an X application object:
$ tarantella object edit --name obj --ssoauth 2Use the tarantella passcache command to add base credentials for the application, as follows:
$ tarantella passcache new \ --person "SSO" \ --type "SSO" \ --resource ".../_ens/o=applications/cn=app&.../_ens/o=appservers/cn=appserv" \ --resuserbase-user
where app is the name of the
application, appserv is the name of
the application server, and
base-user is the base user for the
application server.