1. Forum
  2. USENET
  3. comp.protocols.kerberos

  • Is there a way to steer kinit to a specific kdc?

    From Dan Mahoney (Gushi)@danm@prime.gushi.org to kerberos on Tue Apr 4 21:52:58 2023
    From Newsgroup: comp.protocols.kerberos

    Hey there all.

    I'm writing up a Nagios check to make sure our KDC's are answering, and
    rather than just sending a tcp/udp probe to port 88, I want to actually
    get a ticket, probably by using a keytab and an otherwise unprivileged
    user.

    I'm reading about one such plugin, here: https://exchange.nagios.org/directory/Plugins/Security/check_kdc/details
    and it looks *okay*. I'm not super invested in reinventing the wheel.
    It's a fairly simple shell script.

    It *looks* like, in order to check basically fakes this out with a
    krb5.conf that only includes a single KDC (the one being tested).

    Is that really the best way to go about it?

    Can neither mit kinit nor the heimdal one supplied with BSD systems by default, not just be forced to a single KDC?

    -Dan
    --

    --------Dan Mahoney--------
    Techie, Sysadmin, WebGeek
    Gushi on efnet/undernet IRC
    FB: fb.com/DanielMahoneyIV
    LI: linkedin.com/in/gushi
    Site: http://www.gushi.org
    ---------------------------

    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Ken Hornstein@kenh@cmf.nrl.navy.mil to Dan Mahoney (Gushi) on Wed Apr 5 10:46:09 2023
    From Newsgroup: comp.protocols.kerberos

    It *looks* like, in order to check basically fakes this out with a
    krb5.conf that only includes a single KDC (the one being tested).

    Is that really the best way to go about it?

    Can neither mit kinit nor the heimdal one supplied with BSD systems by >default, not just be forced to a single KDC?

    You are correct; there's no easier way to go about it. At least for
    MIT Kerberos you could write a "locate" plugin that provided some way
    of specifying server locations. That would probably be worse than just
    writing out a custom krb5.conf. As a practical matter I could see it
    being challenging to design a good API to do that and it would probably
    have limited use. I feel your pain because there are a number of
    times when I specifically contact a single KDC for testing/development
    purposes and I also just edit krb5.conf. FWIW, there are many times
    when I want to do some testing and send a TGS-REQ to a particular KDC
    and that would involve not just having a modified kinit, so I think
    the problem is more complex than it appears.

    --Ken
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Greg Hudson@ghudson@mit.edu to Dan Mahoney (Gushi) on Wed Apr 5 12:11:42 2023
    From Newsgroup: comp.protocols.kerberos

    On 4/5/23 00:52, Dan Mahoney (Gushi) wrote:
    Can neither mit kinit nor the heimdal one supplied with BSD systems by default, not just be forced to a single KDC?

    It can't, and the library APIs don't really enable it. A program could
    use krb5_init_creds_step() or krb5_tkt_creds_step() to compose KDC
    requests and do its own network transport, but kinit isn't in the
    business of doing its own network stuff and it doesn't use the _step APIs.

    Adding an init_creds option to specify a KDC host would raise some
    questions. Does the application specify a hostname or an address? Can
    it specify specifically TCP or UDP or the fallback order? What about https?

    At this time I would rather see an externally-maintained KDC probe
    application using the _step APIs (or for people to keep doing this with faked-up krb5.conf files) than accept the complexity of building this
    into the MIT krb5 kinit and the API.
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Carson Gaspar@carson@taltos.org to kerberos on Wed Apr 5 09:33:17 2023
    From Newsgroup: comp.protocols.kerberos

    On 4/5/2023 9:11 AM, Greg Hudson wrote:
    On 4/5/23 00:52, Dan Mahoney (Gushi) wrote:
    Can neither mit kinit nor the heimdal one supplied with BSD systems
    by default, not just be forced to a single KDC?

    It can't, and the library APIs don't really enable it.

    If krb5_init_context_profile() actually did what it said, rather than
    creating a new profile based on the embedded profile path, it would be
    easy (profile_init_path(), change the KDC settings in the profile, pass
    it to krb5_init_context_profile()). As is you have to manipulate
    internal-only krb5 context struct data to override anything.

    There was a thread a while ago discussing fixing this API mistake - did
    it ever go anywhere?
    --

    Carson


    --- Synchronet 3.21d-Linux NewsLink 1.2