Greg,
while on a KDC that section does have value for setting things like the DB
path among other things
"
kdc = kdc-master-dev.stanford.edu
master_kdc = kdc-master-dev.stanford.edu
admin_server = kdc-master-dev.stanford.edu
kpasswd_server = kdc-master-dev.stanford.edu
"
I did glance over at the MIT Kerberos site and its changed a lot since i
last looked at it, I will try to find the exact document where I read that
(I think it might have been in some of the bundled documentation with the
code but its been over a year since i looked for it), if its true than its
inline with what the commercial implementations have all done based on the
more recent RFC's (admittedly most of the RFC's regarding this subject were
written by Microsoft), but if not then the document should be corrected.
that said many implementation of the libraries don't handle coding it there
well or in static configuration files at all particularly when it comes to
fail over even if they are built against the MIT or Heimdal libraries. by
the way this also includes statically coding it in SSSD configuration
files, which have issues with fail overs when its in the config files but
fail over seamlessly when they use the DNS for discovery.
On Mon, May 14, 2018 at 11:17 AM, Greg Hudson <ghud...@mit.edu> wrote:
> On 05/14/2018 07:30 AM, Paul Robert Marino wrote:
> > In modern implementations no in fact you shouldn't instead you should
> use the DNS for all of these settings and at most use the default realm and
> possibly the domain to realm matching section.
> > In most implementations of Kerberos the ability to set this local is
> deprecated or not avaliable at all amy more. Even in MIT's implementation
> it is slated to go away in a few versions so it is generally considered a
> bad idea to use it. Also the testers of the client libraries are mostly
> testing around DNS so you may run into issues if you use that section of
> the configuration.
>
> Speaking as the primary maintainer of MIT krb5, we have no plans to get
> rid of [realms] -> realmname -> kdc, and to my knowledge we never had
> any such plans. Our continuous integration tests use it, and many
> client machines at MIT specify [realms] -> ATHENA.MIT.EDU -> kdc values.
> I don't see anything in our documentation discouraging its use.
>
> Also, I'm not sure this answer is responsive to the original question,
> which was about the KDC. As to that question, I am not super familiar
> with the Heimdal code, but looking at kdc/connect.c:configure() and
> lib/krb5/get_addrs.c:krb5_get_all_server_addrs(), it doesn't look like
> the KDC uses [realms] -> realmname -> kdc. Instead, it looks like it
> uses [kdc] -> addresses and [kdc] -> ports; if those don't exist, it
> enumerates interface addresses and uses a list of standard ports (port
> 88 and maybe port 80 and 9878 depending on whether the KDC is also
> serving HTTP and kx509).
>
