On a Heimdal KDC server for the stanford.edu domain we start the KDC
service using the --config-file option and point to the file /etc/heimdal-kdc/kdc.conf. This file is different than /etc/krb5.conf, for example, it contains some different log settings. In the file /etc/heimdal-kdc/kdc.conf we have this section: [realms] stanford.edu = { 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 default_domain = stanford.edu kadmind_port = 749 } Since the KDC service's realm is stanford.edu, is the KDC even using those settings? If so, how? Adam Lewenberg |
> [realms] > stanford.edu = { > 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 > default_domain = stanford.edu > kadmind_port = 749 > } I think these settings are only used if libkrb needs to contact a realm "on the net" and as the KDC does not make any outgoing connections AFAIK that part should be unused. Just my 5c. Harald. |
In reply to this post by Adam Lewenberg
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. Original Message From: [hidden email] Sent: May 10, 2018 10:41 AM To: [hidden email] Subject: Does KDC service need the [realms] section in its configuration file? On a Heimdal KDC server for the stanford.edu domain we start the KDC service using the --config-file option and point to the file /etc/heimdal-kdc/kdc.conf. This file is different than /etc/krb5.conf, for example, it contains some different log settings. In the file /etc/heimdal-kdc/kdc.conf we have this section: [realms] stanford.edu = { 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 default_domain = stanford.edu kadmind_port = 749 } Since the KDC service's realm is stanford.edu, is the KDC even using those settings? If so, how? Adam Lewenberg |
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). |
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 <[hidden email]> wrote: On 05/14/2018 07:30 AM, Paul Robert Marino wrote: |
Free forum by Nabble | Edit this page |