Re: [Freeipa-users] Using external KDC
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 Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Using external KDC
On 03/10/2014 03:13 PM, Nathaniel McCallum wrote: On Mon, 2014-03-10 at 14:50 -0400, Dmitri Pal wrote: On 03/10/2014 10:32 AM, Nathaniel McCallum wrote: On Sat, 2014-03-08 at 18:53 -0500, Dmitri Pal wrote: On 03/08/2014 04:36 PM, Trey Dockendorf wrote: I got a RHEL7-beta VM up and running with basic ipa install (no DNS and no NTP). IPA is 3.3.3-5.el7 SSSD is 1.11.2-1.el7 krb5 is 1.11.3-31.el7 Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted the CLI commands under "Feature Management", with no luck. For example: --- # ipa config-mod --user-auth-type=['password', 'otp', 'radius'] Usage: ipa [global-options] config-mod [options] ipa: error: no such option: --user-auth-type --- The ipa subcommands "radiusproxy-*" do not exist either. What version of IPA should I use to test this proof of concept? The docs mention needing Kerberos no earlier than 1.12, which isn't available in EL7. My understanding of Kerberos is not great, but is FreeIPA simply not designed for external Kerberos (like the use of an external CA)? Is there possibly a way to utilize FreeIPA without Kerberos, and just manage 389DS while still using the web interface (hard to find good Identity Management Web UI) and CLI tools? I'd still like to get this working in FreeIPA, but am working on upgrading our HPC cluster to EL6 (or EL7) and moving to FreeIPA would be a great improvement over 389DS in terms of manageability. Nathaniel, do we have a build of the latest bits for RHEL7 somewhere? Can you help with this POC please? None of those commands will be present in EL 7.0 and we don't currently have EL 7.0 builds of FreeIPA 4.0 master to my knowledge. I thought we have something that builds latest bits for RHEL. If not is it hard to produce one? http://koji.fedoraproject.org/koji/packageinfo?packageID=11554 Koji doesn't currently list an EPEL build of IPA, most likely because such a package would disturb the EL packages. We could create a Copr build for EL6, but I don't know how many dependencies it would drag in. If the dependencies are minimal, the job would be fairly easy. I may take a stab at this later this week. No build on top of RHEL7b build would be good enough. It would be possible to do this via manual manipulation of the LDAP entries. You'd need to create an ipatokenRadiusConfiguration object and then add the ipatokenRadiusProxyUser class (ipatokenRadiusConfigLink attribute) to each user you'd like to proxy. However, I don't think manual manipulation of LDAP like this is a supported operation. I would also imagine that your University may look down on an intentional man-in-the-middle password proxy. Nathaniel Nathaniel. All the security disclaimers have been mentioned earlier in the thread. While I agree with you from security POV proxy is a solution that already in place so it is not worse than now. Yup, I just wanted to make sure I covered the disclaimers in full in the same email detailing how to enable it. :) Nathaniel -- 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 Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Using external KDC
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. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Using external KDC
On Mon, 2014-03-10 at 14:50 -0400, Dmitri Pal wrote: > On 03/10/2014 10:32 AM, Nathaniel McCallum wrote: > > On Sat, 2014-03-08 at 18:53 -0500, Dmitri Pal wrote: > >> On 03/08/2014 04:36 PM, Trey Dockendorf wrote: > >>> I got a RHEL7-beta VM up and running with basic ipa install (no DNS and > >>> no NTP). > >>> > >>> IPA is 3.3.3-5.el7 > >>> SSSD is 1.11.2-1.el7 > >>> krb5 is 1.11.3-31.el7 > >>> > >>> Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted > >>> the CLI commands under "Feature Management", with no luck. > >>> > >>> For example: > >>> > >>> --- > >>> # ipa config-mod --user-auth-type=['password', 'otp', 'radius'] > >>> Usage: ipa [global-options] config-mod [options] > >>> > >>> ipa: error: no such option: --user-auth-type > >>> --- > >>> > >>> The ipa subcommands "radiusproxy-*" do not exist either. > >>> > >>> What version of IPA should I use to test this proof of concept? The > >>> docs mention needing Kerberos no earlier than 1.12, which isn't > >>> available in EL7. > >>> > >>> My understanding of Kerberos is not great, but is FreeIPA simply not > >>> designed for external Kerberos (like the use of an external CA)? Is > >>> there possibly a way to utilize FreeIPA without Kerberos, and just > >>> manage 389DS while still using the web interface (hard to find good > >>> Identity Management Web UI) and CLI tools? I'd still like to get this > >>> working in FreeIPA, but am working on upgrading our HPC cluster to EL6 > >>> (or EL7) and moving to FreeIPA would be a great improvement over 389DS > >>> in terms of manageability. > >>> > >> Nathaniel, do we have a build of the latest bits for RHEL7 somewhere? > >> Can you help with this POC please? > > None of those commands will be present in EL 7.0 and we don't currently > > have EL 7.0 builds of FreeIPA 4.0 master to my knowledge. > > I thought we have something that builds latest bits for RHEL. If not is > it hard to produce one? http://koji.fedoraproject.org/koji/packageinfo?packageID=11554 Koji doesn't currently list an EPEL build of IPA, most likely because such a package would disturb the EL packages. We could create a Copr build for EL6, but I don't know how many dependencies it would drag in. If the dependencies are minimal, the job would be fairly easy. I may take a stab at this later this week. > > It would be possible to do this via manual manipulation of the LDAP > > entries. You'd need to create an ipatokenRadiusConfiguration object and > > then add the ipatokenRadiusProxyUser class (ipatokenRadiusConfigLink > > attribute) to each user you'd like to proxy. > > > > However, I don't think manual manipulation of LDAP like this is a > > supported operation. I would also imagine that your University may look > > down on an intentional man-in-the-middle password proxy. > > > > Nathaniel > > > Nathaniel. All the security disclaimers have been mentioned earlier in > the thread. > While I agree with you from security POV proxy is a solution that > already in place so it is not worse than now. Yup, I just wanted to make sure I covered the disclaimers in full in the same email detailing how to enable it. :) Nathaniel ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Using external KDC
On 03/10/2014 10:32 AM, Nathaniel McCallum wrote: On Sat, 2014-03-08 at 18:53 -0500, Dmitri Pal wrote: On 03/08/2014 04:36 PM, Trey Dockendorf wrote: I got a RHEL7-beta VM up and running with basic ipa install (no DNS and no NTP). IPA is 3.3.3-5.el7 SSSD is 1.11.2-1.el7 krb5 is 1.11.3-31.el7 Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted the CLI commands under "Feature Management", with no luck. For example: --- # ipa config-mod --user-auth-type=['password', 'otp', 'radius'] Usage: ipa [global-options] config-mod [options] ipa: error: no such option: --user-auth-type --- The ipa subcommands "radiusproxy-*" do not exist either. What version of IPA should I use to test this proof of concept? The docs mention needing Kerberos no earlier than 1.12, which isn't available in EL7. My understanding of Kerberos is not great, but is FreeIPA simply not designed for external Kerberos (like the use of an external CA)? Is there possibly a way to utilize FreeIPA without Kerberos, and just manage 389DS while still using the web interface (hard to find good Identity Management Web UI) and CLI tools? I'd still like to get this working in FreeIPA, but am working on upgrading our HPC cluster to EL6 (or EL7) and moving to FreeIPA would be a great improvement over 389DS in terms of manageability. Nathaniel, do we have a build of the latest bits for RHEL7 somewhere? Can you help with this POC please? None of those commands will be present in EL 7.0 and we don't currently have EL 7.0 builds of FreeIPA 4.0 master to my knowledge. I thought we have something that builds latest bits for RHEL. If not is it hard to produce one? It would be possible to do this via manual manipulation of the LDAP entries. You'd need to create an ipatokenRadiusConfiguration object and then add the ipatokenRadiusProxyUser class (ipatokenRadiusConfigLink attribute) to each user you'd like to proxy. However, I don't think manual manipulation of LDAP like this is a supported operation. I would also imagine that your University may look down on an intentional man-in-the-middle password proxy. Nathaniel Nathaniel. All the security disclaimers have been mentioned earlier in the thread. While I agree with you from security POV proxy is a solution that already in place so it is not worse than now. -- 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 Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Using external KDC
On Sat, 2014-03-08 at 18:53 -0500, Dmitri Pal wrote: > On 03/08/2014 04:36 PM, Trey Dockendorf wrote: > > I got a RHEL7-beta VM up and running with basic ipa install (no DNS and no > > NTP). > > > > IPA is 3.3.3-5.el7 > > SSSD is 1.11.2-1.el7 > > krb5 is 1.11.3-31.el7 > > > > Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted > > the CLI commands under "Feature Management", with no luck. > > > > For example: > > > > --- > > # ipa config-mod --user-auth-type=['password', 'otp', 'radius'] > > Usage: ipa [global-options] config-mod [options] > > > > ipa: error: no such option: --user-auth-type > > --- > > > > The ipa subcommands "radiusproxy-*" do not exist either. > > > > What version of IPA should I use to test this proof of concept? The > > docs mention needing Kerberos no earlier than 1.12, which isn't > > available in EL7. > > > > My understanding of Kerberos is not great, but is FreeIPA simply not > > designed for external Kerberos (like the use of an external CA)? Is > > there possibly a way to utilize FreeIPA without Kerberos, and just > > manage 389DS while still using the web interface (hard to find good > > Identity Management Web UI) and CLI tools? I'd still like to get this > > working in FreeIPA, but am working on upgrading our HPC cluster to EL6 > > (or EL7) and moving to FreeIPA would be a great improvement over 389DS > > in terms of manageability. > > > > Nathaniel, do we have a build of the latest bits for RHEL7 somewhere? > Can you help with this POC please? None of those commands will be present in EL 7.0 and we don't currently have EL 7.0 builds of FreeIPA 4.0 master to my knowledge. It would be possible to do this via manual manipulation of the LDAP entries. You'd need to create an ipatokenRadiusConfiguration object and then add the ipatokenRadiusProxyUser class (ipatokenRadiusConfigLink attribute) to each user you'd like to proxy. However, I don't think manual manipulation of LDAP like this is a supported operation. I would also imagine that your University may look down on an intentional man-in-the-middle password proxy. Nathaniel ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Using external KDC
On 03/08/2014 04:36 PM, Trey Dockendorf wrote: I got a RHEL7-beta VM up and running with basic ipa install (no DNS and no NTP). IPA is 3.3.3-5.el7 SSSD is 1.11.2-1.el7 krb5 is 1.11.3-31.el7 Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted the CLI commands under "Feature Management", with no luck. For example: --- # ipa config-mod --user-auth-type=['password', 'otp', 'radius'] Usage: ipa [global-options] config-mod [options] ipa: error: no such option: --user-auth-type --- The ipa subcommands "radiusproxy-*" do not exist either. What version of IPA should I use to test this proof of concept? The docs mention needing Kerberos no earlier than 1.12, which isn't available in EL7. My understanding of Kerberos is not great, but is FreeIPA simply not designed for external Kerberos (like the use of an external CA)? Is there possibly a way to utilize FreeIPA without Kerberos, and just manage 389DS while still using the web interface (hard to find good Identity Management Web UI) and CLI tools? I'd still like to get this working in FreeIPA, but am working on upgrading our HPC cluster to EL6 (or EL7) and moving to FreeIPA would be a great improvement over 389DS in terms of manageability. Nathaniel, do we have a build of the latest bits for RHEL7 somewhere? Can you help with this POC please? Thanks - Trey On Fri, Mar 7, 2014 at 4:38 PM, Dmitri Pal wrote: On 03/07/2014 05:26 PM, Trey Dockendorf wrote: On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal wrote: On 03/05/2014 06:24 PM, Trey Dockendorf wrote: 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 wrote: On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Palwrote: 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? You do not need trust for that setup. Any user account (i am not sure about special system accounts that are not created in cn=users) would be able to go to external RADIUS server. 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? Upstream. Is it possible use these latest versions in EL6, or is using Fedora 19+ the only feasible way to do this? If using EL6 is not possible, is it going to be something possible in EL7? Latest RHEL7 beta snapshots might be a good s
Re: [Freeipa-users] Using external KDC
I got a RHEL7-beta VM up and running with basic ipa install (no DNS and no NTP). IPA is 3.3.3-5.el7 SSSD is 1.11.2-1.el7 krb5 is 1.11.3-31.el7 Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted the CLI commands under "Feature Management", with no luck. For example: --- # ipa config-mod --user-auth-type=['password', 'otp', 'radius'] Usage: ipa [global-options] config-mod [options] ipa: error: no such option: --user-auth-type --- The ipa subcommands "radiusproxy-*" do not exist either. What version of IPA should I use to test this proof of concept? The docs mention needing Kerberos no earlier than 1.12, which isn't available in EL7. My understanding of Kerberos is not great, but is FreeIPA simply not designed for external Kerberos (like the use of an external CA)? Is there possibly a way to utilize FreeIPA without Kerberos, and just manage 389DS while still using the web interface (hard to find good Identity Management Web UI) and CLI tools? I'd still like to get this working in FreeIPA, but am working on upgrading our HPC cluster to EL6 (or EL7) and moving to FreeIPA would be a great improvement over 389DS in terms of manageability. Thanks - Trey On Fri, Mar 7, 2014 at 4:38 PM, Dmitri Pal wrote: > On 03/07/2014 05:26 PM, Trey Dockendorf wrote: >> >> On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal wrote: >>> >>> On 03/05/2014 06:24 PM, Trey Dockendorf wrote: 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 wrote: > > On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal 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? >>> >>> >>> You do not need trust for that setup. Any user account (i am not sure >>> about >>> special system accounts that are not created in cn=users) woul
Re: [Freeipa-users] Using external KDC
On 03/07/2014 05:26 PM, Trey Dockendorf wrote: On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal wrote: On 03/05/2014 06:24 PM, Trey Dockendorf wrote: 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 wrote: On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal 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? You do not need trust for that setup. Any user account (i am not sure about special system accounts that are not created in cn=users) would be able to go to external RADIUS server. 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? Upstream. Is it possible use these latest versions in EL6, or is using Fedora 19+ the only feasible way to do this? If using EL6 is not possible, is it going to be something possible in EL7? Latest RHEL7 beta snapshots might be a good starting point. This will not be a part of RHEL6, sorry. Please take a look at the design page: http://www.freeipa.org/page/V3/OTP - that will give you an idea about the internals. Latest upstream UI should be able to allow to configure external RADIUS servers and then change per user policy to proxy via RADIUS. Then you can try binding with LDAP to IPA using password from your main KDC. Then you can use SSSD on the same system to try to authenticate using Kerberos. You will create a new user, set him to use RADIUS server for authentication and then try to su to this user or ssh into the box as that user. It should work and klist should report a TGT for this user on the box. Thanks for the info. I'll see if I can piece together how to make this work. Let me know if you need any help or guidance with this POC. -- 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 Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- 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 mail
Re: [Freeipa-users] Using external KDC
On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal wrote: > On 03/05/2014 06:24 PM, Trey Dockendorf wrote: >> >> 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 >> wrote: >>> >>> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal 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? > > > You do not need trust for that setup. Any user account (i am not sure about > special system accounts that are not created in cn=users) would be able to > go to external RADIUS server. > > >>> 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? > > > Upstream. > Is it possible use these latest versions in EL6, or is using Fedora 19+ the only feasible way to do this? If using EL6 is not possible, is it going to be something possible in EL7? > Please take a look at the design page: http://www.freeipa.org/page/V3/OTP - > that will give you an idea about the internals. > > Latest upstream UI should be able to allow to configure external RADIUS > servers and then change per user policy to proxy via RADIUS. Then you can > try binding with LDAP to IPA using password from your main KDC. > Then you can use SSSD on the same system to try to authenticate using > Kerberos. You will create a new user, set him to use RADIUS server for > authentication and then try to su to this user or ssh into the box as that > user. It should work and klist should report a TGT for this user on the box. > Thanks for the info. I'll see if I can piece together how to make this work. > >>> -- 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 Freeipa-users@redhat.com https://www.red
Re: [Freeipa-users] Using external KDC
On 03/05/2014 06:24 PM, Trey Dockendorf wrote: 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 wrote: On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal 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? You do not need trust for that setup. Any user account (i am not sure about special system accounts that are not created in cn=users) would be able to go to external RADIUS server. 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? Upstream. Please take a look at the design page: http://www.freeipa.org/page/V3/OTP - that will give you an idea about the internals. Latest upstream UI should be able to allow to configure external RADIUS servers and then change per user policy to proxy via RADIUS. Then you can try binding with LDAP to IPA using password from your main KDC. Then you can use SSSD on the same system to try to authenticate using Kerberos. You will create a new user, set him to use RADIUS server for authentication and then try to su to this user or ssh into the box as that user. It should work and klist should report a TGT for this user on the box. -- 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 Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- 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 Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Using external KDC
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 wrote: > On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal 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 >> Freeipa-users@redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Using external KDC
On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal 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 > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Using external KDC
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? Would you be OK if your accounts would be in IPA but the authentication would be proxied out? 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? Would require latest SSSD and kerberos library on the client though but would work with LDAP binds too. -- 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 Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Using external KDC
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. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Using external KDC
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. Thanks - Trey ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
