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 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
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, these restrictions do not apply. Any user that binds using DIGEST-MD5 and the authzid keyword 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 and demonstrates the requirements for user authentication using the DIGEST-MD5 SASL mechanism.
The following example creates a test environment and then demonstrates the requirements for a user authentication using the DIGEST-MD5 SASL mechanism.
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 ... 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 ... description: This is the description for user.1 ds-privilege-name: proxied-auth dn: uid=proxy user,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson ... description: This is the description for proxy user dn: uid=user.2,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson ... description: This is the description for user.2 ds-privilege-name: proxied-auth
Bind using DIGEST-MD5 as uid=user.1,ou=People,dc=example,dc=com:
$ ldapsearch --port 1389 -w password --saslOption mech=DIGEST-MD5 \ --saslOption authid=dn:uid=user.1,ou=People,dc=example,dc=com --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)
The search fails because uid=user.1,ou=People,dc=example,dc=com is not granted the proxy right by the ACI.
Bind using DIGEST-MD5 as uid=user.0,ou=People,dc=example,dc=com:
$ ldapsearch --port 1389 -w password --saslOption mech=DIGEST-MD5 \ --saslOption authid=dn:uid=user.0,ou=People,dc=example,dc=com --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)
The search fails because uid=user.0,ou=People,dc=example,dc=com does not have the proxied-authproperty.
Bind using DIGEST-MD5 as uid=user.2,ou=People,dc=example,dc=com authid with both access control access and the proxied-auth privilege:
$ ldapsearch --port 1389 -w password --saslOption mech=DIGEST-MD5 \ --saslOption authid=dn:uid=user.2,ou=People,dc=example,dc=com --saslOption \ authzid=dn:uid=proxy user,ou=People,dc=example,dc=com --baseDN "" \ --searchScope base "(objectClass=*)" dn: objectClass: ds-root-dse objectClass: top
The search succeeds because uid=user.2,ou=People,dc=example,dc=com has access allowed by the ACI and the proxied-auth privilege.