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
---------------------------

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: kerberos@mit.edu

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)