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 > >>>>>>> user. > >>>>>>> > >>>>>>> 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 > >>>>>>> that. > >>>>>>> > >>>>>>> Is it possible? Help on how would be great. If not, feature > >>>>>>> request? > >>>>>>> > >>>>>>> thanks, > >>>>>>> > >>>>>>> -t > >>>>>>> > >>>>>> We have several tickets: > >>>>>> > >>>>>> https://fedorahosted.org/freeipa/ticket/433 > >>>>>> > >>>>>> https://fedorahosted.org/freeipa/ticket/3659 > >>>>>> > >>>>>> https://fedorahosted.org/freeipa/ticket/4498 > >>>>>> > >>>>>> 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 > >>>>>> SSSD. > >>>>>> > >>>>>> Before filing tickets I would like to hear opinions on the > >>>>>> matter. > >>>>> 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. > >>>>> > >>>>> Simo. > >>>>> > >>>> 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. > >>> > >>> Simo. > >>> > >> 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. > If we are paranoid we can use SSL over this socket to pass the user > credential. > 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). Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project