duplicate kdc settings in krb5.conf

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

duplicate kdc settings in krb5.conf

Weijun Wang
My main krb5.conf is

 include /etc/u
 [libdefaults]
 default_realm = D1.LOCAL

 [realms]
 D1.LOCAL = {
   kdc = kdc1
 }

and /etc/u is

 [realms]
 D1.LOCAL = {
   kdc = kdc2
 }

and kinit uses kdc2 as the KDC.

The same is observed if I just include the content of /etc/u inside krb5.conf.

Why is it designed this way? Shouldn't the latecomer override the old one? Or, nobody should ever write this (or these) files so this is just a "undefined" behavior?

Thanks
Max


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: duplicate kdc settings in krb5.conf

Greg Hudson
On 02/10/2014 03:01 AM, Wang Weijun wrote:
> Why is it designed this way? Shouldn't the latecomer override the old one? Or, nobody should ever write this (or these) files so this is just a "undefined" behavior?

The profile library is designed so that keys can have multiple values.
In your example, {realms, D1.LOCAL, kdc} has two values, kdc2 and kdc1,
and those will be contacted in order.

For most keys like allow_weak_crypto or kdc_timesync, only one value
will be used.  Usually the first definition wins, *unless* the value was
retrieved through libkadm5, in which case the last definition
wins--presumably because whoever wrote that library thought, as you did,
that latecomers should be able to override earlier definitions.  But the
inconsistent application of this principle renders it more of a design
annoyance than a useful feature.  And of course, even if we always used
the last value for single-valued keys, that wouldn't provide a way to
override the values of multi-valued keys like "kdc".

For administrators and users, the best practice in the face of this
inconsistency is not to assume any kind of override functionality in the
profile library, and only specify values for a particular key in one place.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: duplicate kdc settings in krb5.conf

Weijun Wang

On Feb 11, 2014, at 0:21, Greg Hudson <[hidden email]> wrote:

> On 02/10/2014 03:01 AM, Wang Weijun wrote:
>> Why is it designed this way? Shouldn't the latecomer override the old one? Or, nobody should ever write this (or these) files so this is just a "undefined" behavior?
>
> The profile library is designed so that keys can have multiple values.
> In your example, {realms, D1.LOCAL, kdc} has two values, kdc2 and kdc1,
> and those will be contacted in order.

If they are defined in a single sub-stanza, for example

[realms]
D1 = {
   kdc = k1
   kdc = k2
}

then both will be contacted, but if it's two different sub-stanza or stanza (could be in the same or different files), then only the first one will be picked up. For example, only k1 will be contacted for

[realms]
D1 = {
   kdc = k1
}
D1 = {
   kdc = k2
}

or

[realms]
D1 = {
   kdc = k1
}
[realms]
D1 = {
   kdc = k2
}

> For most keys like allow_weak_crypto or kdc_timesync, only one value
> will be used.  Usually the first definition wins, *unless* the value was
> retrieved through libkadm5, in which case the last definition
> wins--presumably because whoever wrote that library thought, as you did,
> that latecomers should be able to override earlier definitions.  But the
> inconsistent application of this principle renders it more of a design
> annoyance than a useful feature.  And of course, even if we always used
> the last value for single-valued keys, that wouldn't provide a way to
> override the values of multi-valued keys like "kdc".
>
> For administrators and users, the best practice in the face of this
> inconsistency is not to assume any kind of override functionality in the
> profile library, and only specify values for a particular key in one place.

Sure.

Thanks
Max



_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: duplicate kdc settings in krb5.conf

Greg Hudson
On 02/11/2014 04:56 AM, Wang Weijun wrote:
> then both will be contacted, but if it's two different sub-stanza or stanza (could be in the same or different files), then only the first one will be picked up. For example, only k1 will be contacted for
>
> [realms]
> D1 = {
>    kdc = k1
> }
> D1 = {
>    kdc = k2
> }

I think that's a bug.  If I trace through the profile code, it winds up
creating a second subsection node for D1 within [realms], which is
inaccessible to searches.

By contrast, if you specify a top-level stanza (like [realms]) multiple
times, the relations within (directly within, not inside subsections)
get placed in the same top-level section node.

I'll open a ticket if I don't find an existing one.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: duplicate kdc settings in krb5.conf

Weijun Wang

On Feb 12, 2014, at 10:56, Greg Hudson <[hidden email]> wrote:

> On 02/11/2014 04:56 AM, Wang Weijun wrote:
>> then both will be contacted, but if it's two different sub-stanza or stanza (could be in the same or different files), then only the first one will be picked up. For example, only k1 will be contacted for
>>
>> [realms]
>> D1 = {
>>   kdc = k1
>> }
>> D1 = {
>>   kdc = k2
>> }
>
> I think that's a bug.

Oh, I thought that was by design.

My understanding was that the top-level stanzas should be merged (I can imagine people have [libdefaults] in both krb5.conf and an included file) but not the others. While it's OK to merge (or not merge) the kdc settings above but if it's [capaths] the merge will be a disaster.

--Max

>  If I trace through the profile code, it winds up
> creating a second subsection node for D1 within [realms], which is
> inaccessible to searches.
>
> By contrast, if you specify a top-level stanza (like [realms]) multiple
> times, the relations within (directly within, not inside subsections)
> get placed in the same top-level section node.
>
> I'll open a ticket if I don't find an existing one.


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev