Example of setting up a Kerberos directory
The following diagram shows an example of how you could set up a Kerberos directory.
Note: Because of space limitations in the diagram, the entries in
the example do not contain all the necessary information to make them
valid directory entries. For example, object classes and required
attributes have been left out of many of the entries.

Assume that Kerberos support has been enabled for this server, all backends have set krbIdentityMap to on, and the JEFF user ID has performed a kinit to acquire a Kerberos ticket before issuing the GSS API Kerberos bind.
The user JEFF with a Kerberos identity of jeff@IBM.COM is
performing a Kerberos GSS API Bind to an LDAP server which has been
configured with a TDBM backend, an LDBM backend, and an SDBM backend.
During the bind process the Kerberos identity jeff@IBM.COM by
default is mapped to ibm-kn=jeff@IBM.COM and this
value is added to the list of DNs that is used for access control.
After default mapping is performed, each of the backends attempt
to perform identity mapping:
- The LDBM backend first looks for the Kerberos realm object with
a
krbRealmName-V2=IBM.COMand does not find one. Now the backend attempts to find the entry that containsaltSecurityIdentities=KERBEROS:jeff@ibm.com. The entry with the DNcn=Jeff,o=IBM,c=USmatches this criteria and the DN is added to the alternate DN list. - Now the server moves on to the TDBM backend and tries to find
the Kerberos realm object with a
krbRealmName-V2=IBM.COM. This time the realm object is found so all the krbPrincSubtree values of the realm object are collected. Next, the server searches each of these subtrees (in this example, only theo=Lotus,c=USsubtree) for entries that containkrbPrincipalName=jeff@IBM.COM. In this backend the entrycn=Jeff,o=Lotus,c=USis found and is added to the DN list. Next the JEFF entry is checked for the krbAliasedObjectName attribute. There is a krbAliasedObjectName specified so authorization of the alias must be performed. The alias iscn=Tim,o=Lotus,c=USso the Tim entry must be checked for the attribute krbHintAliases with a value ofcn=Jeff,o=Lotus,c=US. This value does exist so the DNcn=Tim,o=Lotus,c=USis added to the access control DN list.Note: If the valuecn=Jeff,o=Lotus,c=USdid not exist in Tim's krbHintAliases, then Tim did not want you to be an alias, so the DNcn=Tim,o=Lotus,c=USwould not have been added to the DN list. - Finally, the server gets to the SDBM backend and invokes a RACF® API that attempts to map the
Kerberos identity
jeff@IBM.COMto its associated RACF ID. In this example, the API returns the JEFF user ID and the DNracfid=JEFF,profiletype=user,sysplex=plex1is constructed and added to the list of access control DNs.
ibm-kn=jeff@IBM.COM
cn=Jeff,o=IBM,c=US
cn=Jeff,o=Lotus,c=US
cn=Tim,o=Lotus,c=US
racfid=JEFF,profiletype=user,sysplex=plex1See Associating DNs, access groups, and additional bind and directory entry access information with a bound user for information about group gathering after
a successful bind. Now that
jeff@IBM.COM is bound to the server and
his list of alternate DNs has been generated, he now has authority
to perform other operations: - Because
jeff@IBM.COMwas mapped toibm-kn=jeff@IBM.COMhe has read and write permission to normal attributes in thecn=Scott,o=IBM,c=USentry. jeff@IBM.COMalso has read and write permission to the normal attributes in thecn=Ken,o=IBM,c=USentry because of his identity also being mapped tocn=Jeff,o=IBM,c=US.- Modify operations would be permitted on the
cn=Shayne,o=IBM,c=USentry sincejeff@IBM.COMwas also mapped tocn=Tim,o=Lotus,c=USand Tim has write access to Shayne. - Read access is also permitted on the
cn=Shayne,o=IBM,c=USentry becausejeff@IBM.COMwas mapped to the SDBM DN racfid=JEFF,profiletype=user,sysplex=plex1who has read permission to thecn=Shayne,o=IBM,c=USentry.