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!

  • I assume, in those OU you either have sub OU's which holds user accounts, security groups, contacts etc. My suggestion is you apply Full Access for Users, Full Access for Groups, Full Access Contacts and so on. Don't give Full Access (all objects).
  • I agree with this - it is much cleaner from an auditing perspective as well. That is, when you delegate access to specific classes of objects (ideally using separate access templates), you can see exactly "who can do what to whom" when you look at the AR permissions tab.
  • (in parallel) my understanding: FC over OU to AD\OUADmins group
    (a) does not provide view of the ARS’s CN=Configuration (contains AT, Policies etc…)
    (b) does provide R/W Control over OU
    Because of (a) AD\OUAdmins will not be able to see AT’s and will not be able apply new AT’s. Not sure it will allow remove existing ART links to the OU. AT links are stored as records in hidden CN=ATLinks,CN=Configuration which requires permissions over the CN=ATLinks.
    It is a correct practice to grant FC over OU=<Region> (Regional AD Admins)

    #2. Make sure AD\OUAdmins is not DSAdminitrators (aka ARS Admins with FC over whole ARS)
  • I do confirm AD\EMEAADmins with
     • AT <All Object – FC> on OU=EMEA
     • not DSAdministrators
     got:
     • cannot apply new AT links because do not see CN=Access Templates,CN=Configruation
     • can disable existing AT linked to the OU=EMEA, because FC includes R/W Control
     • (*) cannot see all AT linked to the OU=EMEA (I cannot understand it yet ?!)
    It is a correct behavior.
    Workaround: I will add explicit permission <Deny - Write Control> to same linked AT <All Object – FC>.

  • Hi,

    Thanks for the comments/suggestions.

    I indeed granted read-only access to the Policies for our admins, just to give them insight - this allows them to review the Policy settings, but now has a negative side effect in that, combined with Full Access to All objects, it also allows them to link policies.

    The team is native domain admin, so wanted to give them to most rich experience in AR as well, hence the "full access - all objects". I will look into just adding specific permissions. I agree that's neater, but was more from a convenience perspective I chose that method. Helpdesks do have fine grained access.

    Thanks again!
  • 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).
  • Thanks Johnny - I absolutely see your point here! Rest assured that, aside from the default AR super admins, I never delegated any modify permissions on the AR Configuration node.

    This is also why I was a bit surprised/disappointed to see that by granting read-only access to the AR config area, combined with full access to the "Active Directory" node, it would allow staff to assign Access Templates. I never intended to allow anyone to make any modifications to the AR settings (which, in my opinion, also means assigning Policies and ATs) but I have now found out that this combination of permissions makes that possible anyway.

    I still want to allow staff to see (read-only) the AR policies so I guess that the only safe way out would be to specifically allow access to the object classes they need rather than using "All objects, Full Access" (at the AD level!)

    Thanks again for your input!
  • The subtle "kicker" here is the notion of "Full Access". Best practice when delegating access through AR is to NEVER grant anyone the ability to modify security on objects - i.e. delegation. When you look at the delegation Wizard, in AR, there is a "Full Control" option - granting this allows people to modify security on objects. I believe that if you grant only read/write access to all properties, that this ability to modify delegations goes away.

    If you wanted to go a step further and really be transparent about restricting delegation, you could set a Deny on "Write Control" under Object Access in the delegation Wizard.

  • Hi Johnny,

    Thanks for the tip regarding a Deny on "Write Control" under Object Access in the delegation Wizard.

    I initially tried with an Access Template which only grants Full Control on these classes:
    - Computer
    - Contact
    - Container
    - group
    - OU
    - User

    Unfortunately the above, along with Read-Only permissions on the AR Configuration container, would still allow them to link Access Templates and Policies.

    I've now included the Deny on "Write control" as you mentioned and this eliminated the option completely. Seems like the best solution for me at the moment!
    Thanks again for you effort to get this explained/resolved - much appreciated! Best regards,

    Michiel