Problems with kprop and incremental propagation - works but bugs found

[Matej Zagiba]

Hi Jeremy,

if You configure/make/install kerberos with --prefix=/krb5, then default place for kdc configuration and database file is
/krb5/var/krb5kdc/ - so Your file paths are all default ones. Hence You don't need any workarounds.

On debian however, the policy is to place configuration files under /etc and database files under /var/lib/krb5kdc.
This requires explicit configuration in kdc.conf file (or krb5.conf, but that is non-intuitive) which is ignored
by kpropd when calling ulog_replay. In manual page only kdc.conf is mentioned as configuration file and -F option to
set principal database is documented, but none of it works with ulog_reply().


On 11/17/2010 01:24 AM, Jeremy Hunt wrote:
> Hi Greg,
>
> I don't know that your conclusions are necessarily true. I would say
> the only bug is that the location of the principal database (and
> therefore the location of kdc.conf) is not settable in krb5.conf. My
> point is that if you can override the kdc location in krb5.conf then
> you can put the correct subsection in the realms section of the
> kdc.conf and everything will work. Of course, if Matej had been able
> to set the location of his principal database in the krb5.conf file,
> then everything would work as he defined it from that file without
> reference to a kdc.conf file.
>
> I administer a more static domain than Matej, but I suspect that is
> irrelevant. I built my version of kerberos to use /krb5 as the
> containing directory for everything and configured incremental
> propagation entirely in kdc.conf. I needed none of the workarounds
> Matej did, my incremental propagation works seamlessly.
>
> To put this in perspective my realm is used correctly and so is
> Matej's now he has correctly defined his domain in the domain_realm
> section of krb5.conf. The location of my principal database is
> /krb5/var/krb5kdc, this is not a typical location.
>
> I put the directives as defined in the documentation in the
> subsection for my domain in the realms section of the kdc.conf file,
> and put the kdc.conf file in the same directory as the principal
> database. I built my kerberos by configuring with " --prefix=/krb5
> --exec-prefix=/krb5" which set @LOCALSTATEDIR+/krb5/var in the
> Makefile, this defines the location of my principal database as
> /krb5/var/krb5kdc.
>
> For what it is worth here is a sanitised version of my configuration,
> which works as advertised with no principal pathnames defined:
>
> /krb5/etc/krb5.conf
> --------------------------
> [libdefaults]
> #     irrelevant, except possibly this
>           default_realm = MYREALM.COM
>
> [appdefaults]
> #     irrelevant
>
> [realms]
> #      only relevant in it defines where propagation is from and to
>           MYREALM.COM = {
>                   kdc = kdc1
>                   kdc = kdc2
>                   admin_server = kdc1
> #              I am not advertising my password port here
>                   kpasswd_server = kdc1:myPasswdPort
>           }
>
> [domain_realm]
> #    The lines for my kdc systems probably set the realm correctly. this is satisfactory if you can do it this way.
> #    Matej's setting is more general, more elegant and entirely satisfactory,
> #    remember his settings were initially wrong and this was one of the causes of his problems
>          kdc1 = MYREALM.COM
>          kdc2 = MYREALM.COM
>          sys1 = MYREALM.COM
>          sys2 = MYREALM.COM
>          sys3 = MYREALM.COM
> #     etcetera
>
> [logging]
> #     irrelevant
>
> /krb5/var/krb5kdc/kdc.conf
> -------------------------------------
> [kdcdefaults]
> #     irrelevant
>
> [realms]
>           MYREALM.COM= {
> #              Left out irrelevant stuff in this email like principal flags and enctypes, ports, files used, etcetera
> #              From my build, the location of  kdc.conf is known
> #              The realm is referred to in this subsection.
> #              Incremental propagation is defined in the simplest way
> #              the principal database is found and the correct realm is used
>                   iprop_enable = true
>                   iprop_port = 2107
>           }
>
> [logging]
> #     irrelevant
>
> On 16/11/2010 11:14 AM, Greg Hudson wrote:
>> [safeTgram (safetgram-in) receive status: NOT encrypted, NOT signed.]
>>
>>
>> I can confirm two bugs that you have encountered and worked around:
>>
>> 1. kprop uses krb5_sname_to_principal() to determine its client
>> principal, and does not understand the referral realm.  So it does not
>> work without a -r parameter unless the profile's domain_realm section
>> can map the local hostname.  You worked around this by correcting your
>> existing domain_realm section in your profile.
>> A reasonable, if not perfect, fix here is to do what kpropd does in a
>> similiar piece of code: substitute the default realm for the referral
>> realm when using the result of krb5_sname_to_principal() as a client
>> principal.
>>
>> 2. kpropd, when processing incremental updates, modifies the KDB using
>> ulog_replay(), but does not initialize its context to use the KDC
>> profile, so it uses only settings from krb5.conf to find the KDB.  You
>> worked around this with symlinks.  An alternative workaround would be to
>> put the KDB configuration into krb5.conf instead of kdc.conf.  (In the
>> past, it used to be required to put KDB configuration into krb5.conf.
>> That odd requirement was relaxed somewhere around krb5 1.5 for most
>> programs which run on the KDC, but a few have escaped the net, including
>> kpropd.)
>>
>> I will open issues for both bugs and try to get them fixed for 1.9.
>> Thanks for your investigative work.
>>
>>
>> ________________________________________________
>> Kerberos mailing list           Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>
>
> --
>
> "The whole modern world has divided itself into Conservatives and
> Progressives. The business of Progressives is to go on making
> mistakes. The business of the Conservatives is to prevent the
> mistakes from being corrected." -- G. K. Chesterton
>