C H A P T E R  2

User Authentication

Sun Secure Global Desktop Software (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:

The following troubleshooting topics are also included:


Secure Global Desktop Authentication

SGD is designed to integrate with your existing authentication infrastructure and supports the following two mechanisms for authenticating users:

The following are main results of a successful authentication:

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:

User Identity

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

User Profile

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.

System Authentication Mechanisms

The following table lists the available system authentication mechanisms and describes the basis for authentication.


TABLE 2-1   System Authentication Mechanisms
Mechanism Description
Anonymous user Enables users to log in to SGD without using a user name and password.

All anonymous users have the same webtop content.

See Anonymous User Authentication.

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.

See UNIX System Authentication.

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.

See Windows Domain Authentication

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.

See LDAP Authentication

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.

See Active Directory Authentication.

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 system group have the same webtop content.

See UNIX System Authentication.

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.

All UNIX system users have the same webtop content.

See UNIX System Authentication.

SecurID Enables users with RSA SecurID tokens to log in to SGD.

Users might have their own webtop content, depending on configuration.

See SecurID Authentication


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.

Password Expiry

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 Supported LDAP Directory Servers for details.
SecurID Yes. If the user’s personal identification number (PIN) has expired, a new PIN dialog is displayed instead of the Aged Password dialog.
Third-party

(including web server authentication)

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.

Security and Passwords

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:


Application Authentication

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:

FIGURE 2-1   Screen Capture of the SGD Application Authentication Dialog

Screen capture showing the SGD Application
Authentication dialog


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:

Login Scripts

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:

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.

Configuring Application Authentication

In the Administration Console, the attributes on the Global Settings -> Application Authentication tab control application authentication. These attributes allow you to configure the following:

The Application Server Password Cache

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.



Note - SGD cannot store the user name and password used to log in to SGD if the user is authenticated with third‐party authentication.



For Windows applications that use the Microsoft RDP protocol, it is the Terminal Server handles the authentication process. 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.

Managing the Application Server Password Cache

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 user name – The user name for the application server

  • A password – The password for the application server

  • 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.



Security and 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.

Windows Domains and the Password Cache

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:

  1. 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.

  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.

  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.



Using RSA SecurID for Application Authentication

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.

Supporting Users in Different Locales

To support users in different locales when starting applications, you might have to do the following:

The following sections describe how you do this.

Adding Support for System Prompts in Different Languages

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.

Enabling an Input Method

An input is a program or operating system component that enables 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

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:

How Active Directory Authentication Works

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.

User Identity and User Profile

The user identity is the DN of the LDAP person object. In the Administration Console, the user identity is displayed as LDAP-dn (LDAP). On the command line, the user identity is displayed as .../_service/sco/tta/ldapcache/LDAP-dn.

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.

    For example, dc=com/dc=Indigo Insurance/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

Setting up Active Directory authentication involves the following configuration steps:

  1. 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.

  2. Configure SGD for Kerberos authentication.

    Configure SGD with the details of the KDCs to use for Kerberos authentication.

    See Configuring SGD for Kerberos Authentication.

  3. 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.

Configuring SGD for Kerberos Authentication

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.

Synchronizing System Clocks

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.

Kerberos Configuration File

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 system default Kerberos configuration file.

    This is usually one the following files:

    • /etc/krb5/krb5.conf on Solaris OS platforms.

    • /etc/krb5.conf on Linux platforms.

  • 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.

Kerberos Realms and KDCs

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. If a default realm is not specified, users might not be able to log in to SGD, or change an expired password.

  • [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 be 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

Password Expiry

SGD can be configured to prompt a user for a new password if their Active Directory password has expired. If a default realm is not specified in the krb.conf file, users are unable to change an expired password.

To configure password expiry, 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 be 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
 }

Network Protocols

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

KDC Timeout

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.

procedure icon  How to Enable Active Directory Authentication

  1. 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.

  2. On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.

  3. On the System Authentication - Repositories step, select the LDAP/Active Directory check box.

  4. On the LDAP Repository Details step, configure the Active Directory domain details.

    1. For Repository Type, select the Active Directory option.

    2. 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.

    3. 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.



        Note - The Kerberos option is selected by default.



      • 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.

    4. 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.

    5. 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.

  5. On the Review Selections step, check the authentication configuration and click Finish.

procedure icon  How to Configure SSL Connections to Active Directory

  1. Enable LDAP signing requirements for the domain.

    You must enable LDAP signing on your domain controllers so that they accept SSL connections.

    Consult your system documentation for details of how to enable LDAP signing.

    The following is an example of how to enable LDAP signing.

    1. In Group Policy Object Editor, select Domain Security Policy -> Local Policies -> Security options.

    2. Edit the Domain controller: LDAP server signing requirements policy, select Require signing.

    3. Edit the Network security: LDAP client signing requirements policy, select Require signing.

  2. 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 SSL 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.

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

    1. 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.

    2. 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.

      1. Using Microsoft Internet Explorer, go to http://WindowsServer/certsrv and log in.

      2. On the Microsoft Certificate Services page, click Request a certificate.

      3. On the Request a Certificate page, click advanced certificate request.

      4. 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.

      5. 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.

      6. Select an appropriate template from the Certificate Templates list.

      7. Click Submit.

      8. On the Certificate Issued page, ensure Base 64 encoded is selected and click Download certificate.

      9. Save the certificate file.

      10. Copy the certificate file to the SGD host.

    3. Install the client certificate for an SGD server.

  4. 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 3269 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 3268 for the secure connection to the global catalog server

  5. Restart each SGD server in the array.


Anonymous User Authentication

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:

How Anonymous User Authentication Works

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.

User Identity and User Profile

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.

Application Sessions and Password Cache Entries

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.

procedure icon  How to Enable Anonymous User Authentication

  1. 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.

  2. On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.

  3. On the System Authentication - Repositories step, select the Anonymous check box.

  4. On the Review Selections step, check the authentication configuration and click Finish.


LDAP Authentication

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:

How LDAP Authentication Works

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.

User Identity and User Profile

The user identity is the DN of the LDAP person object. In the Administration Console, the user identity is displayed as LDAP-dn (LDAP). On the command line, the user identity is displayed as .../_service/sco/tta/ldapcache/LDAP-dn.

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.

    For example, dc=com/dc=Indigo Insurance/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.

Supported LDAP Directory Servers

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:

Other directory servers might work, but are not supported.

Sun Java System Directory Server

For Sun Java System Directory Servers, additional configuration might be needed for SGD to handle password expiry, as follows:

  • 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.

Microsoft Active Directory

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.

Novell eDirectory

By default, Novell eDirectory requires that all simple LDAP binds that contain a password must be encrypted. To use simple binds with a password for SGD, you must do either of the following:

  • Configure SGD to use secure connections to eDirectory by using ldaps:// URLs

  • Configure the LDAP group object in eDirectory and disable TLS for simple binds

procedure icon  How to Enable LDAP Authentication

Before you enable LDAP authentication, make sure all the SGD servers in the array can contact each LDAP directory server used for authentication.

See Supported LDAP Directory Servers for the requirements for using particular LDAP Directory servers with SGD.

  1. 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.

  2. On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.

  3. On the System Authentication - Repositories step, select the LDAP/Active Directory check box.

  4. On the LDAP Repository Details step, configure the LDAP directory details.

    1. For Repository Type, select the LDAP option.

      Select this option even if you are using a Microsoft Active Directory server.

    2. 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 SSL 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.

    3. Type the details of an LDAP user in the User Name and Password fields.

      The user name must be the DN of the user, for example cn=sgd-user,cn=Users,dc=indigo-insurance,dc=com. This is the LDAP bind DN.

      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.

  5. On the Review Selections step, check the authentication configuration and click Finish.

Restricting the LDAP Users That Can Log In to SGD

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 match the filter can log in to SGD. The LDAP login filter must test for something on the LDAP person object, such as an attribute value or membership of a group. See How to Configure an LDAP Login Filter for details of how to apply the filter to SGD.

procedure icon  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.

  1. Log in as superuser (root) on the host.

  2. Stop the SGD server.

  3. Configure the LDAP login filter.

    Use the following command:


    # tarantella config edit \
    --searchldapla.properties-searchFilter (&({0}={1})(filter))
    

    For example, to test that the LDAP person object is a member of the LDAP group cn=sgdusers, run the following command:


    # tarantella config edit --searchldapla.properties-searchFilter \
    (&({0}={1})(memberOf=cn=sgdusers,dc=indigo-insurance,dc=com))
    

    For example, to test for an attribute called allowsgdlogin on the LDAP person object, run the following command:


    # tarantella config edit \
    --searchldapla.properties-searchFilter (&({0}={1})(allowsgdlogin=true))
    

    If SGD tests for an attribute value, that attribute must be set for all users in the LDAP directory.

  4. Start the SGD server.


SecurID Authentication

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:

Supported Versions of SecurID

SGD works with versions 4, 5, and 6 of the RSA Authentication Manager.

SGD supports system-generated PINs and user-created PINs.

How SecurID Authentication Works

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.

User Identity and User Profile

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

Setting up SecurID authentication involves the following configuration steps:

  1. 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.

  2. 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.

    See Configuring SGD servers as Agent Hosts.

  3. Enable SecurID authentication in SGD.

    Configure SecurID authentication so that SecurID users can log in to SGD.

    See How to Enable SecurID Authentication.

Configuring SGD servers as Agent Hosts

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.

procedure icon  How to Configure an SGD Server as an Agent Host

Before you begin, ensure you have access to the RSA Authentication Manager configuration file, sdconf.rec.

  1. Log in as superuser (root) on the SGD host.

  2. 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.

    The default ports that must be open are the following:

    • UDP port 5500 from the SGD server to the Authentication Manager.

    • UDP ports 1024 to 65535 from the Authentication Manager to the SGD server.

  3. Specify the location of the RSA Authentication Manager configuration file.

    1. Create the /etc/sdace.txt file with the following content:

      VAR_ACE=/opt/ace/data

    2. Save the file.

  4. Copy the RSA Authentication Manager configuration file to the SGD server.

    1. Create an /opt/ace/data directory.

    2. Copy the sdconf.rec file to the /opt/ace/data directory.

  5. 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
    

  6. 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.

procedure icon  How to Enable SecurID Authentication

  1. 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.

  2. On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.

  3. On the System Authentication - Repositories step, select the SecurID check box.

  4. On the Review Selections step, check your authentication configuration and click Finish.


Third-Party and Web Server Authentication

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:

How Third-Party Authentication Works

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.

Search Local Repository

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.

User Identity and User Profile

If a user profile is found, 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

Search LDAP Repository

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.

For a list of supported LDAP directory servers for third‐party authentication, see Supported LDAP Directory Servers.

User Identity and User Profile

If an LDAP person object is found, the user identity is the DN of the LDAP person object. In the Administration Console, the user identity is displayed as LDAP-dn (LDAP). On the command line, the user identity is displayed as .../_service/sco/tta/ldapcache/LDAP-dn.

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.

    For example, dc=com/dc=Indigo Insurance/cn=LDAP Profile.

If there is no match, the profile object System Objects/LDAP Profile is used for the user profile.

Use Default Third-Party Identity

The Use Default Third‐Party Identity method does not perform a search.

User Identity and User Profile

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.

procedure icon  How to Enable Third-Party Authentication

See Supported LDAP Directory Servers for the requirements for using particular LDAP Directory servers with third‐party authentication.

  1. 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.

  2. On the Third-Party/System Authentication step, select the Third-Party Authentication check box.

  3. 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.

  4. 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.

    1. For Repository Type, select the LDAP option.

      Select this option even if you are using a Microsoft Active Directory server.

    2. 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 SSL 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.

    3. Type the details of an LDAP user in the User Name and Password fields.

      The user name must be the DN of the user, for example cn=sgd-user,cn=Users,dc=indigo-insurance,dc=com. The is the LDAP bind DN.

      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.

  5. On the Review Selections step, check the authentication configuration and click Finish.

Web Server Authentication

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.

How Web Server Authentication Works

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.

Security Considerations of Using Web Server Authentication

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.

Enabling Web Server Authentication

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.

procedure icon  How to Enable Web Server Authentication for the SGD Web Server

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.

  1. Log in as superuser (root) on the SGD host.

  2. Create a web server password file.

    Use the /opt/tarantella/webserver/apache/2.2.10_openssl‑0.9.8i_jk1.2.27/bin/htpasswd program to create a web server password file and add entries.

  3. Change the permissions on the web server password file.

    The password file must accessible by the ttaserv user.

    For example, if the web server password file is /etc/httpd/passwords, run the following commands:


    # chmod 440 /etc/httpd/passwords
    # chown ttaserv:ttaserv /etc/httpd/password
    

  4. Edit the Apache configuration file and protect the /sgd URL.

    The Apache configuration file is /opt/tarantella/webserver/apache/2.2.10_openssl‑0.9.8i_jk1.2.27/conf/httpd.conf.

    1. Insert the following directives at the end of the configuration file:

      SetEnvIf Request_URI "\.(class|cab|jar|gif|der)$" sgd_noauth_ok
      <Location /sgd>
       Order Allow,Deny
       Allow from env=sgd_noauth_ok
       AuthUserFile file-path 
       AuthName auth-domain 
       Authtype Basic
       Require valid-user
       Satisfy any
      </Location>

      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.

      For more information on how to configure the <Location> directive, check the Apache documentation.



      Note - You must use a Location directive rather than a Directory directive because the SGD web server delegates the management of the /sgd URL to Tomcat. This is configured in the Apache configuration file and means you cannot use an .htaccess file to protect the /sgd URL.



    2. Save the changes.

  5. 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/6.0.18_axis1.4/conf/server.xml.

    1. Amend the configuration of the AJP 1.3 Connector.

      Add a tomcatAuthentication="false" attribute to the <Connector> element as follows:

      <!-- Define an AJP 1.3 Connector on port 8009 -->
      <Connector port="8009" protocol="AJP/1.3"
      redirectPort="8443" tomcatAuthentication="false" />

    2. Save the changes.

  6. Restart the SGD web server.

    You must restart the SGD web server for the configuration changes to take effect.


    # tarantella restart webserver
    

Using Authentication Plug-ins With Web Server Authentication

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

procedure icon  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.

  1. Log in as superuser (root) on the SGD host.

  2. Configure the Apache component of the SGD web server to forward your variable to the Tomcat component.

    1. Edit the Apache configuration file.

      The file is /opt/tarantella/webserver/apache/2.2.10_openssl‑0.9.8i_jk1.2.27/conf/httpd.conf.

    2. 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 " "

    3. Make the variable available in the /SGD location.

      Remove the comment marks (#) from the Location directive as follows:

      <Location "/sgd">
       SSLOptions +StdEnvVars +ExportCertData
      </Location>

    4. Save the changes.

  3. Configure the webtop web application to use your environment variable.

    1. Change to the SGD web application resources directory.


      # cd /opt/tarantella/webserver/tomcat/6.0.18_axis1.4
      # cd webapps/sgd/resources/jsp
      

    2. 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.

    3. Save the changes.

  4. Restart the SGD web server.

Using Client Certificates With Web Server Authentication

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.

procedure icon  How to Enable Support for the SSL_CLIENT_S_DN_CN Variable

Repeat the following procedure on each SGD server in the array.

  1. Log in as superuser (root) on the SGD host.

  2. Configure the Apache component of the SGD web server to forward the SSL_CLIENT_S_DN_CN variable to the Tomcat component.

    1. Edit the Apache configuration file.

      The file is /opt/tarantella/webserver/apache/2.2.10_openssl‑0.9.8i_jk1.2.27/conf/httpd.conf.

    2. 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 " "

    3. 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>

    4. Save the changes.

  3. Restart the SGD web server.

SGD Administrators and Third-Party Authentication

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

Trusted Users and Third-Party Authentication

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

Information for Application Developers

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/6.0.18_axis1.4/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/6.0.18_axis1.4/conf/server.xml.

  • The list of trusted users is stored in the Tomcat users configuration file /opt/tarantella/webserver/tomcat/6.0.18_axis1.4/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.

procedure icon  How to Create a New Trusted User

Repeat the following procedure on each SGD server in the array.

  1. Log in as superuser (root) on the SGD host.

  2. Stop the SGD web server.

  3. Add the new trusted user to the database of trusted users on the SGD server.

    1. Think of a user name and password for the trusted user.

    2. Create the trusted user.

      Use the following command:


      # tarantella webserver add_trusted_user username
      

      When prompted, type the password.

    3. Check the user is created.

      Use the following command:


      # tarantella webserver list_trusted_users
      

    4. Check that the trusted user works.

      Go to the http://SGD-server/axis/services/document/externalauth URL. When prompted, log in as the trusted user.

  4. 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.

    1. Encode the user name and password of the trusted user.

      Use the following command:


      # /opt/tarantella/bin/jre/bin/java -classpath \
      /opt/tarantella/webserver/tomcat/6.0.18_axis1.4/shared/lib/sgd-webservices.jar \
      com.tarantella.tta.webservices.client.views.SgdPasswd \
      --encode username:password
      

    2. Copy the encoded user name and password from the output.

    3. Change to the shared resources directory.


      # cd /opt/tarantella/webserver/tomcat/6.0.18_axis1.4
      # cd shared/classes/com/tarantella/tta/webservices/client/views
      

    4. Edit the Resources.properties file.

    5. Replace the text after sgdaccess= with the encoded user name and password.

    6. Save the changes.

  5. Start the SGD web server.


UNIX System Authentication

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:

How UNIX System Authentication Works

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.

Search Unix User ID in Local Repository

At the SGD login screen, the user types a user name and password. The user name can be any of the following:

  • A common name, for example Indigo Jones

  • A user name, for example indigo

  • An email address, for example indigo@indigo-insurance.com

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.

This search method is enabled by default.

User Identity and User Profile

The matching user profile in the local repository 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.

Search Unix Group ID in Local Repository

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.

User Identity and User Profile

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 system 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.

Use Default 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.

User Identity and User Profile

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 system users receive the same webtop content.

UNIX System Authentication and PAM

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 system 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.

procedure icon  How to Enable UNIX System Authentication

  1. 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.

  2. On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.

  3. On the System Authentication - Repositories step, select the Unix check box.

  4. 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.

  5. On the Review Selections step, check the authentication configuration and click Finish.


Windows Domain Authentication

Windows domain authentication enables users to log in to SGD if they belong to a specified Windows domain.

Windows domain authentication is disabled by default.

This section includes the following topics:

How Windows Domain Authentication Works

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.

User Identity and User Profile

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.

procedure icon  How to Enable Windows Domain Authentication

  1. 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.

  2. On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.

  3. On the System Authentication - Repositories step, select the Windows Domain Controller check box.

  4. On the Windows Domain Authentication - Domain Controller step, type the name of a domain controller in the Windows Domain field.

  5. On the Review Selections step, check the authentication configuration and click Finish.

Passwords, Domains, and Domain Controllers

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.

procedure icon  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.

  1. Log in a superuser (root) on the SGD host.

  2. Stop the SGD server.

  3. Configure the domain controller

    Use the following commands:


    # 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 IP address of the domain controller.

  4. Start the SGD server.


Troubleshooting Secure Global Desktop Authentication

Use the information in this section to troubleshoot problems when users log in to SGD. This section includes the following topics:

Setting Log Filters for Authentication Problems

To help diagnose problems with Secure Global Desktop authentication, use one or more of the log filters shown in the following table to obtain more information.


Log Filter Purpose
server/ad/* Information about Active Directory authentication.

Applies to Active Directory authentication.

server/login/* Information about what happens when users attempt to log in.

Applies to all authentication mechanisms.

server/ldap/* Information about connections to an LDAP directory.

Applies to Active Directory, LDAP, and third-party authentication.

server/kerberos/* Information about Kerberos authentication.

Applies to Active Directory authentication.

server/securid/* Information about connections to RSA Authentication Manager.

Applies to SecurID authentication.


For information about setting log filters, see Using Log Filters to Troubleshoot Problems With an SGD Server.

Tuning LDAP Performance for Authentication

This section describes how to tune LDAP performance for the following SGD authentication mechanisms:

This section includes the following topics:

LDAP User Name Search Attributes

Whenever SGD searches an LDAP directory to establish a user’s identity, it checks the following attributes on the LDAP person object:

  • cn

  • uid

  • mail

  • userPrincipalName

  • sAMAccountName

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.

procedure icon  How to Configure LDAP User Name 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.

  1. Log in as superuser (root) on the SGD host.

  2. Stop the SGD server.

  3. Configure the LDAP user name search attributes.



    caution icon

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

  4. Start the SGD server.

LDAP Timeout

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

LDAP Cache

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.



Troubleshooting Active Directory Authentication

With Active Directory authentication, SGD uses the Kerberos protocol to authenticate users. SGD then performs an LDAP search to establish the user identity and user profile, and to generate webtops (LDAP assignments).

For information on troubleshooting problems with the LDAP search part of Active Directory authentication, see the following:

LDAP Discovery Timeout

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.

Searching Only the Global Catalog

When searching for user information from Active Directory, SGD uses the domain controller for the user’s domain by default.

While the domain controller contains the most complete and reliable source for user information, it can result in longer timeouts and delays because SGD has to manage connections to both the domain controller and the global catalog.

SGD can be configured to search for user information only from the global catalog. Run the following command:


$ tarantella config edit --tarantella‐config‐ad‐alwaysusegc 1

After running this command, you must flush the cache of LDAP data. Run the following command as superuser (root) on every SGD server in the array:


# tarantella cache --flush all

Troubleshooting LDAP Authentication

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.

Check the URLs, as follows:

  • Does each URL refer to a valid LDAP directory server?

  • 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 URL of the LDAP directory server begin ldaps://?

  • Does the CA certificate truststore on each SGD server contain the CA certificate, or certificate chain, used to sign the SSL 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:

  • cn

  • uid

  • mail

  • userPrincipalName

  • sAMAccountName

If these attributes are not sufficient for identifying users, you can add extra attributes, see LDAP User Name Search Attributes.

Troubleshooting Web Server Authentication

Common problems that users experience when they log in to SGD using web server authentication include the following:

Web Server Authentication Fails

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.

Check the following:

  • Does the user have an entry in the web server password file?

  • Is the web server configured to use the correct password file?

  • If you are using the SGD web server, is the password file accessible by the ttaserv user? If this user cannot read the password file, web server authentication fails.

Users See the Standard SGD Login Page

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/6.0.18_axis1.4/conf/server.xml file. Add the tomcatAuthentication="false" attribute to the <Connector> element for the 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.

Users Get the Wrong Webtop

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.

To resolve the situation, you can either of the following:

  • Accept the first match

  • Attempt to manually resolve the ambiguity, for example by creating or amending user profiles

Denying Users Access to SGD After Failed Login Attempts

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.

procedure icon  How to Enable the Login Failure Handler

You can only enable the login failure handler from the command line.

  •   Use the following command:


    $ tarantella config edit \
    --tarantella-config-components-loginfailurehandler 1 \
    --tarantella-config-components-loginfailurefilter 1
    

procedure icon  How to Change the Number of Login Attempts

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.

  1. Log in to the primary SGD server as superuser (root).

  2. Stop the primary SGD server.

  3. Set the number of login attempts.

    Use the following command:


    # tarantella config edit \
    --com.sco.tta.server.login.LoginFailureHandler.properties-attemptsallowed num
    

  4. Start the primary SGD server.

  5. Do a warm restart of all secondary SGD servers.

    Use the following command:


    # tarantella restart sgd --warm
    

Users Cannot Log In to Any SGD Server

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

Using Shared Accounts for Guest Users

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.

procedure icon  How to Share a User Profile Between Users

  1. In the Administration Console, go to the User Profiles tab.

  2. Select the user profile that is to be shared.

    The General tab is displayed.

  3. For Login, select the Multiple check box.

  4. Click Save.

Solaris OS Users Cannot Log in When Security is Enabled

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.

An Ambiguous User Name Dialog Is Displayed When a User Tries to Log in

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.


Troubleshooting Application Authentication

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

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.

Using Windows Terminal Services, Users Are Prompted for User Names and Passwords Too Often

If you are using Windows Terminal Services, users might be prompted for a user name and password by SGD or by the Terminal Server.

SGD Prompts the User

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.

Terminal Server Prompts the User

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 and later does not. See Authentication Settings for details on how to change this behavior.