12.2. SASL Identity Mapping

When processing a SASL bind request, the server matches, or maps, the SASL authentication ID used to authenticate to the Directory Server with an LDAP entry stored within the server. When using Kerberos, the SASL user ID usually has the format userid@REALM, such as scarter@EXAMPLE.COM. This ID must be converted into the DN of the user's Directory Server entry, such as uid=scarter,ou=people,dc=example,dc=com.

If the authentication ID clearly corresponds to the LDAP entry for a person, it is possible to configure the Directory Server to map the authentication ID automatically to the entry DN. Directory Server has some preconfigured default maps which handle most common configurations, and customized maps can be created. During a bind attempt, the first matching mapping rule is applied. If only one user identity is returned, the bind is successful; if none or more than one are returned, then the bind fails. Red Hat recommends configuring SASL maps so that only one mapping rule matches the authentication string.

NOTE

SASL proxy authorization is not supported in Directory Server; therefore, Directory Server ignores any SASL authzid value supplied by the client.

SASL is configured by entries under a container entry:

dn: cn=sasl,cn=config
objectClass: top
objectClass: nsContainer
cn: sasl

SASL identity mapping entries are children of this entry:

dn: cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsContainer
cn: mapping

Mapping entries contain three attributes, nsSaslMapRegexString, nsSaslMapBaseDNTemplate, and nsSaslMapFilterTemplate. The nsSaslMapping object class sets these identity mapping parameters.

The nsSaslMapRegexString attribute sets variables of the form \1, \2, \3, as in the example, for bind IDs which are filled into the template attributes during a search. For example, this sets up nsSaslMapping:

dn: cn=mymap,cn=mapping,cn=sasl,cn=config
objectclass:top
objectclass:nsSaslMapping
cn: mymap
nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
nsSaslFilterTemplate: (objectclass=inetOrgPerson)
nsSaslBaseDNTemplate: uid=\1,ou=people,dc=\2,dc=\3

When a Directory Server receives a SASL bind request with mconnors@EXAMPLE.COM as the user ID (authid), the regular expression would fill in the base DN template with uid=mconnors,ou=people,dc=EXAMPLE,dc=COM as the user ID, and authentication would proceed from there.

NOTE

The dc values are not case sensitive, so dc=EXAMPLE and dc=example are equivalent.

The Directory Server can also use a broader mapping scheme, such as the following:

objectclass: top
objectclass: nsSaslMapping
cn: mymap2
nsSaslMapRegexString: \(.*\)
nsSaslMapBaseDNTemplate: ou=People,dc=example,dc=com
nsSaslMapFilterTemplate: (cn=\1)

This will match any user ID and map to the result of the the subtree search with base ou=People,dc=example,dc=com and filter cn=userId.

The Directory Server has pre-defined SASL mapping rules to handle some of the most common cases:

Kerberos UID Mapping. This mapping matches a Kerberos principal using a two part realm, such as user@example.com. The realm is then used to define the search base, and the authid defines the filter. In this example, the search base would be dc=example,dc=com and the filter of (uid=user).
RFC 2829 DN Syntax. This mapping matches an authid that is a valid DN (defined in RFC 2829) prefixed by dn:. The authid maps directly to the specified DN.
RFC 2829 U Syntax. This mapping matches an authid that is a UID prefixed by u:. The value specified after the prefix defines a filter of (uid=value). The search base is hard-coded to be the suffix of the default userRoot database.
uid Mapping. This mapping matches an authid that is any plain string that does not match the other default mapping rules. It use this value to define a filter of (uid=value). The search base is hard-coded to be the suffix of the default userRoot database.