From K5Wiki
Jump to: navigation, search
This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

Currently the MIT KDC implementation contains support for name canonicalization; however, neither of the shipped back ends has any support for aliases or principal name transformation on lookup. This project will implement very basic read-only alias support for the DB2 back end. The primary use case for this feature is servers with more than one hostname. Case folding and other transformations of principal names are out of scope. Management and propagation of aliases is out of scope.

Functional Requirements

  • It must be possible to create aliases in the DB2 and LDAP back end such that looking up the alias produces the entry for the canonical name.
  • It must be possible to synchronize aliases for host principals with an outside source of information such as a DNS zone file.


  • The LDAP back end will support a new attribute, krbCanonicalName, which determines which of several krbPrincipalNames is canonical. If this attribute is set and does not match the searched-for principal name, then the entry is returned only if canonicalization was requested, and is returned with the canonical name.
  • The DB2 back end will attempt to read an existing database named with ".alias" appended to the base DB name. If this database does not exist, it will be assumed that there are no aliases.
  • The alias database will map alias principal names to canonical principal names (with realms, in both cases). In order to facilitate automatic generation of the alias database, there will be no flags or extensibility fields in the values.
  • krb5_db2_db_get_principal will, on failure to find the principal in the main database, consult the alias database and try to canonicalize the principal name. If successful, it will look up the canonical name in the main database.
  • There will be no changes to the delete-principal or iterate operations. Aliases do not exist from their point of view.
  • If necessary, a short C program will be provided to manipulate the alias database. (Investigate whether this is possible with Perl's DB_File or with Python in a manner compatible with Kerberos.)
  • A sample script, or feature of the short C program, will be provided to synchronize an alias database with the CNAME entries from a BIND zone file.