Starting and Stopping Your Server Instance
Configuring the Server Instance
Configuring the Proxy Components
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
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
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
ldapsearch Command Line Arguments Applicable To Security
Testing SASL External Authentication
Controlling Connection Access using Allowed and Denied Rules
Configuring Security Between the Proxy and the Data Source
Configuring Servers With the Control Panel
This section explains the access control and privilege restrictions on a user using the authorization ID keyword (authzid). If the user is not using the authzid keyword, the restrictions do not apply.
Any user that binds using GSSAPI must fulfill the following requirements:
The authentication ID (authid) must be granted access by an ACI that grants it the proxy right to the authorization ID.
The authentication ID (authid) entry must contain the proxied-auth privilege.
The following example creates a test environment with three example entries and demonstrates the requirements for user authentication using the GSSAPI SASL mechanism. These examples require a fully configured Kerberos environment, including a valid keytab file.
Create three Kerberos principals in the realm TESTLOCAL.NET:
user.0@TESTLOCAL.NET
user.1@TESTLOCAL.NET
user.2@TESTLOCAL.NET
Configure the GSSAPI SASL handler to be enabled, to use the regular expression identity mapper, and to use a valid TESTLOCAL.NET keytab file.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -w password -X \ set-sasl-mechanism-handler-prop --handler-name "GSSAPI" \ --set enabled:true --set identity-mapper:"Regular Expression" \ --set keytab:keytabPath
The default value of the GSSAPI enabled property is false, so it must be set to true. The default value of identity-mapper is Regular Expression. The default value of the keytab property is /etc/krb5/krb5.keytab.
Import the following entries into the directory. These entries define an ACI and three users:
The entry uid=user.0,ou=People,dc=example,dc=com does not have the proxied-auth privilege but is granted proxy access by the ACI.
The entry uid=user.1,ou=People,dc=example,dc=com has the proxied-auth privilege but is not granted proxy access by the ACI.
The entry uid=user.2,ou=People,dc=example,dc=com has the proxied-auth privilege and is granted proxy access by the ACI.
dn: ou=People,dc=example,dc=com objectClass: top objectClass: organizationalunit objectClass: posixGroup ou: People aci: (target="ldap:///uid=proxy user,ou=People,dc=example,dc=com") \ (targetattr="*") (version 3.0; acl "allow SASL Example"; \ allow (proxy) userdn="ldap:///uid=user.0,ou=People,dc=example,dc=com" || "ldap:///uid=user.2,ou=People,dc=example,dc=com";) dn: uid=user.0,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson uid=user.0 ... description: This is the description for user.0 dn: uid=user.1,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson uid=user.1 ... description: This is the description for user.1 ds-privilege-name: proxied-auth dn: uid=user.2,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson uid=user.2 ... description: This is the description for user.2 ds-privilege-name: proxied-auth dn: uid=proxy user,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson uid=proxy user ... description: This is the description for proxy user
Run this command to demonstrate a failing GSSAPI SASL bind using the Kerberos principal, user.0@TESTLOCAL.NET:
$ ldapsearch --port 1389 \ --saslOption mech=GSSAPI \ --saslOption authid=user.1@TESTLOCAL.NET \ --saslOption authzid=dn:uid=proxy user,ou=People,dc=example,dc=com \ --baseDN "" --searchScope base "(objectClass=*)" The SASL DIGEST-MD5 bind attempt failed Result Code: 49 (Invalid Credentials)
This search fails because user.0@TESTLOCAL.NET maps to uid=user.0,ou=People,dc=example,dc=com, which has the proxied-auth privilege but does not have access control permissions to uid=proxy user,ou=People,dc=example,dc=com.
Run this command to demonstrate a failing GSSAPI SASL bind using the Kerberos principal, user.1@TESTLOCAL.NET.
$ ldapsearch --port 1389 \ --saslOption mech=GSSAPI \ --saslOption authid=user.2@TESTLOCAL.NET \ --saslOption authzid=dn:uid=proxy user,ou=People,dc=example,dc=com \ --baseDN "" --searchScope base "(objectClass=*)" The SASL DIGEST-MD5 bind attempt failed Result Code: 49 (Invalid Credentials)
This search fails because user.1@TESTLOCAL.NET maps to uid=user.1,ou=People,dc=example,dc=com, which has access control permissions to uid=proxy user,ou=People,dc=example,dc=com but does not have the proxied-auth privilege.
Run this command to demonstrate a successful GSSAPI SASL bind using the Kerberos principal user.2@TESTLOCAL.NET:
$ ldapsearch --port 1389 \ --saslOption mech=GSSAPI \ --saslOption authid=user.0@TESTLOCAL.NET \ --saslOption authzid=dn:uid=proxy user,ou=People,dc=example,dc=com \ --baseDN "" --searchScope base "(objectClass=*)" dn: objectClass: ds-root-dse objectClass: top }}} \\ \\
This search succeeds because user.2@TESTLOCAL.NET maps to uid=user.2,ou=People,dc=example,dc=com, which has both the proxied-auth privilege and access control permission to id=proxy user,ou=People,dc=example,dc=com.