I figured out how to do this without a separate role.
Create a separate accessControlSubEntry with the following subtree
specification:
{ specificationFilter (objectClass=posixAccount) }
Then add the following prescriptiveACI to it:
{
identificationTag "preventPosixAccountDelete",
precedence 0,
authenticationLevel simple,
itemOrUserFirst userFirst:
{
userClasses
{
name { "uid=crowd,ou=servers,dc=gimmethebrain,dc=net" }
}
,
userPermissions
{
{
protectedItems
{
attributeValue {objectclass=posixAccount },
entry
}
,
grantsAndDenials { denyRemove }
}
}
}
}
…which prevents crowd from deleting the entry or the objectClass=posixAccount
value.
Best regards,
Mike Przybylski
On Jan 7, 2014, at 7:52 AM, Mike Przybylski <[email protected]> wrote:
> Hello, Kiran,
>
> Thank you for the reply.
>
> Performing all deletes with a separate role is a reasonable compromise.
>
> Thank you for the help.
>
> Best regards,
> Mike Przybylski
>
> On Jan 7, 2014, at 1:56 AM, Kiran Ayyagari <[email protected]> wrote:
>
>> On Tue, Jan 7, 2014 at 3:52 AM, Mike Przybylski
>> <[email protected]>wrote:
>>
>>> Hello,
>>>
>>> I’m trying to lock down what my (Atlassian) Crowd server can do to my
>>> directory, and one of the things I DON’T want my crowd server to do is
>>> delete any users with objectClass=posixAccount.
>>>
>>> However, the following…
>>>
>>> protectedItems
>>> {
>>> entry,
>>> attributeValue {objectclass=posixAccount }
>>> }
>>> ,
>>> grantsAndDenials { denyRemove }
>>>
>>> …prevents the deletion of any entries.
>>>
>>> Is protecting an entry with a specific objectClass attribute value even
>>> possible? If so, how do I configure the prescriptiveACI properly?
>>>
>>> AFAIK, this is not possible, instead if you want to prevent the user used
>> by Crowd server to connect
>> to the directory server from deleting entries then add a special role to
>> that user and apply the below
>> given ACI (forget not to replace the value of userGroup)
>>
>> {
>> identificationTag "preventEntryDelete",
>> precedence 15,
>> authenticationLevel simple,
>> itemOrUserFirst userFirst:
>> {
>> userClasses
>> {
>> userGroup { "cn=Operator,ou=groups,dc=example,dc=com" }
>> }
>> ,
>> userPermissions
>> {
>> {
>> protectedItems { entry },
>> grantsAndDenials
>> {
>> grantFilterMatch,
>> denyRemove,
>> grantBrowse,
>> grantRead,
>> grantReturnDN
>> }
>> }
>> }
>> }
>> }
>>
>> HTH
>>
>> Best regards,
>>> Mike Przybylski
>>
>>
>>
>>
>> --
>> Kiran Ayyagari
>> http://keydap.com
>
