Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices
SGD is designed to integrate with your existing authentication infrastructure and has the following two methods for authenticating users:
System authentication. SGD checks the user's credentials against one or more external authentication services, for example a Lightweight Directory Access Protocol (LDAP) directory. See Section 2.1.3, “System Authentication Mechanisms” for details of the available system authentication mechanisms.
Third-party authentication. An external mechanism authenticates the user and SGD trusts that the authentication is correct. The most common use of third-party authentication is web authentication. See Section 2.6, “Third-Party Authentication and Web Authentication” for more details.
The following are main results of a successful authentication:
A user identity. The name that identifies the user. See Section 2.1.1, “User Identity” for more details.
A user profile. The user's SGD-related settings. See Section 2.1.2, “User Profile” for more details.
Sometimes the user identity and the user profile are the same.
In the SGD Administration Console, you can monitor user sessions and application sessions using either the user identity or the user profile.
Depending on how users are authenticated, SGD can prompt users to change their password when they try to log in with an expired password. See Section 2.1.4, “Password Expiry” for details.
SGD authentication is global. A user can log in to any SGD server in the array with the same user name and password.
SGD Administrators can enable and disable each authentication mechanism independently, as follows:
In the Administration Console, use the Global Settings → Secure Global Desktop Authentication tab.
On the command line, use the tarantella config command.
A user identity is the name that identify the user. 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.
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
o=System Objects/cn=LDAP Profile.
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. |
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. |
LDAP | Enables users to log in to SGD if they have an entry in an LDAP directory. Users might have their own webtop content, depending on configuration. |
Active Directory | Enables users to log in to SGD if they have an account in an Active Directory forest. Users might have their own webtop content, depending on configuration. |
UNIX system – Search Unix Group ID in Local Repository | Enables users to log in to SGD if they have UNIX or Linux system accounts on the SGD host. All users in the same UNIX system group have the same webtop content. |
UNIX system – Use Default User Profile | Enables users to log in to SGD if they have UNIX or Linux system accounts on the SGD host. All UNIX system users have the same webtop content. |
SecurID | Enables users with RSA SecurID tokens to log in to SGD. Users might have their own webtop content, depending on configuration. |
When a user logs in, the enabled authentication mechanisms are tried in the order they are listed in Table 2.1, “System Authentication Mechanisms”. 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.
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:
Confirms that the password has expired
Enables the user to enter and confirm a new password
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 Section 2.2.4, “Configuring SGD for Kerberos Authentication” for details. |
Anonymous user | Not applicable. User logs in without a user name or password. |
LDAP | No. Once a user's password has expired, they cannot log in to SGD. However, SGD can be configured to force users to change their password before it expires. See Section 2.4.3.3, “LDAP Bind DN and Password Change” 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 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 Section 2.7.2, “UNIX System Authentication and PAM” for details. |
Windows domain | No. |
When logging in to SGD, passwords and authentication tokens are only encrypted if there is an HTTP over Secure Sockets Layer (HTTPS) connection.
SGD uses external mechanisms for authenticating users. The security of passwords when authenticating users is as follows:
Active Directory authentication uses the Kerberos protocol for authentication, which is secure
LDAP authentication can be configured to use a secure connection
Web authentication is only secure if the user has an HTTPS connection
All other authentication mechanisms use the native protocols for authenticating users
Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices