This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Delegate Full Access but prevent assigning of additional Access Templates

Hi,

In my company, I have delegated Full Access (all objects) to several Organizational Units in AD - I recently noticed this also allows admins to assign additional Access Templates to allow other users to have access to that same area. Is there any way I can prevent this from happening? I don't mind them seeing the existing config or the templates themselves, but they should not be able to assign or remove any Access Templates. I already tried blocking class "Access Templates" but that didn't seem to help (guess that only locks out modifying the templates themselves). Couldn't find the option for denying (un)assigning templates or policies etc.

Thanks!

Parents
  • Michiel,
    I would suggest you tread very carefully here. It's one thing to delegate access to AD and another thing to delegate access within ActiveRoles itself. I tend to recommend to my customers to avoid delegating anything beyond 'read' over the configuration of AR itself as if you do, you are into creating 'delegation over delegation'. Doing this in some respects confounds the AR delegation concept in the first place. i.e. You run the run risk of re-creating the problem that AR is supposed to solve which is too many people with too many privileges. Moreover, if you start delegating modify access to parts of the AR configuration, you can run up against an issue I have seen where Change History doesn't seem to work consistently on AR configuration objects. At that point, you are into having to rely on the AR Event Log which for some people, is a bit unfriendly to decipher (unless you store it in SQL with the Collector and use the audit reports - but this has its own challenges that I won't get into here).
Reply
  • Michiel,
    I would suggest you tread very carefully here. It's one thing to delegate access to AD and another thing to delegate access within ActiveRoles itself. I tend to recommend to my customers to avoid delegating anything beyond 'read' over the configuration of AR itself as if you do, you are into creating 'delegation over delegation'. Doing this in some respects confounds the AR delegation concept in the first place. i.e. You run the run risk of re-creating the problem that AR is supposed to solve which is too many people with too many privileges. Moreover, if you start delegating modify access to parts of the AR configuration, you can run up against an issue I have seen where Change History doesn't seem to work consistently on AR configuration objects. At that point, you are into having to rely on the AR Event Log which for some people, is a bit unfriendly to decipher (unless you store it in SQL with the Collector and use the audit reports - but this has its own challenges that I won't get into here).
Children
No Data