suggestion for locating master kdc logic

Will Fiveash will.fiveash at oracle.com
Fri Apr 6 15:53:04 EDT 2012


On Thu, Apr 05, 2012 at 11:25:05PM -0400, Greg Hudson wrote:
> On 04/05/2012 07:53 PM, Will Fiveash wrote:
> > Anyone have a problem if I modify the MIT krb code so that if a
> > master_kdc spec is not found to then look for admin_server and if that
> > isn't found also look for kpasswd_server?  This change would affect
> > dns_locate_server() and prof_locate_server().
> 
> I'm always a little nervous about reversing previous design decisions
> that I don't completely understand.  I can find a little bit of design
> rationale in ticket #1692, which says:
> 
>     Currently the admin_server tag is overloaded for kadmin and
>     password changing.  So, don't use it as a filter on the KDC list;
>     instead, look for master_kdc as an independent list.
> 
> I'm not quite sure what Ken had in mind here.  I can speculate that he
> was concerned about environments where the kadmin or kpasswd server host
> doesn't run a KDC, in which case trying to contact it would result in an
> unwelcome timeout.

I assuming that in the vast majority of krb deployments if admin_server
is set then it is set to the master KDC and that the admins of such
deployments would want the master KDC fall back logic to be:
master_kdc -> admin_server -> kpasswd_server

Certainly for Solaris, we have not documented master_kdc so I'm pretty
sure most if not all krb configs on those systems are not benefiting
from the fall back to master_kdc when getting a krb err.

I suggest introduction of new config parameter, try_admin_server_on_err
(or something like that), that if true would allow using admin_server or
kpasswd_server if master_kdc was not specified as a fall back when a krb
error is received.  If false, only the master_kdc would be used.  It
should be true by default.

-- 
Will Fiveash
Oracle Solaris Software Engineer
http://opensolaris.org/os/project/kerberos/
Sent using mutt, a sweet, text based e-mail app <http://www.mutt.org/>


More information about the krbdev mailing list