duplicate kdc settings in krb5.conf

Wang Weijun weijun.wang at oracle.com
Tue Feb 11 04:56:27 EST 2014


On Feb 11, 2014, at 0:21, Greg Hudson <ghudson at MIT.EDU> 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





More information about the krbdev mailing list