Problems with kprop and incremental propagation - works but bugs found
Jeremy Hunt
jeremyh at optimation.com.au
Thu Nov 18 18:14:46 EST 2010
Hi Matej,
You are right, we agree.
Because my kdc is in the default location everything is found, including the kdc.conf which is in the same location as the kdc. This means having a kdc location directive in the kdc.conf file is a circular reference.
As I said in the my last email, the real bug/improvement is for the kdc location to be defined in the krb5.conf file. You are correct in that this definition should be referred to by all kerberos daemons and be a default or command line value otherwise.
If this was the case then debian packages could include the location of the kdc in the krb5.conf file and it would not need to be intuitive.
Regards,
Jeremy
On 18/11/2010 8:21 PM, Matej Zagiba wrote:
> [safeTgram (safetgram-in) receive status: NOT encrypted, NOT signed.]
>
>
> 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
>>
> ________________________________________________
> 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
More information about the Kerberos
mailing list