AD DS: Domain Services
The most important service is AD DS (usually called "AD") which is responsible for managing all Windows hosts, endpoints for example by enforcing GPOs and access rights. It also implements the Kerberos Authentication Protocol and hosts the SYSVOL share.
The Domain Controller
When AD DS is installed on one or multiple servers, the server(s) is called Domain Controller (DC). AD can also be setup to have separate instances acting as Read-Only Domain Controller (RODC) (link1, link2) which is intended separate office-branches which may have a lesser security posture. This differs from Read-Write Domain Controller (RWDC) which are usually just called "DC".
The DC hosts Key Distribution Center (KDC) service which implements the Kerberos Authentication Protocol. The KDC is executed by the KRBTGT local system account which therefore exists on all DCs in the domain. RODC-hosts have an separate KRBTGT account used for their respective sites.
Note: The password hash of the KRBTGT account acts as the shared secret between the KDC/AS and KDC/TGS and is used to encrypt the TGT. The KDC trusts all TGTs which it has issued, regardless of set policies in the AD. This is important in Golden Ticket Attacks. Because of this, the KRBTGT account password should be changed periodically (link). The STIG recommendation is to change it every 180 days (link).
The DC also hosts the SYSVOL SMB-shared folder which is used to replicate GPOs and startup/shutdown scripts.
Principals and resources
In AD, information about users, network-resources (endpoints) etc. are expressed trough objects. There are two types of objects
Principals (users or groups)
Resources (printers, computers, etc)
These can be grouped together as organizational units (OU) and AD security groups respectively.
Figuring out how the business organization should be structured within AD is a topic of its own. Not only do we have the option to nest OUs, AD also introduces concepts which allows to logically express relationship between objects as an hieratic structure. The concepts are different layers of hierarchy being, from bottom to top: domain, domain trees and forests.
Domains, OUs and security groups
Because of this, there exists several best-practices in how an organization should be represented in AD. OU design and domain architecture is something which should be studied carefully as the security implications will depend on the structure.
The difference between OUs and groups are
OUs can contain GPOs and be used to delegate rights
AD groups can be used to manage permissions of shared resources
OUs can be nested. This is vital when applying permissions and access rights or delegating privileges. Domains are the highest form of logical structure which objects can be placed directly.
In the example below, policies can be applied to the Desktops OU specifically. When a new device is added to it, all policies will be applied automatically. In addition, it will inherit all policies from BIZ Computers OU and bizcompany.org Domain.
Note that the organizational structre of the business is NOT the optimal way to represent the business' IT environment in AD.
Here are some best practices (based on this link)
Separate endusers from computers. Separate servers from endpoints.
Apply permissions to Security Groups, not individual accounts.
Use a dedicated OU for security groups (BIZ Groups in example).
Trees and Forests
Domains can be nested to create domain trees which can be placed under the same forest:
As mentioned, forests are at the top of the hierarchy. All domains within a forest, regardless of which tree they are part of, are trusted by each other with regard to authentication and authorization. In this regard, only forests offer separation. In Microsoft terminology, this is called security boundary.
SYSVOL and GPOs
SYSVOL is a special folder which is hosted on domain controllers. It is shared using SMB across the domain and enabled domain-joined clients to fetch GPOs, startup-/shutdown scripts, etc. Since SMB can use either Kerberos or NTLM for authentication, if SMB signing is not activated, SMB-shares can be accessed using NTLM relay attacks. In addition, there are other attacks:
SMB session hijacking
SMB Null session (anonymous or guest access)
By default, domain controllers require SMB signing of clients connecting to them. In Windows 10, trough UNC Hardened Paths, clients also require SMB-signing and Kerberos (not NTML) when connecting to SYSVOL or NETLOGON. But this only applies to those volumes and not other SMB-shares.
(SMB is the protocol, CIFS is an old dialect of SMB, and Samba is the Linux/Unix-like implementation of the SMB protocol.)
TO-DO
Describe Forest trust model more!! https://learn.microsoft.com/en-us/entra/identity/domain-services/concepts-forest-trust
Last updated