Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section of Man Page:
Select Man Page Repository:

NetBSD 6.1.5 - man page for krb5_524_conv_principal (netbsd section 3)

KRB5_425_CONV_PRINCIPAL(3)	   BSD Library Functions Manual        KRB5_425_CONV_PRINCIPAL(3)

     krb5_425_conv_principal, krb5_425_conv_principal_ext, krb5_524_conv_principal -- converts to
     and from version 4 principals

     Kerberos 5 Library (libkrb5, -lkrb5)

     #include <krb5/krb5.h>

     krb5_425_conv_principal(krb5_context context, const char *name, const char *instance,
	 const char *realm, krb5_principal *principal);

     krb5_425_conv_principal_ext(krb5_context context, const char *name, const char *instance,
	 const char *realm, krb5_boolean (*func)(krb5_context, krb5_principal),
	 krb5_boolean resolve, krb5_principal *principal);

     krb5_524_conv_principal(krb5_context context, const krb5_principal principal, char *name,
	 char *instance, char *realm);

     Converting between version 4 and version 5 principals can at best be described 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
     instance 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.

     krb5_425_conv_principal_ext() will try to convert a version 4 principal, given by name,
     instance, and realm, to a version 5 principal. This can result in several possible princi-
     pals, and if func is non-NULL, it will be called for each candidate principal.  func should
     return true if the principal was ``good''.  To accomplish this,
     krb5_425_conv_principal_ext() will look up the name in krb5.conf.	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 func).  If the resolve parameter is true, the instance will
     be looked up with gethostbyname().  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 domains 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 config file, so you can
     override these defaults.

     krb5_425_conv_principal() will call krb5_425_conv_principal_ext() with NULL as func, and the
     value of v4_instance_resolve (from the libdefaults section) as resolve.

     krb5_524_conv_principal() basically does the opposite of krb5_425_conv_principal(), it just
     doesn't have to look up any names, but will instead truncate instances found to belong to a
     host principal. The name, instance, and realm should be at least 40 characters long.

     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 ver-
     sion 4 realm, FOO.COM. The version 4 krb.realms file looked like:

	   foo.com	   FOO.COM
	   .foo.com	   FOO.COM
	   .bar.com	   FOO.COM

     A krb5.conf file that covers this case might look like:

		   v4_instance_resolve = yes
		   FOO.COM = {
			   kdc = kerberos.foo.com
			   v4_instance_convert = {
				   foo = foo.com
			   v4_domains = foo.com

     With this setup and the following host table:

     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 domain). And all of this is of
     course only valid if you have working name resolving.

     krb5_build_principal(3), krb5_free_principal(3), krb5_parse_name(3),
     krb5_sname_to_principal(3), krb5_unparse_name(3), krb5.conf(5)

BSD					September 3, 2003				      BSD

All times are GMT -4. The time now is 08:00 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password