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.
# 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?
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. All the security disclaimers have been mentioned earlier in
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. :)
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-users mailing list