C H A P T E R 2 |
SGD has two stages to user authentication. First, users authenticate to an SGD server to log in to SGD. This is known as Secure Global Desktop authentication. Second, users authenticate to an application server to run an application. This is known as application authentication. User authentication is described in the following topics:
The following topics describe the Secure Global Desktop authentication mechanisms and how they are configured:
SGD is designed to integrate with your existing authentication infrastructure and supports the following two mechanisms for authenticating users:
System authentication. SGD tries to authenticate the user’s credentials against one or more external authentication services, for example an LDAP directory. See System Authentication Mechanisms for details of the available system authentication mechanisms.
Third-party authentication. An external mechanism authenticates the user and SGD trusts that the authentication is correct. The most common use of third-party authentication is web server authentication. See Third-Party and Web Server Authentication for more details.
The following are main results of a successful authentication:
A user identity. The SGD idea of who a user is. See User Identity for more details.
A user profile. The user’s SGD-related settings. See User Profile for more details.
Sometimes the user identity and the user profile are the same.
In the SGD Administration Console, you can monitor user sessions and application sessions using either the user identity or the user profile.
Depending on how users are authenticated, SGD can prompt users to change their password when they try to log in with an expired password. See Password Expiry for details.
SGD authentication is global. A user can log in to each SGD server in the array with the same user name and password.
SGD Administrators can enable and disable each authentication mechanism independently, as follows:
A user identity is the SGD idea of who a user is. Each authentication mechanism has its own set of rules for determining the user identity.
A user identity is a name assigned by SGD and is sometimes referred to as the fully qualified name. The user identity is not necessarily the name of a user profile in the local repository. For example, for Lightweight Directory Access Protocol (LDAP) authentication the identity is the distinguished name (DN) of the user in the LDAP directory.
The user identity is associated with the user’s SGD session, their application sessions, and their entries in the application server password cache.
A user profile controls a user’s SGD-specific settings. Depending on whether or not you use an LDAP directory to assign applications to users, a user profile can also control the applications a user can access through SGD, sometimes called webtop content. Each authentication mechanism has its own set of rules for determining the user profile.
A user profile is always an object in the local repository and is sometimes referred to as an equivalent name. A user profile can be a special object called a profile object stored in the System Objects organization. For example, for LDAP authentication the default user profile is System Objects/LDAP Profile.
The following table lists the available system authentication mechanisms and describes the basis for authentication.
Mechanism | Description |
---|---|
Anonymous user | Enables users to log in to SGD without using a user name and password. |
Authentication token | Enables users to log in to SGD if the
SGD Client supplies a valid authentication token.
Users might have their own webtop content, depending on configuration. Used when the SGD Client operates in Integrated mode, see Integrated Mode. |
UNIX system – Search Unix User ID in Local Repository | Enables users to log in to SGD if they
have user profiles in the local repository and UNIX or Linux system
accounts on the SGD host.
Users might have their own webtop content, depending on configuration. |
Windows Domain | Enables users to log in to SGD if they
belong to a specified Windows domain.
Users might have their own webtop content, depending on configuration. |
LDAP | Enables users to log in to SGD if they
have an entry in an LDAP directory.
Users might have their own webtop content, depending on configuration. |
Active Directory | Enables users to log in to SGD if they
have an account in an Active Directory domain.
Users might have their own webtop content, depending on configuration. |
UNIX system – Search Unix Group ID in Local Repository | Enables users to log in to SGD if they
have UNIX or Linux system accounts on the SGD host.
All users in the same UNIX group have the same webtop content. |
UNIX system – Use Default User Profile | Enables users to log in to SGD if they have UNIX or Linux system accounts on the SGD host. |
SecurID | Enables users with RSA SecurID tokens
to log in to SGD.
Users might have their own webtop content, depending on configuration. |
When a user logs in, the enabled authentication mechanisms are tried in the order they are listed in TABLE 2-1. When you configure SGD authentication, the Administration Console shows the order in which the mechanisms are tried. The first authentication mechanism that authenticates a user “wins” and no further authentication mechanisms are tried.
In most circumstances, SGD can handle the expiry of the user’s password if configured to do so. When a user attempts to log in to SGD with an expired password, the Aged Password dialog displays. This dialog does the following:
If the new password is accepted, the user is logged in to SGD.
The following table shows which authentication mechanisms support aged passwords.
Authentication Mechanism | Aged Password Support |
---|---|
Active Directory | Yes. See Kerberos Configuration File for details. |
Anonymous user | Not applicable. User logs in without a user name or password. |
Authentication token | Not applicable. User logs in without a user name or password. |
LDAP | Yes. See LDAP Authentication and Password Expiry for details. |
SecurID | Yes. If the user’s PIN has expired, a new PIN dialog is displayed instead of the Aged Password dialog. |
Third-party | No. The expiry of the user’s password is handled by the third-party authentication mechanism and is nothing to do with SGD. |
UNIX system | Yes. See UNIX System Authentication and PAM for details. |
Windows domain | No. |
When logging in to SGD, passwords and authentication tokens are only encrypted if there is an Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) connection.
SGD uses external mechanisms for authenticating users. The security of passwords when authenticating users is as follows:
Active Directory authentication uses the Kerberos protocol for authentication, which is secure
LDAP authentication can be configured to use a secure connection
Web server authentication is only secure if the user has an HTTPS connection
All other authentication mechanisms use the native protocols for authenticating users
When a user clicks a link to start an application, the login script configured for the application connects to the application server, handles the authentication process, and starts the application.
The Execution Protocol Engine is the SGD component that runs the login script. The login script authenticates the user to the application server by submitting a user name and password stored in the SGD application server password cache. If there is a problem with the user’s credentials, SGD displays an Application Authentication dialog as follows:
The Application Authentication dialog enables users to enter their credentials and store them in the application server password cache so that they are not prompted when they next run an application on that application server.
Users can also force SGD to display the Application Authentication dialog by holding down the Shift key when they click an application’s link on the webtop.
Note - You cannot use the Shift key in this way when the SGD Client is in Integrated mode. |
This section includes the following topics:
SGD uses login scripts to handle the connection to the application server, to run the application, and to perform additional tasks.
Typically a login script performs the following tasks:
Logs in to the application server, prompting the user for a password if necessary.
Sets environment variables. These are the variables specified by the Environment Variables attribute on the Launch tab for the application object.
Starts any window manager programs. These are the programs specified by the Window Manager attribute on the Presentation tab for the application object.
Starts an input method or input method editor if one is required.
The login script takes into account the differences between application servers, and checks for any errors that might occur during the login process. If an error is encountered that cannot be handled, control is passed back to the user.
The SGD login scripts are designed to be as universal and robust as possible. However, you might need to cope with an unusual scenario. For example, if you have a system prompt that is not catered for, you can add it to the list of prompts recognized by the script.
The login scripts supplied with SGD also contain commands and procedures that you can use to customize the display of the Application Authentication dialog, for example by adding your own labels for the Username and Password fields.
If you need to customize a login script, make a copy of an SGD login script and work on the copy. Do not modify the standard SGD login scripts. contains detailed reference information about SGD login scripts.
In the Administration Console, the attributes on the Global Settings -> Application Authentication tab control application authentication. These attributes allow you to configure the following:
Whether to automatically try the user’s SGD user name and password when logging in to an application server if these details have been cached
What action to take if the user’s application server password has expired
Whether to log in to a Microsoft Windows application server using a smart card
When to display the Application Authentication dialog, what the default settings are on the dialog, and whether users can change them
SGD supports RSA SecurID authentication for X and character applications.
To use SecurID authentication, ensure that users can log in to the application server using SecurID before introducing SGD. When you are ready to use SecurID authentication, configure the application object to use the securid.exp login script.
When logging in to an application server that uses SecurID authentication, users enter a user name and password. When they click OK, they are prompted for a passcode.
In the Administration Console, go to the Global Settings -> Application Authentication tab and deselect the Password Cache Usage check box. This prevents SGD from using SGD login details when logging in to the application server.
By default, SGD stores the user names and passwords used to run applications in its application server password cache. SGD also stores the user names and passwords used to log in to SGD.
In the Administration Console, you can manage the application server password cache as follows:
The Caches -> Passwords tab – This tab enables you to manage any entry in the password cache
The Passwords tab for user profile objects – This tab enables you to manage password cache entries for the selected user profile
The Passwords tab for application server objects – This tab enables you to manage password cache entries for the selected application server
On the command line, you manage the application server password cache with the tarantella passcache family of commands.
You can use the Administration Console and the command line to list and delete entries in the password cache. You can also create entries in the password cache. With the tarantella passcache command, you can populate the password cache with a batch script.
Each entry in the password cache involves the following elements:
A resource – The application server or domain name for which the password is cached
A user identity –The identity of the user that “owns” the entry in the password cache
Note - The user’s SGD password can also be stored in the password cache. |
Entries in the application server password cache are encrypted with an encryption key. When starting applications, the passwords are decrypted as they are needed.
By default, the encryption key used for the password cache never changes. You can configure SGD to generate a new encryption key for the password cache whenever an SGD server restarts. In the Administration Console, go to the Global Settings -> Security tab and select the New Password Encryption Key check box. Alternatively, use the following command:
$ tarantella config edit --security-newkeyonrestart 1 |
Existing entries in the password cache are re-encrypted with the new key.
When SGD caches a user’s password for a Microsoft Windows application server, the password cache entry is created using the Windows domain name.
The domain name can be specified using the Domain Name attribute on application server objects, Windows application objects, or user profile objects. Users can also specify a domain name on the Application Authentication dialog.
When a user starts an application, SGD goes through the following process to establish the domain name and password cache entry to use:
Check if a domain name is set on the application server object.
If a domain name is set, SGD searches the password cache for an entry for the user identity.
If there is no domain name, or there is no entry in the password cache, move to step 2.
Check if a domain name is set on the application object.
If a domain name is set, SGD searches the password cache for an entry for the user identity.
If there is no domain name, or there is no entry in the password cache, move to step 3.
Check if the user typed a domain name type when they logged in to SGD.
If you are using Windows Domain authentication, users can specify a domain name when they log in to SGD. They do this by typing a user name in the format domain\name, for example indigo\rusty.
If a domain name is set, SGD searches the password cache for an entry for the user identity.
If there is no domain name, or there is no entry in the password cache, SGD displays the Application Authentication dialog.
The Application Authentication dialog has an NT Domain field that enables users to set the domain name. This field is automatically completed if the Domain Name attribute is set for the application server or application object, or if the domain is cached in the password cache. If the Domain Name attribute is set only on the user profile object, the NT Domain field is not completed.
To force users to specify a domain when they start a Windows application for the first time, you must ensure that the Domain Name attribute is blank for the user profile object, the application server object, and the application object.
If a user’s SGD password is also their Windows domain password, the domain name and password can be cached if the following are true:
SGD must be configured to save the user’s SGD user name and password in the password cache. SGD does this by default.
The Domain Name must be set on the user profile object.
Note - If the user is authenticated using a Microsoft Active Directory server, you do not need to set the Domain Name attribute on the user profile object as the domain name can be inferred. |
To support users in different locales when starting applications, you might have to do the following:
The following sections describe how you do this.
By default, the login scripts supplied with SGD support English system prompts on application servers. SGD Administrators can add support for system prompts in other languages.
To do this, you edit the vars.exp login script and add a translation for each of the English prompts defined. The vars.exp login script is located in the /opt/tarantella/var/serverresources/expect directory on the SGD server. You do not need to translate every prompt, only the prompts that are different to the English ones. The file contains examples to help you get started. You can also provide translations for the variables, strings, and error message section to match the client or user locale.
In the Administration Console, configure the General tab -> Prompt Locale attribute for your application server objects, to match a locale defined in vars.exp.
An input method is a program or operating system component that allows users to enter characters and symbols not found on their keyboard. On Microsoft Windows Platforms, an input method is called an input method editor (IME).
When running applications, SGD enables an IM if either the TTA_PreferredLocale, TTA_HostLocale, or the LANG (from the application environment overrides) environment variables are set to a locale that requires an IM. The locales that require an IM are controlled by the IM_localeList variable, defined in the vars.exp login script.
By default, an IM is enabled for all Japanese, Korean, and Chinese locales.
To enable an IM in other locales, you must edit vars.exp and add the locale to the IM_localeList variable.
Active Directory authentication enables users to log in to SGD if they have an account in an Active Directory domain. Active Directory authentication offers users a faster, more secure, and more scalable authentication mechanism than LDAP authentication. By using the Kerberos authentication protocol, SGD can securely authenticate any user against any domain in a forest.
Active Directory authentication is disabled by default.
This section includes the following topics:
At the SGD login screen, the user types a user principal name and password. A user principal name is a user name and a domain name joined by the “@” sign, for example indigo@indigo-insurance.com.
SGD uses the Kerberos protocol to check the user principal name and password against a Key Distribution Center (KDC) for a domain.
If the authentication fails, the next authentication mechanism is tried.
If the Kerberos authentication succeeds, SGD establishes the user’s identity by performing an LDAP search of Active Directory. Next, SGD searches for the user profile. See User Identity and User Profile for details. If the Login attribute of the user profile is not enabled, the user cannot log in and no further authentication mechanisms are tried. If the Login attribute of the user profile is enabled, the user is logged in.
The user identity is the LDAP identity. In the Administration Console, the user identity is displayed as LDAP-ID (LDAP). On the command line, the user identity is displayed as .../_service/sco/tta/ldapcache/LDAP-ID.
SGD establishes the user profile by searching the local repository, allowing for differences between the LDAP and SGD naming systems. SGD searches for the following until a match is found:
A user profile with the same name as the LDAP person object.
For example, if the LDAP person object is cn=Emma Rald,cn=Sales,dc=Indigo Insurance,dc=com, SGD searches the local repository for dc=com/dc=Indigo Insurance/cn=Sales/cn=Emma Rald.
A user profile in the same organizational unit as the LDAP person object but with the name cn=LDAP Profile.
For example, dc=com/dc=Indigo Insurance/cn=Sales/cn=LDAP Profile.
A user profile in any parent organizational unit with the name cn=LDAP Profile.
If there is no match, the profile object System Objects/LDAP Profile is used for the user profile.
You can use Active Directory authentication with Directory Services Integration. The applications assigned to Active Directory users come from a combination of the user profile and from LDAP searches. See Chapter 3 for details of how applications are assigned to users.
Setting up Active Directory authentication involves the following configuration steps:
Ensure Active Directory is configured correctly.
Kerberos authentication must be enabled in Active Directory. It is by default.
Ensure each Active Directory domain has a global catalog server.
Consult your system documentation for details of Kerberos authentication and global catalog servers.
Configure SGD for Kerberos authentication.
Configure SGD with the details of the KDCs to use for Kerberos authentication.
Enable Active Directory authentication.
Configure SGD to use Active Directory authentication and specify the Active Directory domain details.
See How to Enable Active Directory Authentication.
Connections to Active Directory are always secure. To use SSL for secure connections, additional configuration is required. See How to Configure SSL Connections to Active Directory.
To use Active Directory authentication, every SGD server in the array must be configured for Kerberos authentication.
Whenever you make changes to your Kerberos configuration, SGD does not detect the changes until you restart the SGD server. Alternatively, you can use the following command to refresh the Kerberos configuration without restarting the SGD server:
$ tarantella cache --flush krbconfig |
For the Administration Console to detect changes to your Kerberos configuration, you must restart the SGD Web Server.
You configure SGD for Kerberos authentication by synchronizing system clocks and adding entries to a Kerberos configuration file, as described in the following sections.
To use Kerberos authentication, the clocks on the KDCs and the SGD servers in the array must be synchronized so that the time is within the maximum tolerance for computer clock synchronization defined for the Kerberos security policy and the Default domain security policy on the Microsoft Windows server. This is called clock skew. If the clock skew is exceeded, the Kerberos authentication fails.
Because time synchronization is important, use Network Time Protocol (NTP) software to synchronize clocks. Alternatively, use the rdate command.
A Kerberos configuration file must be present on each SGD server in the array. The Kerberos configuration file used by an SGD server is either of the following:
The SGD Kerberos configuration file.
This is the /opt/tarantella/bin/jre/lib/security/krb5.conf file.
You must manually create this file or copy an existing configuration file. If this configuration file exists, it is used instead of the system default configuration file.
A Kerberos configuration file contains many options for controlling Kerberos authentication. Consult your system documentation for more details. The following configuration options are the minimum requirements for SGD:
Kerberos realms and KDCs. The KDCs SGD uses to authenticate users.
Password expiry. Whether or not SGD prompts a user for a new password if their password has expired.
Network protocol. Whether SGD uses the User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) for Kerberos authentication.
KDC timeout. What happens if there is a failure in the authentication process.
These configuration options are described in the following sections.
As a minimum, the Kerberos configuration file must contain the following sections:
[libdefaults]. This sets defaults for Kerberos authentication. You must set the default_realm and default_checksum.
[realms]. This sets the KDCs for each Kerberos realm. A realm can have more than one KDC. The entry for each KDC has the form host:port. The port can omitted if the default port 88 is used.
[domain_realm]. This maps Active Directory domains to Kerberos realms.
The following is an example Kerberos configuration file:
[libdefaults] default_realm = INDIGO-INSURANCE.COM default_checksum = rsa-md5 [realms] INDIGO-INSURANCE.COM = { kdc = melbourne.indigo-insurance.com } EAST.INDIGO-INSURANCE.COM = { kdc = ad01.east.indigo-insurance.com kdc = ad02.east.indigo-insurance.com } WEST.INDIGO-INSURANCE.COM = { kdc = ad01.west.indigo-insurance.com kdc = ad02.west.indigo-insurance.com } [domain_realm] indigo-insurance.com = INDIGO-INSURANCE.COM .east.indigo-insurance.com = EAST.INDIGO-INSURANCE.COM east.indigo-insurance.com = EAST.INDIGO-INSURANCE.COM .west.indigo-insurance.com = WEST.INDIGO-INSURANCE.COM west.indigo-insurance.com = WEST.INDIGO-INSURANCE.COM |
SGD can be configured to prompt a user for a new password if their Active Directory password has expired. To do this, the details of the server that handles the password change for each Kerberos realm must be added to the Kerberos configuration file, as follows:
kpasswd_server = host:port admin_server = host:port kpasswd_protocol = SET_CHANGE
The kpasswd_server and admin_server lines identify the Kerberos administration server that handles the password change. If kpasswd_server is omitted, the admin_server is used instead. The port can omitted if the default port 464 is used.
The following is an example of password expiry configuration for a realm:
EAST.INDIGO-INSURANCE.COM = { kdc = ad01.east.indigo-insurance.com kdc = ad02.east.indigo-insurance.com admin_server = ad01.east.indigo-insurance.com kpasswd_protocol = SET_CHANGE }
When sending messages to the KDC or the Kerberos administration server, SGD uses either the UDP or TCP protocols. The protocol used is determined by the following line in the [libdefaults] section of the Kerberos configuration file:
udp_preference_limit = bytes
This line sets the maximum size in bytes for packets that can be sent using UDP. If the message is larger than this size, TCP is used. If the KDC or administration server indicates that the package is too big, TCP is used instead. To always use TCP, set the udp_preference_limit as follows:
udp_preference_limit = 1
If the Kerberos authentication process fails, you can configure a KDC timeout that controls how long SGD waits for a reply from a KDC, and how many times it tries to contact each KDC.
To set the KDC timeout, add the following lines to the [libdefaults] section of the Kerberos configuration file:
kdc_timeout = time max_retries = number
The kdc_timeout sets the maximum number of milliseconds to wait for a reply from a KDC. The max_retries is the maximum number of times each KDC is tried. The KDCs for each realm are tried in the order they are listed in the [realms] section of the Kerberos configuration file.
It is best to keep the KDC timeout and the LDAP discovery timeout in step. If you increase the KDC timeout, increase the LDAP discovery timeout. See LDAP Discovery Timeout.
If SGD cannot contact any KDCs for the user’s realm, the authentication phase fails.
In the Administration Console, display the Secure Global Desktop Authentication Configuration Wizard.
Go to the Global Settings -> Secure Global Desktop Authentication tab and click the Change Secure Global Desktop Authentication button.
On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.
On the System Authentication - Repositories step, select the LDAP/Active Directory check box.
On the LDAP Repository Details step, configure the Active Directory domain details.
In the URLs field, type the URL of an Active Directory domain.
For example, ad://east.indigo-insurance.com.
The URL must start with ad://. Only type one URL.
SGD uses the domain name to perform a Domain Name System (DNS) lookup to obtain a list of global catalog servers. The global catalog is used to determine which Active Directory servers SGD can search to determine the user identity and user profile.
Configure secure connections to Active Directory.
To use only the Kerberos protocol for secure connections, select the Kerberos option for Connection Security, and type the user name and password of a user that has privileges to search Active Directory in the User Name and Password fields.
To use Kerberos and SSL for secure connections, select the SSL option for Connection Security, and type the user name and password of a user that has privileges to search Active Directory in the User Name and Password fields.
To use Kerberos, SSL, and client certificates for secure connections, select the SSL option for Connection Security, and select the Use Certificates check box.
See How to Configure SSL Connections to Active Directory for details of the additional configuration required to use SSL connections.
If you type a user name and password, the user name must be the user principal name, for example sgd-ldap@indigo-insurance.com. You might want to create a special user reserved for Active Directory authentication.
In the Base Domain field, type a partial domain name.
The base domain is used when users only supply a partial domain when they log in. For example, if the base domain is set to indigo-insurance.com and a user logs in with the user name rouge@west, SGD tries to authenticate the user as rouge@west.indigo-insurance.com.
In the default Domain field, type a domain name to use as a default.
The default domain is used when users do not supply a domain when they log in. For example, if the default domain is set to east.indigo‐insurance.com and a user logs in with the user name rouge, the SGD tries to authenticate the user as rouge@east.indigo‐insurance.com.
On the Review Selections step, check the authentication configuration and click Finish.
Enable LDAP signing requirements for the domain.
You must enable LDAP signing on your domain controllers so that they accept SSL connections.
Consult you system documentation for details of how to enable LDAP signing.
Import the Certificate Authority (CA) or root certificate for your Active Directory servers into the CA certificates truststore.
To be able to use SSL for secure connections, SGD must be able to validate the certificate presented by an Active Directory server.
You might have to import the CA certificates for the Active Directory servers you are using with SGD into the CA certificate truststore. See The CA Certificate Truststore for details of how to check for supported CAs and how to import CA certificates.
Create and install client certificates for each SGD server in the array.
If you are using client certificates for SSL connections to Active Directory, each SGD server in the array must have a valid client certificate that has been signed using the Certificate Services on a Microsoft Windows server.
You create and install a client certificate as follows:
Create a certificate signing request (CSR) for the client certificate for an SGD server.
See How to Create a Client Certificate CSR for an SGD server.
Create the client certificate for an SGD server using Microsoft Certificate Services.
Consult your system documentation for details of how to create a client certificate using Microsoft Certificate Services.
The following is an example of how to create a client certificate.
Using Microsoft Internet Explorer, go to http://WindowsServer/certsrv and log in.
On the Microsoft Certificate Services page, click Request a certificate.
On the Request a Certificate page, click advanced certificate request.
On the Advanced Certificate Request page, click Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
On the Submit a Certificate Request or Renewal Request page, paste the contents of the CSR into the Saved Request text box or browse to the CSR file.
Select an appropriate template from the Certificate Templates list.
On the Certificate Issued page, ensure Base 64 encoded is selected and click Download certificate.
Ensure the correct firewall ports are open.
Each SGD server in the array must be able to make secure connections to Active Directory.
The ports required depends on the SSL configuration used for Active Directory authentication, as follows:
SSL connections without client certificates – TCP port 636 for the secure LDAP connection to an Active Directory server, and TCP port 3289 for the secure connection to the global catalog server
SSL connections with client certificates – TCP port 389 for the secure LDAP connection to an Active Directory server, and TCP port 3288 for the secure connection to the global catalog server
Anonymous user authentication enables users to log in to SGD without using a user name and password.
As users are anonymous, SGD assigns each anonymous user a temporary user identity. The user identity is only effective while the user is logged in.
Anonymous user authentication is disabled by default.
This section includes the following topics:
At the SGD login screen, the user clicks the Log In button, leaving the user name and password blank.
If the user types a user name or a password, the authentication fails and the next authentication mechanism is tried.
If both the user name and the password are blank, the user is authenticated and is logged in.
As the user does not supply a user name or password when they log in, SGD assigns a temporary user identity. In the Administration Console, the user identity is displayed as server:number (anon). On the command line, the user identity is displayed as .../_dns/server/_anon/number.
The profile object System Objects/Anonymous Profile is always used for the user profile. All anonymous users receive the same webtop content.
Each user logged in anonymously has independent application sessions. The application sessions end automatically when the user logs out even if the application is configured to be always resumable.
All password cache entries belong to the System Objects/Anonymous User Profile object. All anonymous users share the same application server passwords. Anonymous users are not allowed to add or change entries in the password cache. This means that, unless an SGD Administrator has cached application server passwords for the System Objects/Anonymous User Profile object using the tarantella passcache command, anonymous users are prompted for a password every time they start an application.
In the Administration Console, display the Secure Global Desktop Authentication Configuration Wizard.
Go to the Global Settings -> Secure Global Desktop Authentication tab and click the Change Secure Global Desktop Authentication button.
On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.
On the System Authentication - Repositories step, select the Anonymous check box.
On the Review Selections step, check the authentication configuration and click Finish.
LDAP authentication enables users to log in to SGD if they have an entry in an LDAP directory.
This authentication mechanism is disabled by default.
This section includes the following topics:
At the SGD login screen, the user types a user name and password. The user name can be any of the following:
SGD searches the LDAP directory for a person object with an attribute that matches the user name typed by the user. By default, SGD searches the following attributes:
If a person object is not found, the next authentication mechanism is tried.
If a person object is found, the password typed by the user is checked against the LDAP person object. If the authentication fails, the next authentication mechanism is tried.
If the authentication succeeds, SGD searches the local repository for the user profile, see User Identity and User Profile for details. If the Login attribute of the user profile is not enabled, the user cannot log in and no further authentication mechanisms are tried. If the Login attribute of the user profile is enabled, the user is logged in.
The user identity is the LDAP identity. In the Administration Console, the user identity is displayed as LDAP-ID (LDAP). On the command line, the user identity is displayed as .../_service/sco/tta/ldapcache/LDAP-ID.
SGD establishes the user profile by searching the local repository, allowing for differences between the LDAP and SGD naming systems. SGD searches for the following until a match is found:
A user profile with the same name as the LDAP person object.
For example, if the LDAP person object is cn=Emma Rald,cn=Sales,dc=Indigo Insurance,dc=com, SGD searches the local repository for dc=com/dc=Indigo Insurance/cn=Sales/cn=Emma Rald.
A user profile in the same organizational unit as the LDAP person object but with the name cn=LDAP Profile.
For example, dc=com/dc=Indigo Insurance/cn=Sales/cn=LDAP Profile.
A user profile in any parent organizational unit with the name cn=LDAP Profile.
If there is no match, the profile object System Objects/LDAP Profile is used for the user profile.
You can use LDAP authentication with Directory Services Integration. The applications assigned to LDAP users come from a combination of the user profile and from LDAP searches. See Chapter 3 for details of how applications are assigned to users.
SGD supports version 3 of the standard LDAP protocol. You can use LDAP authentication with any LDAP version 3‐compliant directory server. SGD supports this functionality on the following directory servers:
Before you enable LDAP authentication, make sure all the SGD servers in the array can contact each LDAP directory server used for authentication.
In the SGD Administration Console, display the Secure Global Desktop Authentication Configuration Wizard.
Go to the Global Settings -> Secure Global Desktop Authentication tab and click the Change Secure Global Desktop Authentication button.
On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.
On the System Authentication - Repositories step, select the LDAP/Active Directory check box.
On the LDAP Repository Details step, configure the LDAP directory details.
For Repository Type, select the LDAP option.
Select this option even if you are using a Microsoft Active Directory server.
In the URLs field, type the URL of one or more LDAP directory servers.
For example, ldap://melbourne.indigo-insurance.com.
After typing each URL, press the Return key.
If there is than one URL, SGD uses the URLs in the order they are listed. If the first LDAP directory server in the list is unavailable, the next one is tried.
To use secure connections to LDAP directory servers, use an ldaps:// URL.
To be able to use secure connections, SGD must be able to validate the certificate presented by an LDAP directory server. You might have to import the CA certificates for the LDAP directory servers you are using with SGD into the CA certificate truststore. See The CA Certificate Truststore for details of how to check for supported CAs and how to import CA certificates.
The standard port used for connections to LDAP directory servers is port 389. If the LDAP directory server uses a different port, specify the port number as part of the URL, for example ldap://melbourne.indigo-insurance.com:5678.
Adding a search root to the end of the URL, for example ldap://melbourne.indigo-insurance.com/dc=indigo-insurance,dc=com restricts the part of the LDAP directory used to search for the user identity.
Type the details of an LDAP user in the User Name and Password fields.
The user name must be the distinguished name of the user, for example cn=sgd-user,cn=Users,dc=indigo-insurance,dc=com.
Some LDAP directory servers support anonymous logins, so you do not need to supply a user name or password. Others, including Microsoft Active Directory, require the user name and password of a user that has sufficient privileges to search the LDAP directory.
As you can only enter one user name and password, this user must be able to search all LDAP directory servers listed in the URL field.
You might want to create a special LDAP user reserved for the SGD LDAP authentication.
On the Review Selections step, check the authentication configuration and click Finish.
SGD can prompt a user for a new password if their password has expired on the LDAP directory server. Additional configuration might be needed, as follows.
For Sun Java System Directory Servers (formerly known as Sun ONE, Netscape software, or iPlanet Directory Server) Sun One Directory Servers, note the following:
Do not use the “User must change password after reset” option either in the global password policy or for an individual password policy. This causes the password change to fail.
The LDAP user entered in the User Name and Password fields for LDAP authentication must have administrative privileges.
For Microsoft Active Directory, password expiry, including forcing the user to change their password at next logon, can only be handled if there is a secure connection between the SGD server and the Active Directory server.
Once LDAP authentication is enabled, any user with an entry in the LDAP directory can log in to SGD. However, you might not want all LDAP users to have access to SGD.
To restrict the LDAP users that can log in to SGD, you can configure an LDAP login filter so that only the users that have a required attribute value on their LDAP person object can log in to SGD. This requires extra configuration in the LDAP directory and in SGD.
To be able to apply a filter, SGD must be able to test for an attribute value on the person object in the LDAP directory. You can use an attribute that already exists in your LDAP directory or create a new attribute, for example an attribute called allowsgdlogin. This attribute must be set for all users in the LDAP directory.
Once you have configured the LDAP user object attribute, you configure the login filter to test for the LDAP attribute and allow users to log in if they meet the condition. See How to Configure an LDAP Login Filter.
Repeat this procedure on each SGD server in the array.
Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.
SecurID authentication enables users with RSA SecurID tokens to log in to SGD. SGD authenticates users against an RSA Authentication Manager, formerly known as ACE/Server.
RSA SecurID is a product from RSA Security, Inc., that uses two-factor authentication based on something you know, a PIN, and something you have, a tokencode supplied by a separate token such as a PIN pad, standard card, or software token. The PIN and tokencode are combined to form a passcode which is used as the password when you log in to SGD.
This authentication mechanism is disabled by default.
This section includes the following topics:
SGD works with versions 4, 5, and 6 of the RSA Authentication Manager.
At the SGD login screen, the user types their SecurID user name, for example indigo, and their passcode.
This authentication mechanism searches the local repository for a user profile with a Name attribute that matches the user name typed by the user. If there is no match, the search is repeated on the Login Name attribute, and finally on the Email Address attribute.
If a user profile is found, the Login Name attribute of that object is used as the SecurID user name. If no user profile is found, the name the user typed is used as the SecurID user name.
Next, SGD checks the SecurID user name, and the passcode typed by the user, against the RSA Authentication Manager. If the authentication fails, the user cannot log in because there are no further authentication mechanisms to try.
If the authentication succeeds and the Login attribute for the user profile is not enabled, the user is not logged in. If the authentication succeeds and the Login attribute for the user profile is enabled, the user is logged in.
If a user profile was found in the local repository, this is used for the user identity and user profile. In the Administration Console, the user identity is displayed as user-profile (Local). On the command line, the user identity is displayed as .../_ens/user-profile.
If no user profile was found in the local repository, the user identity is the SecurID user name. In the Administration Console, the user identity is displayed a SecurID-username (SecurID). On the command line, the identity is displayed as .../_service/sco/tta/securid/SecurID-username. The profile object System Objects/SecurID User Profile is used for the user profile.
Setting up SecurID authentication involves the following configuration steps:
Install and configure RSA SecurID.
Ensure you are using a supported version of RSA SecurID, see Supported Versions of SecurID
Ensure the RSA Authentication Manager is up to date with the latest patches released by RSA.
Configure each SGD server in the array as an Agent Host.
Each SGD server in the array acts an Agent Host so that it can authenticate users against the RSA Authentication Manager.
Enable SecurID authentication in SGD.
Configure SecurID authentication so that SecurID users can log in to SGD.
To use SecurID authentication, each SGD server in the array must be configured as an Agent Host. As SecurID implementations can vary, the following procedure is an example only. Consult your SecurID documentation for details of how to configure an Agent Host.
Before you begin, ensure you have access to the RSA Authentication Manager configuration file, sdconf.rec.
Ensure the SGD server can contact the RSA Authentication Manager on the network.
You might have to open ports in your firewalls to allow an SGD server to contact the RSA Authentication Manager.
Specify the location of the RSA Authentication Manager configuration file.
Copy the RSA Authentication Manager configuration file to the SGD server.
Set the file permissions so that SGD can read and write the configuration files.
# chmod 444 /etc/sdace.txt # chown -R ttasys:ttaserv /opt/ace # chmod -R 775 /opt/ace |
Register the SGD servers as Agent Hosts in the RSA Authentication Manager database.
Use either the RSA Authentication Manager Database Administration application or sdadmin application.
Add the SGD server as a UNIX Agent Host in the database, using the fully qualified name, server.domain.com.
For each Agent Host, Configure Group or User Activation. Alternatively, set the Open to All Locally Known Users option.
In the SGD Administration Console, display the Secure Global Desktop Authentication Configuration Wizard.
Go to the Global Settings -> Secure Global Desktop Authentication tab and click the Change Secure Global Desktop Authentication button.
On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.
On the System Authentication - Repositories step, select the SecurID check box.
On the Review Selections step, check your authentication configuration and click Finish.
Third-party authentication enables users to log in to SGD if they have been authenticated by an external mechanism.
If you are using the SGD webtop, the only form of third-party authentication you can use is web server authentication. If you develop your own webtop applications using SGD web services, you can use any third-party authentication mechanism.
Third-party authentication is disabled by default.
This section includes the following topics:
The user types in a user name and password directly to the external mechanism, typically using a web browser’s authentication dialog.
Third-party authentication is based on trust. SGD trusts that the third-party mechanism has authenticated the user correctly and so they are authenticated to SGD.
Next SGD performs a search to establish the user identity and user profile. SGD supports the following search methods for establishing the user identity and user profile:
If more than one search method is enabled, the methods are tried in the order they are listed above. The first matching user identity found is used. The search methods are described in the following sections.
If the searches do not produce a match, SGD cannot establish an identity for the user and the user cannot log in. If you are using the SGD webtop, the standard login page displays so that the user can log in using system authentication.
The Search Local Repository method searches the local repository for a user profile with a Name attribute that matches the user’s third-party user name. If there is no match, the search is repeated on the Login Name attribute, and finally on the Email Address attribute. If no user profile is found, the next search method is tried.
The Search LDAP Repository method searches an LDAP directory for a person object with a cn (common name) attribute that matches the user name typed by the user. If there is no match, the search is repeated on the uid (username) attribute, and finally on the mail (email address) attribute. If a person object is not found, the next search method is tried.
If a person object is found, that object is used for the user identity. In the Administration Console, the user identity is displayed as LDAP-ID (LDAP). On the command line, the user identity is displayed as .../_service/sco/tta/ldapcache/LDAP-ID.
Next SGD searches for the user profile. When searching for the user profile, you can specify Use Default LDAP Profile or Use Closest Matching LDAP Profile. Use Default LDAP Profile is the default.
If Use Default LDAP Profile is selected, the profile object System Objects/LDAP Profile is used for the user profile.
If Use Closest Matching LDAP Profile is selected, SGD establishes the user profile by searching the local repository, allowing for differences between the LDAP and SGD naming systems. SGD searches for the following until a match is found:
A user profile with the same name as the LDAP person object.
For example, if the LDAP person object is cn=Emma Rald,cn=Sales,dc=Indigo Insurance,dc=com, SGD searches the local repository for dc=com/dc=Indigo Insurance/cn=Sales/cn=Emma Rald.
A user profile in the same organizational unit as the LDAP person object but with the name cn=LDAP Profile.
For example, dc=com/dc=Indigo Insurance/cn=Sales/cn=LDAP Profile.
A user profile in any parent organizational unit with the name cn=LDAP Profile.
If there is no match, the profile object System Objects/LDAP Profile is used for the user profile.
The Use Default Third‐Party Identity method does not perform a search.
The user identity is always the third-party user name. In the Administration Console, the user identity is displayed as third-party-username (3rd party). On the command line, the user identity is displayed as .../_service/sco/tta/thirdparty/third-party-username.
The profile object System Objects/Third Party Profile is always used for the user profile.
In the SGD Administration Console, display the Secure Global Desktop Authentication Configuration Wizard.
Go to the Global Settings -> Secure Global Desktop Authentication tab and click the Change Secure Global Desktop Authentication button.
On the Third-Party/System Authentication step, select the Third-Party Authentication check box.
On the Third-Party Authentication - User Identity and Profile step, select the check box for one or more search methods for finding the user identity.
For details on how the search methods work, see How Third-Party Authentication Works.
If the Search LDAP Repository check box is selected, select an option for finding the LDAP user profile.
On the LDAP Repository Details step, configure the LDAP directory details.
The LDAP Repository Details step only displays if an LDAP search method is selected in Step 3.
For Repository Type, select the LDAP option.
Select this option even if you are using a Microsoft Active Directory server.
In the URLs field, type the URL of one or more LDAP directory servers.
For example, ldap://melbourne.indigo-insurance.com.
After typing each URL, press the Return key.
If there is than one URL, SGD uses the URLs in the order they are listed. If the first LDAP directory server in the list is unavailable, the next one is tried.
To use secure connections to LDAP directory servers, use an ldaps:// URL.
To be able to use secure connections, SGD must be able to validate the certificate presented by an LDAP directory server. You might have to import the CA certificates for the LDAP directory servers you are using with SGD into the CA certificate truststore. See The CA Certificate Truststore for details of how to check for supported CAs and how to import CA certificates.
The standard port used for connections to LDAP directory servers is port 389. If the LDAP directory server uses a different port, specify the port number as part of the URL, for example ldap://melbourne.indigo-insurance.com:5678.
Adding a search root to the end of the URL, for example ldap://melbourne.indigo-insurance.com/dc=indigo-insurance,dc=com restricts the part of the LDAP directory used to search for the user identity.
Type the details of an LDAP user in the User Name and Password fields.
The user name must be the distinguished name of the user, for example cn=sgd-user,cn=Users,dc=indigo-insurance,dc=com.
Some LDAP directory servers support anonymous logins, so you do not need to supply a user name or password. Others, including Microsoft Active Directory, require the user name and password of a user that has sufficient privileges to search the LDAP directory.
As you can only enter one user name and password, this user must be able to search all LDAP directory servers listed in the URL field.
You might want to create a special LDAP user reserved for the SGD LDAP authentication.
On the Review Selections step, check the authentication configuration and click Finish.
Web server authentication, or Hypertext Transfer Protocol (HTTP) authentication, is the most common use of third-party authentication. With web server authentication, the web server performs the authentication, and SGD determines the user identity and user profile.
The advantage of web server authentication is that you can use any web server authentication plug-in as long as it sets the REMOTE_USER environment variable. If the authentication plug-in you use sets a different variable, you can configure SGD to support it, see Using Authentication Plug-ins With Web Server Authentication.
You can use web server authentication and system authentication together. It is best to enable at least one system authentication mechanism as a fallback. If SGD cannot find a user profile for a user, the standard SGD login page displays so that the user can authenticate using a system authentication mechanism.
Web server authentication works as follows:
A web server administrator protects a section of a web site. For SGD, this is usually the http://server.example.com/sgd URL, where server.example.com is the name of an SGD server.
When a web browser first tries to access a URL within the protected section, the web server responds by requesting authentication.
The web browser displays an authentication dialog to the user. SGD users do not see the SGD login screen.
The user types a user name and password, which the browser sends to the web server.
The web server authenticates the user’s credentials and grants access to the requested URL. SGD users go directly to their webtop.
The web browser caches the user’s credentials because the credentials must be sent with every request to the protected URL. The browser sends the credentials automatically. The credentials are cached as follows:
Temporarily. The credentials are cached until the user closes the browser.
Permanently. The user selects the check box on the browser’s authentication dialog.
Once the web server has authenticated the user, its sets the REMOTE_USER environment variable. This variable contains the user name of the authenticated user. SGD takes the value of the REMOTE_USER variable and uses it to search for the user identity and user profile. SGD supports four search methods for establishing the user identity and user profile, see How Third-Party Authentication Works.
The following are the main security considerations of using web server authentication with SGD:
Web browser cache. With web server authentication, the web browser caches the user’s credentials and, in effect, their authentication to SGD. To minimize the risk of cached credentials being used by someone else, ensure that users do the following:
Deselect the save password check box in the web browser authentication dialog. This ensures that user credentials are not saved permanently by the web browser.
Close the web browser after logging out. This clears the user’s credentials from the temporary cache. Logging out of SGD does not clear the credentials.
Secure web server. Use a secure (HTTPS) web server to prevent user credentials from being sent in plain text.
Trusted user. SGD is able to trust the web server’s authentication because the SGD webtop and the SGD server have a shared secret which is the user name and password of a trusted user. The credentials of this trusted user are created by default when you install SGD. You might want to change these credentials, see Trusted Users and Third-Party Authentication for details of how to do this.
To enable web server authentication, you must configure both the web server and SGD.
You configure the web server for web server authentication by protecting the /sgd URL on each SGD host. How you protect the /sgd URL depends on your web server, see your web server documentation for details. For the SGD Web Server, you can protect the /sgd URL in either the Apache or the Tomcat components. See How to Enable Web Server Authentication for the SGD Web Server for an example of how to do this.
To configure SGD to support web server authentication, you must enable third-party authentication, see How to Enable Third-Party Authentication.
|
For the SGD Web Server, you can protect the /sgd URL in either the Apache or the Tomcat components. This procedure protects the URL in Apache.
Repeat the following procedure on each SGD server in the array.
Create a web server password file.
Use the /opt/tarantella/webserver/apache/2.2.8_openssl‑0.9.8g_jk1.2.25/bin/htpasswd program to create a web server password file and add entries.
Edit the Apache configuration file and protect the /sgd URL.
The Apache configuration file is /opt/tarantella/webserver/apache/2.2.8_openssl‑0.9.8g_jk1.2.25/conf/httpd.conf.
Insert the following directives at about line 358:
SetEnvIf Request_URI "\.(class|cab|jar|gif|der)$" sgd_noauth_ok <LocationMatch /sgd> Order Allow,Deny Allow from env=sgd_noauth_ok AuthUserFile file-path AuthName auth-domain Authtype Basic Require valid-user Satisfy any </LocationMatch>
where file-path is the full path to the web server password file and auth-domain is the name of authorization realm that appears in the web browser’s authentication dialog.
The SetEnvIf directive protects the /sgd URL without affecting the operation of the Welcome Page of the SGD Web Server.
Edit the Tomcat configuration file.
The Tomcat component of the SGD Web Server must be configured to trust the web server’s authentication.
The Tomcat configuration file is /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/conf/server.xml.
Amend the configuration of the Coyote/JK2 AJP 1.3 Connector.
Add a tomcatAuthentication="false" attribute to the <Connector> element as follows:
<!-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 --> <Connector port="8009" minProcessors="5" maxProcessors="75" enableLookups="true" redirectPort="8443" acceptCount="10" debug="0" connectionTimeout="0" useURIValidationHack="false" tomcatAuthentication="false" protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>
You must restart the SGD Web Server for the configuration changes to take effect.
SGD web server authentication relies on the web server setting the REMOTE_USER environment variable to identify the user. If you use an authentication plug-in for web server authentication, it is likely that the plug-in uses a different environment variable to identify the user.
Tip - It is best to install to your authentication plug-in and verify that it is working, before configuring SGD. |
In addition to the REMOTE_USER environment variable, SGD includes support for the SSL_CLIENT_S_DN_CN variable. This environment variable is set when using client certificates with web server authentication. See Using Client Certificates With Web Server Authentication for details of how to enable support for this variable.
If your plug-in uses a different environment variable, you must configure the webtop web application to support your environment variable. See How to Enable Support for Other Environment Variables for Web Server Authentication.
|
Before you begin, consult the documentation for the web server authentication plug-in and make a note of the environment variable it sets to identify users.
Repeat the following procedure on each SGD server in the array.
Configure the Apache component of the SGD Web Server to forward your variable to the Tomcat component.
Edit the Apache configuration file.
The file is /opt/tarantella/webserver/apache/2.2.8_openssl‑0.9.8g_jk1.2.25/conf/httpd.conf.
Add a JkEnvVar directive to forward your environment variable.
Search for the existing JKEnvVar directives and add a directive for your own variable, as follows:
#JkEnvVar SSL_CLIENT_S_DN_CN " " #JkEnvVar HTTP_SAFEWORD_USER " " JKEnvVar Your-Variable " "
Make the variable available in the /SGD location.
Remove the comment marks (#) from the Location directive as follows:
<Location "/sgd"> SSLOptions +StdEnvVars +ExportCertData </Location>
Configure the webtop web application to use your environment variable.
Change to the SGD web application resources directory.
# cd /opt/tarantella/webserver/tomcat/5.0.28_axis1.2 # cd webapps/sgd/resources/jsp |
Edit the webtopsession.jsp file and add support for your variable.
Search for either the HTTP_SAFEWORD_USER or the SSL_CLIENT_S_DN_CN variable and use the code for these variables as examples of how to implement your own variable.
You can strengthen the security of web server authentication by authenticating users if they have valid Public Key Infrastructure (PKI) certificate installed on the client device.
To use PKI certificates, you must configure the web server so that to access the /sgd URL you need a client certificate. The SGD Web Server includes the Apache mod_ssl module which you can use to set up PKI client certificates.
SGD web server authentication relies on the web server setting the REMOTE_USER variable to identify the user. However, when users are authenticated using client certificates generally another environment variable is used to identify the user. For Apache web servers, including the SGD Web Server, the SSL_CLIENT_S_DN_CN variable is used. See How to Enable Support for the SSL_CLIENT_S_DN_CN Variable for details of how to add support for this variable. If your web server sets a different variable, see How to Enable Support for Other Environment Variables for Web Server Authentication.
Configure the Apache component of the SGD Web Server to forward the SSL_CLIENT_S_DN_CN variable to the Tomcat component.
Edit the Apache configuration file.
The file is /opt/tarantella/webserver/apache/2.2.8_openssl‑0.9.8g_jk1.2.25/conf/httpd.conf.
Enable the JkEnvVar directive to forward SSL_CLIENT_S_DN_CN variable.
Search for the existing JKEnvVar directives and remove the comment mark (#) for the SSL_CLIENT_S_DN_CN variable as follows:
JkEnvVar SSL_CLIENT_S_DN_CN " " #JkEnvVar HTTP_SAFEWORD_USER " "
Make the SSL_CLIENT_S_DN_CN variable available in the /SGD location.
Remove the comment marks (#) from the Location directive as follows:
<Location "/sgd"> SSLOptions +StdEnvVars +ExportCertData </Location>
By default, third-party authentication does not allow SGD Administrators to log in to SGD. This is a security measure. To change this behavior, use the following command:
$ tarantella config edit \ --tarantella-config-login-thirdparty-allowadmins 1 |
Third-party authentication gives users access to SGD without having to authenticate to an SGD server. SGD is able to trust the third-party authentication mechanism because client applications, such as the webtop, and the SGD server have a shared secret which is the user name and password of a trusted user.
In a standard installation, there is just one trusted user. However, you might want to create additional trusted users in the following circumstances:
You relocate the webtop to a different JavaServer Pages (JSP) container on a different host. See Relocating the Webtop for details.
You develop your own client applications, using the SGD com.tarantella.tta.webservices.client.views package, either on the same host as SGD or on a different host.
You have concerns about the security of the default trusted user.
You create and maintain the “database” of trusted users on each SGD server in the array. The database is not shared between SGD servers. See How to Create a New Trusted User for details of how to add a trusted user. Note the following:
The tarantella webserver add_trusted_user command is the only supported way to store trusted users on the SGD server.
To change the password of an existing trusted user, you must first delete the user with the tarantella webserver delete_trusted_user command and then create the user again.
Every time you make a change to a trusted user, you must restart the SGD Web Server.
Usually client applications only use the credentials of a single trusted user to access SGD services.
If you are using SGD web services to develop your own applications, the ITarantellaExternalAuth web service is used for third-party authentication. This web service is protected with Basic web server authentication so that you can only access it using the credentials of a trusted user. This is configured as follows:
The http://SGD-server/axis/services/document/externalauth URL is protected in the configuration file for the Axis web application /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/axis/WEB-INF/web.xml
The Tomcat component of the SGD Web Server is configured to support Basic web server authentication using Tomcat’s MemoryRealm and Secure Hash Algorithm (SHA) digested passwords. This is in the Tomcat configuration file /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/conf/server.xml.
The list of trusted users is stored in the Tomcat users configuration file /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/conf/tomcat-users.xml
If you have developed your own client applications using the com.tarantella.tta.webservices.client.views package, you can store the trusted user credentials for the application in the same way as the webtop, see How to Create a New Trusted User. Otherwise, you need to develop your own methods for storing the credentials.
Add the new trusted user to the database of trusted users on the SGD server.
Add the new trusted user to the web services resources file for the webtop application.
If you have relocated the webtop to a different host, perform this step on the remote host.
Encode the user name and password of the trusted user.
# /opt/tarantella/bin/jre/bin/java -classpath \ /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/shared/lib/sgd-webservices.jar \ com.tarantella.tta.webservices.client.views.SgdPasswd \ --encode username:password |
Change to the shared resources directory.
# cd /opt/tarantella/webserver/tomcat/5.0.28_axis1.2 # cd shared/classes/com/tarantella/tta/webservices/client/views |
Replace the text after sgdaccess= with the encoded user name and password.
UNIX system authentication enables users to log in to SGD if they have UNIX or Linux system accounts on the SGD host.
UNIX system authentication is enabled by default.
This section includes the following topics:
UNIX system authentication supports the following search methods for authenticating users against a UNIX or Linux system user database and determining the user identity and profile:
These search methods are described in the following sections.
At the SGD login screen, the user types a user name and password. The user name can be any of the following:
SGD searches the local repository for a user profile with a Name attribute that matches what the user typed. If there is no match, the search is repeated on the Login Name attribute, and finally on the Email Address attribute. If no user profile is found, the next authentication mechanism is tried.
If a user profile is found, the Login Name attribute of that object is treated as a UNIX or Linux system user name. This user name, and the password typed by the user, are checked against the UNIX or Linux system user database. If the authentication fails, the next authentication mechanism is tried.
If the authentication succeeds and the Login attribute for the user profile is not enabled, the user is not logged in and no further authentication mechanisms are tried. If the authentication succeeds and the Login attribute for the user profile is enabled, the user is logged in.
SGD checks the user name and password typed by the user at the login screen against the UNIX or Linux system user database.
If the authentication fails, the next authentication mechanism is tried.
If the authentication succeeds, SGD searches for the user profile. See User Identity and User Profile for details. If the Login attribute of the user profile object is not enabled, the user cannot log in and no further authentication mechanisms are tried. If the Login attribute of the user profile is enabled, the user is logged in.
This search method is enabled by default.
The user identity is the UNIX or Linux system user name. In the Administration Console, the user identity is displayed as UNIX-username (UNIX). On the command line, the user identity is displayed as .../_user/UNIX-username.
SGD searches the local repository for a user profile cn=gid, where gid is the UNIX group ID of the authenticated user. If found, this is used as the user profile. If the user belongs to more than one group, the user’s primary or effective group is used. If no user profile is found in the local repository, the profile object System Objects/UNIX User Profile is used for the user profile.
SGD checks the user name and password typed by the user at the login screen against the UNIX or Linux system user database.
If the authentication fails, the next authentication mechanism is tried.
If the authentication succeeds, the user is logged in.
This search method is disabled by default.
The user identity is the UNIX or Linux system user name. In the SGD Administration Console, the user identity is displayed as UNIX-username (UNIX). On the command line, the user identity is displayed as .../_user/UNIX-username.
The profile object System Objects/UNIX User Profile is used for the user profile. All UNIX users receive the same webtop content.
SGD supports Pluggable Authentication Modules (PAM). UNIX system authentication uses PAM for user authentication, account operations, and password operations.
If you want SGD to prompt UNIX users for a new password when they log in with an expired password, the PAM interface must be installed on your SGD servers. If the PAM interface is not installed, SGD cannot support aged passwords. An error message is logged in /opt/tarantella/var/log/pemanagerpid_error.log on server startup if this is the case.
When you install SGD on Linux platforms, the SGD Setup program automatically creates PAM configuration entries for SGD by copying the current configuration for the passwd program and creating the /etc/pam.d/tarantella file. On Solaris OS platforms, you must add a new entry for tarantella in the /etc/pam.conf file.
In the SGD Administration Console, display the Secure Global Desktop Authentication Configuration Wizard.
Go to the Global Settings -> Secure Global Desktop Authentication tab and click the Change Secure Global Desktop Authentication button.
On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.
On the System Authentication - Repositories step, select the Unix check box.
On the Unix Authentication - User Profile step, select the check box for one or more search methods for finding the user profile.
See How UNIX System Authentication Works for details on the search methods.
On the Review Selections step, check the authentication configuration and click Finish.
Windows domain authentication enables users to log in to SGD if they belong to a specified Windows 2000 or Windows 2003 Server domain.
Windows domain authentication is disabled by default.
This section includes the following topics:
At the SGD login screen, the user types a user name and password. The user name can be any of the following:
SGD searches the local repository for a user profile with a Name attribute that matches the user name typed by the user. If there is no match, the search is repeated on the Login Name attribute, and finally on the Email Address attribute.
If a user profile is found, the Login Name attribute of the user profile is treated as the Windows domain user name. If no user profile is found, the name the user typed is used as the Windows domain user name. SGD then checks the Windows domain user name and the password typed by the user against the domain controller.
If the authentication fails, the next authentication mechanism is tried.
If the authentication succeeds and the Login attribute for the user profile is not enabled, the user is not logged in and no further authentication mechanisms are tried.
If the authentication succeeds and either the Login attribute for the user profile is enabled or no matching user profile is found, the user is logged in.
If a user profile was found in the local repository, that object is used for the user identity and user profile. In the Administration Console, the user identity is displayed as user-profile (Local). On the command line, the user identity is displayed as .../_ens/user-profile.
If no user profile was found in the local repository, the user identity is the Windows domain user name. The profile object System Objects/NT User Profile is used for the user profile. In the Administration Console, the user identity is displayed as NT-username (NT). On the command line, the user identity is displayed as .../_service/sco/tta/ntauth/NT-username.
In the SGD Administration Console, display the Secure Global Desktop Authentication Configuration Wizard.
Go to the Global Settings -> Secure Global Desktop Authentication tab and click the Change Secure Global Desktop Authentication button.
On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.
On the System Authentication - Repositories step, select the Windows Domain Controller check box.
On the Windows Domain Authentication - Domain Controller step, type the name of a domain controller in the Windows Domain field.
On the Review Selections step, check the authentication configuration and click Finish.
Windows domain authentication supports 8-bit case-sensitive passwords. The user name can contain any characters.
If you need to authenticate users from more than one domain, you must have one domain that is trusted by all the other domains. You must use the trusted domain as the Windows domain controller when you configure Windows domain authentication.
When a user from another domain logs in to SGD, they must use the format domain\username for their user name. If they do not use this format, SGD tries to authenticate the user using the authentication domain and fails.
Note - The Windows NT domain (--ntdomain) attribute for user profiles plays no part in the SGD login. |
If an SGD server is on a different subnet to the domain controller, you must hard code the domain controller information, see How to Specify a Domain Controller on a Different Subnet.
Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.
Configure the domain controller
# tarantella config edit \ --com.sco.tta.server.login.ntauth.NTAuthService.properties-authConfig \ authnbt=NTNAME # tarantella config edit \ --com.sco.tta.server.login.ntauth.NTAuthService.properties-authConfig-append \ authserver=my.domain.name |
where NTNAME is the NetBIOS name of the domain controller and my.domain.name is the DNS name or Internet Protocol (IP) address of the domain controller.
Use the information in this section to troubleshoot problems when users log in to SGD. This section includes the following topics:
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.
For information about setting log filters, see Using Log Filters to Troubleshoot Problems With an SGD Server.
This section describes how to tune LDAP performance for the following SGD authentication mechanisms:
This section includes the following topics:
Whenever SGD searches an LDAP directory to establish a user’s identity, it checks the following attributes on the LDAP person object:
As SGD checks all of these attributes, this can lead to slow login times if you have a large directory. You can improve login times by reducing the number of search attributes, for example to just cn and mail.
If your LDAP directory uses other attributes for identifying users, users might not be able to log in to SGD. The solution is to configure SGD to search for additional attributes.
See How to Configure LDAP User Name Search Attributes for details of how to change the search attributes.
Repeat the following procedure on each SGD server in the array.
Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.
Configure the LDAP user name search attributes.
![]() | Caution - Any mistakes in this step can result in all users being unable to log in. |
Use a comma‐separated list of attributes. The default list is:
cn, uid, mail, userPrincipalName, sAMAccountName
For Active Directory and LDAP authentication, use the following command:
# tarantella config edit \ --searchldapla.properties-searchAttributes attr ... |
For third-party and web server authentication, use the following command:
# tarantella config edit \ --thirdpartyldaploginauthority.properties-searchAttributes attr ... |
You can configure an LDAP timeout in the event that the LDAP searches of an LDAP directory or Active Directory server fail. The LDAP timeout controls how long SGD waits for the directory server to respond to LDAP operations, such as requests for data. The default is 20 seconds.
SGD makes two attempts to contact the LDAP directory server. If there is no response, SGD tries another LDAP directory server in the list. For Active Directory authentication, the list of Active Directory servers for a domain is obtained from the global catalog. For LDAP and third-party authentication, the list of LDAP directory servers comes from the URLs configured for the authentication mechanism.
If all LDAP directory servers time out, SGD might not be able to authenticate users or use directory services integration.
To change this timeout, use the following command:
$ tarantella config edit --tarantella-config-ldap-timeout secs |
The LDAP discovery timeout is only used with Active Directory authentication.
The LDAP discovery timeout controls how long SGD waits for an Active Directory server to respond to the initial contact request. The default is 20 seconds.
SGD makes two attempts to contact the Active Directory server. If there is no response, SGD tries another Active Directory server. The list of Active Directory servers for a domain is obtained from the global catalog. If all Active Directory servers time out, SGD might not be able to use directory services integration.
To change this timeout, use the following command:
$ tarantella config edit \ --tarantella-config-ldap-discovery-timeout secs |
The LDAP discovery timeout must be longer than the KDC timeout. See KDC Timeout. For example, if the KDC timeout is 10 seconds and the KDC retries is 3, make the LDAP discovery timeout 35 seconds (3 x 10 seconds + extra 5 seconds). Keep the KDC timeout and the LDAP discovery timeout in step. If you increase the KDC timeout, increase the LDAP discovery timeout.
SGD caches the data it collects from an LDAP directory. If you find that SGD is not detecting changes, you can flush the cached data manually with the following command:
$ tarantella cache \ --flush ldapgroups | ldapconn | ldapconn-lookups | all |
Option | Description |
---|---|
ldapgroups | Flushes the cache of all LDAP group data. Used for Directory Services Integration. |
ldapconn | Flushes the cache of all the IP address, domain, and attribute data. |
ldapconn-lookups | Flushes the cache of all LDAP search data. Used for Directory Services Integration. |
all | Flushes all LDAP data. |
Note - This command only flushes the cache on the SGD server on which the command is run. It has no effect on the Administration Console. |
If LDAP users find they cannot log into SGD, use the following checklist to resolve the problem.
Is LDAP authentication enabled?
You cannot use an LDAP directory server with SGD unless the LDAP authentication is enabled.
Are the URLs of the LDAP directory servers correct?
To be able to use LDAP authentication, each SGD server must be able to contact the LDAP directory servers at the specified URLs.
Does the URL use the fully qualified name of the LDAP directory server?
If the LDAP directory server listens on a non-standard port, is the port number the LDAP directory server listens on included in the URL?
Can all SGD servers in the array contact the LDAP directory server at this URL. For example, can you connect from the SGD server to the LDAP directory server using the telnet program?
If you have used a search root to restrict the start point of the search of the LDAP directory, check that the search root is correct.
If the log files indicate that the connection to the LDAP directory server is timing out, try increasing the LDAP timeout, see LDAP Timeout.
Is the LDAP directory server user name and password correct?
Some LDAP directory servers support anonymous logins, so you do not need to supply a user name or password. Others, including Microsoft Active Directory, require the user name and password of a user that has sufficient privileges to search the LDAP directory.
If you are you using secure connections to the LDAP directory server, has this been configured correctly?
Check the following:
Does the CA certificate truststore on each SGD server contain the CA certificate, or certificate chain, used to sign the certificate for each LDAP directory server?
See The CA Certificate Truststore for details of how to check for supported CAs and how to import CA certificates.
Have recent LDAP configuration changes taken effect?
After making changes to your LDAP database, it is advisable to wait for a period of time for the changes to take effect.
SGD caches the data it collects from an LDAP directory. If you find that SGD is not detecting changes, you can manually flush the cached data with the tarantella cache command, see LDAP Cache.
Is SGD providing the right information for locating the user?
When SGD searches an LDAP directory for a user it uses the following attributes:
If these attributes are not sufficient for identifying users, you can add extra attributes, see LDAP User Name Search Attributes.
Common problems that users experience when they log in to SGD using web server authentication include the following:
If a user fails to authenticate to the web server, they might 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.
If web server 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.
Is the right SGD URL protected?
For the webtop, you must set up your web server to protect the /sgd URL.
Is Tomcat configured to trust the web server authentication?
The Tomcat component of the SGD Web Server has to be configured to trust the Apache web server authentication.
On each array member, edit the /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/conf/server.xml file. Add the tomcatAuthentication="false" attribute to the <Connector> element for the Coyote/JK2 AJP 1.3 Connector.
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 might 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 How Third-Party Authentication Works for more details.
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 SGD Administrators and Third-Party Authentication for details.
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 Trusted Users and Third-Party Authentication for details.
With web server 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.
SGD Administrators can enable a login failure handler so that users are denied access to SGD after three failed login attempts. See How to Enable 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. See for details
The number of login attempts is configurable, see How to Change 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 typed an incorrect password.
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.
If all users, including the UNIX system root user, cannot log in to any SGD server, this might be caused by either of the following:
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.
Note - Anonymous users are always treated as using a shared account, see Anonymous User Authentication. |
Guest users are never prompted for application server passwords. This means guest users cannot add or change password cache entries. Use the tarantella passcache command to manage application server passwords for guest users.
If users with Solaris OS client devices find that they cannot log in to an SGD server when SGD security services are enabled, check that the /dev/random device is present on the client device.
SGD security services require the /dev/random device. If it is missing, install the Solaris OS patch that contains this device.
The Ambiguous User Name dialog 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 which asks them to provide either an email address or a user name. The dialog 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 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.
Use the information in this section to troubleshoot problems when users log in to start an application. This section includes the following topics:
Users Can Start Applications With Different User Names and Passwords
Using Windows Terminal Services, Users Are Prompted for User Names and Passwords Too Often
By default, users can force SGD to display the Application Authentication dialog by holding down the Shift key when they click an application’s link on the webtop. This enables users to start applications with different username and passwords.
Note - You cannot use Shift-click with the SGD Client when it is in Integrated mode. |
You can disable the Shift-click behavior. In the Administration Console, go to the Global Settings -> Application Authentication tab and deselect the On Shift-Click check box. Alternatively, use the following command:
$ tarantella config edit --launch-showauthdialog system |
Disabling the Shift-click behavior means that the Application Authentication dialog only displays when there is a problem with the password or there is no password.
If you are using Windows Terminal Services, users might be prompted for a user name and password by SGD or by the Terminal Server.
If SGD always prompts the user for a user name and password, the problem is usually caused by a missing domain name. If the user has no entries in the password cache that have a domain name, the Application Authentication dialog is displayed.
To fix this problem, the domain name must be provided when saving details in the password cache. You must do this even if the application server is not part of a domain.
The easiest way to configure the domain name is with the Domain Name attribute on the application server object or the application object. Users can also provide their own domain names in the Application Authentication dialog. See Windows Domains and the Password Cache.
SGD sends user name and password information to Windows Terminal Services to authenticate the user. If the authentication fails, Windows prompts the user again. No information is returned to SGD indicating whether authentication succeeds or fails, and the details remain in the SGD password cache whether correct or incorrect.
The user might have saved the wrong user name, password or domain name in the password cache.
To fix, the user must press Shift when clicking the link to start, the application. This displays the Application Authentication dialog, and the user can correct their user name, password, and domain name. Alternatively, delete the user’s entry in the password cache so that SGD prompts the user the next time they start the application.
The Terminal Server might also be configured to always prompt for a password when a user logs in. Microsoft Windows 2000 Server does this by default, but Microsoft Windows Server 2003 does not. See Authentication Settings for details on how to change this behavior.
Copyright © 2008, Sun Microsystems, Inc. All rights reserved.