[Freeipa-users] Host based 2FA ?

[Dmitri Pal]

On 12/12/2014 02:29 PM, Simo Sorce wrote:
> On Fri, 12 Dec 2014 13:49:24 -0500
> Dmitri Pal <dpal at redhat.com> wrote:
>
>> On 12/12/2014 01:38 PM, Simo Sorce wrote:
>>> On Fri, 12 Dec 2014 13:32:03 -0500
>>> Dmitri Pal <dpal at redhat.com> wrote:
>>>
>>>> On 12/12/2014 01:27 PM, Simo Sorce wrote:
>>>>> On Fri, 12 Dec 2014 13:17:18 -0500
>>>>> Dmitri Pal <dpal at redhat.com> wrote:
>>>>>
>>>>>> On 12/12/2014 01:07 PM, Simo Sorce wrote:
>>>>>>> On Thu, 11 Dec 2014 18:30:06 -0500
>>>>>>> Dmitri Pal <dpal at redhat.com> wrote:
>>>>>>>
>>>>>>>> On 12/11/2014 06:32 PM, freeipa at 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.

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
>> 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.
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.