Determining Authentication Methods

Directory Server Enterprise Edition supports the following authentication mechanisms:

• Anonymous Access

• Simple Password Authentication

• Simple Password Authentication Over a Secure Connection

• Certificate-Based Client Authentication

• SASL-Based Client Authentication

The same authentication mechanism applies to all users, whether the users are people or LDAP-aware applications.

Apart from the authentication mechanisms described above, this section also includes the following information about authentication:

• Preventing Authentication by Account Inactivation

• Preventing Authentication by Using Global Account Lockout

• External Authentication Mappings and Services

Anonymous Access

Anonymous access is the simplest form of directory access. Anonymous access makes data available to any directory user, regardless of whether the user has authenticated.

Anonymous access does not allow you to track who is performing searches or what kind searches are being performed, only that someone is performing searches. When you allow anonymous access, anyone who connects to your directory can access the data. If you allow anonymous access to data, and attempt to block a user or group from that data, the user can access the data by binding to the directory anonymously.

You can restrict the privileges of anonymous access. Usually, directory administrators allow anonymous access only for read, search, and compare privileges. You can also limit access to a subset of attributes that contain general information such as names, telephone numbers, and email addresses. Do not allow anonymous access to sensitive data, such as government identification numbers, home telephone numbers and addresses, and salary information.

Anonymous access to the root DSE (base DN "") is required. Access to the root DSE enables applications to discover the capabilities of the server, the supported security mechanisms, and the supported suffixes.

Simple Password Authentication

If anonymous access is not set up, a client must authenticate to Directory Server to access the directory contents. With simple password authentication, a client authenticates to the server by providing a simple, reusable password.

The client authenticates to Directory Server through a bind operation in which the client provides a distinguished name and credentials. The server locates the entry that corresponds to the client DN, then checks whether the client's password matches the value stored with the entry. If the password matches, the server authenticates the client. If the password does not match, the authentication operation fails and the client receives an error message.

The drawback of simple password authentication is that the password is transmitted in clear text, which can compromise security. If a rogue user is listening, that user can impersonate an authorized user.

Simple password authentication offers an easy way of authenticating users. However, you need to restrict the use of simple password authentication to your organization’s intranet. This kind of authentication does not offer the level of security that is required for transmissions between business partners over an extranet or for transmissions with customers on the Internet.

Simple Password Authentication Over a Secure Connection

A secure connection uses encryption to make data unreadable to third parties while the data is sent over the network between Directory Server and its clients. Clients can establish secure connections in either of the following ways:

• Binding to the secure port by using the Secure Socket Layer (SSL)

• Binding to an insecure port with anonymous access, then sending the Start TLS control to begin using Transport Layer Security (TLS)

In either case, the server must have a security certificate, and the client must be configured to trust this certificate. The server sends its certificate to the client to perform server authentication, using public-key cryptography. This results in the client knowing that it is connected to the intended server and that the server is not being tampered with.

Then, for privacy, the client and server encrypt all data transmitted through the connection. The client sends the bind DN and password on the encrypted connection to authenticate the user. All further operations are performed with the identity of the user. The operations might also be performed with a proxy identity if the bind DN has proxy rights to other user identities. In all cases, the results of operations are encrypted when these results are returned to the client.

Certificate-Based Client Authentication

When establishing encrypted connections over SSL or TLS, you can also configure the server to require client authentication. The client must send its credentials to the server to confirm the identity of the user. The user's certificate, not the DN, is used to determine the bind DN. Client authentication protects against user impersonation and is the most secure type of connection.

Certificate-based client authentication operates at the SSL, TLS layer only. To use a certificate-based authentication ID with LDAP, you must use SASL EXTERNAL authentication after establishing the SSL connection.

You can configure certificate-based client authentication by using the dsconf get-server-prop command. See dsconf(1M) for more information.

SASL-Based Client Authentication

Client authentication during an SSL or TLS connection can also use the Simple Authentication and Security Layer (SASL), a generic security interface, to establish the identity of the client. Directory Server Enterprise Edition supports the following mechanisms through SASL:

• DIGEST-MD5. This mechanism authenticates clients by comparing a hashed value sent by the client with a hash of the user's password. However, because the mechanism must read user passwords, all users wanting to be authenticated through DIGEST-MD5 must have {CLEAR} passwords in the directory.

• GSSAPI. The General Security Services API (GSSAPI) is available only on the Solaris Operating System. It allows Directory Server to interact with the Kerberos V5 security system to identify a user. The client application must present its credentials to the Kerberos system, which in turn validates the user's identity to Directory Server.

• EXTERNAL. This mechanism authenticates a user in LDAP based on the credentials specified by an external security layer, such as SSL or TLS.

For more information, see Using SASL DIGEST-MD5 in Clients in Oracle Fusion Middleware Administration Guide for Oracle Directory Server Enterprise Edition and Using Kerberos SASL GSSAPI in Clients in Oracle Fusion Middleware Administration Guide for Oracle Directory Server Enterprise Edition.

Preventing Authentication by Account Inactivation

You can temporarily prevent authentication by inactivating a user account or a set of accounts. When the account is inactivated, the user cannot bind to Directory Server, and authentication operations fail. For more information, see Manually Locking Accounts in Oracle Fusion Middleware Administration Guide for Oracle Directory Server Enterprise Edition.

Preventing Authentication by Using Global Account Lockout

In this version of Directory Server, authentication failures with a password are monitored and replicated. This enables rapid, global account lockout after a specified number of authentication attempts with an invalid password. Global account lockout is supported in any of the following cases:

• Client applications bind to a single server in the topology only

• The topology does not include any read-only consumers

• Directory Proxy Server is used to control all bind traffic

Imagine a situation where all bind attempts are not directed to the same server, and the client application performs bind attempts on multiple servers faster than lockout data can be replicated. In the worst-case scenario, the client would be allowed the specified number of attempts on each server where the client attempted to bind. This situation would be unlikely if the client application were driven by input from a human user. However, an automated client built to attack a topology could exploit this deployment choice.

Prioritized replication can be used to minimize the impact of asynchronous replication latency on intrusion detection. However, you might require account lockout immediately after the specified number of failed bind attempts. In this situation, you must use Directory Proxy Server to route all bind attempts on a particular entry to the same master replica. For information about how to configure Directory Proxy Server to do this, see Operational Affinity Algorithm for Global Account Lockout in Oracle Fusion Middleware Reference for Oracle Directory Server Enterprise Edition.

To retain a strictly local lockout policy in a replicated topology, you must maintain compatibility with the 5.2 password policy. In this situation, the policy in effect must not be the default password policy. Local lockout can also be achieved by restricting binds to read-only consumers.

For detailed information about how global account lockout works, see Global Account Lockout in Oracle Fusion Middleware Reference for Oracle Directory Server Enterprise Edition.

External Authentication Mappings and Services

Directory Server provides user account host mapping, which associates a network user account with a Directory Server user account. This feature simplifies the management of both user accounts. Host mapping is required for users who are externally authenticated.