suggestion for locating master kdc logic

[Will Fiveash]

On Mon, Apr 09, 2012 at 08:16:53AM -0400, Sam Hartman wrote:
> So, whether to go to a master KDC is a realm property.  If your realm is
> multi-master or otherwise has fairly good replication (iprop with the
> default deflay doesn't count) then the master KDC concept is
> problematic.  Similarly, if different principals are homed at different
> KDCs, then master KDC doesn't make sense.
> 
> So, whether it makes sense to go to a master KDC is a property of a
> realm.

I agree.

> I don't think it makes sense to have a libdefault switch to set that
> behavior because there's no general default.

That's fine with me.

> So, I guess you could have a per-realm switch to specify whether to fall
> back to admin_server for that realm, but why not just specify the master
> KDC at that point.

My point is that Solaris has for a long time been falling back to
admin_server when a invalid password or princ not found error was
returned when the client sends a AS/TGS request to one of the KDCs
specified by the krb5.conf kdc parameter for the realm in use.

What I'm want is MIT and Solaris default behavior to be the same in this
regard.  To allow admins to control this behavior a new realm config
parameter could be introduced as I've described earlier.  I'm requesting
this so that existing krb configs that only contain kdc and admin_server
specifications will continue to provide expected behavior.  For those
that desire different behavior, they can either use the master_kdc
parameter (which should take precedence over admin_server for fall-back
on error) or they can use the new realm parameter, whatever it is named,
to prevent fall-back to admin_server.

Hopefully, if MIT agrees with the above then the Solaris and MIT krb
code bases can stay in sync in this area.

-- 
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/>