[Freeipa-users] Using external KDC

Dmitri Pal dpal at redhat.com
Mon Mar 10 22:49:27 UTC 2014


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/






More information about the Freeipa-users mailing list