On 9 October 2017 at 12:46, Sumit Bose via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:
> On Mon, Oct 09, 2017 at 11:50:59AM +0100, Andy Stubbs via FreeIPA-users
> wrote:
> > I'm having a bit of a hard time trying to enforce OTP on VPN access using
> > FreeRADIUS backed by FreeIPA as the auth oracle.
> >
> > I'm using a FreeIPA 4.5.0-21 client which is running FreeRADIUS 3.0.13-8,
> > enrolled to a FreeIPA 4.5.0-21 server, both on clean installs of CentOS
> > 7.4.1708
> >
> > I need to enforce OTP for VPN access, and have it optional everywhere
> else.
> > This kind of access based on auth indicators seems to be pretty standard,
> > and is even mentioned in the RH IdM manual (section 22.3).
> >
> > But I can't get it to work. I have been banging my head against this for
> a
> > few days now. Could somebody point me in the right direction please?
> >
> > I have users who have "password" and "otp" auth mechanisms enabled. Of
> > course, this means I can't use LDAP to enforce OTP.
> >
> > PAM feels like it should be the right answer, but I've singularly failed
> to
> > coax it into doing the right thing.
> >
> > I note that if "password" is _not_ an allowed auth mechanism, then
> > system-auth, su, and sudo seem to be happy accepting "password+OTP" at
> the
> > "First Factor" and leaving "Second Factor" blank. OTOH, if "password" is
> > allowed, the "password+OTP" at "First Factor" and leaving "Second Factor
> > (optional)" blank fails.
>
> This is currently expected behavior. The reason is that single factor
> (password) and two factor (password and OTP) authentication are handled
> by two different Kerberos pre-authentication methods. If both methods
> are enabled for a user the KDC will tell the client so and SSSD will
> prompt the user accordingly ("First Factor" and "Second Factor
> (optional)" in this case).
>
> But now SSSD has to decide which pre-authentication method to use and
> using the wrong one would cause an authentication error on the server
> side which might trigger an account or password lock. That's why SSSD
> currently only does two factor authentication if the "Second Factor" is
> given explicitly.
>
Ah this makes sense and provides some illumination as to what's going on
behind the scenes, thanks.
Regards
Andy
>
> There is already https://pagure.io/SSSD/sssd/issue/3264 make make this
> more configurable.
>
> bye,
> Sumit
>
> >
> > I've tried enforcing OTP on the host the FreeRADIUS server is running on,
> > instead of on the user, and trying "password+OTP" at the "password"
> prompt.
> > Also no dice.
> >
> > In any case, it seems that whatever pam module I configure the rlm_pam
> > module to use, "password+OTP" just isn't accepted, but if I turn off otp
> as
> > an auth mechanism for a user, the password is accepted just fine.
> >
> > I've tried krb5 too, creating a specific service, and trying just about
> > every combination of password/otp options on host, service, and user...
> and
> > again, no dice (though it works if otp is off on all of them, but that's
> > obviously not what I need to achieve).
> >
> > I can't find any reference to a specific API for testing an OTP token
> for a
> > user independent of a password (though I have seen references to the
> > ipa-otpd process on the V4/OTP page), and I don't really want to roll my
> > own - so that kind of rules out writing my own python/perl module for
> > FreeRADIUS. Nor do I particularly relish the idea of managing another
> layer
> > of dedicated OTP software like privacyIDEA. (Of course, if that's the
> > _right_ answer, then that's what I'll do)
> >
> > I figure I must be missing something fairly simple as I just can't get it
> > to work and I can't imagine this is a particularly exotic use case: force
> > OTP on VPN and have it optional everywhere else.
> >
> > Any pointers? I would love this to be an embarrassing and trivial
> oversight
> > on my part. Please let it be that :)
> >
> > Thanks in advance for your consideration,
> >
> > Andy
> >
> > --
> > <https://www.treatwell.com/>
> >
> > Andrew Stubbs, PhD
> > Head of Technical Operations
> >
> > +44 203 770 4582
> > treatwell.co.uk
>
> > _______________________________________________
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave@lists.
> fedorahosted.org
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
--
<https://www.treatwell.com/>
Andrew Stubbs, PhD
Head of Technical Operations
+44 203 770 4582
treatwell.co.uk
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
