On 29.5.2014 18:40, Nathaniel McCallum wrote:
On Mon, 2013-09-23 at 08:12 -0400, Simo Sorce wrote:
On Mon, 2013-09-23 at 09:00 +0200, Petr Spacek wrote:
On 20.9.2013 21:35, Simo Sorce wrote:
This patch set is an initial implementation of ticket #3859

It seem to be working fine in my initial testing but I have not yet
tested all cases.

However I wonted to throw it on the list to get some initial feedback
about the choices I made wrt access control and ipa-getkeytab flags and
default behavior.

In particular, the current patch set would require us to make
host/service keytabs readable by the requesting party (whoever that is,
admin or host itself) in order to allow it to get back the actual
keytab. I am not sure this is ideal. Also write access to the keytab is
still all is needed to allow someone to change it.

Neither is ideal, but it was simpler as a first implementation. In
particular I think we should allow either permission indipendently, and
it should be something an admin can change. However I do not like
allowing normal writes or reads to these attributes, mostly because w/o
access to the master key nobody can really make sense of actually
reading out the contents of KrbPrincipalKey or could write a blob that
can be successfully decrypted.

So I was wondering if we might want to prevent both reading and writing
via LDAP (except via extended operations) and instead use another method
to determine access patterns.

As for ipa-getkeytab is everyone ok with tryin the new method first and
always falling back to the old one (if a password has been provided) ?

Simo.

I was always curious why we don't use normal kadmin protocol? :-)

Kadmin won't respect LDAP based ACIs, it always operate as "root"
against LDAP,
This leads to question: Why? Wouldn't be approach with S4U sufficient?

>> and has it's own simple ACL file. We want to be able to
easily manage and delegate access to keytab creation.

We might try to change the kadmin code to impersonate the user but I
think it would be invasive, I never seriously looked into it though.

IMHO we have two options:
A) Operate as root & use LDAP proxy control.
-- Determine DN of an object representing principal used by user.
-- Use LDAP proxy control with given DN.

B) Use S4U and connect to LDAP with user's credentials.

Wouldn't such an approach have inherently better security properties
(and potentially gain other operations for free)? The current patch set
is also invasive (at least in terms of its size). If the kadmin approach
is a similar sized or smaller change, I'd probably prefer that.

I agree with Nathaniel.

--
Petr^2 Spacek

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to