When a user clicks a link to start an application, the login script configured for the application connects to the application server, handles the authentication process, and starts the application.
The Execution Protocol Engine is the SGD component that runs the login script. The login script authenticates the user to the application server by submitting a user name and password stored in the SGD application server password cache. If there is a problem with the user's credentials, SGD displays an Application Authentication dialog as follows:
The Application Authentication dialog enables users to enter their credentials and store them in the application server password cache so that they are not prompted when they next run an application on that application server.
Users can also force SGD to display the Application Authentication dialog by holding down the Shift key when they click an application's link on the webtop.
This section includes the following topics:
SGD uses login scripts to handle the connection to the application server, to run the application, and to perform additional tasks.
Typically a login script performs the following tasks:
Logs in to the application server, prompting the user for a password if necessary.
Sets environment variables. These are the variables specified by the Environment Variables attribute on the Launch tab for the application object.
Starts any window manager programs. These are the programs specified by the Window Manager attribute on the Presentation tab for the application object.
Starts an input method 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.
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
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.
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.
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
The user's SGD password can also be stored in the password cache.
Entries in the application server password cache are encrypted with an encryption key. When starting applications, the passwords are decrypted as they are needed.
By default, the encryption key used for the password cache never changes. You can configure SGD to generate a new encryption key for the password cache whenever an SGD server restarts. In the Administration Console, go to the Global Settings → Security tab and select the New Password Encryption Key check box. Alternatively, use the following command:
$ tarantella config edit --security-newkeyonrestart 1
Existing entries in the password cache are re-encrypted with the new key.
When SGD caches a user's password for a Microsoft Windows application server, the password cache entry is created using the Windows domain name.
The domain name can be specified using the Domain Name attribute on application server objects, Windows application objects, or user profile objects. Users can also specify a domain name on the Application Authentication dialog.
When a user starts an application, SGD goes through the following process to establish the domain name and password cache entry to use:
Check if a domain name is set on the application server object.
If a domain name is set, SGD searches the password cache for an entry for the user identity.
If there is no domain name, or there is no entry in the password cache, move to step 2.
Check if a domain name is set on the application object.
If a domain name is set, SGD searches the password cache for an entry for the user identity.
If there is no domain name, or there is no entry in the password cache, move to step 3.
Check if 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.
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”.
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
.
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.
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”.