On Tue, 2014-06-17 at 15:30 -0400, Rob Crittenden wrote:
> Simo Sorce wrote:
> > On Mon, 2014-06-16 at 09:53 +0200, Petr Viktorin wrote:
> >> On 06/13/2014 10:20 PM, Simo Sorce wrote:
> >> [...]
> >>> 2) and I think this is a MUCH bigger issue, the Admin users are
> >>> unbounded and pass any Access Control Check and this means they can now
> >>> retrieve any key for users or machines.
> >>> It is already bad enough that admins can unconditionally set any key,
> >>> but this at least leaves back a pretty big trail (the original client
> >>> password/key fails to work), and is a necessary evil (password resets,
> >>> hosts creation/recovery).
> >>> But I am not very comfortable with the idea an admin can retrieve any
> >>> key without actually ending up changing it. Petr do we have any short
> >>> term plan to address the Admin's super ACI ?
> >>
> >> No, nothing in the short term.
> > 
> > Ok, then I think attached is the patch 0003 we want.
> > This changes admins superpowers to not allow ipaProtectedOperation by
> > default and instead adds a specific right in cn=accounts so admin can
> > keep fetching keytabs for any principal. We may want to turn this into a
> > permission with a future patch.
> 
> Upgrade in F-20 fails:
> 
> Upgrade failed with ACL Syntax
> Error(-5):(targetattr=\22ipaProtectedOperation;write_keys\22)(version
> 3.0; acl \22Admins are allowed to rekey any entity\22; allow(write)
> groupdn = \22ldap:///cn=admins: Invalid syntax.
> IPA upgrade failed.
> 
> You also have $SUFFIX hardcoded as dc=ipa,dc=dev,dc=lan here and in
> default-aci.ldif . I think the fix is to quote the whole thing like:

Arghh :(
Let me fix that, sorry.

> -add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0;
> acl "Admins are allowed to rekey any entity"; allow(write) groupdn =
> "ldap:///cn=admins,cn=groups,cn=accounts,dc=ipa,dc=dev,dc=lan";;)
> +add:aci: '(targetattr="ipaProtectedOperation;write_keys")(version 3.0;
> acl "Admins are allowed to rekey any entity"; allow(write) groupdn =
> "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";;)'
> 
> I don't know if this is your issue or not, but after fixing that the
> upgrade still fails with:
> 
> Upgrade failed with unknown object class "ipaVirtualOperation":

I know nothing about this. I do not touch or manipulate this in any way.

> 2014-06-17T19:17:20Z DEBUG Final value after applying updates
> 2014-06-17T19:17:20Z DEBUG dn: cn=request certificate,cn=virtual
> operations,cn=etc,dc=greyoak,dc=com
> 2014-06-17T19:17:20Z DEBUG objectClass:
> 2014-06-17T19:17:20Z DEBUG      nsContainer
> 2014-06-17T19:17:20Z DEBUG      top
> 2014-06-17T19:17:20Z DEBUG      ipaVirtualOperation
> 2014-06-17T19:17:20Z DEBUG cn:
> 2014-06-17T19:17:20Z DEBUG      request certificate
> 2014-06-17T19:17:20Z DEBUG [(0, u'objectClass', ['ipaVirtualOperation'])]
> 2014-06-17T19:17:20Z DEBUG Live 1, updated 1
> 2014-06-17T19:17:20Z ERROR Upgrade failed with unknown object class
> "ipaVirtualOperation"
> 
> On update the global admin ACI is not changed to add
> ipaProtectedOperation to the list of protected attributes.

uhmm can you show me exactly what your current ACI looks like ?

Simo.

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

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

Reply via email to