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.
- It must be possible to create aliases in the DB2 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 DB2 back end will attempt to open 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.