Domain Controllers in Active Directory

domain-controller

Domain controllers are the key piece of active directory network infrastructure since they are responsible to authenticate all users and computers in the domain. DNS or domain name service is a critical piece of supporting the logon and authentication process. Two types of domain controllers are read-only and read-write. The read-only version contains a copy of the ADDS database that is read-only. As the name implies, read-write domain controllers have the ability to also write to the ADDS database.

Key components of a domain controller

  • Host the AD database known as NTDS.DIT and the SYSVOL
  • Use Kerberos authentication
  • Should have a least two domain controllers for redundancy

The domain controller stores the NTDS.DIT file which contains all the information about every object in that domain. The SYSVOL folder is also on the domain controller. The SYSVOL is used to store templates for use with Group Policy. Any domain controller in the network can make changes to the database unless it is a read-only domain controller. Active Directory then uses a process known as replication to keep all domain controllers up to date and in sync with each other. Active Directory also provides Kerberos authentication for users and computers. This service makes use of the Key Distribution Center to issue TGT for computers to log on to the domain. Some domain controllers also will have a copy of the global catalog. It is best practice to have at least two domain controllers for redundancy. If you only have one domain controller and there is a failure, the whole network would be impacted.

The Global Catalog

  • Contains a partial attribute set for other domains in the forest
  • Supports queries for objects in the entire forest
  • Typically on the first domain controller in the forest root domain

Replication of the NTDS.DIT is contained within the domain. As such, there needs to be a method to enable searching beyond one domain in the forest and this is what the global catalog provides. This distributed database or every object from all domains is what makes this possible. Since the global catalog needs to keep track of a very large number of objects, it does not contain all attributes of every object. The global catalog uses a pared-down set of attributes that would likely be the most useful for users trying to query the network for resources. If the global catalog had to maintain all attributes, it would be too resource and replication intensive. Common attributes that may be searched upon include firstname, displayname, and location.

Logging on to the Domain

  • Uses a two-step process
  • The user provides user name and password and if the user name and password validate against the AD DS database, the user becomes authenticated and is issued a TGT by the domain controller. The user does not yet have access to any resources.
  • A secondary process submits the TGT to the domain controller to request access to the local computer. A service ticket is issued to the user, who can then use the local computer. The user is now authenticated to AD DS and logged on to the local machine.

When logging on to the domain SRV records are used to find the closest domain controller. Service resource records hold information on available services and are in DNS on all domain controllers. It is using this DNS lookup that provides clients the most appropriate domain controller to serve the logon request. Once the user or computer logs on, an access token containing the SIDs for the user and his or her membership groups is granted. It is with this token that rights and permissions are granted to the user via the domain. Users, Computers, and Groups all have a unique SID.

Active Directory Sites

When a client uses SRV records to find a domain controller, it will use a local site as the first option. Sites are defined in ADDS by administrators usually based on network connectivity and bandwidth availability. A remote office that is connected via a less than reliable wide area network connection would be an example of a location that should be defined as its own site.

Operations Masters

All domain controllers are not created equal. Well, they are mostly equal but some tasks are completed only via single master and this is where different types of operations masters come into play. These are named operations masters, single masters, or flexible single master operations. I know, confusing, right?

The forest contains one schema master
The forest contains one domain naming master
The domain has one RID master
The domain has one infrastructure master
The domain has one PDC emulator

The schema master is the domain controller where schema changes are made. A user needs to be a member of Schema Admins as well as Enterprise Admins in order to make changes. The domain naming master is the domain controller responsible for adding or removing a domain or making any DNS changes. The RID master handles the replication ID and ensures that no domain controller will accidentally assign the same SID to two different objects. The infrastructure master role is a service that handles cross-domain object references such as group membership. When you view the member of the information of an object, what is really happening is a SID lookup. The infrastructure master maintains the integrity of these associations. Lastly, you have on PDC emulator or primary domain controller emulator master. The PDC handles time for the domain. PDC’s across domains in a forest synchronize to the PDC in the forest root domain. This PDC in the forest root domain is configured to sync with an external atomic time source. Password changes are routed through the PDC emulator as well as for use with the editing of Group Policy Objects.

Thank you for reading Domain Controllers in Active Directory – If you found this post helpful, Please do share using the buttons below!