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?
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.
> > 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. :)
Freeipa-users mailing list