2.5 SecurID Authentication

SecurID authentication enables users with RSA SecurID tokens to log in to SGD. SGD authenticates users against an RSA Authentication Manager.

RSA SecurID is a product from RSA, 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.

2.5.1 How SecurID Authentication Works

At the SGD login dialog box, the user enters their SecurID user name, for example indigo, and their passcode.

Next, SGD performs a search to establish the user identity and user profile. The following search methods can be used:

Search Local Repository
Search LDAP Repository
Use Default SecurID Identity

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 selected 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 workspace, the standard login page displays, so that the user can log in using system authentication.

If a user profile is found, the Login Name attribute of that object is used as the SecurID user name.

If the Use Default SecurID Identity search method is used, the name the user entered is used as the SecurID user name.

Next, SGD checks the SecurID user name, and the passcode entered 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 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.

2.5.1.1 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 SecurID 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 SGD datastore, the user identity is in the Local namespace. In the Administration Console, the text "(Local)" is displayed next to the user identity. On the command line, the user identity is located in .../_ens.

2.5.1.2 Search LDAP Repository

The Search LDAP Repository method searches an LDAP directory for an LDAP object with an attribute that matches the SecurID user name entered by the user. By default, SGD searches the following attributes:

cn
uid
mail
sAMAccountName

Ambiguous logins are not supported for this search method.

If an LDAP object is not found, the next search method is tried.

User Identity and User Profile

The user identity is the DN of the user's LDAP object. In the SGD datastore, the user identity is in the LDAP namespace. In the Administration Console, the text "(LDAP)" is displayed next to the user identity. On the command line, the user identity is located in .../_service/sco/tta/ldapcache.

Next SGD searches for the user profile. When searching for the user profile, SGD looks for the closest matching LDAP profile in the local repository.

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 user's LDAP object.
For example, if the LDAP object is cn=Emma Rald,cn=Sales,dc=example,dc=com, SGD searches the local repository for dc=com/dc=example/cn=Sales/cn=Emma Rald.
A user profile in the same organizational unit as the user's LDAP object but with the name cn=LDAP Profile.
For example, dc=com/dc=example/cn=Sales/cn=LDAP Profile.
A user profile in any parent organizational unit with the name cn=LDAP Profile.
For example, dc=com/dc=example/cn=LDAP Profile.

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

2.5.1.3 Use Default SecurID Identity

The Use Default SecurID Identity method does not perform a search.

User Identity and User Profile

The user identity is the SecurID user name. In the SGD datastore, the user identity is in the SecurID namespace. In the Administration Console, the text "(SecurID)" is displayed next to the user identity. On the command line, the user identity is located in .../_service/sco/tta/securid.

The profile object System Objects/SecurID User Profile is always used for the user profile.

2.5.2 Setting Up SecurID Authentication

Setting up SecurID authentication involves the following configuration steps:

Install and configure RSA SecurID.
Ensure you are using a supported version of RSA SecurID. The supported versions of SecurID are listed in the Oracle Secure Global Desktop Platform Support and Release Notes.
Ensure the RSA Authentication Manager is up to date with the latest patches released by RSA.
Install the SecurID Authentication Agent software on each SGD host.
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 Section 2.5.3, “Configuring SGD Servers as Agent Hosts”.
Enable SecurID authentication for SGD.
Configure SecurID authentication so that SecurID users can log in to SGD.
See Section 2.5.4, “Enabling SecurID Authentication”.
Establish a node secret for each SGD server in the array.
See Section 2.5.5, “Establishing a Node Secret”.

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

2.5.3.1 Configuring an SGD Server as an Agent Host

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

Log in as superuser (root) on the SGD host.
Ensure the SGD server can contact the RSA Authentication Manager on the network.
You may have to open ports in your firewalls to enable 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.
Copy the RSA Authentication Manager configuration file to the SGD host.
The default location is /opt/tarantella/var/rsa/sdconf.rec.
Set the file permissions and ownership for sdconf.rec, as follows:
```
# chown ttasys:ttaserv sdconf.rec
# chmod 444 sdconf.rec
```
Specify the location of the RSA Authentication Manager configuration file.
To specify the location, you use the rsa_api.properties properties file.
1. Make a copy of the template properties file included in the /opt/tarantella/var/rsa directory.
```
# cp rsa_sample.properties rsa_api.properties
# chmod 444 rsa_api.properties
```
2. Edit the SDCONF_LOC setting in rsa_api.properties to point to the location of the RSA Authentication Manager configuration file.
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.

2.5.4 Enabling SecurID Authentication

In the SGD Administration Console, display the Secure Global Desktop Authentication Configuration Wizard.
Go to the Global Settings, Secure Global Desktop Authentication tab and click the Change Secure Global Desktop Authentication button.
On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.
On the System Authentication - Repositories step, select the SecurID check box.
On the SecurID Authentication - User Profile step, select the check box for one or more search methods for finding the user identity.
See Section 2.5.1, “How SecurID Authentication Works” for details on the search methods.
(Optional) On the LDAP Repository Details step, configure the LDAP directory details.
The LDAP Repository Details step only displays if the Search LDAP Repository search method is selected in Step 4.
1. For Repository Type, select the LDAP option.
  Select this option even if you are using a Microsoft Active Directory server for LDAP authentication. The Active Directory option enables Active Directory authentication, see Section 2.2, “Active Directory Authentication”.
2. In the URLs field, enter the URL of one or more LDAP directory servers.
  For example, ldap://melbourne.example.com.
  If you enter more than one URL, separate each URL with a semicolon (;).
  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.
  The URLS must all be of the same type, either ldap:// or ldaps://. You cannot use a mixture of ldap:// and ldaps:// URLs.
  If the LDAP directory uses a non-standard port, specify the port number as part of the URL, for example ldap://melbourne.example.com:5678. Otherwise the port number can be omitted.
  You can specify a DN to use as the search base, for example ldap://melbourne.example.com/dc=example,dc=com. This specifies the part of the LDAP directory used to search for the user identity.
3. Enter 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=example,dc=com. This is the administrator bind DN, see Section 2.4.3.3, “LDAP Bind DN and Password Change” for more details.
  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.
  If the directory server supports anonymous binds, you can omit the user name and password. You must be able to perform LDAP queries for user data to use anonymous binds.
On the Review Selections step, check your authentication configuration and click Finish.
If you enabled the LDAP search method, SGD creates a service object called generated. Service objects are used to manage directory services configuration, see Section 2.9.4, “Using Service Objects” for more details.

2.5.5 Establishing a Node Secret

Before you start to use an SGD host for SecurID authentication, you must establish and store a node secret on the SGD host.

Log in to the SGD server using an RSA SecurID token. The node secret is copied automatically from the RSA Authentication Manager to the SGD host.

In some cases, you may need to copy the node secret manually from the RSA Authentication Manager to the SGD host. Copy the node secret to the /opt/tarantella/var/rsa directory on the SGD host. Run the tarantella restart command, to restart the SGD server and load the node secret.