Hi Jeremy,
well, problem is not location of kdc.conf, kpropd can find kdc.conf just fine.
Problem is, when principal database is in non-standart location. Actually,
kprpod reads and uses settings from kdc.conf
when it does check for last serial and timestamp, but does not use this values
when calling ulog_replay().
And as Greg pointed out, putting database_name = /var/lib/krb5kdc/principal
directive (or whole kdc configuration)
to realms section in krb5.conf solves the problem too.
Anyway, this shoud not be hard to fix, so I will look forward to 1.9 release
(and may be debian will port the patch to 1.8.3)
On 11/19/2010 12:14 AM, Jeremy Hunt wrote:
> 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 [email protected]
>>>> 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 [email protected]
>> 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 [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
