[Freeipa-users] Using external KDC

[Nordgren, Bryce L -FS]

I'm jumping in kind of late, but I may have a way for you to eliminate your current man in the middle password proxy.

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

First, I understand you to be saying that the University provides Kerberos authentication, but the associated "id_provider" either does not exist, is irrelevant to your situation, or you need to override/replace some values. If this is not correct, the remainder is unlikely to be applicable. Furthermore, some users allowed on your HPC cluster do not exist in the University system, so you need to be able to add users.

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

First thing: emphasize in your deployment plan that you intend to eliminate your current password proxy. Gold star for you.

Second thing: you need two IPA instances because you have two realms. The first IPA instance manages the users from the University realm (for your machines only). The second IPA instance manages the extra users you plan on adding. The second instance also contains the machine entries for the nodes in your HPC cluster. For each user you intend to permit to use your cluster, you need to create an account in one of these IPAs.

Third: Configure sssd on your HPC nodes with a "University" realm. Your "University" realm should point "auth_provider" and "chpass_provider" "krb5_server", and "krb5_kpasswd"  to your university's KDC, "id_provider" should be ipa, and should point to your very own "HPC IPA". This will replace any "id_provider" information your university supplies, or create it if it does not exist.

Fourth: Configure sssd with an "HPC" Realm. Everything (auth_provider/id_provider) points to your HPC IPA instance.

Your "University" IPA instance manages a KDC. Ignore it. Never have your clients connect to it. You are interested in creating accounts having the same username as in the University's KDC. Just make it so that those users can't login using the IPA instance you set up. Give them random passwords which never expire. SSSD should take care of authenticating against the University.

You may also have to manually create the one-way Kerberos trust with the university using the MIT tools. This trust goes to the KDC managed by your "HPC" ipa instance.

It's probably not necessary to mess with a trust relationship between the two IPAs. Trust is a Kerberos thing, and only one of your IPAs has an important Kerberos store.

It may be useful to maintain the [capaths] section of krb5.conf on all your login appliances. It may not. Try it and let me know.

Your login node(s) will require network connectivity to the University's KDC. Other nodes will not. Once your users get a forwardable TGT from your HPC IPA (which they should get on login), they can directly authenticate to your cluster. Both of your IPA instances will need to be accessible from all nodes on your cluster.

This is just hypothetical. YMMV. I've been mulling over a similar problem for a long time, and I can't claim to have a perfect solution.

Bryce




This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.