On 03/30/2015 01:03 PM, Petr Spacek wrote:
On 30.3.2015 11:50, thierry bordaz wrote:
Hello,
The aci "Admin read-only attributes" grants, for the complete
suffix, read access to 'admin' users for the following attributes.
"ipaUniqueId || memberOf || enrolledBy || krbExtraData ||
krbPrincipalName || krbCanonicalName || krbPasswordExpiration ||
krbLastPwdChange || krbLastSuccessfulAuth || krbLastFailedAuth"
"userPassword" and "krbPrincipalKey" are not "read-only" attributes
so I guess it is the reason why they are not part of this list.
For User life cycle, I would need admin users to be granted read
access on "userPassword" and "krbPrincipalKey".
The scope could be limited to Stage container but I was wondering if
there is a security reason to not grant read access on the full suffix ?
AFAIK admins were not given read access to keys and passwords on purpose as a
security measure. It prevents accidental key disclosure when admin does
ldapsearch and posts result somewhere (e.g. while debugging something).
Yes that sounds a very good reason.
I did not follow the whole user life-cycle discussion. Why you need read
access to it? Is it because you plan to do add/del instead of modrdn?
There are two use case where I think I need access to those attributes:
* A stage entry can have userpassword/krb keys attributes.
When activating an entry those values are copied to a the active entry.
So the newly active user can authenticate with the credential set
while his entry was in stage container.
In that case, it would need a read access because the stage entry is
copied into a new entry (ADD).
* An active entry is deleted (preserve mode), so the entry is modrdn
to the delete container.
Then to prevent the reuse of old credential, those attibutes are
cleared.
So here I would need a read/search/write access to those attributes
in the delete container.
That means that if I limit the ACIs to stage/delete containers, an admin
could accidentally disclose stage/delete entries keys.
thanks
thieryr
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
