[Freeipa-users] Using external KDC

[Dmitri Pal]

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/