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.


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 

Freeipa-users mailing list

Reply via email to