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