On Mon, 11 Aug 2014, Michael Lasevich wrote:
So, it is NOT intended to use for border-style 2FA authentication (i.e.
VPN) - which seems may be a common use case for 2FA?
You can always supplement authentication check with some host-specific
information at the VPN concentrator. We don't have ready to use solution
here but it is definitely possible to use such scheme against FreeIPA

 Is there any way to block password auth based on source (HBAC rules?) So
far the only way I can figure out is to create a second account, which is
less than optimal.

No, this functionality is not supported. One particular issue is that
we'll need to authenticate before applying HBAC rules, not after, so
some other means to validate the request chain are needed.

Additionally, Kerberos authentication requires to enter your credentials
only when obtaining a ticket granting ticket (TGT) which happens before
a client will ask for a ticket to a specific service. Also, renewing the
ticket might be possible without original credentials. Perhaps we could
add a flag into TGT that would tell how strong were credentials (how
many factors were in use) when TGT was obtained and then use it in a
policy to see if a ticket to the target service principal could be

I think I understand -  HBAC has no way to know how you authenticated - so
you cannot make rules based on that?
Yes, these are different stages in the PAM stack and unless all modules
are cooperating you have no means to get them in accord.

Is there a way to test OTP token auth while bypassing kerberos? For
example, you can validate user's password via a LDAP login, - can you do a
similar validation of OTP token directly?
Just try to bind to LDAP, it will work the same way regardless whether
you are using a password or 2FA -- if only 2FA is enabled, only 2FA
login will be accepted over LDAP bind.

/ Alexander Bokovoy

Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to