[17582] in Kerberos_V5_Development
Re: suggestion for locating master kdc logic
daemon@ATHENA.MIT.EDU (Tom Yu)
Mon Apr 9 17:36:35 2012
To: Sam Hartman <hartmans@mit.edu>
From: Tom Yu <tlyu@mit.edu>
Date: Mon, 09 Apr 2012 17:36:28 -0400
In-Reply-To: <tsl8vi4fwd9.fsf@mit.edu> (Sam Hartman's message of "Mon,
09 Apr 2012 17:06:42 -0400")
Message-ID: <ldv62d8h9k3.fsf@cathode-dark-space.mit.edu>
MIME-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Sam Hartman <hartmans@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.
Do you mean in the krb5.conf files, or elsewhere? I'm not sure it
makes sense to configure AD KDCs in krb5.conf as admin_servers.
> 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.
I doubt that AD publishes SRV records for "kerberos-adm", since that
port number is meant for the MIT krb5 kadmin RPC protocol. Based on a
single sample, AD does appear to publish SRV records for "kpasswd".
How would an AD KDC function as an admin_server?
If you meant SRV records for "kerberos-master", AD doesn't appear to
publish those either, and "kerberos-master" is also not registered in
the IANA ports and services registry.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
