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:

• Microsoft best practices for delegating Active Directory administration (white paper and the appendices).
• Securing Active Directory administrative groups and accounts and protecting the Administrator account.
• Well known security identifiers in Windows operating systems (Microsoft knowledge base article 243330).
• Default groups in Windows operating systems.