[Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs

[Simo Sorce]

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

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York