Secure Global Desktop 4.40 Administration Guide > Users and Authentication > LDAP Authentication

LDAP Authentication

LDAP authentication allows users to log in to SGD if they have an entry in an LDAP directory.

This authentication mechanism is disabled by default.

This page includes the following topics:

How LDAP Authentication Works
Enabling LDAP Authentication
LDAP Authentication and Password Expiry
Restricting the LDAP Users That Can Log In to SGD
The LDAP Cache
LDAP Timeout

How LDAP Authentication Works

At the SGD login screen, the user types either a common name (for example Indigo Jones), a user name (for example indigo), or an email address (for example indigo@indigo-insurance.com) and a password.

SGD searches the 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 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 the following section). 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 LDAP identity. In the SGD Administration Console, the user identity is displayed as LDAP-ID (LDAP). On the command line, the user identity is displayed as .../_service/sco/tta/ldapcache/LDAP-ID.

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.

Application Sessions and Password Cache Entries

Application sessions and password cache entries belong to the LDAP person object.

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

In the SGD Administration Console, display the Secure Global Desktop Authentication Configuration Wizard.
On the Global Settings » Secure Global Desktop Authentication tab, click the Change Secure Global Desktop Authentication button.

Use the Next and Previous buttons to move between the steps of the Wizard.
On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.
On the System Authentication - Repositories step, select the LDAP/Active Directory check box.
On the LDAP Repository Details step, configure the details of the LDAP directory.
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 and install the root certificates for the LDAP directory servers.
  - 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 distinguished name of the user, for example cn=sgd-user,cn=Users,dc=indigo-insurance,dc=com.
  - 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.
On the Review Selections step, check the authentication configuration and click Finish.

LDAP Authentication and Password Expiry

If you are using the LDAP authentication, SGD can prompt a user for a new password if their password has expired on the LDAP directory server. Additional configuration might be needed, as follows.

For Sun Java System Directory Servers (formerly known as Sun ONE, Netscape software, or iPlanet Directory Server) Sun One Directory Servers:

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.

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. See Securing connections to LDAP directory servers for details.

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 a search filter so that only the users that have a required attribute value on their LDAP person object can log in to SGD. This requires extra configuration in the LDAP directory and in SGD.

Configuring the LDAP Directory

To be able to apply a filter, SGD must be able to test for an attribute value on the person object in the LDAP directory. You can use an attribute that already exists in your LDAP directory or create a new attribute, for example an attribute called allowsgdlogin. This attribute must be set for all users in the LDAP directory.

Configuring the LDAP Search Filter

Once you have configured the LDAP user object attribute, you configure the search filter to test for the LDAP attribute and allow users to log in if they meet the condition(s).

To set the search filter:

Log in as superuser (root).
Stop the SGD server.

Use the following command:

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

For example:

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

Start the Secure Global Desktop server.
Repeat this procedure on each SGD server in the array.

Once the filter is enabled, only users who match the search filter can log in to SGD.

The LDAP Cache

SGD caches the LDAP 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

Note This command only flushes the cache on the SGD server on which the command is run.

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.

LDAP Timeout

You can configure an LDAP timeout in the event that the LDAP searches of an LDAP directory server fail. The LDAP timeout controls how long SGD waits for an LDAP directory server to respond to LDAP operations, such as requests for data. The default is 30 seconds. To change this timeout, run the following command:

$ tarantella config edit --tarantella-config-ldap-timeout secs

SGD makes two attempts to contact the LDAP directory server. If there is no response, SGD tries another LDAP directory server. The list of LDAP directory servers comes from the URLs configured for LDAP authentication. If all LDAP directory servers time out, SGD might not be able to authenticate users or use directory services integration (DSI.

Related Topics
LDAP Users Cannot Log in to SGD Securing Connections to Active Directory and LDAP Directory Servers Using Directory Services Integration Active Directory Authentication Secure Global Desktop and User Authentication