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