Delegation of Administration in Active Directory

Active Directory administration is usually a heavy task if it is done only by Domain Admins. That is why many companies proceed with the delegation of administration to other people / teams in order to offload specific tasks.

This delegation could be done via multiple ways and each of them has its own advantages and drawbacks.

This Wiki discusses the following ways for the delegation of administration in Active Directory:

1. Updating Active Directory ACLs to grant direct access to objects
2. Using scripts running with service accounts to achieve administrative tasks

Updating Active Directory ACLs to grant direct access to objects:

Active Directory Users and Computers snap-in allows the delegation of administration by updating ACLs on the following levels:

• Domain 
• Organizational Units 
• Containers 
• Objects 

ACLs can be updated with two possible ways:

1. Using Delegation of Control Wizard: It allows delegating new permissions on the Domain / Organizational Units level
2. Using Security tab: It allows delegating or removing permissions

Delegation of Control Wizard is the easiest way to delegate new permissions. You just need to proceed like the following in order to use it:

• In Active Directory Users and Computers snap-in, do a right-click on the Domain / Organizational unit you would like to delegate administration on it then select Delegate Control…

• Click on Next >

• Select the user / group to whom you want to delegate control and then click on Next >

• Select Delegate the following Common tasks if you would like to select a pre-defined task to delegate or select Create a custom task to delegate if you would like to create a customized one. Once done, click on Next >

• Click on Finish once you finished specifying the tasks to delegate

Using Security tab is also an option to add new permissions but it is more useful to remove existing ones.

Using scripts running with service accounts to achieve administrative tasks:

Active Directory administration could be done without granting explicit permissions to persons / teams. That is feasible by developing scripts that does the changes using service accounts.

The advantages are the following:

• Only authorized changes will be allowed
• The company standards and rules can be applied in a better way
• All Active Directory changes can be tracked in a better way (Changes can be communicated by e-mails, stored in databases …)
• The delegation is based on tasks and not on roles

The disadvantage of this approach is that changes in Active Directory will be logged as done by service accounts and not the user who launched the scripts. That makes auditing more complicated when using event viewer to track changes in Active Directory. An alternative way of tracking is to use the scripts’ capabilities to introduce a new layer of tracking (Mail notifications, storage of events in databases …).

Windows PowerShell is a good candidate to make this delegation method true. This is applicable for cmdlets having –Credential switch available.

Example: Below are Powershell commands that allow updating a user account title and mail attributes with other credentials:

Import-module activedirectory $Username = 'FABRIKAM\serviceaccount' $Password = 'P@ssword' $pass = ConvertTo-SecureString -AsPlainText $Password -Force $Cred = New-Object System.Management.Automation.PSCredential -ArgumentList $Username,$pass Set-ADUser GlenJohn -Replace @{title="director";mail="glenjohn@fabrikam.com"} –Credential $Cred

The problem with using Powershell in these cases is that the users running these scripts will be able to get the passwords and use the service accounts credentials to make changes without calling the scripts. This can be avoided by using programs that allow creating an exe file that can run Powershell scripts without exposing the source codes or developing programs that do the same once compiled.