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? > >> 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 >> [email protected] >> https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
