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.
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.
I am not sure of the client coverage of the OTP FAST factor, though.
Ken Hornstein <kenh@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.
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.
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?
Ken Hornstein <kenh@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.
Ken Hornstein <kenh@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.
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?
On Oct 7, 2021, at 12:55 PM, Russ Allbery <eagle@eyrie.org> wrote:
Simo Sorce <simo@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
--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/> ________________________________________________
Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
I mean, this might be dumb, but why not have the kdc able to speak to
pam modules directly?
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?".
On Oct 7, 2021, at 3:16 PM, Russ Allbery <eagle@eyrie.org> wrote:
Ken Hornstein <kenh@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.
--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/> ________________________________________________
Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
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.
[...]
On Oct 15, 2021, at 5:50 PM, Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:

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
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 85:27:38 |
Calls: | 6,495 |
Calls today: | 6 |
Files: | 12,099 |
Messages: | 5,276,973 |