On 03/10/2014 05:09 PM, Nordgren, Bryce L -FS wrote:
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
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
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 

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

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 

This is very similar to sort of split brain approach that we do not recommend because it is hard to maintain. See the following presentation
https://www.youtube.com/watch?v=cS6EJ1L7fRI minute 32:00
See the diagram but instead of AD assume it is your University KDC.

Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.

Looking to carve out IT costs?

Freeipa-users mailing list

Reply via email to