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:
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 firstname.lastname@example.org
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:
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 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.
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 from LDAP searches. See Chapter 3, Publishing Applications to Users for details of how applications are assigned to users.
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 Preparing for LDAP Authentication.
Enable LDAP authentication.
Configure SGD to use LDAP authentication and specify the LDAP directory details, see How to Enable LDAP Authentication.
For organizations with complex LDAP deployments, use service objects to manage and tune your LDAP configuration. See Using Service Objects.
You prepare for LDAP authentication as follows:
Ensure you are using a supported LDAP directory, see Supported LDAP Directories.
Ensure your SGD servers can connect to the LDAP directory servers, see Network Requirements for LDAP Authentication.
Ensure that you understand the requirements for the LDAP bind DN and SGD password change operations, see LDAP Bind DN and Password Change
Ensure that Novell eDirectory users can authenticate, see Authentication to Novell eDirectory
The supported LDAP directories are listed in the Oracle Secure Global Desktop 4.6 Platform Support and Release Notes available at http://docs.sun.com/app/docs/doc/821-1928.
Before you enable LDAP authentication, make sure all the SGD servers in the array can contact each LDAP directory server used for authentication.
The standard port used for connections to LDAP directory servers is 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 The CA Certificate Truststore for details of how to check for supported CAs and how to import CA certificates.
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 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 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
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 LDAP Bind DN and Password Change for more details.
Change the user login filter so that it does not filter the cn attribute. See Filtering LDAP or Active Directory Logins for more details.
Go to the Global Settings -> Secure Global Desktop Authentication tab and click the Change Secure Global Desktop Authentication button.
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 Active Directory Authentication.
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.
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 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.
When you click Finish, SGD creates a service object called generated. Service objects are used to manage directory services configuration, see Using Service Objects for more details.