suggestion for locating master kdc logic

[Jeffrey Altman]

kdc_master was added to MIT kerberos because of real world deployment
problems.  It is not not true that every machine that hosts a kadmind is
in fact a KDC that should be treated as a KDC with an up to date KDB
or vice-versa.  In a world with an LDAP backend or any multi-master 
database
as the backend, every KDC can potentially be a master even though only 
one
machine may host kadmind (or none in the case of Active Directory).

kdc_master is less about deciding where to fallback to; it is primarily 
a
determination of whether or not a fallback should occur at all.

In my opinion, the Solaris team should fix their distribution to
support kdc_master and provide a krb5 profile parsing tool that is run
at system startup which writes a warning to syslog() if 'kdc_master'
is not provided for a realm either within the krb5.conf or via DNS SRV
records.

If the Solaris team is especially aggressive, they could add a 
kdc_master
entry that matches the kadmin_server entry within the krb5.conf.

I do not believe that MIT should change the Kerberos distribution 
behavior
8 years later simply because one vendor decided not to support the 
change.
I agree that all Kerberos distributions should parse the krb5 profile 
and
interpret it the same way.  However, absent a standard, the MIT 
distribution
is the reference and everyone else should follow it.

On Monday, April 09, 2012 6:28:51 PM, Will Fiveash wrote:
> On Mon, Apr 09, 2012 at 05:46:04PM -0400, Sam Hartman wrote:
>>>>>>> "Tom" == Tom Yu <tlyu at MIT.EDU> writes:
>>
>>     Tom> Sam Hartman <hartmans at MIT.EDU> writes:
>>     >> I also think it would be reasonable to consider an argument that
>>     >> the default user experience for most installations of MIT
>>     >> Kerberos will be improved by falling back to admin_server.  My
>>     >> suspicion as to why we decided not to do this is that a lot of
>>     >> people configure AD KDCs as admin_servers not kpasswd_servers.
>>
>>     Tom> Do you mean in the krb5.conf files, or elsewhere?  I'm not sure
>>     Tom> it makes sense to configure AD KDCs in krb5.conf as
>>     Tom> admin_servers.
>>
>> Keep in mind that we used to not support or at least not document
>> kpasswd_server.
>
> I agree that it is quite possible even in AD environments that only the
> admin_server is being specified.  In fact, the Solaris krb client config
> utility, kclient does not set kpasswd_server because at the time it was
> created the developer presumed init cred error fall back to admin_server
> behavior.
>
>>     >> One thing to check here is what AD's default SRV records do in
>>     >> this instance. If they publish admin_server records then it's
>>     >> probably not a good idea to fall back by default.
>>
>>     Tom> I doubt that AD publishes SRV records for "kerberos-adm", since
>>     Tom> that port number is meant for the MIT krb5 kadmin RPC protocol.
>>     Tom> Based on a single sample, AD does appear to publish SRV records
>>     Tom> for "kpasswd".  How would an AD KDC function as an
>>     Tom> admin_server?
>>
>> If they did it it would be because of the kpasswd server.
>
> In draft-ietf-krb-wg-krb-dns-locate-03.txt, the SRV record for the
> kpassword server is described.

Internet Drafts are not a normative source of information.  Many people
make the mistake but simply because something appears as in an I-D does
not mean it should be implemented.   This is especially true with a 
document
such as the one you reference where the working group pulled out the 
pieces
it though were worth standardizing and incorporated them into RFC 4120.
There are many things in the dns-locate draft that explicitly should 
not be
implemented.

Jeffrey Altman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20120409/8be286db/attachment.bin