Deny Access Templates for object class creation

Hello all,

Kind of a bind i can't seem to figure out.. Creating Access templates to deny creation of common object classes except for certain ones, ie only allow group creation in a groups ou and only showing that as an option under new

Running into an issue as when allowing user class creation, i get user and the 4 group mailbox type under new as they are considered user class objects. Any way to differentiate them?

any ideas would be greatly appreciated!

  • 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.

  • Active Roles already splits the object creation permissions for these mailboxe types out into constructed attributes.

    If you don't want someone to create a Room Mailbox, for example, don't grant them access to the "edsva-MsExch-CreateRoomMailbox" attribute.