On 12/12/2014 02:29 PM, Simo Sorce wrote:
On Fri, 12 Dec 2014 13:49:24 -0500
Dmitri Pal <d...@redhat.com> wrote:

On 12/12/2014 01:38 PM, Simo Sorce wrote:
On Fri, 12 Dec 2014 13:32:03 -0500
Dmitri Pal <d...@redhat.com> wrote:

On 12/12/2014 01:27 PM, Simo Sorce wrote:
On Fri, 12 Dec 2014 13:17:18 -0500
Dmitri Pal <d...@redhat.com> wrote:

On 12/12/2014 01:07 PM, Simo Sorce wrote:
On Thu, 11 Dec 2014 18:30:06 -0500
Dmitri Pal <d...@redhat.com> wrote:

On 12/11/2014 06:32 PM, free...@pettyvices.com wrote:
I'd like to be able to require 2FA on *certain* hosts and
allow just passwords on others.

It seems you can check both "passwords" and "2FA" under the

I was hoping I could create a HBAC such that certain hosts
would only allow 2FA, but I can't see an obvious way to do

Is it possible?  Help on how would be great.  If not, feature



We have several tickets:




If you see
https://fedorahosted.org/freeipa/ticket/4498#comment:6 we
discussed this use case. And I was about to fork it as said
but then I realized that there is not good way on the KDC to
determine the host you are coming from. So IMO it should be a
policy decision on SSSD. There are two options:
- short term solution: allow SSSD to have a local overwrite to
require OTP if server offers different options.
- longer term solution: actually have a per host policy that is
centrally managed that is fetched per host and enforced by

Before filing tickets I would like to hear opinions on the
If we are using a FAST channel using the credentials of the host
then you may be able to know (probably requires changes in the
KDC to internally retain/convey the information).
This is possible via SSSD, but will not work via kinit done by a
generic user, so normal kinit's would require 2FA all the time.


Can kinit do FAST? Is there some kind of kinit flag to use FAST?
Yes kinit can do FAST, but is cumbersome to manually do it.

May be in such setup we will require all clients to use FAST for
the accounts that have several options configured.
It won't help, users do not have access to the host keys so they
can't do FAST with *those* keys.

Then we will know the principal used to armor the connection and
can make policy decisions based on it.
We can do this with SSSD because it has access to the host key,
being a privileged process. Normal user's can't.


What about kinit working with GSS proxy in this case?
Can that help?
No, kinit does not use GSSAPI.
I know it does not. What I mean is to use GSS proxy to as a proxy for
kinit to armor the request.
Have an option for kinit to send user credentials to the local
socket, make GSSproxy or SSSD do the work for him.
There is no way to convey this request over the GSS-Proxy protocol
either, sorry.

Did I ever said that I mean to use GSS-proxy protocol.
I am more thinking of GSS proxy as a conduit of the things related to kerberos that has access to the host key. Now it exposes one socket. It can expose another with the completely different protocol.

If we are paranoid we can use SSL over this socket to pass the user
But I am still not convinced we should care about this use case.
We should not care for the kinit case.

I think it is a potential good thing for the SSSD/pam_krb5 case (being
able to say that in order to log into a specific machine you need 2FA,
but on another less privileged one you can use single factor).


Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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

Reply via email to