Configuring the Directory Server
Configuring Security in the Directory Server
Getting SSL Up and Running Quickly
To Accept SSL-Based Connections Using a Self-Signed Certificate
Enabling SSL and StartTLS in QuickSetup
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
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
SASL Options for the GSSAPI Mechanism
SASL Options for the PLAIN Mechanism
Configuring SASL Authentication
Configuring SASL External Authentication
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
Troubleshooting Kerberos Configuration
Testing SSL, StartTLS, and SASL Authentication With ldapsearch
The directory server currently supports the following SASL mechanisms:
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 OpenDS, 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, OpenDS 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.