What is a domain controller for

What Is a Domain Controller, and Why Would I Need It?

User authentication and authorization are critical for protecting your network infrastructure. It ensures that only trustworthy and relevant users can access the network. A Windows Server domain logically groups users, PCs, and other objects in a network, while a domain controller authenticates access requests to the domain’s resources. It also stores information about user accounts and devices and enforces security policies.

Learn the important role of a domain controller within a network infrastructure, and set it up with fault tolerance.

What Does a Domain Controller Do?

Each PC has its own local accounts, but these accounts cannot be used to access the network. This is because it makes more sense for the IT administrators to configure and manage user accounts centrally, not separately on each PC. Also, centrally managed user accounts that are not tied to a particular device allow users to access network resources from just about any workstation. And that is exactly why domain controllers are essential for your organization’s IT infrastructure.

In a network infrastructure, domains are used to group computers and other devices in the network for ease of administration. And within a domain, the domain controller is used to authenticate and authorize users and store account information centrally instead of individually on each computer.

Domain controllers are security essentials for Windows Server domains and were initially introduced in Windows NT (first released in 1993). Basically, a domain controller is a server computer that acts like a brain for a Windows Server domain. It stores user credentials and controls who can access the domain’s resources. Whenever a user tries to access a domain, the request must go through the domain controller, which then runs the login process for validating the user. The domain controller also determines access privileges based on user roles, e.g., regular users and system administrators. It ensures that bad actors stay out, and only authorized users can access the relevant resources in the domain they control.

Why is a Domain Controller Important?

Domain controllers oversee everything within domain access, preventing unwanted access to domain networks while allowing users to use all approved directory services.

Because the domain controller controls all network access, it’s critical to safeguard it with additional security features like:

Because domain controllers handle all of the access to a company’s computing resources, they have to be built to withstand attacks and then still be able to function in the face of adversity.

What Is Active Directory?

Microsoft introduced Active Directory (AD) for centralized domain management in Windows Server 2000. But later in the 2008 Windows Server, Active Directory also included other services such as Directory Federation Services for Single Sign-On, security certificates for public-key cryptography, rights management, and Lightweight Directory Access Protocol (LDAP).

Essentially, an Active Directory is a framework for managing several Windows Server domains, while a domain controller is a critical part of the Active Directory. The server runs the Active Directory and authenticates users based on the data stored in the Active Directory.

An Active Directory stores information as objects organized into forests, trees, and domains. Each AD forest can have multiple domains, and domain controllers manage trusts between those domains to grant users from one domain access to another domain. Several types of trusts exist between domains:

System administrators can also set security policies through domain controllers, such as password complexity.

Setting up Domain Controllers in Active Directory

The Benefits of a Domain Controller

Benefits of a domain controller include:

Why Should I Have a Secondary Domain Controller?

A domain controller authenticates and authorizes users, which is a primary security function in a network infrastructure. It has all the keys to the realm of your Windows Server domain. Now, if your domain controller goes down, there will be no way for your users to authenticate themselves and access any of the domain’s resources. All applications, services, and even business-critical systems that require Active Directory authentication will be inaccessible. Automatic designation of Internet Protocol (IP) addresses will fail, forcing system administrators to revert to manual assignments.

You may even have to rebuild your entire server from scratch, which could take days and even weeks if your company does not have an established backup protocol. This is why resilience is so important for ensuring business continuity and minimal or no downtime. Investing in a secondary domain controller can reduce downtime considerably in the event of domain controller failure. While your IT team works to restore the failed domain controller, a secondary domain controller will ensure that your users are able to access important domain resources and that business-critical systems and services keep running until everything goes back to normal.

With a secondary domain controller, you can avoid complete failure. Having a recent backup at the infrastructure level can speed up and simplify the restoration process for the primary domain controller. It may look like an additional burden initially, but it can save your IT team from investing time and resources in reconstructing the entire infrastructure from scratch under extreme pressure as business operations come to a halt.

How Can Cloud Directory Services Help?

Previously, IT infrastructure was largely Microsoft-based, so companies relied entirely on Microsoft’s Active Directory for access management. But now, as IT networks are increasingly shifting to the cloud, cloud-based access management options have also emerged. Cloud directory services are a modem alternative to the traditional, on-premises Active Directory. Delivered through the cloud, these services can be used to build an identity management system from scratch or extend your company’s Active Directory services across cloud and on-premises environments.

Cloud directory services provide similar functionality to Microsoft Active Directory services along with the added security, scalability, and convenience of the cloud. For companies running on a single domain controller, cloud directory services, such as Azure Directory, make it extremely simple and quick to set up a secondary domain controller in the cloud. With a secondary domain controller within the Azure cloud, your Network infrastructure can enjoy business continuity and resilience at a very low cost.

By setting up a secondary domain controller in Azure, your company can leverage the comprehensive identity and access management solution provided by Azure Active Directory. This includes managing users and groups and providing secure access to users across a number of Software as a Service (SaaS) applications. This could also bring your company a step closer to compliance with General Data Protection Regulation (GDPR) and Cyber Essentials.

Parallels RAS Uses Active Directory Authentication

Parallels ® Remote Application Server (RAS) provides consolidated access management by making use of Active Directory and supports Azure Directory services. Parallels RAS Client Group Policy enables IT administrators to enforce client policies on Active Directory groups and endpoint devices to keep corporate data safe regardless of the end-user, the device, and the location from which the network is accessed.

Parallels RAS Enrollment Server enrolls and manages digital certificates and authenticates users without them having to enter their Active Directory credentials by communicating directly with the Microsoft Certificate Authority. Companies can easily configure a third-party identity provider like Azure with Parallels RAS to provide a true single sign-on (SSO) experience across subsidiaries.

Centrally control, manage and restrict access for your users.

Domain Controller (DC)

Table of Contents

What Does Domain Controller (DC) Mean?

A domain controller (DC) is a server that responds to security authentication requests within a Windows Server domain.

It is a server on a Microsoft Windows or Windows NT network that is responsible for allowing host access to Windows domain resources.

A domain controller is the centerpiece of the Windows Active Directory service. It authenticates users, stores user account information and enforces security policy for a Windows domain.

It allows hierarchical organization and protection of users and computers operating on the same network.

In simpler terms, when a user logs into their domain, the DC authenticates and validates their credentials (usually in the form of username, password and/or IP location) and then allows or denies access.

Techopedia Explains Domain Controller (DC)

A domain controller gives access to another domain in a trust relationship so that a user logging into a domain can access resources in another domain.

Early versions of Windows such as Windows NT had one domain controller per domain, which was called a primary domain controller.

All other domain controllers were backup domain controllers.

Beginning with Windows 2000, the primary domain controller and backup domain controller roles were replaced by Active Directory.

The domain controllers in these domains are considered to be equal, as all controllers have full access to the accounts database stored on their machines.

When a network is comprised of hundred of computers, managing the authentication of each individual machine may be too complicated.

To simplify this task a single computer (the domain controller) can be dedicated to manage all the authentications for all the others (the clients).

All login credentials of all client computers and devices connected to the network are stored in the DC’s Active Directory. The Active Directory is shared by all computers on the network, and whenever a user tries to login, their credentials are checked against those saved in this master directory database.

To strengthen security, no one except the administrator of the DC has the authority to change security or login information or add new computers to the domain.

A DC is usually a key target during a cyberattack since it represents a primary entry point to the entire infrastructure. To prevent serious data breaches, they are usually protected with robust cybersecurity measures.

To ensure that network resources are always stable and readily available, DCs are often deployed as a cluster.

The network administrator may designate a single primary domain controller (PDC) as well as additional backup domain controllers (BDCs). Periodically, the PDC automatically creates a backup copy of the Active Directory database on all BDCs that is stored in read-only format.

If the server performing the domain controller role is lost, the domain can still function. If the PDC is not available or fails, the administrator can designate an alternate BDC to assume the role.

BDCs are also used to ease the workload when the network is too busy.

domain controller

A domain controller is a type of server that processes requests for authentication from users within a computer domain. Domain controllers are most commonly used in Windows Active Directory (AD) domains but are also used with other types of identity management systems.

Domain controllers restrict access to domain resources by authenticating user identity through login credentials, and by preventing unauthorized access to those resources.

Domain controllers apply security policies to requests for access to domain resources. For example, in a Windows AD domain, the domain controller draws authentication information for user accounts from AD.

Domain services, such as those that domain controllers provide, are just one part of Microsoft Active Directory.

A domain controller can operate as a single system, but they are usually implemented in clusters for improved reliability and availability. For domain controllers running under Windows AD, each cluster comprises a primary domain controller (PDC) and one or more backup domain controllers (BDC). In Unix and Linux environments replica domain controllers copy authentication databases from the primary domain controller.

Domain controllers control all domain access, blocking unauthorized access to domain networks while allowing users access to all authorized directory services.

The domain controller mediates all access to the network, so it is important to protect it with additional security mechanisms such as:

Domain controllers control all access to computing resources in an organization, so they must be designed to resist attacks and to continue to function under adverse conditions.

Domain control is a function of Microsoft’s Active Directory, and domain controllers are servers that can use Active Directory to respond to authentication requests.

Experts advise against relying on a single domain controller, even for smaller organizations. Best practices call for one primary domain controller and at least one backup domain controller to avoid downtime from system unavailability.

Another best practice is to deploy each domain controller on a standalone physical server. This includes virtual domain controllers, which should be run on virtual machines (VMs) running on different physical hosts.

Domain controllers can be deployed on physical servers, running as VMsor as part of a cloud directory service.

Steps for setting up an AD domain controller include:

Specifics for setting up and configuring AD domain controllers vary depending on the version of Windows Server in use on the domain.

See video below for how to set up a domain controller in Windows Server 2019.

The following options are available when setting up a domain controller with AD:

Domain controller benefits include:

Some domain controller limitations include:

Domain controllers are fundamental to securing unauthorized access to an organization’s domains. Learn how to set up and deploy a Windows Server 2016 domain controller securely.

Related Terms

domain

Microsoft drops emergency patch after Patch Tuesday screw up

Active Directory Domain Services (AD DS)

active directory

Microsoft’s Azure Advisor service offers recommendations based on five categories. Learn these categories and the roles they play.

Many user tasks rely on the browser used, but not all browsers are well suited to these tasks. Learn the strengths and weaknesses.

While there are plenty of similarities across web browsers, the processes that they consume RAM with can greatly differ. This may.

What Is a Domain Controller?

A domain controller is a type of computer server that responds to security authentication requests and verifies users on the domain of a computer network. The controller is a gatekeeper for allowing host access to domain resources. It also enforces security policies, stores a user’s account information, and authenticates users for a domain.

This blog looks at the approach attackers use, after gaining an initial foothold on a domain controller, to discover and understand an environment prior to moving laterally. Many of the techniques effectively “live off the land” of an endpoint or server to eventually get to domain controllers and launch an attack. Our next post will examine some ways attackers move laterally, and lastly, we’ll explore mitigations for preventing lateral movement.

Attackers find a way in.

Once they do get in, it is a matter of moving laterally, often to reach the domain controller in order to orchestrate an attack. Once an attacker has access to it, they are effectively an IT admin, so “living off the land” could not be easier. Let’s examine an attack, assuming breach—that an attacker will eventually find a way in.

But first, let’s look at domain controllers. You likely know this already, but a Microsoft Domain Controller server, Active Directory, is responsible for authenticating access (verifying users logging on) to a Windows domain and associated network resources. It holds a directory of users, groups and computers and is a repository of network services such as file shares, network shares and printers. A server provisioned with the Active Directory Domain Services roles becomes a domain controller. It is also installed with a DNS server to manage name resolution and other internal network services. Although quite heavily GUI driven, a domain controller and active directory server are very complex, especially in a typical corporate network where there is likely to be several for replication and fault tolerance.

Windows Server 2012 – Server Manager Dashboard showing three roles: AD directory server, DNS and file services.

As a result of the heavily intertwined roles on a Windows domain, the domain controller hosts many different services depending on the number of roles it is provisioned to perform. Roles such as DNS for name internal resolution, Kerberos ticketing for authentication, Server Message Block, Certificate services and a whole lot more. This broadens the attack surface and indeed there are many attacks against components such as:

Most of these attacks are heavily facilitated by network traversal. All these services come with associated ports and protocols.

The table below shows the ports and protocols likely to be used by a typical domain controller that must be left open. This amounts to an expansive attack surface that bad actors can make use of. The challenge is that if we decided to close ports, to reduce attack surfaces, Active Directory ceases to function properly.

Path to the domain controller

The premise here is aligned with the assume breach philosophy which implies that a threat actor may already have unauthorized access to your systems or network, albeit possibly with lower-level privileges. For example, this could be the compromise of a user account via phishing that may, in turn, lead to business email compromise (BEC). This will also imply that the threat actor is more than likely trying to work their way to a higher privileged account and subsequently crown jewel system such as the domain controller.

Let’s look at a hypothetical attack flow following this pattern:

The initial attack involves a phishing email to an employee. This phishing attack contains a link to a fake Office 365 OneDrive login which the employee falls for. In conjunction with javascript execution and in some cases vulnerability, such a link automatically runs a memory-only malware leveraging Windows Powershell. This then leads to a reverse shell command and control (C&C) backdoor from the compromised user’s Windows laptop back to the attacker. This is the starting point for this article’s ‘assume breach’ premise.

The attack up to this stage will be mostly automated so the attacker will likely get a C&C notification about a new shell and therefore a new compromised machine. They are also going to be mainly oblivious of the full details of the compromised system such as user accounts, privileges and network resource access. This is where the ATT&CK Discovery Phase is important to an attacker.

ATT&CK: Discovery

What is the first thing you must do to pivot from a single system, be it employee endpoint or workload, to a domain controller?

As ATT&CK would say in the Discovery phase, “try to figure out the environment.”

Adversaries begin by understanding who the user of the system is, the running processes, file/directory/group membership and session information.

Tools like NMAP for port scanning are an option to get a lay of the land to see what services are listening on remote machines they can exploit. Additionally, Bloodhound can be used to map the Active Directory environment to understand the fastest way to the domain controller.

These tools have been used in attacks, however, they have an inherent challenge. They draw too much attention to themselves as third-party tools that generate traffic. They are chatty and somewhat overt, meaning they could be detected by security systems.

Attackers are best served by simply «living-off-the-land» when they have access to a domain-joined endpoint or workload. This way they use tools that are native to the endpoint and don’t generate any noise on the network.

Attackers can begin with basic CLI commands many of us are familiar with as an easy, discreet way to understand where they are and what they can do next.

On a domain-joined client machine, commands like whoami will allow for the discovery of the system owner or user, and show an output similar to what is shown below.

This lets the attacker build an account profile of the compromised system to see what that account has access to. A quick look at the Active Directory groups that the machine is a part of lets the attacker discern that the user is for example, on the Finance team. They know that they’ll likely have access to finance file shares to exploit or may choose to immediately examine files on the machine if finance data is what they are after.

The threat actor can also use a simple yet effective command like net users and associated switches to discover the name of the domain controller their compromised machine is joined to and the list of user accounts that exist on the domain controller.

From here, there is a clear set of important details that can aid their path to the domain controller.

They may also be able to decipher additional subnets and routes and their corresponding Gateways and corroborate that routing information with reverse DNS details of, for example, network share server names.

Most organizations use network shares for employees within the same team to share and sometimes archive information. Threat actors can leverage Windows network share detail from built-in utilities such as net use to locate File Servers or even domain controllers. They can also use this information combined with any compromised or escalated accounts to access hidden Windows network shares like AMDIN$ or C$. These can be used to facilitate the spreading malware to other machines over the local SMB network or through a valid remote access VPN connection connected to an SMB network.

With this information, we can now see what shares and servers we have access to in Windows, below. Once the attacker has a bit more information about the compromised system under their control, they can formulate the next plan of action.

In this example, the user is a local administrator for their laptop, they have a VPN adapter in their list of NICs and a corresponding VPN application but do not have any Domain Admin access. Since a core aim is to get access to the Domain controller, the attacker has a few options like trying to escalate privileges which can be used for lateral movement. If there are no other accounts present on the system for which privileges can be escalated, then they will most likely have to try to get such an account. They could leverage the authenticity of the compromised account and machine to send even more targeted phishing attacks inside the organization’s email domain. They could also cause a man-made glitch on their targeted system to force an IT support case which will most likely mean a remote help session with an IT admin who will more than likely “Run as administrator” on the infected machine. Threat actors tend to be determined and are patient and will typically do whatever it takes to get what they are after.

It is important to note that up to this point, we have not even used more powerful native capabilities like PowerShell or WMI. This is to deliberately point out the amount of information that can still be obtained on legacy operating systems as on modern ones. For example, the attacker may yet still test the possibility of native remote access using a system tool like PowerShell to see what machines they access remotely to aid lateral movement and pivoting.

Powershell Remoting capabilities offers up yet another avenue of discovery and lateral movement capabilities with commands like Enter-PSSession and various other cmdlets that can run the ComputerName parameter. The former utilizing WinRM (HTTP 5985 and HTTPS 5986) and the later the more ubiquitous RPC.

We understand the importance of domain controllers, we know an intrusion has occurred, and now we have a better understanding as to how attackers can use simple CLI commands and the all-important living off the land techniques (that won’t generate noise your endpoint or network security tools will see) to get a lay of the land and discover where they are in an environment.

Our next post will examine the lateral movement that attackers exhibit after discovery, to get to the domain controller.

Domain Controllers Overview

Authentication is an essential function for a computer network, helping ensure that only authorized users have access to the system. As a managed services provider (MSP), authentication is a key element of helping ensure your customers’ data is secure and only accessible to the correct users.

Related Product

N‑sight RMM

Get up and running quickly with RMM designed for smaller MSPs and IT departments.

For this reason, MSPs should invest time in understanding domain controllers, which play an important role in modern authentication. What are domain controllers? In this article, we’ll explain their function and examine the various types of domain controllers, including Active Directory.

What is the difference between a domain and a domain controller?

Every computer workstation has its own user accounts, called local accounts, that are used to log in to that particular machine. However, these accounts are not designed to log in to a network for two reasons. First, network accounts need to be portable—a user should be able to access the network from any workstation. Second, account configuration needs to be controlled from a central location. Otherwise, whenever account privileges change, system administrators would need to separately configure accounts on each local device.

This is where a domain comes in. A network domain centralizes user accounts so they can be more easily administered and enables users to log in to the network from any given machine. Within a domain, a domain controller is used to regulate user account access to the network.

What is the main function of a domain controller?

Domain controllers are part of the Microsoft network environment. A Windows domain controller handles user authentication requests. When a user seeks to access the network, the domain controller responds to that request. The domain controller verifies that the user should be let in, runs the login process, and regulates permissions (controlling which parts of the network the user can see). This is a critical security function. Domain controllers ensure that only authorized users are permitted to access the network, helping to keep out hacker threats.

Validation is usually performed with a username and password combination, though biometric techniques and multifactor authentication (MFA) can be incorporated for greater security. Once a user is validated, the domain controller determines whether they are a normal user or a system administrator with extra privileges.

Domain controllers were first introduced in Windows NT. They remain a key tool in contemporary networking, though these days they are sometimes being supplanted as organizations move to cloud networks.

What is the difference between a domain controller and Active Directory?

Active Directory is Microsoft’s directory service for Windows domain networks. When it was introduced in Windows 2000 Server, Active Directory was solely used to handle centralized domain management. However, with the advent of Windows Server 2008, Active Directory was transformed into a suite of directory services, of which the domain controller is just one. Other Active Directory functions include Lightweight Directory Services, Certificate Services (for public-key encryption infrastructure), Federation Services (for single sign-on), and Rights Management Services (for information rights management, which controls access to particular data).

In this schema, the server running Active Directory is known as the domain controller. An instance of Active Directory includes both a database and executable code (called the Directory System Agent) for running the database and servicing user requests. The database is structured using objects, which are organized into three levels—forests, trees, and domains.

Active Directory domain controllers use trusts to grant users in one domain access to others. Trusts exist in the database’s forest, which is automatically created whenever a domain is created. The types of trust include a one-way trust (in which users of one domain have access to another domain, but not vice versa), a two-way trust (where two domains are permitted access to each other), a transitive trust (which can extend beyond two domains), an explicit trust (created by a system administrator), a forest trust (which applies to an entire forest), and an external trust (enabling connection to non-Active Directory domains).

An Active Directory domain controller enables sysadmins to set policies to help ensure adequate password complexity. For security, an Active Directory password cannot contain the username or the user’s full name. Moreover, Microsoft allows you to require that a password include characters from certain categories such as uppercase letters, lowercase letters, numbers, symbols (e.g., [email protected]#$%), and Unicode.

Active Directory also lets you set a minimum password length—the longer a password is, the harder it is to crack using brute-force techniques. By default, Windows 10 Active Directory requires a password to have characters from at least three of the previously mentioned categories and to be no less than eight characters long. These specifications yield 218,340,105,584,896 different total possibilities that hackers would need to try with brute-force methods. The more sensitive the information you’re trying to protect, the more robust your password requirements should be.

How many domain controllers do you need?

In their original Windows implementation, domain controllers were divided into two categories: primary domain controller and backup domain controller (DC). A primary DC is the first-line domain controller that handles user-authentication requests. Only one primary DC can be designated. According to security and reliability best practices, the server housing the primary DC should be solely dedicated to domain services. Because of its central importance to the network, the primary DC server must not run file, application, or print services, which could slow it down or risk crashing it.

A backup domain controller exists as a fail-safe in case the primary domain controller goes down. There can be multiple backup domain controllers for redundancy. Having a dedicated backup DC is a wise precaution. If the primary DC fails and there’s no backup, users will not be able to gain access to the network. When a user attempts to log in, the software contacts the primary DC. If the primary DC is unavailable, it then contacts the backup DC. The backup can be promoted to the primary role in the event that the primary is permanently out of service. Note that domain updates (such as additional users, new passwords, or changes to user groups) can only be made to the primary DC. They are then propagated into the backup DC databases. This is a form of the master-slave replication structure, with the primary DC being the master and secondary DCs being the slaves.

Nowadays, however, the primary and backup domain controller architecture has been deprecated. When Active Directory was introduced in Windows 2000, it was designed with a multimaster replication structure. This means that user account privileges are stored redundantly among a group of domain controllers, and each member of the group can update all the others. When a new user is added to one domain controller, for example, multimaster replication pushes the change out to the other controllers. In contrast to the master-slave architecture, multimaster replication yields greater reliability (the failure of a single master is not catastrophic), increased flexibility, and faster performance.

In sum, whether in its original primary/backup implementation or in today’s Active Directory framework, the domain controller remains a critical part of a contemporary network. The higher the number of domain controllers you have, the easier it is to ensure uptime for users seeking access to the network.

For more information on domain controllers and Active Directory, read through our related blog articles.