- The Evolution of Directory Services
- Understanding the Development of AD DS
- AD DS Structure
- Outlining AD DS Components
- Understanding Domain Trusts
- Defining Organizational Units
- Outlining the Role of Groups in an AD DS Environment
- Understanding AD DS Replication
- Outlining the Role of DNS in AD DS
- Outlining AD DS Security
- Getting Familiar with AD DS Features in Windows Server 2016
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Outlining AD DS Components
The main components of AD DS were designed to be highly configurable and secure. AD DS and all it contains are physically located in a database file but are composed of a wide assortment of objects and their attributes. Many of these characteristics are familiar to those acquainted with other directory services products, but there are some new additions as well.
Understanding AD DS X.500 Roots
AD DS loosely follows, but does not exactly conform to, the X.500 directory services information model. In a nutshell, X.500 defines a directory service through a distributed approach defined by a directory information tree (DIT). This logically divides a directory service structure into the now familiar servername.subdomainname.domainname.com layout. In X.500, directory information is stored across the hierarchical layout in what are called directory system agents (DSAs). Microsoft designed AD DS around many of the basic principles of the X.500 definition, but AD DS itself is not compatible with X.500 implementations, as X.500 follows an OSI model that is inefficient under the TCP/IP implementation that AD DS follows.
Conceptualizing the AD DS Schema
The AD DS schema is a set of definitions for all object types in the directory and their related attributes. The schema determines the way that all user, computer, and other object data are stored in AD DS and configured to be standard across the entire AD DS structure. Secured by the use of discretionary access control lists (DACLs), the schema controls the possible attributes to each object within AD DS. In a nutshell, the schema is the basic definition of the directory itself and is central to the functionality of a domain environment. Care should be taken to delegate schema control to a highly selective group of administrators because schema modification affects the entire AD DS environment.
Schema Objects
Objects within the AD DS structure such as users, printers, computers, and sites are defined in the schema as objects. Each object has a list of attributes that define it and that can be used to search for that object. For example, a user object for the employee named Weyland Wong will have a FirstName attribute of Weyland and a LastName attribute of Wong. In addition, there might be other attributes assigned, such as departmental name, email address, and an entire range of possibilities. Users looking up information in AD DS can make queries based on this information (for example, searching for all users in the Sales department).
Extending the Schema
One of the major advantages to the AD DS structure is the ability to directly modify and extend the schema to provide for custom attributes. A common attribute extension occurs with the installation of Microsoft Exchange Server, which extends the schema, significantly from the default size. An upgrade from earlier AD operating systems to Windows Server 2016 AD DS also extends the schema to include any new attributes specific to Windows Server 2016. Many third-party products have their own schema extensions as well, each providing for different types of directory information to be displayed. It should be noted that schema extensions should only be performed when absolutely required, however, as an improper schema extension can wreak havoc on an AD DS environment.
Performing Schema Modifications with the AD DS Service Interfaces
An interesting way to actually view the nuts and bolts of the AD DS schema is by using the AD Service Interfaces (ADSI) utility. This utility was developed to simplify access to the AD DS and can also view any compatible foreign LDAP directory. The ADSIEdit utility, shown in Figure 4.3, enables an administrator to view, delete, and modify schema attributes. Great care should be taken before schema modifications are undertaken because problems in the schema can be difficult to fix.
)
FIGURE 4.3 Using the ADSIEdit tool to view schema attributes in AD DS.
Defining the Lightweight Directory Access Protocol
The Directory Service Protocol that is used by AD DS is compliant with the Internet-standard Lightweight Directory Access Protocol as defined by RFC 2251. LDAP allows queries and updates to take place in AD DS. Objects in an LDAP-compliant directory must be uniquely identified by a naming path to the object. These naming paths take two forms: distinguished names and relative distinguished names.
Distinguished Names in AD
The distinguished name of an object in AD DS is represented by the entire naming path that the object occupies in AD DS. For example, the user named Joel Oleson can be represented by the following distinguished name:
CN=Joel Oleson,OU=SLC,DC=Companyabc,DC=com
The CN component of the distinguished name is the common name, which defines an object within the directory. The OU portion is the organizational unit in which the object belongs. The DC components define the DNS name of the Active Directory domain.
Relative Distinguished Names
The relative distinguished name of an object is basically a truncated distinguished name that defines the object’s place within a set container. For example, take a look at the following object:
OU=SLC,DC=companyabc,DC=com
This object would have a relative distinguished name of OU=SLC. The relative distinguished name in this case defines itself as an organizational unit within its current domain container.
Detailing Multimaster Replication with AD DS Domain Controllers
AD DS uses domain controllers (DCs) to authenticate users. These DCs use the concept of multiple DCs that each contains a master read/write copy of domain information. Changes that are made on any DC within the environment are replicated to all other DCs in what is known as multimaster replication.
Global Catalog and Global Catalog Servers
The global catalog is an index of the AD DS database that contains a partial copy of its contents. All objects within the AD DS tree are referenced within the global catalog, which allows users to search for objects located in other domains. Not every attribute of each object is replicated to the global catalogs, only those attributes that are commonly used in search operations, such as first name, last name, and so on.
Global catalog servers, commonly referred to as GCs or GC/DCs, are AD DS DCs that contain a copy of the global catalog. It is wise to either locate a minimum of one global catalog server in each physical location or use RODCs in remote sites because the global catalog must be referenced often by clients and the traffic across slower wide-area network (WAN) links would limit this traffic. In addition, technologies such as Microsoft Exchange Server need fast access to global catalog servers for all user transactions, making it very important to have a global catalog server nearby. Note that Exchange cannot make use of RODCs or read-only global catalog (ROGC) servers.
Often, a larger organization will use multiple DCs and multiple global catalog servers in each large location, which distributes load, provides redundancy, and locates resources where they are needed. Choosing the right blend of global catalog servers and DCs is vital to the proper functionality of your AD DS environment.
Defining the Operations Master Roles
Most DC functionality in Windows Server 2016, and going back all the way to Windows Server 2000, was designed to be distributed, multimaster based. This effectively eliminated the single point of failure that was present with Windows NT primary domain controllers (PDCs). However, five functions still require the use of a single server because their functionality makes it impossible to follow a distributed approach. These operations master (OM) roles (previously referred to as FSMO roles) are as follows:
Schema master—There is only one writable master copy of the AD DS schema in a single AD DS forest. It was deliberately designed this way to limit access to the schema and to minimize potential replication conflicts. There can be only one schema master in the entire AD DS forest.
Domain naming master—The domain naming master is responsible for the addition of domains into the AD DS forest. This OM role must be placed on a global catalog server because it must have a record of all domains and objects to perform its function. There can be only one domain naming master in a forest.
PDC emulator—This role used to exist to emulate the legacy Windows NT 4.0 PDC for down-level clients. With Windows Server 2016, the PDC emulator still performs certain roles, such as acting as the primary time sync server for the domain. There is one PDC emulator FSMO role per AD DS domain.
RID master—All objects within AD DS that can be assigned permissions are uniquely identified through the use of a security identifier (SID). Each SID is composed of a domain SID, which is the same for each object in a single domain, and a relative identifier (RID), which is unique for each object within that domain. When assigning SIDs, a DC must be able to assign a corresponding RID from a pool that it obtains from the RID master. When that pool is exhausted, it requests another pool from the RID master. If the RID master is down, you might not be able to create new objects in your domain if a specific DC runs out of its allocated pool of RIDs. There is one RID master per AD DS domain.
Infrastructure master—The infrastructure master manages references to domain objects not within its own domain. In other words, a DC in one domain contains a list of all objects within its own domain plus a list of references to other objects in other domains in the forest. If a referenced object changes, the infrastructure master handles this change. Because it deals with only referenced objects and not copies of the object itself, the infrastructure master must not reside on a global catalog server in multiple domain environments. The only exceptions to this are if every DC in your domain is a global catalog server or if you are in a single-domain environment. In the first case, there is no need to reference objects in other domains because full copies are available. In the second case, the infrastructure master role is not used because all copies of objects are local to the domain.
Transfer of an OM role to another DC can be performed as part of regular maintenance, or in the case of a disaster recovery situation where an OM server is brought offline, the OM can be seized to be brought back online. This is true for conditions where the schema master, domain naming master, or RID master either needs to be moved to another system (transfer) or has gone down and no backup is available (seized). The transfer and seizure of an OM role is done through the use of a command-line tool called Ntdsutil, shown in Figure 4.4. Keep in mind that you should use this utility only in emergency situations and should never bring the old OM server that has had its role seized back online into the domain (at the risk of some serious system conflicts). You can read more about this tool in Chapter 7, “Active Directory Infrastructure.”
)
FIGURE 4.4 The Ntdsutil utility for AD DS management.