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?

Thanks
- Trey

On Fri, Mar 7, 2014 at 4:38 PM, Dmitri Pal<d...@redhat.com>  wrote:
On 03/07/2014 05:26 PM, Trey Dockendorf wrote:
On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal<d...@redhat.com>   wrote:
On 03/05/2014 06:24 PM, Trey Dockendorf wrote:
Correction from my email, the condition that sets if a 389DS user is
proxied to pam_krb5 is the "pamFilter", sorry.

On Wed, Mar 5, 2014 at 5:22 PM, Trey Dockendorf<treyd...@gmail.com>
wrote:
On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal<d...@redhat.com>    wrote:
On 03/03/2014 07:47 PM, Simo Sorce wrote:
On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
Is it possible with FreeIPA to use an external KDC or pass some or
all
authentication to an external KDC?  The KDC at our University may
give
me a one way trust if I describe my implementation plan for FreeIPA.
Currently I use 389DS with PAM pass through using untrusted
pam_krb5.
I'd like to fully utilize FreeIPA without managing passwords since
all
my users already have University accounts.  I just want to manage
authorization for my systems, not authentication.
You could set up a kerberos trust manually but at the moment we do
not
support it in the code or the utilities.

SSSD in particular will have no place to find identity information if
all you have is a kerberos trust, you'd need also an external
identity
store to point to, but there is no builtin code in SSSD to link the 2
domain at this point.

We are planning on working on IPA-to-IPA trust, and possibly
IPA-to-*other* so any requirements you can throw at us will be made
part
of the consideration and planning to add this kind of functionality
in
the future.

NM B HTH,
Simo.

Can you describe your workflows because I have some idea in mind?
Right now the workflow I have with 389ds using PAM Pass Through Auth
is the following:

For users with the proper attribute defined in 'pamIDAttr'

client --->    389DS --->    389DS server's pam_krb5 --->    Campus KDC

For users lacking the attribute for 'pamIDAttr'

client --->    389DS

The Kerberos setup currently on the 389DS server is untrusted (no
krb5.keytab).

The ideal workflow with FreeIPA would be

client ---->    IPA --->    Campus KDC

Would you be OK if your accounts would be in IPA but the
authentication
would be proxied out?
This is fine with me.  Does the idea you describe allow for some
authentication (ie system accounts or internal accounts) to be handled
by FreeIPA?  That's the benefit to us when using PAM Pass Through
Auth, is that we can conditionally proxy out the authentication.

The idea is that you can use OTP RADIUS capability to proxy passwords
to
your main KDC.

client ---OTP--->    IPA --->    OTP Proxy --->    RADIUS --->    Your KDC

Disclaimer: that would defeat the purpose of Kerberos and the password
will
be sent over the wire but it seems that you are already in this setup.

Would you be interested to give it a try?
Absolutely.  Right now I need to contact our campus IT group and let
them know what I require to make our setup work.  I have been told a
one way trust is the most I can get.  Will that facilitate what you
described?

You do not need trust for that setup. Any user account (i am not sure
about
special system accounts that are not created in cn=users) would be able
to
go to external RADIUS server.


Would require latest SSSD and kerberos library on the client though
but
would work with LDAP binds too.
Latest SSSD and Kerberos that's available in EL6, or latest upstream?

Upstream.

Is it possible use these latest versions in EL6, or is using Fedora
19+ the only feasible way to do this?  If using EL6 is not possible,
is it going to be something possible in EL7?


Latest RHEL7 beta snapshots might be a good starting point.
This will not be a part of RHEL6, sorry.


Please take a look at the design page: http://www.freeipa.org/page/V3/OTP
-
that will give you an idea about the internals.

Latest upstream UI should be able to allow to configure external RADIUS
servers and then change per user policy to proxy via RADIUS. Then you can
try binding with LDAP to IPA using password from your main KDC.
Then you can use SSSD on the same system to try to authenticate using
Kerberos. You will create a new user, set him to use RADIUS server for
authentication and then try to su to this user or ssh into the box as
that
user. It should work and klist should report a TGT for this user on the
box.

Thanks for the info.  I'll see if I can piece together how to make this
work.

Let me know if you need any help or guidance with this POC.


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


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


--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/





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