2FA with krb5

[Dan Mahoney (Gushi)]

All,

We use Kerberos but NOT LDAP at the day job.

We'd like to be able to leverage 2fa for some services (admins) and some
services (ssh logins) but not have to pump a 2fa code into, say, our mail
applications. Is there a way to make the acquisition of a TGT (for GSSAPI
authentication) vs Password Authentication require 2fa?

That's complication number one.

Complication number 2 is something like "SecurID is *expensive* for a
fairly small (<10) admin team."

Is there any reasonable support for off-the-shelf TOTP or HOTP
authenticators, i.e. google authenticator or whatnot? If so, is there
support to have a user have *multiple* available authenticators, such that
one can be expired and others not?

Googling this all gets me a bunch of (some older, some newer articles
about the varying states of SPAKE and the like), and...a whole bunch of
ads now being shown for startups that want to do it differently but I'm
SURE no way to integrate with this.

The final problem, of course, is that if I make all my KDC's 2fa-aware on
their own, there's no communication of double-use of a token, unless I
centralize things, which breaks the purpose of having geo-diverse KDC's.
I don't suppose the kerberos db replication mechanism has anything that
can also share this state?

This is all pie-in-the-sky stuff, but practical answers "just an FAQ" are
hard to find.

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

[Ken Hornstein]

>We'd like to be able to leverage 2fa for some services (admins) and some
>services (ssh logins) but not have to pump a 2fa code into, say, our mail
>applications. Is there a way to make the acquisition of a TGT (for GSSAPI
>authentication) vs Password Authentication require 2fa?

Yes (I'll explain more below).

>That's complication number one.
>
>Complication number 2 is something like "SecurID is *expensive* for a
>fairly small (<10) admin team."

Yeah, tell me about it.

>Is there any reasonable support for off-the-shelf TOTP or HOTP
>authenticators, i.e. google authenticator or whatnot? If so, is there
>support to have a user have *multiple* available authenticators, such that
>one can be expired and others not?

There is not such a thing yet, AFAIK. It's something on my list to
implement TOTP support (but, it's kinda far down). It's complicated
(again, see below).

>Googling this all gets me a bunch of (some older, some newer articles
>about the varying states of SPAKE and the like), and...a whole bunch of
>ads now being shown for startups that want to do it differently but I'm
>SURE no way to integrate with this.
>
>The final problem, of course, is that if I make all my KDC's 2fa-aware on
>their own, there's no communication of double-use of a token, unless I
>centralize things, which breaks the purpose of having geo-diverse KDC's.
>I don't suppose the kerberos db replication mechanism has anything that
>can also share this state?
>
>This is all pie-in-the-sky stuff, but practical answers "just an FAQ" are
>hard to find.

So, I think I speak with some authority on this subject; I've been involved
with some kind of 2FA with Kerberos for a ... couple of decades? Yikes,
I feel old. Anyway, the super short summary is:

- You can do it, but depending on exactly WHAT you want to do may
involve writing some code. You've heard the expression, "With a big
enough engine, you can make a barn door fly"? That applies here.
- There are some architectural issues that makes this all complicated
to deploy. I'll try to touch on those.

The first question you need to answer is: what are your clients? This
is important because which specific 2FA protocol you use depends on
what clients you have. The 3 main protocols I am aware of are

- SAM2 - this is the old protocol that we originally used waay back
when we started (and we still use today for some factors). You can
pretty much use any factor with it; we used SecurID, CryptoCARD,
and today use YubiKey. The major disadvantage is it is only supported
by MIT-based Kerberos clients. I did a small amount of the protocol
work on SAM2 but for various complicated reasons it never resulted
in a published RFC.

- FAST. This is a newer protocol that provides a generic encrypted
tunnel to send preauthentication messages over (these are called "FAST
factors"). It's a more complicated protocol, but superior to SAM2;
if it was around when we started we would have used it. It is supported
by MIT and Heimdal; it may be supported by Windows, I am not sure.
There is already a FAST factor defined for One-Time Passwords, called
"OTP". I am not sure of the client coverage of the OTP FAST
factor, though. I will admit that I do not know as much about FAST as
the other mechanisms, so if people chime in and correct me you should
believe them over me.

- PKINIT. This uses an existing PKI to completely replace a password. I
mention this as 2FA since in our deployment we use client certificates
on smartcards which require PINs to unlock, hence the two factors.
This is supported by all 3 major Kerberos implementations (well, maybe
not the smartcard piece, but MIT Kerberos does, except on Windows).
If you can leverage an existing PKI then it's not a bad choice, but
it is a complicated mess to get going; there are SO MANY ways for
it to go wrong.

So, which protocol should you use? Well, even though I hold a soft spot
for SAM2, I can't really recommend using it for new implementations;
ours is really just due to legacy code. So that's either FAST OTP or
PKINIT. However ... FAST does require a special "FAST armour key"
(which is typically a host key) or support for anonymous PKINIT.
Either of those requires a bit of magic at kinit time, which I haven't
completely sussed out all yet. I'm not actually sure if FAST OTP has
been deployed anywhere; it may be! If so, no one talks about it.
One advantage of SAM2 is that it "just works" when you enable it
(assuming everything else is set up correctly).

There is an existing FAST OTP implementation for MIT Kerberos; the
documentation is here:

https://web.mit.edu/kerberos/www/krb5-latest/doc/admin/otp.html

The implementation requires you to verify the token using a RADIUS
server. If you do not like that, you'd have to write your own
implementation (and, sadly, that requires Kerberos internals; sigh, I
wish that interface was better defined).

In terms of using it for access to certain hosts, you have a couple
of options. The preauth mechanism can set what are known as "authentication
indicators" in the ticket; you can either configure a host principal
to only allow the acquisition of a service ticket if it has a particular
indicator, or you can modify the server software so it checks for
a particular indicator. We used a variation of the second approach;
there is a Kerberos ticket flag called HW_AUTH, and our application server
code checks for that on the subset of hosts that require it (this was
before authentication indicators were developed as a protocol extension).

Now, in terms of "challenges" ... here's my understanding of the
practical issues you will face:

- As you note, talking to an external server kills the KDC redundancy.
And a lot of OTP mechanisms require this. In the larger deployment
I have worked on, we supported three OTP hardware tokens: SecurID,
CRYPTOCard, and YubiKey. With CRYPTOCard, I wrote that mechanism and
put the "secret" directly in the KDC. That worked, but it had an
unfortunate wart that if you talked to a replica KDC there was no way
of propagating the "used" token back to the primary (since 99% of the
requests went to the primary KDC, it never ended up being a problem in
practice, but I knew it was an issue and never figured out a reasonable
solution). With SecurID and YubiKey, the KDC ends up talking to external
verification servers. For various dumb reasons the SecurID server
implementation never worked well, but the YubiKey one seems to work
pretty well. It does have the obvious problem that if the YubiKey
server goes down then you can't kinit if you're using YubiKey (and
that has happened to us).

- There's not a way to OPTIONALLY say, "I'd like to use OTP now". You can
set it on a per-user basis, but kinit (and the underlying API) doesn't
have the ability to say, "Please let me use OTP for this request".
We have some local hacks to enable this functionality. In discussions
on krbdev I believe MIT was open to this functionality, but the
actual WORK hasn't been done. I was the obvious one to do this work,
but I just submitted a pullup request for a very simple change that I
said I'd do back in May, so ... I'm behind. Discussion on this is
here:

http://mailman.mit.edu/pipermail/krbdev/2021-April/013448.html

Now, strangely enough, even though PKINIT is a giant pain in the ass
it solves a lot of these issues (admittedly, by foisting them off onto
a PKI, but hey ...). So if you want to use PKINIT, that might be a
way to go. In terms of second factors, have you looked at the YubiKey
tokens? The latest ones can act as a PIV token, and you should be able
to get PKINIT working with them (I will admit I've played around with
a YubiKey token and I see it shows up as a PIV token, but I didn't get
a chance to go farther). In theory you could implement the YubiKey
verification directly in the KDC, but that has all of the issues with
the CRYPTOCard support I mentioned.

I hope it doesn't sound like I'm crapping on people here; a lot of
very smart people did a lot of very good work in terms of the protocol
and the code framework for implementing multi-factor authentication in
Kerberos. It is not an easy problem! But the documentation on it all
is a bit ... diffused.

Anyway, I hope that helps.

--Ken

[J.Wit...@mindef.nl]

What do you regard as “expensive”?
Strong 2FA with world-wide acceptable PKI can be obtained for €70 a piece.
If you can afford the time, and willing to do your own CA, you can lower it to €15 a piece.

The first can be obtained when applying for Estonian E-resident, https://learn.e-resident.gov.ee/hc/en-us/articles/360000625098-Why-become-an-e-resident

second one by buying smart cards at aventra.fi https://aventra.fi/webshop/index.php?route=product/product&product_id=87

From: "Dan Mahoney (Gushi)" <da...@prime.gushi.org<mailto:da...@prime.gushi.org>>
Date: Wednesday, 6 October 2021 at 23:18:51
To: "kerb...@mit.edu" <kerb...@mit.edu<mailto:kerb...@mit.edu>>
Subject: 2FA with krb5

All,

We use Kerberos but NOT LDAP at the day job.

We'd like to be able to leverage 2fa for some services (admins) and some
services (ssh logins) but not have to pump a 2fa code into, say, our mail
applications. Is there a way to make the acquisition of a TGT (for GSSAPI
authentication) vs Password Authentication require 2fa?

That's complication number one.

Complication number 2 is something like "SecurID is *expensive* for a
fairly small (<10) admin team."

Is there any reasonable support for off-the-shelf TOTP or HOTP
authenticators, i.e. google authenticator or whatnot? If so, is there
support to have a user have *multiple* available authenticators, such that
one can be expired and others not?

Googling this all gets me a bunch of (some older, some newer articles
about the varying states of SPAKE and the like), and...a whole bunch of
ads now being shown for startups that want to do it differently but I'm
SURE no way to integrate with this.

The final problem, of course, is that if I make all my KDC's 2fa-aware on
their own, there's no communication of double-use of a token, unless I
centralize things, which breaks the purpose of having geo-diverse KDC's.
I don't suppose the kerberos db replication mechanism has anything that
can also share this state?

This is all pie-in-the-sky stuff, but practical answers "just an FAQ" are
hard to find.

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

________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

[Jochen Kellner]

Hi,

[I'm running Kerberos inside FreeIPA, so plain Kerberos might be
different...]

Ken Hornstein <ke...@cmf.nrl.navy.mil> writes:

>>We'd like to be able to leverage 2fa for some services (admins) and some
>>services (ssh logins) but not have to pump a 2fa code into, say, our mail
>>applications. Is there a way to make the acquisition of a TGT (for GSSAPI
>>authentication) vs Password Authentication require 2fa?
>

> Yes (I'll explain more below).
>

>>That's complication number one.
>>
>>Complication number 2 is something like "SecurID is *expensive* for a
>>fairly small (<10) admin team."
>

> Yeah, tell me about it.

I've been running Privacyidea (https://www.privacyidea.org/) for some
time to manage the tokens. Exposed the Application with RADIUS and told
FreeIPA to authenticate against RADIUS. Had some rough edges, but was
usable for me and is able to manage many kinds of tokens.

Will it work for you? Maybe...

Jochen

--
This space is intentionally left blank.

[Ken Hornstein]

>I've been running Privacyidea (https://www.privacyidea.org/) for some
>time to manage the tokens. Exposed the Application with RADIUS and told
>FreeIPA to authenticate against RADIUS. Had some rough edges, but was
>usable for me and is able to manage many kinds of tokens.

So what's the _client_ look like? Specifically, are you doing FAST-OTP?
If so, what client software are you using? Does this only work on
systems with host keys, or do you do anonymous PKINIT?

--Ken

[Russ Allbery]

Ken Hornstein <ke...@cmf.nrl.navy.mil> writes:

> I am not sure of the client coverage of the OTP FAST factor, though.

For what it's worth, although my pam-krb5 module implements FAST including
both keyed and anonymous FAST, it does not implement FAST OTP. This is
because (a) I didn't find any documentation of what I was supposed to do
as a client (it's been years since I looked so this quite possibly has
changed), and (b) attempting to set up a reasonable test environment
looked painful. In particular, there was (at the time, again haven't
checked recently) a lot of hand-waving about exactly to set up the RADIUS
part, since MIT Kerberos just treats it as an oracle.

I haven't checked if sssd supports FAST OTP. That seems much more likely
given that they probably have enterprise use cases that would warrant
implementing it.

I'd be happy to take pull requests since I try to make pam-krb5 reasonably
completionist as a hobby (although be aware that it's a purely hobby
project at this point), but they would need to include changes to the ci
directory to set up the KDC and RADIUS server appropriately so that the
test suite could do a proper end-to-end integration test.

--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>

[Simo Sorce]

On Thu, 2021-10-07 at 11:50 -0700, Russ Allbery wrote:
> Ken Hornstein <ke...@cmf.nrl.navy.mil> writes:
>
> > I am not sure of the client coverage of the OTP FAST factor, though.
>
> For what it's worth, although my pam-krb5 module implements FAST including
> both keyed and anonymous FAST, it does not implement FAST OTP. This is
> because (a) I didn't find any documentation of what I was supposed to do
> as a client (it's been years since I looked so this quite possibly has
> changed), and (b) attempting to set up a reasonable test environment
> looked painful. In particular, there was (at the time, again haven't
> checked recently) a lot of hand-waving about exactly to set up the RADIUS
> part, since MIT Kerberos just treats it as an oracle.

It is somewhat documented, but see below.

> I haven't checked if sssd supports FAST OTP. That seems much more likely
> given that they probably have enterprise use cases that would warrant
> implementing it.

It does, and FreeIPA implements the server part, so you can look there
for examples and testing capabilities if you are so inclined.

> I'd be happy to take pull requests since I try to make pam-krb5 reasonably
> completionist as a hobby (although be aware that it's a purely hobby
> project at this point), but they would need to include changes to the ci
> directory to set up the KDC and RADIUS server appropriately so that the
> test suite could do a proper end-to-end integration test.

HTH,
Simo.

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[Ken Hornstein]

>Ken Hornstein <ke...@cmf.nrl.navy.mil> writes:
>
>> I am not sure of the client coverage of the OTP FAST factor, though.
>
>For what it's worth, although my pam-krb5 module implements FAST including
>both keyed and anonymous FAST, it does not implement FAST OTP. This is
>because (a) I didn't find any documentation of what I was supposed to do
>as a client (it's been years since I looked so this quite possibly has
>changed),

Huh, I _kinda_ thought that if you had FAST going, you got FAST OTP (on
the client at least) for free! Which shows what I know. Maybe it works
already and you never tested it?

>and (b) attempting to set up a reasonable test environment
>looked painful. In particular, there was (at the time, again haven't
>checked recently) a lot of hand-waving about exactly to set up the RADIUS
>part, since MIT Kerberos just treats it as an oracle.

Right, THIS is actually a huge problem. Like having to set up a RADIUS
server? Ugh. It's also a problem for development! Like the only
way I have found to effectively test preauth mechanisms is to do
testing on one of our replica KDCs.

--Ken

[Russ Allbery]

Ken Hornstein <ke...@cmf.nrl.navy.mil> writes:

> Huh, I _kinda_ thought that if you had FAST going, you got FAST OTP (on
> the client at least) for free! Which shows what I know. Maybe it works
> already and you never tested it?

The bit that I suspect doesn't work is all the interactions between the
prompting and the prompt control options like use_first_pass.

[Simo Sorce]

On Thu, 2021-10-07 at 15:14 -0400, Ken Hornstein wrote:
> > Ken Hornstein <ke...@cmf.nrl.navy.mil> writes:
> >
> > > I am not sure of the client coverage of the OTP FAST factor,
> > > though.
> >
> > For what it's worth, although my pam-krb5 module implements FAST
> > including
> > both keyed and anonymous FAST, it does not implement FAST OTP.
> > This is
> > because (a) I didn't find any documentation of what I was supposed
> > to do
> > as a client (it's been years since I looked so this quite possibly
> > has
> > changed),
>

> Huh, I _kinda_ thought that if you had FAST going, you got FAST OTP
> (on
> the client at least) for free! Which shows what I know. Maybe it
> works
> already and you never tested it?
>

> > and (b) attempting to set up a reasonable test environment
> > looked painful. In particular, there was (at the time, again
> > haven't
> > checked recently) a lot of hand-waving about exactly to set up the
> > RADIUS
> > part, since MIT Kerberos just treats it as an oracle.
>
> Right, THIS is actually a huge problem. Like having to set up a
> RADIUS
> server? Ugh. It's also a problem for development! Like the only
> way I have found to effectively test preauth mechanisms is to do
> testing on one of our replica KDCs.

Starting an ad-hoc kdc is pretty easy, I have it done in the make check
phase in many small projects, including starting an ldap server, I
haven't tried radius, but hopefully starting a freeradius server is not
exceedingly hard either.

[Russ Allbery]

Simo Sorce <si...@redhat.com> writes:

> Starting an ad-hoc kdc is pretty easy, I have it done in the make check
> phase in many small projects, including starting an ldap server, I
> haven't tried radius, but hopefully starting a freeradius server is not
> exceedingly hard either.

Yeah, for the record it was just the RADIUS bit that I didn't already have
working. If anyone is curious:

https://github.com/rra/pam-krb5/tree/master/ci

contains scripts that will set up either an MIT Kerberos KDC or a Heimdal
KDC with PKINIT configured and a variety of keytabs and whatnot premade.
They are used via GitHub Actions here:

https://github.com/rra/pam-krb5/blob/master/.github/workflows/build.yaml

[Jochen Kellner]

I mostly use sssd and kinit. I'm not sure what sssd uses, but I remember
traces from kinit using PKINIT. These two clients worked well for me.

Other clients (java applications) had problems with OTP. See
https://lists.jboss.org/pipermail/keycloak-user/2018-January/012759.html
for the analysis we did there.

As you said - with the "right" clients it might work. Otherwise you
might be stuck.

[Dan Mahoney]

So, there’a an assumption here: all the kerberos 2fa stuff is really only used when you kinit. And that extra protcol is the one where the three differing protocols come in. Just like sshd’s Password Authentication vs Challenge Response Authentication, the client has to be *able* to ask for more info.

Here’s my use case.

I ssh in to things. Sometimes from MacOS, sometimes from iPadOS. Some of our things require a kerberos ticket *or* some other 2fa, typically used in cases where you can’t kinit.

If you’re using kerberos in some other way (say, normal HTTP basic auth via mod_auth_kerb), you don’t have the benefit of the 2fa. (You can tell apache not to let that work, and simply have your users forced to use ticket auth, but that doesn’t work on Android, iOS, iPadOS, etc).

HTTP Basic Auth has no support for asking for additional factors — you can, depending on the application, ask for a 2fa code, or use the “put your 2fa token at the end of the password, but I don’t know if keberos knows how to split this off — and continue allowing it when the 2fa value continues changing.

Same goes for GSSAPI Auth with sshd — if you’re using either the builtin KerberosAuthentication or the alternative, pam with pam_krb5, you can fall back to password authentication and then use something like pam-whatever-other-2fa provider to get the same net effect. I don’t know what the KDC says in those cases, if it refuses to work at all because no 2fa was presented, or if it Just Works.

And Radius, I get it but...I know for example with SecurID, one of the things you can do is talk to the SecurID server over RADIUS, and I’m pretty sure other 2fa servers (mypw, cryptocard, etc) do the same thing. Radius isn’t an unreasonable protocol, but there’s no RADIUS server for, say, Google Authenticator, or OPIE.

You could have your KDC talk ta a RADIUS server that’s talking to a PAM service that calls some sort of 2fa server. That feels…duct-tapey.

I mean, this might be dumb, but why not have the kdc able to speak to pam modules directly?

-Dan

[Ken Hornstein]

>I mean, this might be dumb, but why not have the kdc able to speak to
>pam modules directly?

All of those things are "send me a 2FA token and I will verify it".
(Also, the pam API really really wants to talk to a person, that's
the whole point of the "pam conversation" functions; I don't see how
you could make that work with a KDC).

Kerberos is "I am going to take your password which I already know,
convert it into an encryption key, and use it to verify your Kerberos
request". Kerberos needs to know the password/factor to make that
happen, where the typical 2FA API only tells you "is this token good
or not?".

I am aware of one site that a long, long time ago had developed code
that you used the 2FA code as the Kerberos password directly; I never
thought that was a good idea myself as the 2FA code never had a lot
of entropy to serve as a good encryption key, but it worked for them.

If you want to use something like TOTP, then I think you're probably
going to have to write your own FAST OTP preauth module. Which is
doable! Although in practice it seems like any preauth module requires
access to the MIT Kerberos ASN.1 decoder/encoder API, which means
an internal dependency. Sigh.

Sadly, at this stage right now if you want to effectively use 2FA with
Kerberos you're going to be stuck at the very minimum reading a lot of
source code and protocol documents to see if you have the application
coverage you need.

--Ken

[Greg Hudson]

On 10/8/21 7:45 AM, Ken Hornstein wrote:
>> I mean, this might be dumb, but why not have the kdc able to speak to
>> pam modules directly?

> Kerberos is "I am going to take your password which I already know,
> convert it into an encryption key, and use it to verify your Kerberos
> request". Kerberos needs to know the password/factor to make that
> happen, where the typical 2FA API only tells you "is this token good
> or not?".

I think Dan was assuming one of the cases where the KDC received a 2FA
value and needs an oracle, such as FAST OTP.

One concern is that PAM modules must operate synchronously (unless I'm
badly mistaken), so the KDC process would be blocked if the module has
to talk to a remote server. You can get away with that if your
population of 2FA users is small and the oracle is fast, but OTP oracles
are often deliberately slow to answer. We developed an async kdcpreauth
interface and async RADIUS code to address that problem for FAST OTP.

[Charles Hedrick]

We use TOTP. That allows us to tack the token on the end of the password. That makes it easy to fix programs that expect a simple password prompt.

In fact I have a wrapper that can be interposed around pretty much anything use LD_PRELOAD.

https://github.com/clhedrick/kerberos/blob/master/radius-wrap/radius-wrap.c

> On Oct 7, 2021, at 3:16 PM, Russ Allbery <ea...@eyrie.org> wrote:

>
> Ken Hornstein <ke...@cmf.nrl.navy.mil> writes:
>
>> Huh, I _kinda_ thought that if you had FAST going, you got FAST OTP (on
>> the client at least) for free! Which shows what I know. Maybe it works
>> already and you never tested it?
>

> The bit that I suspect doesn't work is all the interactions between the
> prompting and the prompt control options like use_first_pass.
>

[Ken Hornstein]

>We use TOTP. That allows us to tack the token on the end of the
>password. That makes it easy to fix programs that expect a simple
>password prompt.
>
>In fact I have a wrapper that can be interposed around pretty much
>anything use LD_PRELOAD.

>[...]

Well, that answers PART of my question. And I am guessing based on
the README for that you use k5start to generate the FAST armor cache
using the host key in the keytab? But this seems kind of RADIUS
specific; do you use TOTP for people who just use kinit?

--Ken

[Charles Hedrick]

I’m not using that code now. When using it for real I would generate a special key tab with a user that had no permissions to do anything or use the host key tab depending upon the application.

Our staff and a few users have TOTP set for their account, so it has to work for everything. Logins use sssd, with its pam. We have a service with source in the same repo that keeps credentials renewed and kills them when the users last session is gone. In case we need to kinit I have a script that gets an anonymous credential and passes it to kinit -T. I get the credential,from a service on the Kerberos server. It’s the same service that generates credentials for cron jobs . I could use kinit -n, but that creates a problem of distributing cents to all clients. The service is easier.

I don’t like key tabs for users because if someone manages to get a copy you have no way of knowing, and it can be used anywhere in the system. So if a user wants to use cron jobs that need credentials, they register with the service. At that point a Pam module used by cron can get a credential,for them. It’s not forwardsble, and is locked to that hosts IP. The primary use is so cron jobs can access files, since all our file systems are kerberized.

We are fully kerberized. But one implementation constraint was that it should be invisible to users, except if they run cron jobs. That requires more work than it ought to.

> On Oct 15, 2021, at 5:50 PM, Ken Hornstein <ke...@cmf.nrl.navy.mil> wrote:
>
>