Active Directory (AD) is the core of a Windows Server network and consists of a database that stores usernames and passwords, plus several technologies that work together to provide security and management services to clients and servers. Domain controllers (DCs) are servers that host a copy of the AD database and run related services.
Technical personnel sometimes require access to domain controllers, maybe to perform maintenance connected to backup, patching or a one-off task. This leaves security administrators with something of a quandary, as most of the work likely to be carried out requires full administrative access to the DC, and in turn the crown jewels – Active Directory.
Let’s make it simple and start off by saying that it’s not possible to separate AD and administrator permissions on a regular DC. If you need to grant a user domain administrator permissions to complete some work on a DC, you must trust that person with full access to the AD domain. Read-only domain controllers (RODCs) do exactly what they say on the tin and host a read-only copy of the Active Directory database. Wherever possible you should deploy RODCs, as any domain user can be given permission to install and manage the server without privileged access to Active Directory.
Windows IT professionals often assume that the built-in Server Operators group in AD gives the equivalent of local administrator access to DCs without elevated rights to Active Directory. This is not strictly true and any kind of administrative permission on a DC can result in the user gaining privileges to AD. All built-in AD groups that end in ‘Operators’ are legacy groups and shouldn’t be populated unless you have an application that requires it. For example, if you need to grant permission to perform backup duties, create a new group and assign rights as necessary.
One approach you could adopt to grant admin privileges to DCs is to issue a unique username and password each time access is requested. The credentials are assigned to a technician for a given period of time and for an agreed piece of work. This information is recorded and permissions revoked at the end of the allotted session. Setting up the user account and recording the necessary logon session details is often done manually, although can be automated. The person requesting access is responsible for anything that happens during their logon session. Nevertheless, you still need to trust that person with Active Directory.
Depending on the type of work being carried out, a 3rd-party solution, such as Avecto's Defendpoint, could be deployed to allow a standard user to run only pre-approved applications with elevated privileges, greatly reducing the risk involved. Even if a technician must perform a task regularly on a DC, think twice before granting permanent permissions to sensitive production systems and always make sure that all actions are audited.
Russell Smith, IT Consultant & Security MVP
Russell Smith specializes in the management and security of Microsoft-based IT systems. In addition to blogging about Windows and Active Directory for the Petri IT Knowledgebase, Russell is a Contributing Editor at CDW’s Biztech Magazine.
Russell has more than 15 years of experience in IT, has written a book on Windows security, co-authored one for Microsoft’s Official Academic Course (MOAC) series and has delivered several courses for Pluralsight.
