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 <treyd...@gmail.com> wrote:
> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal <d...@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?
>
>> 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?
>
>>
>>
>> --
>> 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@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to