[Freeipa-users] Using external KDC

Fri Mar 7 22:26:46 UTC 2014

On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal <dpal at redhat.com> wrote:
> On 03/05/2014 06:24 PM, Trey Dockendorf wrote:
>>
>> Correction from my email, the condition that sets if a 389DS user is
>> proxied to pam_krb5 is the "pamFilter", sorry.
>>
>> On Wed, Mar 5, 2014 at 5:22 PM, Trey Dockendorf<treydock at gmail.com>
>> wrote:
>>>
>>> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal<dpal at redhat.com>  wrote:
>>>>
>>>> On 03/03/2014 07:47 PM, Simo Sorce wrote:
>>>>>
>>>>> On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
>>>>>>
>>>>>> Is it possible with FreeIPA to use an external KDC or pass some or all
>>>>>> authentication to an external KDC?  The KDC at our University may give
>>>>>> me a one way trust if I describe my implementation plan for FreeIPA.
>>>>>> Currently I use 389DS with PAM pass through using untrusted pam_krb5.
>>>>>> I'd like to fully utilize FreeIPA without managing passwords since all
>>>>>> my users already have University accounts.  I just want to manage
>>>>>> authorization for my systems, not authentication.
>>>>>
>>>>> You could set up a kerberos trust manually but at the moment we do not
>>>>> support it in the code or the utilities.
>>>>>
>>>>> SSSD in particular will have no place to find identity information if
>>>>> all you have is a kerberos trust, you'd need also an external identity
>>>>> store to point to, but there is no builtin code in SSSD to link the 2
>>>>> domain at this point.
>>>>>
>>>>> We are planning on working on IPA-to-IPA trust, and possibly
>>>>> IPA-to-*other* so any requirements you can throw at us will be made
>>>>> part
>>>>> of the consideration and planning to add this kind of functionality in
>>>>> the future.
>>>>>
>>>>> NM B HTH,
>>>>> Simo.
>>>>>
>>>> Can you describe your workflows because I have some idea in mind?
>>>
>>> Right now the workflow I have with 389ds using PAM Pass Through Auth
>>> is the following:
>>>
>>> For users with the proper attribute defined in 'pamIDAttr'
>>>
>>> client --->  389DS --->  389DS server's pam_krb5 --->  Campus KDC
>>>
>>> For users lacking the attribute for 'pamIDAttr'
>>>
>>> client --->  389DS
>>>
>>> The Kerberos setup currently on the 389DS server is untrusted (no
>>> krb5.keytab).
>>>
>>> The ideal workflow with FreeIPA would be
>>>
>>> client ---->  IPA --->  Campus KDC
>>>
>>>> Would you be OK if your accounts would be in IPA but the authentication
>>>> would be proxied out?
>>>
>>> This is fine with me.  Does the idea you describe allow for some
>>> authentication (ie system accounts or internal accounts) to be handled
>>> by FreeIPA?  That's the benefit to us when using PAM Pass Through
>>> Auth, is that we can conditionally proxy out the authentication.
>>>
>>>> The idea is that you can use OTP RADIUS capability to proxy passwords to
>>>> your main KDC.
>>>>
>>>> client ---OTP--->  IPA --->  OTP Proxy --->  RADIUS --->  Your KDC
>>>>
>>>> Disclaimer: that would defeat the purpose of Kerberos and the password
>>>> will
>>>> be sent over the wire but it seems that you are already in this setup.
>>>>
>>>> Would you be interested to give it a try?
>>>
>>> Absolutely.  Right now I need to contact our campus IT group and let
>>> them know what I require to make our setup work.  I have been told a
>>> one way trust is the most I can get.  Will that facilitate what you
>>> described?
>
>
> You do not need trust for that setup. Any user account (i am not sure about
> special system accounts that are not created in cn=users) would be able to
> go to external RADIUS server.
>
>
>>>
>>>> Would require latest SSSD and kerberos library on the client though but
>>>> would work with LDAP binds too.
>>>
>>> Latest SSSD and Kerberos that's available in EL6, or latest upstream?
>
>
> Upstream.
>

Is it possible use these latest versions in EL6, or is using Fedora
19+ the only feasible way to do this?  If using EL6 is not possible,
is it going to be something possible in EL7?

> Please take a look at the design page: http://www.freeipa.org/page/V3/OTP -
> that will give you an idea about the internals.
>
> Latest upstream UI should be able to allow to configure external RADIUS
> servers and then change per user policy to proxy via RADIUS. Then you can
> try binding with LDAP to IPA using password from your main KDC.
> Then you can use SSSD on the same system to try to authenticate using
> Kerberos. You will create a new user, set him to use RADIUS server for
> authentication and then try to su to this user or ssh into the box as that
> user. It should work and klist should report a TGT for this user on the box.
>

Thanks for the info.  I'll see if I can piece together how to make this work.

>
>>>
>>>>
>>>> --
>>>> Thank you,
>>>> Dmitri Pal
>>>>
>>>> Sr. Engineering Manager for IdM portfolio
>>>> Red Hat Inc.
>>>>
>>>>
>>>> -------------------------------
>>>> Looking to carve out IT costs?
>>>> www.redhat.com/carveoutcosts/
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeipa-users mailing list
>>>> Freeipa-users at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users