Identity mapping for Kerberos

Edit online

With identity mapping, the directory administrator can use the existing set of ACL data with the Kerberos authentication method.

The ACL for IBM® Verify Directory is based on the distinguished name (DN) assigned to the client connected to the directory server. The access rights are based on the permissions that are granted for that DN and the permissions for any groups with that DN as a member. If the bind method for GSSAPI is used (that is, Kerberos is used for authenticating to the server), the DN is something like IBM-KN=your_principal@YOUR_REALM_NAME. This type of DN can be used as members of access groups or access IDs. You can also use the Kerberos Identity Mapping feature to grant access rights for this DN to an entry already in the directory.

For example, if there is an entry in the directory for Reginald Bender.
dn: cn=Reginald Bender, ou=internal users, o=ibm.com, c=US
objectclass: top
objectclass: person
objectclass: organizationalperson
cn: Reginald Bender
sn: Bender
aclentry: access-id:CN=THIS:critical:rwsc
aclentry: group:CN=ANYBODY:normal:rsc
userpassword: cL1eNt

The access rights for this entry allow anyone binding with the DN cn=Reginald Bender, ou=internal users, o=ibm.com, c=US to view critical data such as the password, but no one else.

If Reginald Bender used Kerberos to bind to the server, the DN can be something like IBM-KN=rbender@SW.REALM_1. If identity mapping is not enabled on the server, the user is not allowed to view the entry's password.

If identity mapping is enabled, the user can view the password if this entry were changed to include: 
dn: cn=Reginald Bender, ou=internal users, o=ibm.com, c=US...
objectclass: ibm-securityidentities
altsecurityidentities: Kerberos:rbender@SW.REALM_1
When Reginald Bender binds to the directory server, the server first searches the whole directory to determine whether the directory is a KDC (Key Distribution Center) account registry. If it is not, the server searches the directory for any entry with an altsecurityidentities attribute with a value that matches the Kerberos user principal and realm. In this example, rbender is the user principal and SW.REALM_1 is the realm. This value is the default for the Kerberos identity mapping. The bind fails if more than one entry has an attribute with this value. The mapping must be one-to-one. If the mapping is successful, Reginald Bender has all of the access rights for cn=Reginald Bender, ou=internal users, o=ibm.com, c=US, including any access groups with this value as a member.

IBM Security Directory Server can be used to contain Kerberos account information (krbRealmName-V2 =realm_name and krbPrincipalName = princ_name@realm_name) to serve as the backing store for a KDC.

The server with Kerberos identity mapping enabled first searches the directory for entries with objectclass krbRealm-V2 and krbRealmName-V2=realm_name, such as,
dn: krbRealmName-V2=SW.REALM_1, o=ibm.com, c=US
objectclass:krbRealm-V2
krbReamlName-V2: SW.REALM_1
If no entries are found, the server uses the default Kerberos identity mapping that is described previously. If more than one entry is found, the bind fails.
However, if the directory contains the single entry. 
dn: krbRealmName-V2=SW.REALM_1, ou=Group, o=ibm.com, c=US
objectclass:krbRealm-V2
krbRealmName-V2: SW.REALM_1
krbPrincSubtree: ou=internal users,o=ibm.com, c=US
krbPrincSubtree: ou=external users,o=ibm.com, c=US
The server searches each subtree that is listed as a value of krbPrincSubtree for an entry with an attribute krbPrincipalName.
In this release, for identity mapping to work for Reginald Bender, you need to add two attributes to the cn=Reginal Bender, ou=internal users, o=ibm.com, c=US entry: 
objectclass: extensibleObject
krbPrincipalName: rbender@SW.REALM_1
Depending on whether the directory is a KDC account registry, the final entry is, 
dn: cn=Reginald Bender, ou=internal users, o=ibm.com, c=US...
objectclass: ibm-securityidentities
altsecurityidentities: Kerberos:rbender@SW.REALM_1...
or for a KDC account registry: 
dn: cn=Reginald Bender, ou=internal users, o=ibm.com, c=US ...
objectclass: extensibleObject
krbPrincipalName: rbender@SW.REALM_1

In either case, the client is mapped to cn=Reginald Bender, ou=internal users, o=ibm.com, c=US.

If a DN is not mapped because no entry is found, the mapping fails but the bind is still successful. However, if more than one DN is mapped, the bind fails.

Identity mapping enables the existing ACLs to work with Kerberos authentication. A client that uses Kerberos with a mapped identity has two distinct identities, both of which are evaluated in granting access.

Identity mapping has some costs. The internal searches at bind time impact performance and identity mapping requires extra setup to add the appropriate attributes to the entries to be mapped.

In this release, if default identity mapping is used, the administrator (either Kerberos or LDAP) must make sure that the data in the KDC and the data in the LDAP server are synchronized. If the data is not synchronized, incorrect results might be returned because of incorrect ACL evaluation.

Note: The object class, such as KrbPrincipal and the attributes such as KrbPrincSubtree, KRbAliasedObjectName, and KrbHintAliases are used to define an IBM Directory as a Kerberos KDC. See the Kerberos documentation for more information.