Tricky Permissions / When MPR go bad

I’ve reached that special time of the project when it’s time to kick the tyres and test things before releasing an update onto the unsuspecting client and as I’m going back through the test scripts using a number of user accounts was very surprised when one of my RCDC suddenly stopped allowing me to add or remove values to one of my attributes – not by blocking access to the identity picker or locking it to prevent it from being edited, but by throwing an ‘Unable to process your request’ error once you’ve clicked Ok to complete the change.


Naturally I checked the various Requests and could see a Denied Status along with the MPR that was correctly firing to give me the results.



Once I checked the MPR I was more than a little confused as the attribute involved was listed in the ‘Target Resources’ list and when I attempted to edit the user the RCDC was being correctly displayed!

It was only when I went back a tab and checked the ‘Requests and Operations’ that I noticed what was causing the problem – while I’d set the MPR to grant permission and rights over the key attribute, what I’d neglected to do is set the rights to allow values to be added or removed to a multi-value attribute.


It seems that even though the MPR doesn’t actually grant rights to manage a multi-valued attribute, the fact that I’d allowed a single-valued attribute to be edited combined with the correct attribute being listed in the target resources was enough to trick the RCDC into displaying and operating as though the user actually did hold permission to perform an update.

Fortunately this one’s an easy fix, but it was a fraught hour tracing everything through before I spotted it.

This entry was posted in facepalm, FIM, Testing, Troubleshooting and tagged , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *