Skip Navigation Links | |
Exit Print View | |
Oracle Fusion Middleware Administration Guide for Oracle Unified Directory 11g Release 1 (11.1.1) |
1. Starting and Stopping the Server
2. Configuring the Server Instance
3. Configuring the Proxy Components
4. Configuring Security Between Clients and Servers
Getting SSL Up and Running Quickly
To Accept SSL-Based Connections Using a Self-Signed Certificate
Configuring Key Manager Providers
Using the JKS Key Manager Provider
To Sign the Certificate by Using an External Certificate Authority
To Configure the JKS Key Manager Provider
Using the PKCS #12 Key Manager Provider
Using the PKCS #11 Key Manager Provider
Developing Custom Key Manager Providers
Configuring Trust Manager Providers
Overview of Certificate Trust Mechanisms
Using the Blind Trust Manager Provider
Using the JKS Trust Manager Provider
Using the PKCS #12 Trust Manager Provider
Configuring Certificate Mappers
Using the Subject Equals DN Certificate Mapper
Using the Subject Attribute to User Attribute Certificate Mapper
Using the Subject DN to User Attribute Certificate Mapper
Using the Fingerprint Certificate Mapper
Configuring SSL and StartTLS for LDAP and JMX
Configuring the LDAP and LDAPS Connection Handlers
To Enable a Connection Handler
To Specify a Connection Handler's Listening Port
To Specify a Connection Handler's Authorization Policy
To Specify a Nickname for a Connection Handler's Certificate
To Specify a Connection Handler's Key Manager Provider
To Specify a Connection Handler's Trust Manager Provider
To Enable SSL-Based Communication
Enabling SSL in the JMX Connection Handler
SASL Options for the ANONYMOUS Mechanism
SASL Options for the CRAM-MD5 Mechanism
SASL Options for the DIGEST-MD5 Mechanism
SASL Options for the EXTERNAL Mechanism
Configuring SASL Authentication
Configuring SASL External Authentication
Configuring the LDAP Connection Handler to Allow SASL EXTERNAL Authentication
Configuring the EXTERNAL SASL Mechanism Handler
Configuring SASL DIGEST-MD5 Authentication
Configuring SASL GSSAPI Authentication
To Configure Kerberos V5 on a Host
To Specify SASL Options for Kerberos Authentication
Example Configuration of Kerberos Authentication Using GSSAPI With SASL
All Machines: Edit the Kerberos Client Configuration File
All Machines: Edit the Administration Server ACL Configuration File
KDC Machine: Edit the KDC Server Configuration File
KDC Machine: Create the KDC Database
KDC Machine: Create an Administration Principal and Keytab
KDC Machine: Start the Kerberos Daemons
KDC Machine: Add Host Principals for the KDC and Oracle Unified Directory Machines
KDC Machine: Add an LDAP Principal for the Directory Server
KDC Machine: Add a Test User to the KDC
Directory Server Machine: Install the Directory Server
Directory Server Machine: Create and Configure the Directory Server LDAP
Directory Server Machine: Configure the Directory Server to Enable GSSAPI
Directory Server Machine: Add a Test User to the Directory Server
Directory Server Machine: Obtain a Kerberos Ticket as the Test User
Client Machine: Authenticate to the Directory Server Through GSSAPI
Troubleshooting Kerberos Configuration
Testing SSL, StartTLS, and SASL Authentication With ldapsearch
ldapsearch Command Line Arguments Applicable To Security
Testing SASL External Authentication
Controlling Connection Access Using Allowed and Denied Rules
Property Syntax of Allowed and Denied Client Rules
Configuring Allowed and Denied Client Rules
5. Configuring Security Between the Proxy and the Data Source
6. Managing Oracle Unified Directory With Oracle Directory Services Manager
10. Managing Users and Groups With dsconfig
11. Managing Password Policies
The LDAP protocol definition provides two ways in which clients can authenticate to the server: LDAP simple authentication and SASL authentication.
Note - SASL is not supported for use with Oracle Unified Directory proxy.
In LDAP simple authentication, the client specifies the DN and password for the user. This is by far the most common authentication mechanism, and in most cases it is also the easiest to use. However, it has a number of limitations, including the following:
The user is always required to provide a full DN, rather than something that could be more user-friendly like a username.
Only password-based authentication is allowed.
The client must provide the complete clear-text password to the server.
To address these issues, it is also possible to authenticate clients through the Simple Authentication and Security Layer (SASL), as defined in RFC 4422. This is a very extensible framework, and makes it possible for servers to support many different kinds of authentication.
The directory server currently supports the following SASL mechanisms:
Note - With Oracle Unified Directory proxy, currently the only supported SASL mechanism is ANONYMOUS.
This mechanism does not actually authenticate clients, but does provide a mechanism for including trace information in server logs for debugging purposes.
This mechanism is provided for backward compatibility only. Do not configure CRAM-MD5 in a production environment. Use the DIGEST-MD5 mechanism instead, because it provides much better security.
This mechanism provides the ability for clients to use password-based authentication without sending the password to the server. Instead, the client only needs to provide information that proves it knows the password. This mechanism offers more options and better security than the CRAM-MD5 mechanism.
This mechanism provides the ability for clients to identify themselves based on information provided outside of the direct flow of LDAP communication. In Oracle Unified Directory, this may be achieved through the use of SSL client certificates.
This mechanism provides the ability for clients to authenticate to the server through their participation in a Kerberos V5 environment.
This mechanism uses a password based authentication, but does offer the ability to use a username rather than requiring a DN.
Support for additional SASL mechanisms can be added by implementing custom SASL mechanism handlers in the server..
Because SASL mechanisms are so extensible, the set of information that the client needs to provide to the server in order to perform the authentication varies from one mechanism to another. As such, Oracle Unified Directory clients use a generic interface for users to provide this information. This is exposed through the -o or --saslOption argument, and the value for this argument should be a name-value pair. Select which SASL mechanism to use using the mech option, for example:
--saslOption mech=DIGEST-MD5
The other options that are available for use depend on the SASL mechanism that has been chosen, as described in the following sections.
Many of the SASL mechanisms below provide the ability to identify a user based on an authorization ID rather than a user DN. An authorization ID may be given in one of two forms:
This is used to provide the full DN of the user to authenticate (for example, dn:uid=john.doe,ou=People,dc=example,dc=com). A value of dn: with no DN is to be treated as the anonymous user, although this form is not accepted by many of the SASL mechanisms listed below.
This is used to provide the username of the user rather than the full DN (for example, u:john.doe).
If the u:username form is used, the mechanism that the server uses to resolve that username to the corresponding user entry is based on the identity mapping configuration within the server.
Because the ANONYMOUS mechanism is not really used to perform authentication, no additional options are required. However, the following option can be supplied:
This option can be used to provide a trace string that is written to the server's access log. This can be useful for debugging or to identify the client, although without authentication it is not possible to rely on the validity of this value.
The following command demonstrates the use of SASL anonymous authentication:
$ ldapsearch --hostname server.example.com --port 1389 --saslOption mech=ANONYMOUS \ --saslOption "trace=Example Trace String" --baseDN "" \ --searchScope base "(objectClass=*)"
The CRAM-MD5 mechanism is used to perform password-based authentication to the server without exposing the clear-text password. It does this by providing an MD5 digest of the clear-text password combined with some randomly-generated data provided by the server, which helps prevent replay attacks.
The SASL CRAM-MD5 mechanism has one SASL option that must be provided:
This specifies the identity of the user that is authenticating to the server. It should be an authorization ID value as described above.
The password is specified using either the --bindPassword or --bindPasswordFile option, just as when using simple authentication. The following command demonstrates the use of SASL CRAM-MD5 authentication:
ldapsearch --hostname server.example.com --port 1389 --saslOption mech=CRAM-MD5 \ --saslOption authid=u:john.doe --baseDN "" --searchScope base "(objectClass=*)"
The DIGEST-MD5 mechanism is similar to the CRAM-MD5 mechanism, but it is more secure because it combines random data from both the client and the server in order to help foil both replay and man-in-the-middle attacks. DIGEST-MD5 authentication also offers a number of SASL options, including the following:
Specifies the identity of the user that is authenticating to the server. This option must be provided.
This option should not be specified as a DN.
Note - Do not use the realm option, because the server does not use it when mapping identities.
Specifies the digest URI that the client uses to communicate with the server. This is an optional parameter, but if it is provided, specify it in the form ldap/serveraddress, where serveraddress is the fully-qualified address of the server.
Note - Do not use the digest-uri option in a production environment.
Specifies the authorization ID that should be used during the authentication process. This option can be used to indicate that the operations requested on the connection after authentication should be performed under the authority of another user.
The password is specified using either the --bindPassword or --bindPasswordFile option, just as when using simple authentication. The following command demonstrates the use of SASL DIGEST-MD5 authentication:
$ ldapsearch --hostname server.example.com --port 1389 --saslOption mech=DIGEST-MD5 \ --saslOption authid=u:john.doe --saslOption realm=dc=example,dc=com --baseDN "" \ --searchScope base "(objectClass=*)"
The EXTERNAL mechanism is used to perform authentication based on information that is available to the server outside of the LDAP session. At present, this is available only through SSL client authentication, in which case the information that the client's SSL certificate will be used to authenticate that client. As such, it is necessary to use SSL or StartTLS when communicating with the server, and a client certificate keystore must be available.
The EXTERNAL mechanism does not support any additional SASL options. In most cases, it can be requested using either --saslOption mech=EXTERNAL or --useSASLExternal. The following command demonstrates the use of SASL EXTERNAL authentication:
$ ldapsearch --hostname server.example.com --port 1636 --useSSL \ --keyStorePath /path/to/key.store --keyStorePasswordFile /path/to/key.store.pin \ --trustStorePath /path/to/trust.store --saslOption mech=EXTERNAL --baseDN "" \ --searchScope base "(objectClass=*)"
For more information, see Configuring SASL External Authentication.
The GSSAPI mechanism is used to perform authentication in a Kerberos V5 environment, and generally requires that the client system be configured to participate in such an environment. The options available for use with the GSSAPI mechanism include:
Specifies the authentication ID that should be used to identify the user. This ID should be in the form of a Kerberos principal and not in the authorization ID form described previously. This option must be provided if the user has not authenticated to Kerberos before attempting to bind.
Specifies the authorization ID that should be used to identify the user under whose authority operations should be performed. The directory server does not yet support this capability.
Specifies the quality of protection to use for the communication. Currently, only the auth quality-of-protection value is supported by the directory server clients. The auth-int and auth-conf values are supported by the server.
If the user already has a valid Kerberos ticket on the system when attempting to use GSSAPI, the client attempts to use it so that no password is required. However, if the user does not have a valid Kerberos ticket or if it cannot be accessed for some reason, a password must be provided using either the --bindPassword or --bindPasswordFile options.
The following command demonstrates the use of SASL GSSAPI authentication for a user that already has a valid Kerberos session:
$ ldapsearch --hostname server.example.com --port 1389 --saslOption mech=GSSAPI \ --saslOption authid=jdoe@EXAMPLE.COM --baseDN "" --searchScope base "(objectClass=*)"
The PLAIN mechanism provides many of the same capabilities as LDAP simple authentication, although the user may be identified in the form of an authorization ID rather than requiring a full DN. The following options are available for use when using SASL PLAIN authentication:
Specifies the identity of the user that is authenticating to the server. It should be an authorization ID value as described above. This option must be provided.
Specifies the identity of the user under whose authority operations should be performed. It should also be in the form of an authorization ID. The directory server does not yet support this capability.
The password is specified using either the --bindPassword or --bindPasswordFile option, just as when using simple authentication. The following command demonstrates the use of SASL PLAIN authentication:
$ ldapsearch --hostname server.example.com --port 1389 --saslOption mech=PLAIN \ --saslOption authid=u:john.doe --baseDN "" --searchScope base "(objectClass=*)"