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. 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?

Freeipa-users mailing list

Reply via email to