On 10/09/2014 06:53 PM, Nathaniel McCallum wrote:
this doesn't look like full acl logging, did you set errorlog-level to
include 128 ?
On Thu, 2014-10-09 at 18:38 +0200, Ludwig Krispenz wrote:
On 10/09/2014 06:32 PM, thierry bordaz wrote:
On 10/09/2014 06:27 PM, Nathaniel McCallum wrote:
On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote:
On 10/08/2014 11:46 PM, Nathaniel McCallum wrote:
The background of this email is this bug:
Attached are two patches which solve this issue for admin users (not
very helpful, I know). They depend on this fix in 389:
There are two outstanding issues:
1. 389 does not send the post read control for normal users. The
operation itself succeeds, but no control is sent.
The relevant sections from the log are attached. 389 is denying access
to the following attributes (* = valid, ! = invalid):
The post read control needs access to the modified entry to
This access is granted at the condition, the binddn can access
Agreed and understood.
My understanding is that the target entry is
and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com".
The only ACI I found that match this target is:
aci: (targetfilter = "(objectClass=ipaToken)")
(targetattrs = "objectclass || description || managedBy ||
ipatokenUniqueID || ipatokenDisabled
|| ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor
|| ipatokenModel || ipatokenSerial || ipatokenOwner")
(version 3.0; acl "Users/managers can read basic token
info"; allow (read, search, compare) userattr =
"ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";)
Do you know if the target entry has 'ipatokenOwner' or
'managedBy' with the binddn value ?
Yes, both. So why is access to objectClass (et cetera) being denied?
could you post the full aci logging not only the summary for the access
to the attributes ?
Freeipa-devel mailing list