On 9 October 2017 at 11:59, Callum Guy <callum....@x-on.co.uk> wrote:
> Hi Andy,
> Although this isn't going to help resolve your problem I wanted to let you
> know that I am currently working through a similarly confusing OTP
> authentication issue which appears to have been introduced following our
> upgrade to FreeIPA 4.5 / CentOS 7.4.
> In our situation we are authenticating our VPN using password+OTP and
> continue to use this throughout the system - so OTP is required everywhere.
> Since the update the VPN authentications, which use an interim LDAP Bind,
> refuse to accept OTP - the only thing that works is password only even
> though this is specifically prohibited in the configuration.
> As you are using a similar platform perhaps part of your issue is related
> - can you confirm if you are using an interim bind for your VPN auth?
In my initial testing of using the LDAP module in FreeRADIUS, I found the
behaviour was consistent with the description in "Implementation" on
https://www.freeipa.org/page/V4/OTP i.e., that where both password and otp
auth mechanisms are enabled on a user, both password and password+otp login
were successful. Conversely, in my testing where a user had just "otp"
mechanism allowed, it also worked as expected. After this exploratory
testing I moved on to PAM and krb5, and this is where I've been having
trouble - and there's no interim LDAP bind here.
> On Mon, Oct 9, 2017 at 11:52 AM Andy Stubbs via FreeIPA-users <
> email@example.com> 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
>> 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.
>> 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,
>> Andrew Stubbs, PhD
>> Head of Technical Operations
>> +44 203 770 4582 <+44%2020%203770%204582>
>> FreeIPA-users mailing list -- firstname.lastname@example.org
>> To unsubscribe send an email to freeipa-users-leave@lists.
> Callum Guy
> Head of Information Security
> *0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk> | **
> <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel>
> <https://twitter.com/xonuk> *
> X-on is a trading name of Storacall Technology Ltd a limited company
> registered in England and Wales.
> Registered Office : Avaland House, 110 London Road, Apsley, Hemel
> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.
> The information in this e-mail is confidential and for use by the
> addressee(s) only. If you are not the intended recipient, please notify
> X-on immediately on +44(0)333 332 0000 <+44%20333%20332%200000> and
> delete the
> message from your computer. If you are not a named addressee you must not
> use, disclose, disseminate, distribute, copy, print or reply to this email.
> or opinions expressed by an individual
> within this email may not necessarily reflect the views of X-on or its
> associated companies. Although X-on routinely screens for viruses,
> addressees should scan this email and any attachments
> for viruses. X-on makes no representation or warranty as to the absence of
> viruses in this email or any attachments.
Andrew Stubbs, PhD
Head of Technical Operations
+44 203 770 4582
FreeIPA-users mailing list -- email@example.com
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org