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

Petr Spacek pspacek at redhat.com
Mon Sep 23 07:00:34 UTC 2013


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? :-)

-- 
Petr^2 Spacek




More information about the Freeipa-devel mailing list