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

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 from LDAP
searches. See Chapter 3, Publishing Applications to Users for details of how applications are assigned to users.

Setting Up LDAP Authentication

Setting up LDAP authentication involves the following configuration steps:

Supported LDAP Directories

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

LDAP Bind DN and Password Change

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

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.

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.

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.

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 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 Using Service Objects for more details.