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.
Figure 1. Kerberos directory example

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:
  1. The LDBM backend first looks for the Kerberos realm object with a krbRealmName-V2=IBM.COM and does not find one. Now the backend attempts to find the entry that contains altSecurityIdentities=KERBEROS:jeff@ibm.com. The entry with the DN cn=Jeff,o=IBM,c=US matches this criteria and the DN is added to the alternate DN list.
  2. 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 the o=Lotus,c=US subtree) for entries that contain krbPrincipalName=jeff@IBM.COM. In this backend the entry cn=Jeff,o=Lotus,c=US is 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 is cn=Tim,o=Lotus,c=US so the Tim entry must be checked for the attribute krbHintAliases with a value of cn=Jeff,o=Lotus,c=US. This value does exist so the DN cn=Tim,o=Lotus,c=US is added to the access control DN list.
    Note: If the value cn=Jeff,o=Lotus,c=US did not exist in Tim's krbHintAliases, then Tim did not want you to be an alias, so the DN cn=Tim,o=Lotus,c=US would not have been added to the DN list.
  3. Finally, the server gets to the SDBM backend and invokes a RACF® API that attempts to map the Kerberos identity jeff@IBM.COM to its associated RACF ID. In this example, the API returns the JEFF user ID and the DN racfid=JEFF,profiletype=user,sysplex=plex1 is constructed and added to the list of access control DNs.
At this point, the bind has completed and the list of DNs that is used for access control is as follows:
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=plex1
See 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.COM was mapped to ibm-kn=jeff@IBM.COM he has read and write permission to normal attributes in the cn=Scott,o=IBM,c=US entry.
  • jeff@IBM.COM also has read and write permission to the normal attributes in the cn=Ken,o=IBM,c=US entry because of his identity also being mapped to cn=Jeff,o=IBM,c=US.
  • Modify operations would be permitted on the cn=Shayne,o=IBM,c=US entry since jeff@IBM.COM was also mapped to cn=Tim,o=Lotus,c=US and Tim has write access to Shayne.
  • Read access is also permitted on the cn=Shayne,o=IBM,c=US entry because jeff@IBM.COM was mapped to the SDBM DN racfid=JEFF,profiletype=user,sysplex=plex1 who has read permission to the cn=Shayne,o=IBM,c=US entry.
You can see from this example that your access control is based on the combination of all the mapped DN’s access control permissions.