VPN access with FreeRADIUS enforcing OTP backed by FreeIPA

[Andy Stubbs]

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.

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

[Callum Guy]

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?

Thanks,

Callum

On Mon, Oct 9, 2017 at 11:52 AM Andy Stubbs via FreeIPA-users <
[e-mail]> 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.
>
> 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
>
> [phone] <+44%2020%203770%204582>
> treatwell.co.uk
>
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Andy Stubbs]

Hi Callum,

On 9 October 2017 at 11:59, Callum Guy  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.

Regards

Andy
> Thanks,
>
> Callum
>
> On Mon, Oct 9, 2017 at 11:52 AM Andy Stubbs via FreeIPA-users <
> [e-mail]> 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.
> >
> > 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
> >
> > [phone] <+44%2020%203770%204582>
> > treatwell.co.uk
> >
> > FreeIPA-users mailing list -- [e-mail]
> > To unsubscribe send an email to freeipa-users-leave@lists.
> > fedorahosted.org
>
> --
> Callum Guy
> Head of Information Security
> X-on
>
> *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 [phone] <+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. Views
> 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.

[Callum Guy]

Hi Andy,

Thanks for sharing your experience.

Unfortunately I have no experience in the method you are currently
attempting so can't offer any thoughts, best of luck!

Regarding my issue I am still working through the options - something must
have changed in the 4.5 release as it was all working perfectly for months
ahead of the upgrade. I just can't get my head around how the
authentication would operate differently on same user according to the type
of connection used (i.e. interim bind op), certainly nothing i have seen in
the documentation indicates that this is possible.

Well, onwards. (i may need to book into the spa if i'm stuck on this for
much longer! haha)

Callum

On Mon, Oct 9, 2017 at 2:52 PM Andy Stubbs 
wrote:
> Hi Callum,
>
> On 9 October 2017 at 11:59, Callum Guy  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.
>
> Regards
>
> Andy
> > Thanks,
> >
> > Callum
> >
> > On Mon, Oct 9, 2017 at 11:52 AM Andy Stubbs via FreeIPA-users <
> > [e-mail]> 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.
> > >
> > > 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
> > >
> > > [phone] <+44%2020%203770%204582>
> > > treatwell.co.uk
> > >
> > > FreeIPA-users mailing list -- [e-mail]
> > > To unsubscribe send an email to
> > > [e-mail]
> >
> > --
> > Callum Guy
> > Head of Information Security
> > X-on
> >
> > *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
> > https://maps.google.com/?q=110+London+Road,+Apsley,+Hemel+Hempstead,%0D+Herts,+HP3&entry=gmail&source=g
> > 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 [phone] <+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. Views
> > 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.
>
> --
> https://www.treatwell.com/
>
> Andrew Stubbs, PhD
> Head of Technical Operations
>
> [phone] <+44%2020%203770%204582>
> treatwell.co.uk
>
> --

Callum Guy
Head of Information Security
X-on

[Callum Guy]

On the off chance that anyone was following my issue I wanted to post the
resolution.

Quite simply the interim bind connection required a narrower Base DN,
previously set to the dc= components only (i.e. dc=examples,dc=com).

We revised this to cn=users,cn=accounts,dc=examples,dc=com in order to
reduce the result set (partly due to concerns that cn=compat may have been
impacting the results) and all previous functionality was restored;
allowing all connections to be authenticated with with password+OTP
configuration desired.

Have a good day all.

On Mon, Oct 9, 2017 at 4:43 PM Callum Guy  wrote:
> Hi Andy,
>
> Thanks for sharing your experience.
>
> Unfortunately I have no experience in the method you are currently
> attempting so can't offer any thoughts, best of luck!
>
> Regarding my issue I am still working through the options - something must
> have changed in the 4.5 release as it was all working perfectly for months
> ahead of the upgrade. I just can't get my head around how the
> authentication would operate differently on same user according to the type
> of connection used (i.e. interim bind op), certainly nothing i have seen in
> the documentation indicates that this is possible.
>
> Well, onwards. (i may need to book into the spa if i'm stuck on this for
> much longer! haha)
>
> Callum
>
> On Mon, Oct 9, 2017 at 2:52 PM Andy Stubbs 
> wrote:
> > Hi Callum,
> >
> > On 9 October 2017 at 11:59, Callum Guy  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.
> >
> > Regards
> >
> > Andy
> > > Thanks,
> > >
> > > Callum
> > >
> > > On Mon, Oct 9, 2017 at 11:52 AM Andy Stubbs via FreeIPA-users <
> > > [e-mail]> 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.
> > > >
> > > > 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
> > > >
> > > > [phone] <+44%2020%203770%204582>
> > > > treatwell.co.uk
> > > >
> > > > FreeIPA-users mailing list -- [e-mail]
> > > > To unsubscribe send an email to
> > > > [e-mail]
> > >
> > > --
> > > Callum Guy
> > > Head of Information Security
> > > X-on
> > >
> > > *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
> > > https://maps.google.com/?q=110+London+Road,+Apsley,+Hemel+Hempstead,%0D+Herts,+HP3&entry=gmail&source=g
> > > 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 [phone] <+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. Views 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.
> >
> > --
> > https://www.treatwell.com/
> >
> > Andrew Stubbs, PhD
> > Head of Technical Operations
> >
> > [phone] <+44%2020%203770%204582>
> > treatwell.co.uk
> >
> > --
>
> Callum Guy
> Head of Information Security
> X-on

[Sumit Bose]

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
>
> [phone]
> treatwell.co.uk
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Andy Stubbs]

On 9 October 2017 at 12:46, Sumit Bose via FreeIPA-users <
[e-mail]> 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
> >
> > [phone]
> > treatwell.co.uk
> > FreeIPA-users mailing list -- [e-mail]
> > To unsubscribe send an email to freeipa-users-leave@lists.
>
> fedorahosted.org
> _______________________________________________
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]