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

This section includes the following topics:

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

  • Logs in to the application server, prompting the user for a password if necessary.

  • Sets environment variables. These are the variables specified by the Environment Variables attribute on the Launch tab for the application object.

  • Starts any window manager programs. These are the programs specified by the Window Manager attribute on the Presentation tab for the application object.

  • Starts an input method if one is required (UNIX platform applications only).

  • Runs the command to start the application.

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. Appendix E, Login Scripts contains detailed reference information about SGD login scripts.

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

  • Whether to automatically try the user's SGD user name and password when logging in to an application server if these details have been cached

  • What action to take if the user's application server password has expired

  • Whether to log in to a Microsoft Windows application server using a smart card

  • When to display the Application Authentication dialog, what the default settings are on the dialog, and whether users can change them

4.7.3. 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, the Remote Desktop Session Host 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.

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

  • The Passwords tab for dynamic application server objects – This tab enables you to manage password cache entries for the selected dynamic 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, dynamic 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.

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

4.7.3.3. 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 a domain name is set on the user profile 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, 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 attribute must be set on the user profile object.

4.7.4. Input Methods and UNIX Platform Applications

An input method is a program or operating system component that enables users to enter characters and symbols not found on their keyboard.

By default, SGD runs an IM for all locales, apart from C and POSIX.

To change the IM configuration, you can edit variables in the vars.exp login script. The variables are as follows:

  • IM_runByDefault – This variable controls whether an IM is enabled (variable set to 1), or is disabled (variable set to 0) by default. The default is 1.

  • IM_localeNotList – If IM_runByDefault is set to 1, SGD runs an IM for all locales, except the locales listed in the IM_localeNotList variable.

  • IM_localeList – If IM_runByDefault is set to 0, SGD only runs an IM for the locales listed in the IM_localeList variable.

SGD uses the following environment variables to determine the locale TTA_PreferredLocale, TTA_HostLocale, and LANG. See Section E.3, “Login Script Variables”.

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

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

4.7.7. Using Network Level Authentication for Windows Application Authentication

SGD supports network level authentication (NLA) using CredSSP for Windows applications. NLA provides enhanced security by authenticating the user before establishing the connection to the Remote Desktop Session Host.

NLA can be used with Windows 2008 R2, Windows 7, and Windows 2008 application servers.

To use NLA authentication, configure the Enhanced Network Security (--enhancednetworksecurity) attribute for the Windows application object.

Enhanced Network Security is enabled by default for Windows applications. If this attribute is disabled, RDP security is used when authenticating to the application server.

You can enforce the use of NLA for a Remote Desktop Session Host. For example, on Windows Server 2008 R2 enable the Require user authentication for remote connections by using Network Level Authentication setting for the group policy object, at Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security.

If NLA fails when SGD is configured to supply the password for the application server from its password cache, a warning message is shown prompting users to retry the launch using the Shift key. NLA might fail if the SGD credentials do not match the Remote Desktop Session Host credentials. Using Shift-click forces an application server prompt, as described in Section 4.9.7.2, “Remote Desktop Session Host Prompts the User”.