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.

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-leave@lists.fedorahosted.org