2.4. LDAP Authentication

2.4. LDAP Authentication
Prev	Chapter 2. User Authentication	Next

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

This authentication mechanism is disabled by default.

This section includes the following topics:

2.4.1. How LDAP Authentication Works

At the SGD login screen, the user types a user name and password. The user name can be any of the following:

A common name, for example Indigo Jones
A user name, for example indigo
An email address, for example indigo@example.com

SGD searches the LDAP directory for an LDAP object with an attribute that matches the user name typed by the user. By default, SGD searches the following attributes:

cn
uid
mail

If an LDAP object is not found, the next authentication mechanism is tried.

If an LDAP object is found, SGD performs a bind using the name of the LDAP object and the password typed by the user. If the bind fails, the next authentication mechanism is tried.

If the authentication succeeds, SGD searches the local repository for the user profile, see Section 2.4.1.1, “User Identity and User Profile” for details. 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.

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

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 user's 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 profile object o=System Objects/cn=LDAP Profile is used for the user profile.

You can use LDAP authentication with Directory Services Integration. The applications assigned to LDAP users come from a combination of the user profile and LDAP searches. See Chapter 3, Publishing Applications to Users for details of how applications are assigned to users.

2.4.2. Setting Up LDAP Authentication

Setting up LDAP authentication involves the following configuration steps:

Prepare for LDAP authentication.
Additional configuration might be required to use SGD with your LDAP directory, see Section 2.4.3, “Preparing for LDAP Authentication”.
Enable LDAP authentication.
Configure SGD to use LDAP authentication and specify the LDAP directory details, see Section 2.4.4, “How to Enable LDAP Authentication”.
For organizations with complex LDAP deployments, use service objects to manage and tune your LDAP configuration. See Section 2.8.4, “Using Service Objects”.

2.4.3. Preparing for LDAP Authentication

You prepare for LDAP authentication as follows:

Ensure you are using a supported LDAP directory, see Section 2.4.3.1, “Supported LDAP Directories”.
Ensure your SGD servers can connect to the LDAP directory servers, see Section 2.4.3.2, “Network Requirements for LDAP Authentication”.
Ensure that you understand the requirements for the LDAP bind DN and SGD password change operations, see Section 2.4.3.3, “LDAP Bind DN and Password Change”
Ensure that Novell eDirectory users can authenticate, see Section 2.4.3.4, “Authentication to Novell eDirectory”

2.4.3.1. Supported LDAP Directories

The supported LDAP directories are listed in the Oracle Secure Global Desktop Platform Support and Release Notes.

2.4.3.2. Network Requirements for 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.

The ports used for connections to LDAP directory servers are TCP port 389 for standard connections and port TCP 636 for secure (ldaps://) connections. If your directory servers use different ports, you can specify the port when you enable LDAP authentication. You must make sure SGD can make LDAP connections using these ports.

To be able to use secure (ldaps://) connections, SGD must be able to validate the SSL certificate presented by an LDAP directory server. You might have to import the CA certificates for your LDAP directory servers into the SGD CA certificate truststore. See Section 7.5.1, “The CA Certificate Truststore” for details of how to check for supported CAs and how to import CA certificates.

2.4.3.3. LDAP Bind DN and Password Change

By default, SGD uses two LDAP bind DNs, an administrator bind DN and a user bind DN.

The administrator bind DN is the user name and password configured for LDAP authentication. The administrator bind DN is used only for querying the directory server and so this user must have privileges to search the directory. You might want to create a special LDAP user for use with SGD. The administrator bind can be an anonymous bind. Active Directory does not support anonymous binds.

The user bind DN is the user name and password provided when a user logs in. By default, the user bind DN is used for authentication and password change operations.

Once a user's password expires, they cannot log in to SGD and SGD cannot force them to change their password. SGD can be configured to warn users that their password is about to expire, and to force them to change their password before it expires, see Section 2.8.5, “Password Expiry”. For SGD to be able to do this, the following must be true:

On LDAP directories, SGD must be able to read the user's password policy control when binding to the directory as the user
On Active Directory, SGD must be able to read the domain controller's Maximum Password Age setting and the user's Password Last Set attribute

If your directory server does not meet these requirements, and you want SGD to handle password change, you must configure SGD to use the administrator bind DN for password change operations. See Section 2.8.6, “LDAP Password Update Mode”.

Note

On some LDAP directories, password change operations performed using the administrator bind DN are treated as a password reset rather than a change operation.

For Oracle Directory Server Enterprise Edition, if you configure SGD to use the administrator bind DN for password updates, additional configuration might be needed for SGD to handle password change, as follows:

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 administrator bind DN must have administrative privileges.

For 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 (ldaps://) between the SGD server and the Active Directory server.

By default, Novell eDirectory requires that all simple LDAP binds that contain a password must use an SSL connection. To use eDirectory with SGD, do either of the following:

Configure SGD to use secure connections to eDirectory by using ldaps:// URLs
Configure the LDAP group object in eDirectory and disable TLS for simple binds

2.4.3.4. Authentication to Novell eDirectory

Users might not be able to authenticate Novell eDirectory because the user login filter for LDAP authentication filters for the cn attribute and this attribute is a restricted attribute in eDirectory.

To enable users to log in to SGD, do either of the following:

Ensure that the LDAP bind DN has privileges to access to the cn attribute. See Section 2.4.3.3, “LDAP Bind DN and Password Change” for more details.
Change the user login filter so that it does not filter the cn attribute. See Section 2.8.1, “Filtering LDAP or Active Directory Logins” for more details.

2.4.4. How to Enable LDAP 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 LDAP/Active Directory check box.
On the LDAP Repository Details step, configure the LDAP directory details.
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, type the URL of one or more LDAP directory servers.
  For example, ldap://melbourne.example.com.
  If you type more than one URL, separate each URL with a semicolon (;).
  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.
  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. Type 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.
  The URLS configured for an LDAP service object must all be of the same type, either ldap:// or ldaps://. You cannot use a mixture of ldap:// and ldaps:// URLs.
On the Review Selections step, check the authentication configuration and click Finish.
When you click Finish, SGD creates a service object called generated. Service objects are used to manage directory services configuration, see Section 2.8.4, “Using Service Objects” for more details.

Prev	Up	Next
2.3. Anonymous User Authentication	Home	2.5. SecurID Authentication