Today, I’m going to answer all the key questions you might have about Active Directory Domain Services.
What is Active Directory Domain Services? Is it different from Active Directory?
Active Directory Domain Services (AD DS) and Active Directory (AD) are the same thing: a database (or directory) with critical information like all the various users and computers you have, and associated services that control much of the activity that goes on in your IT environment.
As one Redmond Magazine article puts it, “An Active Directory environment means that you must have at least one server with the Active Directory Domain Services installed.”
What does Active Directory Domain Services actually do?
AD DS has two core functions:
- Authentication— Making sure each user is who they claim to be, usually by checking the user ID and password they provide
- Authorization — Allowing each user to access only the data they’re allowed to use
Note that I’m using the word “user” in a generic sense here; AD DS provides authentication and authorization not just for individuals but also for devices, applications, processes and so on.
How do I install Active Directory Domain Services?
You don’t install AD DS per se. Rather, it is one of the server roles included in the Microsoft Windows Server operating system. When you install Windows Server on a machine, you need to specify what role or roles that server will play: file server, web server, DNS server and so on (see Figure 1).
Figure 1. When you install Windows Server on a machine, you need to specify what roles that server will play.
By assigning a server the AD DS role, you make it a domain controller (DC). Note that desktops, laptops and other systems running the regular version of Windows do not run AD DS and cannot be DCs.
As you can see in the figure, there are a variety of other roles you can assign to a server, including:
- Active Directory Certificate Services (AD CS) — Enables the DC to serve digital certificates, signatures and public key cryptography
- Active Directory Federation Services (AD FS) — Provides single sign-on (SSO) so users don’t have to keep providing the same credentials
- Active Directory Lightweight Directory Services — Enables use of LDAP for communicating with other directory services servers, such as any Linux computers in your network
- Active Directory Rights Management Services (RMS) — Helps protect information through persistent usage policies that remain with the content no matter where it is moved
Can I have multiple servers running Active Directory Domain Services?
Yes! In fact, that’s the norm: Organizations almost always have multiple domain controllers for redundancy and scalability. If one DC fails, another one can step in to provide the same services.
Reduce your AD attack surface.
The Active Directory replication service makes sure that all the domain controllers on the network stay in sync. In particular, it keeps them all up to date on any modifications to the users and computers in your directory (such as a user’s password change), and any changes to your schema, which defines all the object classes (such as users, groups, computers, domains and organizational units) that can be stored in your directory.
What are the best practices for protecting domain controllers?
Glad you asked! It’s essential to remember that any server running AD DS is a top target for cyberattacks. A hacker who compromises one of your domain controllers is well-positioned to achieve whatever nefarious goals they have, from stealing your most valuable data to sabotaging critical business processes. And, as Microsoft points out, “Depending on an attacker’s preparation, tooling, and skill, modification or even irreparable damage to the AD DS database can be completed in minutes to hours, not days or weeks.”
Therefore, it’s essential to protect your domain controllers like Fort Knox. In particular:
- Limit who has local administrative rights on each DC.
- Install only applications and services that are essential for functionality and security. A DC should act exclusively as a DC.
- Never permit a domain controller to access the internet. Prohibit the use of web browsers on your DCs not only by policy, but by technical controls. If a DC needs to replicate across sites, implement secure connections between those sites.
- Limit the accounts that can log in interactively and strictly adhere to best practices for password complexity and expiration for those accounts. Remember that various groups, such as Server Operators, empower members to log in interactively.
- Minimize network access to all your domain controllers.
- Tightly control physical access to all DCs. If you’re using virtual DCs, know who your virtualization admins are and keep tabs on their activity, since they can elevate their privileges.
- Keep Windows Server up to date on patches and use the most current version possible.
- Audit activity on all DCs and make sure you get alerted to any suspicious behavior.
- Back up your DCs. (For an entertaining but cautionary tale about how one company failed to implement this best practice and had to physically shuttle its last living DC from Ghana to the UK, check out this tech brief.)
Conclusion
That’s it for my technical dive into AD DS. For a more practical slant, I highly recommend our five-part blog series which covers all the following topics:
