Deny Access Templates for object class creation

Couple of thoughts here:

• 'Strictly limit the membership of the group that actually manages Active Roles itself!  The Active Roles admins are super users and have ALL the privileges of the service account.  Access Templates are virtually meaningless when someone is logged in with an AR admin account.
• Stay away from using Deny in access templates as in the long run, this can really be a nuisance to manage / troubleshoot.
• Instead, build your access templates based on "least privilege" - i.e. what some might call a "white listing" model instead of granting a lot of privileges up front and then trying to restrict them using "Deny's"

When it comes to limiting the "sub classes" of user mailboxes (the Exchange side), these are "object"  permissions (as opposed to object Property permissions) within the Access Template Wizard so you can simply not grant these to begin with.

I had one customer for whom we engineered a special approach that involved managing permissions to the actual right pane menu commands.  This was a special case because they had a need to sub divide user "classes" even more finely.  Normally, the appearance of commands in the right pane is managed by what Access Templates allow you but there is a way to customize this further by changing this visibility to be controlled by a virtual attribute instead.  So if you want to create a custom right pane command and limit its use to specific people, you could control its availability by granting access to a virtual attribute like "edsva_My_Custom_Command1".  Anyone granted write access to this attribute would see your custom command.

'Hope this helps.

Couple of thoughts here:

• 'Strictly limit the membership of the group that actually manages Active Roles itself!  The Active Roles admins are super users and have ALL the privileges of the service account.  Access Templates are virtually meaningless when someone is logged in with an AR admin account.
• Stay away from using Deny in access templates as in the long run, this can really be a nuisance to manage / troubleshoot.
• Instead, build your access templates based on "least privilege" - i.e. what some might call a "white listing" model instead of granting a lot of privileges up front and then trying to restrict them using "Deny's"

When it comes to limiting the "sub classes" of user mailboxes (the Exchange side), these are "object"  permissions (as opposed to object Property permissions) within the Access Template Wizard so you can simply not grant these to begin with.

I had one customer for whom we engineered a special approach that involved managing permissions to the actual right pane menu commands.  This was a special case because they had a need to sub divide user "classes" even more finely.  Normally, the appearance of commands in the right pane is managed by what Access Templates allow you but there is a way to customize this further by changing this visibility to be controlled by a virtual attribute instead.  So if you want to create a custom right pane command and limit its use to specific people, you could control its availability by granting access to a virtual attribute like "edsva_My_Custom_Command1".  Anyone granted write access to this attribute would see your custom command.

'Hope this helps.