First, Kerberos 4 and Kerberos 5 principals are different. A version 4 principal consists of a name, an instance, and a realm. A version 5 principal has one or more components, and a realm (the terms “name” and “instance” are still used, for the first and second component, respectively). Also, in some cases the name of a version 4 principal differs from the first component of the corresponding version 5 principal. One notable example is the “host” type principals, where the version 4 name is ‘rcmd’ (for “remote command”), and the version 5 name is ‘host’. For the class of principals that has a hostname as instance, there is an other major difference, Kerberos 4 uses only the first component of the hostname, whereas Kerberos 5 uses the fully qualified hostname.
Because of this it can be hard or impossible to correctly convert a version 4 principal to a version 5 principal 1. The biggest problem is to know if the conversion resulted in a valid principal. To give an example, suppose you want to convert the principal ‘rcmd.foo’.
The ‘rcmd’ name suggests that the instance is a hostname (even if there are exceptions to this rule). To correctly convert the instance ‘foo’ to a hostname, you have to know which host it is referring to. You can to this by either guessing (from the realm) which domain name to append, or you have to have a list of possible hostnames. In the simplest cases you can cover most principals with the first rule. If you have several domains sharing a single realm this will not usually work. If the exceptions are few you can probably come by with a lookup table for the exceptions.
In a complex scenario you will need some kind of host lookup mechanism. Using DNS for this is tempting, but DNS is error prone, slow and unsafe 2.
Fortunately, the KDC has a trump on hand: it can easily tell if a
principal exists in the database. The KDC will use
krb5_425_conv_principal_ext
to convert principals when handling
to version 4 requests.