Configuring SASL Authentication

This section describes the requirements for configuring directory server to use the various SASL authentication mechanisms.

Configuring SASL External Authentication

The SASL EXTERNAL mechanism is used to allow a client to authenticate itself to the directory server using information provided outside of what is strictly considered LDAP communication. The directory server currently supports authentication using a client certificate presented to the server during SSL or StartTLS negotiation, for LDAP communication only.

Configuring the LDAP Connection Handler to Allow SASL EXTERNAL Authentication

For the directory server to be able to map the client certificate to a user entry, ensure that the connection handler is configured to handle client certificates. Use the dsconfig to set the following LDAP connection handler properties:

• ssl-client-auth-policy. Specifies whether the directory server prompts the client to present its own certificate during the SSL or StartTLS negotiation process. To support SASL EXTERNAL authentication, the value must be either optional or required. If the value is disabled, clients are not prompted to provide a certificate and no certificate is available for authentication.

• trust-manager-provider. Specifies the DN of the trust manager provider used to determine whether the directory server trusts the validity of the client certificate. If the directory server does not trust the client certificate, the SSL or StartTLS negotiation fails and it is not possible for the client to request SASL EXTERNAL authentication. If the directory server trusts illegitimate client certificates, it is possible for malicious users to forge certificates and impersonate any user in the directory. In most cases, the JKS or PKCS12 trust manager provider should be used and the corresponding trust store loaded only with the issuer certificates that are used to sign client certificates.

The following example uses dsconfig to set LDAP connection handler properties:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager"-w password -X -n \
  set-connection-handler-prop --handler-name "LDAP Connection Handler"

Configuring the EXTERNAL SASL Mechanism Handler

SASL EXTERNAL bind requests are processed by the SASL mechanism handler. Use the dsconfig command to set the following SASL mechanism handler properties:

• java-class. Specifies the fully-qualified name of the Java class that provides the logic for the SASL mechanism handler. For the EXTERNAL mechanism, this value is always org.opends.server.extensions.ExternalSASLMechanismHandler. An advanced property.

• enabled. Indicates whether the EXTERNAL SASL mechanism is enabled for use in the directory server. If you do not want to allow clients to use SASL EXTERNAL authentication, change its value to false.

• certificate-mapper. Specifies the DN of the configuration entry for the certificate mapper to be used to map client certificates to user entries.

• certificate-validation-policy. Specifies whether the directory server attempts to locate the client certificate in the user's entry after establishing a mapping. If the value is always, the authentication succeeds only if the mapped user's entry contains the certificate presented by the client. If the value is ifpresent (the default value) and the user's entry contains one or more certificates, the authentication succeeds only if one of those certificates matches the one presented by the client. If the value is ifpresent and the user's entry does not contain any certificates, the authentication still succeeds based on the fact that it would have been accepted by the trust manager and mapped by the certificate mapper. If the value is never, the server does not attempt to match the certificate to a value in the user's entry even if that entry contains one or more certificates.

• certificate-attribute. Specifies the name of the attribute that holds user certificates to be examined if the certificate-validation-policy property has a value of either always or ifpresent.

The following example uses dsconfig to set EXTERNAL SASL mechanism handler properties:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager"-w password -X -n \
  set-sasl-mechanism-handler-prop --handler-name "EXTERNAL" --advanced 

Configuring SASL DIGEST-MD5 Authentication

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.

1. 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

2. 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.

3. 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.

4. 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.

Configuring SASL GSSAPI Authentication

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.

1. Create three Kerberos principals in the realm TESTLOCAL.NET:

   • user.0@TESTLOCAL.NET

   • user.1@TESTLOCAL.NET

   • user.2@TESTLOCAL.NET

2. 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.

3. 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

4. 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.

5. 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.

6. 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.