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

Reply via email to