[17588] in Kerberos_V5_Development
Re: suggestion for locating master kdc logic
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Mon Apr 9 20:28:54 2012
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: krbdev@mit.edu
Message-ID: <4F837EB5.8070303@secure-endpoints.com>
Date: Mon, 09 Apr 2012 20:28:37 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
MIME-Version: 1.0
To: will.fiveash@oracle.com
In-Reply-To: <20120409222851.GE2566@oracle.com>
Cc: Sam Hartman <hartmans@mit.edu>, Tom Yu <tlyu@mit.edu>, krbdev@mit.edu
Reply-To: jaltman@secure-endpoints.com
Content-Type: multipart/mixed; boundary="===============1626200038=="
Errors-To: krbdev-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1626200038==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig725F1C42EB10EF5B2EE1F618"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig725F1C42EB10EF5B2EE1F618
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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=20
database
as the backend, every KDC can potentially be a master even though only=20
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=20
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=20
kdc_master
entry that matches the kadmin_server entry within the krb5.conf.
I do not believe that MIT should change the Kerberos distribution=20
behavior
8 years later simply because one vendor decided not to support the=20
change.
I agree that all Kerberos distributions should parse the krb5 profile=20
and
interpret it the same way. However, absent a standard, the MIT=20
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" =3D=3D Tom Yu <tlyu@MIT.EDU> writes:
>>
>> Tom> Sam Hartman <hartmans@MIT.EDU> writes:
>> >> I also think it would be reasonable to consider an argument tha=
t
>> >> 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 su=
re
>> 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 confi=
g
> utility, kclient does not set kpasswd_server because at the time it was=
> created the developer presumed init cred error fall back to admin_serve=
r
> 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", sin=
ce
>> Tom> that port number is meant for the MIT krb5 kadmin RPC protoco=
l.
>> Tom> Based on a single sample, AD does appear to publish SRV recor=
ds
>> 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=20
document
such as the one you reference where the working group pulled out the=20
pieces
it though were worth standardizing and incorporated them into RFC 4120.
There are many things in the dns-locate draft that explicitly should=20
not be
implemented.
Jeffrey Altman
--------------enig725F1C42EB10EF5B2EE1F618
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iQEcBAEBAgAGBQJPg366AAoJENxm1CNJffh4p/QIAKMj9Aq2q8qdlUoUSDrJQC4o
NJKuxQy+1ZtS/orGxPD4KYrttet9B6oEstMVcvrKtSD4P1lLPTstESXplZWgCxe4
anC3SJmAYHJGaW24C8F2DT3GjVnHk1nvaRPeWWXDFrhK61g7bbsTi/PSujbw6ur4
0NNV24sJWGix3leCMW3nIaKZqSqF7P4y9I9Yt2YQBmwdCGrhPaKbAjj0mLPZyBYo
MvZ9snLt5a5shsZM2yuyAGQ+1JuuHassU0q1Y0RmIRd2pSsF3H9mqyyH7POONH5h
JA42NmP0fuEZg2qTR/nDhx2qDjRPVTUFapYePXO3b7dcwObpJDokcEOtEwrEH54=
=0JT+
-----END PGP SIGNATURE-----
--------------enig725F1C42EB10EF5B2EE1F618--
--===============1626200038==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
--===============1626200038==--
