[Freeipa-users] Using external KDC

Sat Mar 8 23:53:50 UTC 2014

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<dpal at redhat.com>  wrote:
>> On 03/07/2014 05:26 PM, Trey Dockendorf wrote:
>>> On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal<dpal at redhat.com>   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<treydock at gmail.com>
>>>>> wrote:
>>>>>> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal<dpal at redhat.com>    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 at 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 at 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/
>>
>>
>>

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.

-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/