suggestion for locating master kdc logic

Will Fiveash will.fiveash at
Fri Apr 6 18:29:47 EDT 2012

On Fri, Apr 06, 2012 at 04:02:58PM -0400, Greg Hudson wrote:
> One possible concern is that KDC and kadmin servers do not necessarily
> operate on the default port.  For example, the realm configuration for a
> typical test case in our test suite looks like:
> 	kpasswd_server =
> 	admin_server =
> 	kdc =
> So where should the code assume the master KDC is?  Certainly not
>; we know that a kadmin server is running
> there.  If we assume, we'd break the cases in the
> test suite, which is a red flag that we might break some live
> configurations.  If we start matching the hostname of the admin server
> against the hostnames of the KDCs to find the port, that starts to feel
> complicated.

On the other hand, the current logic prevents configs like:

 	kdc =
 	admin_server =

from trying admin_server if slave-kdc returns an error on a AS/TGS_REQ
due to KDB propagation delay.  However, given the account lockout issue
in environments that enforce such a policy, I am less sure about
changing the default behavior to try admin/kpasswd_server if master_kdc
doesn't exist.

Mulling this over more, given this (the master_kdc change) is a change
to previously default behavior that some may be relying on, I think the
thing to do is introduce a new config parameter that allows the admin to
change the default behavior so that admin_server/kpasswd_server is not
used as a fall back when a krb error message is returned for a
AS/TGS_REQ.  Then those that found the default behavior objectionable
could change it.

BTW, if an admin did want fall back on krb error but required a
non-default port be used for the master kdc, they would have to specify

Will Fiveash
Oracle Solaris Software Engineer
Sent using mutt, a sweet, text based e-mail app <>

More information about the krbdev mailing list