Delegation of Active Directory administration (using Quest ActiveRoles Server)

Recently, I’ve been working with a client who has an extraordinarily high number of users with domain administrator rights (i.e. those who are members of the Domain Admins group). The problem is historic and they are in the process of moving from Windows NT to Active Directory (AD); whilst AD allows for delegation of control over objects (although best practice dictates that delegation occurs at organisational unit level), under NT the limit for delegation was the domain.

In order to reduce the number of Domain Admins, I’ve been producing a delegation model for AD administration that is intended to provide a pragmatic balance between the granular control that AD can provide and the access requirements of each support team, yet still remains realistic from a management perspective. One major issue is that, whilst Microsoft provides several-hundred pages of documentation and a delegation of control wizard, there are no native tools to keep track of the objects over which control has been delegated. Consequently it’s often necessary to resort to third party tools.

One such tool is ActiveRoles Server (ARS) from Quest Software. Quest inherited this technology with their acquisition of Aelita Software (they had previously inherited another product, now known as ActiveRoles Direct, when they purchased FastLane Technologies). Installed onto a Windows server (which should be secured as any domain controller would be), the current incarnation of the product, uses a SQL Server database for configuration data (rather than schema extensions as some previous products did) and publishes itself as a connection point object within AD. The configuration database can be mirrored via SQL replication for redundancy, with one server acting as a publisher and one as a subscriber whilst the connection point model allows for load balancing between the two servers.

In terms of management, ARS can be administered using a Microsoft management console (MMC) snap-in, a browser interface, or using AD services interface (ADSI). By default, ARS will bind to the first AD domain controller that it finds, although this can be overridden in the management toolset.

Despite not extending the AD schema, ARS allows additional attributes to be stored for an object. These attributes are placed within the ARS configuration database and can be used for provisioning (e.g. conditional filtering on attributes) or for storing additional information on a user (e.g. staff ID number). Propagation of directory data to other LDAP directories and Microsoft Identity Integration Server (MIIS) are supported via Quick Connect for ActiveRoles Server and Unix support can be provided using through a support pack for Vintela Authentication Services. ARS can also expose attributes that are not normally visible in the standard Active Directory Users and Computers MMC snap-in.

In order to allow for user rights to be elevated as required, user access is proxied via the ARS service account, which should be given the highest level of permissions that will be allowed (e.g. Domain Admins). This means that all access is via ARS, allowing for auditing and reporting of rights use. Quest’s recommendation is that users are not assigned native rights within Active Directory (beyond the standard read-only permissions given to an authenticated user). In this way, all rights can be managed via ARS (otherwise privileged users could circumvent ARS, avoiding any auditing of their actions); however there is also an option for ARS-delegated rights to be propagated to Active Directory if required.

Some ARS terminology includes:

  • Access templates: pre-defined role descriptions controlling what a user can/cannot do. ARS allows further granularity than native AD rights – for example controlling which attributes a particular user can edit on an object (e.g. allowing for self service of certain directory attributes via a web interface).
  • Managed units: query-based filters for management of roles (effectively a virtual OU). This avoids issues whereby best practice recommends delegation at OU level but the OU structure is generally designed with group policy in mind.
  • Policy objects: rules applied to objects as they are created (e.g. when creating a user in a particular OU, add them to certain security groups).
  • Script modules: bespoke code that allows policy objects to be extended beyond the standard capabilities of AD OUs and group policy (e.g. when creating a user account, e-mail the telephone system administrator and ask them to populate the user’s telephone number in AD).

ARS seems pretty powerful but it does have some limitations:

  • Firstly, it operates at the domain level, so delegation of forest-level tasks does not seem to be supported.
  • Secondly ARS is used to provide delegation of control over directory objects – not the resources protected by the directory itself (e.g. file systems). This means that ARS can be used to control the administration of the groups that allow access to a particular resource; but there is nothing that it can do to prevent a sufficiently-privileged user from bypassing ARS and accessing a resource directly.

In reality, this has meant that my client has built part of the delegation model for AD using the Quest tools (the translation of the IT policy and procedures to a provisioning model built around ARS) whilst I have based the administration model for the servers and computers within the domain (as well as forest-wide operations) around Windows groups, with procedural control over the use of privileged and non-privileged accounts.

Although I’ve been working with Active Directory since Windows NT 5.0 beta 2 (about 8 years now), this is the first time I’ve really looked at the administration model. It’s been a difficult process for me – to do it properly requires business analysis skills as well as (and probably more than) technical knowledge. The following links might be useful to anyone else who is looking at delegating AD administrative control:

9 thoughts on “Delegation of Active Directory administration (using Quest ActiveRoles Server)

  1. Mark,

    Hello! I wanted to offer our products as a comparison that doesn’t suffer the same cross-forest limitation as Quest. Our EmpowerID Suite works in any domain scenario (trusted & untrusted). It also works with Microsoft ADAM. We have 30 day trials if you would like to do a head to head comparison.
    P.S. we also have a live demo center running the products at:



  2. Mark,

    We have implement ARS and use it for administration across our ICT support operation.

    I am glad you have done the same as what I plan to implement in our company which is a delegation with ARS purely for User and Group Objects NOT server delegation.

    ARS provides a very good interface into AD and I beleive can be customised heavily.

    Daniel Eason
    Infrastructure Manager, OCS Group

  3. Hi Mark,

    Cheers to you and your excellent blog. My name is Bob Bobel and I am the ActiveRoles Server product manager for Quest Software. I enjoyed reading your entry on my product and wanted to make a quick comment on the multi-forest support we offer.

    ActiveRoles Server does indeed allow for the management of multiple domains from the same or from different forests. Delegation of a single Access Template (a.k.a. role), property generation/validation policies (a.k.a. rules) and AutoProvisioning polices can all be applied one time and be affective on all “managed Domains” regardless of forest affiliation.

    In addition, you can create Managed Units (a.k.a. views) whose members come from any managed domain regardless of forest affiliation. This allows you to dynamically delegate control over objects so permissions are only granted to the trustee when the object is in a state to match the criteria of the view. For example, I could grant un-lock accounts to a centralized help desk and then create a view that showed only the accounts in a locked-out state. After the account is unlocked by the help desk the account no longer would be displayed in the view the delegated permission is essentially revoked. Because of our architecture there is no problem with ACL bloat in AD that other products have.

    Bob Bobel

  4. Hi Bob – Thanks for dropping by and setting the record straight re: ARS and forest-level activities.

    On reflection, I don’t think I made myself as clear as I should have done; however as far as I can see, ARS doesn’t let me control which administrators can use native AD tools to carry out activities outside the control of ARS, leaving me with little more than AD groups and procedural control to prevent highly privileged account holders from circumventing ARS altogether.

    Nevertheless, ARS (and the Quest toolset in general) is certainly impressive in its ability to assist in many other areas of Active Directory administration – including Bob’s example of allowing helpdesk staff to carry out a limited and completely customisable set of tasks.

    Unfortunately, despite Patrick’s offer, I don’t have the time do carry out a head-to-head between Quest ActiveRoles Server and TDNF EmpowerID at the moment, but hopefully the information in this post has been useful to others else looking at delegating control over AD.


  5. hi mark – i thought your blog entry was very timely for me, as we are discussing the use of activeroles for the delegation of rights and the restriction of administrative privileges at my company.

    however, there is some concern from some of the administrative staff that involve the topic – why go with a third party tool if we could just buy licenses for ms lifecycle management tool (formerly MIIS).

    Are you able to elucidate the differences for me?

  6. Hi Dave,
    Glad you found this useful. I haven’t looked at Microsoft Identity Integration Server (MIIS) for a while (I did post an overview on managing identity with MIIS back in April 2005) so I’m not really sure of the differences between ActiveRoles Server (ARS) and Microsoft Identify Lifecycle Manager (ILM) 2007; however my initial impression is that MIIS was more about mapping various identities into one metadirectory, whereas ActiveRoles is about delegation of control based on job function. It could be that ILM’s functionality extends the MIIS model to better cover what ARS does but it’s probably worth talking to both your Quest and Microsoft account managers.

    HTH, Mark

Leave a Reply