Re: help with OTP

What we did:
- in your kdc.conf:

[otp]
   DEFAULT = {
        server = localhost6:1812
        secret = secrettfile
        strip_realm = true
   }

This assumes your kdc runs a local RADIUS server that will answer up
OTP requests.  Change as needed.

- create the file 'secretfile' with your shared RADIUS secret in the
same directory as kdc.conf

- kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS'
- kadmin -q 'modprinc +requires_preauth user
- kadmin -q 'setstr user otp []'

Testing:

Get an initial TGT with anonymous auth
- kinit -n -c /tmp/somecache

Use that anonymous auth
- kinit -T /tmp/somecache  user

Should get prompted for OTP there if that is right.

For Linux things that support 'sssd' - look a the krb5_use_fast
setting - we set our to demand.

For macOS and other things we build Russ Allbery's pam_krb5 -
https://www.eyrie.org/~eagle/software/pam-krb5/pam-krb5.html
that supports FAST.  The Kerberos supplied with macOS sorta works but
is missing so much it has been easier just to push a build of MIT
Kerberos to it.

That's the off the top of my head notes for OTP.

HTH.


On Tue, Apr 25, 2023 at 12:44 PM Matt Zagrabelny via Kerberos
<[email protected]> wrote:
>
> Hi Ken!
>
> On Mon, Apr 24, 2023 at 5:25 PM Ken Hornstein <[email protected]> wrote:
> >
> > >make it look like you can put the secret directly into the
> > >configuration file. There seems to be a little bit of disconnect
> > >between those two parts of the docs. I just wanted to point it out if
> > >it is helpful.
> >
> > It looks like (according to the source code) it has to have that as
> > a filename.
>
> Thanks for source diving and confirming how to use that config directive.
>
> > >I've tried to configure my kdc.conf with the required otp stanzas:
> >
> > Well, it's a preauthentication mechanism, so FIRST you have to make sure
> > your principal is configured to require preauthentication.
>
> Sure. I just did that:
>
> kadmin.local:  modify_principal +requires_preauth [email protected]
> Principal "[email protected]" modified.
>
> I've searched the docs and didn't find anything, but... I don't
> suppose there is a config item for the KDC to require preauth for
> "user" principals?
>
>   And there
> > is a note at the bottom of that page that suggests you need to be using
> > FAST which implies you need to set up a FAST credential cache.
>
> I've done some searching and found:
>
> https://web.mit.edu/kerberos/krb5-1.12/doc/basic/ccache_def.html
>
> ...but no mention of FAST.
>
>
>   And
> > I will be the first person to confess that I've always been a little
> > hazy on how exactly that works!  (We do use an OTP preauthentication
> > mechanism but it predates the newer OTP mechanism you're using).  I am
> > not aware of any extant documentation that explains how you're supposed
> > to use FAST in practice, which I always found a bit odd.
>
> I haven't found any documentation about configuring the KDC to use FAST.
>
>   I wasn't
> > involved with Kerberos protocol development when FAST was designed but I
> > remember a lot of messages about it, but it seems like there's a giant
> > hole on how exactly you're supposed to use it when it comes down to the
> > nuts and bolts.  If there is some documentation about it, hey, I'd love
> > to read it!
>
> Ditto.
>
>   One of my long-term plans is to migrate our weird stuff to
> > something based on OTP which would involve FAST and I sure hope that's
> > actually possible in practice (I am aware that without an available
> > local keytab you'd have to do anonymous PKINIT and that wouldn't be too
> > bad for us since we already have all of the certificate stuff deployed
> > for PKINIT with Kerberos, but if you DIDN'T already have everything set
> > up for PKINIT it would be about as much fun as a punch in the face from
> > John Cena).
> >
> > My guess is you could use kinit -k to get a TGT based on a keytab on the
> > host and then give THAT credential cache you create to the kinit command
> > using the -T option.  Again, that's just a guess.
>
> Yeah... I'm unsure how this all plumbs together.
>
> Thanks for the reply. Maybe someone else, with FAST experience (?),
> will chime in.
>
> Cheers,
>
> -m
>
> ________________________________________________
> Kerberos mailing list           [email protected]
> https://mailman.mit.edu/mailman/listinfo/kerberos

________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos