KRB5_425_CONV_PRINCIPAL(3) UNIX Programmer's Manual KRB5_425_CONV_PRINCIPAL(3) NNAAMMEE kkrrbb55__442255__ccoonnvv__pprriinncciippaall, kkrrbb55__442255__ccoonnvv__pprriinncciippaall__eexxtt, kkrrbb55__552244__ccoonnvv__pprriinncciippaall - converts to and from version 4 principals LLIIBBRRAARRYY Kerberos 5 Library (libkrb5, -lkrb5) SSYYNNOOPPSSIISS _k_r_b_5___e_r_r_o_r___c_o_d_e kkrrbb55__442255__ccoonnvv__pprriinncciippaall(_k_r_b_5___c_o_n_t_e_x_t _c_o_n_t_e_x_t, _c_o_n_s_t _c_h_a_r _*_n_a_m_e, _c_o_n_s_t _c_h_a_r _*_i_n_s_t_a_n_c_e, _c_o_n_s_t _c_h_a_r _*_r_e_a_l_m, _k_r_b_5___p_r_i_n_c_i_p_a_l _*_p_r_i_n_c_i_p_a_l) _k_r_b_5___e_r_r_o_r___c_o_d_e kkrrbb55__442255__ccoonnvv__pprriinncciippaall__eexxtt(_k_r_b_5___c_o_n_t_e_x_t _c_o_n_t_e_x_t, _c_o_n_s_t _c_h_a_r _*_n_a_m_e, _c_o_n_s_t _c_h_a_r _*_i_n_s_t_a_n_c_e, _c_o_n_s_t _c_h_a_r _*_r_e_a_l_m, _k_r_b_5___b_o_o_l_e_a_n _(_*_f_u_n_c_)_(_k_r_b_5___c_o_n_t_e_x_t_, _k_r_b_5___p_r_i_n_c_i_p_a_l_), _k_r_b_5___b_o_o_l_e_a_n _r_e_s_o_l_v_e, _k_r_b_5___p_r_i_n_c_i_p_a_l _*_p_r_i_n_c_i_p_a_l) _k_r_b_5___e_r_r_o_r___c_o_d_e kkrrbb55__552244__ccoonnvv__pprriinncciippaall(_k_r_b_5___c_o_n_t_e_x_t _c_o_n_t_e_x_t, _c_o_n_s_t _k_r_b_5___p_r_i_n_c_i_p_a_l _p_r_i_n_c_i_p_a_l, _c_h_a_r _*_n_a_m_e, _c_h_a_r _*_i_n_s_t_a_n_c_e, _c_h_a_r _*_r_e_a_l_m) DDEESSCCRRIIPPTTIIOONN Converting between version 4 and version 5 principals can at best be de- scribed as a mess. A version 4 principal consists of a name, an instance, and a realm. A version 5 principal consists of one or more components, and a realm. In some cases also the first component/name will differ between version 4 and version 5. Furthermore the second component of a host principal will be the fully qualified domain name of the host in question, while the in- stance of a version 4 principal will only contain the first part (short hostname). Because of these problems the conversion between principals will have to be site customized. kkrrbb55__442255__ccoonnvv__pprriinncciippaall__eexxtt() will try to convert a version 4 principal, given by _n_a_m_e, _i_n_s_t_a_n_c_e, and _r_e_a_l_m, to a version 5 principal. This can result in several possible principals, and if _f_u_n_c is non-NULL, it will be called for each candidate principal. _f_u_n_c should return true if the principal was ``good''. To accomplish this, kkrrbb55__442255__ccoonnvv__pprriinncciippaall__eexxtt() will look up the name in _k_r_b_5_._c_o_n_f. It first looks in the v4_name_convert/host subsection, which should contain a list of version 4 names whose instance should be treated as a hostname. This list can be specified for each realm (in the realms section), or in the libdefaults section. If the name is found the resulting name of the principal will be the value of this binding. The instance is then first looked up in v4_instance_convert for the specified realm. If found the resulting value will be used as instance (this can be used for special cases), no further attempts will be made to find a conversion if this fails (with _f_u_n_c). If the _r_e_s_o_l_v_e parameter is true, the instance will be looked up with ggeetthhoossttbbyynnaammee(). This can be a time consuming, error prone, and unsafe operation. Next a list of hostnames will be created from the instance and the v4_domains variable, which should contain a list of possible do- mains for the specific realm. On the other hand, if the name is not found in a host section, it is looked up in a v4_name_convert/plain binding. If found here the name will be converted, but the instance will be untouched. This list of default host-type conversions is compiled-in: v4_name_convert = { host = { ftp = ftp hprop = hprop imap = imap pop = pop rcmd = host smtp = smtp } } It will only be used if there isn't an entry for these names in the con- fig file, so you can override these defaults. kkrrbb55__442255__ccoonnvv__pprriinncciippaall() will call kkrrbb55__442255__ccoonnvv__pprriinncciippaall__eexxtt() with NULL as _f_u_n_c, and the value of v4_instance_resolve (from the libdefaults section) as _r_e_s_o_l_v_e. kkrrbb55__552244__ccoonnvv__pprriinncciippaall() basically does the opposite of kkrrbb55__442255__ccoonnvv__pprriinncciippaall(), it just doesn't have to look up any names, but will instead truncate instances found to belong to a host principal. The _n_a_m_e, _i_n_s_t_a_n_c_e, and _r_e_a_l_m should be at least 40 characters long. EEXXAAMMPPLLEESS Since this is confusing an example is in place. Assume that we have the ``foo.com'', and ``bar.com'' domains that have shared a single version 4 realm, FOO.COM. The version 4 _k_r_b_._r_e_a_l_m_s file looked like: foo.com FOO.COM .foo.com FOO.COM .bar.com FOO.COM A _k_r_b_5_._c_o_n_f file that covers this case might look like: [libdefaults] v4_instance_resolve = yes [realms] FOO.COM = { kdc = kerberos.foo.com v4_instance_convert = { foo = foo.com } v4_domains = foo.com } With this setup and the following host table: foo.com a-host.foo.com b-host.bar.com the following conversions will be made: rcmd.a-host -> host/a-host.foo.com ftp.b-host -> ftp/b-host.bar.com pop.foo -> pop/foo.com ftp.other -> ftp/other.foo.com other.a-host -> other/a-host The first three are what you expect. If you remove the ``v4_domains'', the fourth entry will result in an error (since the host ``other'' can't be found). Even if ``a-host'' is a valid host name, the last entry will not be converted, since the ``other'' name is not known to represent a host-type principal. If you turn off ``v4_instance_resolve'' the second example will result in ``ftp/b-host.foo.com'' (because of the default do- main). And all of this is of course only valid if you have working name resolving. SSEEEE AALLSSOO krb5_build_principal(3), krb5_free_principal(3), krb5_parse_name(3), krb5_sname_to_principal(3), krb5_unparse_name(3), krb5.conf(5) HEIMDAL April 11, 1999 3