...
| Code Block |
|---|
{ specificationFilter or:{ item:posixAccount, item:inetOrgPerson } }
|
And you may have such a prescriptiveACI:
| Code Block |
|---|
{
identificationTag "allowUserToChangeHisOrHerPassword_ACI",
precedence 10, authenticationLevel simple,
itemOrUserFirst userFirst:
{
userClasses {
thisEntry
},
userPermissions
userPermissions {
{
protectedItems {
entry
},
grantsAndDenials {
grantModify
}
},
{
protectedItems {
allAttributeValues { userPassword }
},
grantsAndDenials {
grantRemove, grantAdd
}
}
}
}
}
|
If you want to allow the use to be able to read his/her password value you need to grantRead in the second UserPermission.
Here is a more compact formatted ACI:
| Code Block |
|---|
{
identificationTag "allowUserToChangeHisOrHerPassword_ACI",
precedence 10, authenticationLevel simple,
itemOrUserFirst userFirst:
{
userClasses { thisEntry },
userPermissions
{
{
protectedItems { entry },
grantsAndDenials { grantModify }
},
{
protectedItems { allAttributeValues { userPassword } },
grantsAndDenials { grantRemove, grantAdd }
}
}
}
}
|
BTW, for For this ACI to work, the userPassword attribute should have an existing value before the user tries to add a value. Because otherwise it will mean the creation of the attribute, and the use will need a grantAdd on the attributeType userPassword (which is still possible with our ACI system).