On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal <[email protected]> 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<[email protected]> >> wrote: >>> >>> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal<[email protected]> 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 >>>> [email protected] >>>> 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 > [email protected] > https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
