Book Image

Identity with Windows Server 2016: Microsoft 70-742 MCSA Exam Guide

By : Vladimir Stefanovic, Sasha Kranjac
Book Image

Identity with Windows Server 2016: Microsoft 70-742 MCSA Exam Guide

By: Vladimir Stefanovic, Sasha Kranjac

Overview of this book

MCSA: Windows Server 2016 certification is one of the most sought-after certifications for IT professionals, which includes working with Windows Server and performing administrative tasks around it. This book is aimed at the 70-742 certification and is part of Packt's three-book series on MCSA Windows Server 2016 certification, which covers Exam 70-740, Exam 70-741, and Exam 70-742. This exam guide covers the exam objectives for the 70-742 Identity with Windows Server 2016 exam. It starts with installing and configuring Active Directory Domain Services (AD DS), managing and maintaining AD DS objects and advanced configurations, configuring Group Policy, Active Directory Certificate Services, and Active Directory Federation Services and Rights Management. At the end of each chapter, convenient test questions will help you in preparing for the certification in a practical manner. By the end of this book, you will be able to develop the knowledge and skills needed to complete MCSA Exam 70-742: Identity with Windows Server 2016 with confidence.
Table of Contents (7 chapters)

Introduction to Active Directory

Every AD DS is composed of both logical and physical components. All components work together and each component has a specific role in the proper functioning of AD DS. In this section, you'll learn what those components are and why they're important. We'll also look at which tools can be used to manage AD DS and what's new in AD DS in Windows Server 2016.

A knowledge of logical components is important for the proper implementation of appropriate AD DS design for an organization.

The following table shows the logical and physical components of AD DS:

Logical components Physical components
  • Partitions
  • Schema
  • Domains
  • Domain trees
  • Forests
  • Sites
  • Organizational units
  • Containers
  • Domain controllers
  • Read-only domain controllers
  • Data stores
  • Global catalog servers

Logical components

Logical components in AD DS are structures that are used to implement AD DS design. Different designs are appropriate for different organizations, so knowledge of logical components and their purpose is very important. In the following section, we'll describe the logical components in more detail.

Partitions

A partition is a portion of the AD DS database. Although the AD DS database stores all the data in one file, C:\Windows\NTDS\ntds.dit, the AD DS database is composed of a few different partitions and each partition contains different data. The AD DS database is logically separated into the following directory partitions:

  • Schema partition: There is only one schema partition per forest. The schema partition is stored on all domain controllers in the forest and contains definitions of all objects and attributes of objects.
  • Configuration partition: The configuration partition contains information about the forest-wide AD DS structure, as well as information about the domains and sites in a forest and the domain controllers that are installed in a forest.
  • Domain partition: Domain partitions are stored on every domain controller in a domain and contain information about users, groups, computers, and organizational units. All objects from the domain partition are stored in the global catalog.
  • Application partition: Every application in AD DS needs to store, categorize, and use specific information. This information is stored in the Application partition that can be domain- or forest-wide, depending on the application type.

Partitions are replicated through directory replication and are stored on every domain controller in the domain and forest.

By default, the location of the AD DS database is C:\Windows\NTDS\ntds.dit. While promoting the server to a domain controller, you can define another location for the AD DS database.

Schemas

A schema defines all object classes and attributes that AD DS uses to store data. Each AD DS object has a lot of attributes that need to be populated, such as the name, sAMAccountname, the canonical name, and the location. All of these are controlled by the schema. All domains in a single forest contain a copy of the schema that applies to the forest level. Each change in the schema is replicated from the schema master to every domain controller in the forest. The schema master is typically the first domain controller installed in a forest. An AD DS schema can be changed or modified, but only when necessary. The schema is responsible for information-storage controls, and every untested schema change can potentially affect other applications in the forest that use AD DS. Any schema changes must be performed by the Schema Admins and from the schema master.

Schema changes are one-way. You can't delete anything from a schema, you can only extend or modify schema attributes or classes.

In most cases, a schema needs to be updated for specific applications. For example, if you want to install Microsoft Exchange Server 2016, you must apply the Exchange Server 2016 Active Directory schema changes. This will be done during the installation of the Exchange Server and will be performed without user interaction.

Domains

The domain is a logical component that acts as a central administrative point for AD DS objects, such as users, groups, and computers. Domains use a specific portion of the AD DS database and can be connected to other domains in a parent-child structure or a tree structure. The AD DS database stores all domain objects, and each domain controller holds a copy of the AD DS database.

AD DS uses a multi-master replication model. This means that every domain controller in the domain can make a change to the objects in the domain and that change will be replicated in all other domain controllers.

The AD DS domain provides authentication and authorization for domain-joined users. Every time the domain user wants to sign in to a domain-joined computer, AD DS must authenticate the login. Windows operating systems use authorization and access-control technologies to allow authenticated users to access resources.

Every domain in a forest has some objects that are unique to that domain:

  • Domain Admins group: By default, every domain has an administrator account and a Domain Admins group. The administrator account is a member of the Domain Admins groups, and the Domain Admins groups is, also by default, a member of the local Administrators group on each domain-joined computer.
  • RID master role: The Relative Identifier (RID) master role is a domain-specific role that's responsible for assigning a unique SID to the new AD DS object. If the RID master server isn't online, you might have issues adding new objects to the domain.
  • Infrastructure master role: This FSMO role is responsible for inter-domain object references, when objects from one domain are part of a group in another domain. If servers with this role are unavailable, domain controllers that aren't configured as a global catalog servers won't be able to authenticate users.
  • PDC emulator role: The Primary Domain Controller (PDC) emulator FSMO role is responsible for time synchronization. The PDC master is the time source for a domain and all PDC masters in the forest synchronize their time with the PDC in the forest root domain. The PDC master is a domain controller that receives information if the user changes their password and replicates that information to other domain controllers. The PDC emulator also plays a big role in editing the GPO, because a PDC holds an editing copy. This prevents potential issues if multiple administrators want to edit the same GPO at the same time.

Domain controllers don't have local users and groups, so local Administrator groups don't exist on domain controllers.

Domain trees

A domain tree is a hierarchical collection of domains in the same forest that share the same root domain name. In the domain tree structure, AD DS domains are organized as parent-child domains.

Forests

A forest is a collection of one or more domain trees that share the AD DS root domain and schema. The first configured domain in the forest is called the root domain. A forest can either contain only one domain or it can be composed of hundreds of domains in different domain trees. The root forest domain contains a few objects that only exist in the forest root domain:

  • Schema master role: This special, forest-wide FSMO role can only exist once in a forest. As mentioned earlier, a schema can only be changed from the domain controller that holds this role.
  • Domain-naming master role: This is another special, forest-wide FSMO role that can only exist once in a forest. The domain-naming master role is responsible for adding new domains, so if the domain controller that holds this role isn't online, new domains can't be added to the forest.
  • Enterprise Admins group: By default, the Enterprise Admins group has the Administrator account for the forest root domain as a member. The Enterprise Admins group is the most powerful group in the forest, because it's a member of the local Administrators group in every domain in the forest. Members of the Enterprise Admins group have full administrative control in every domain in the forest.
  • Schema Admins group: By default, the Schema Admins group has no members. Only members of the Enterprise Admins group or the Domain Admins group (in the forest root domain) can add members to the Schema Admins group. Only members of the Schema Admins group can make changes to the schema.

Every forest has security and replication boundaries. Security boundaries, by default, are very strict. No one from outside the forest can access any resources inside it. If you need to provide access to one forest from another forest, you need to configure forest trust between them. Unlike the forest security boundaries, all the domains in a forest automatically trust the other domains in the forest. With this default configuration, access to resources, such as file shares and websites, is simple for all the users in a forest, regardless of the domain they belong to.

From a replication-boundaries perspective, only configuration and schema partitions from the AD DS database will be replicated to all domains in forest. Because of this, if you want to implement applications with incompatible schemas, you need to deploy additional forests. The global catalog is also part of replication boundaries. This makes it easy to search for AD DS objects from other domains in the forest.

Sites

The site is a logical representative of AD DS objects, such as computers and services, that are specific to a physical location. In a multisite environment, site implementation provides a better authentication process.

Organizational Units

An Organizational Unit (OU) is a logical object in AD DS for collecting users, groups, and computers. You can use OUs to consolidate users, computers, groups, and other objects for simplified management using GPOs linking, or to delegate administrative rights. You can also use OUs to represent a hierarchical and logical structure inside the organization domain. Although no specific rule exists for a logical OU structure, you can create OUs to represent departments in an organization, geographical regions, or anything else based on your organization needs.

If you want to organize the hierarchical and logical structure of your organization, it isn't recommended to add more than five levels of OUs nesting. Although there's no limit for the nesting of OUs, the Distinguished Names can become very long, which could cause problems for some applications.

Containers

A container is an object that provides an organizational framework for use in AD DS. Most containers are created by default. The biggest difference between a container and an OU is that containers don't have the ability to link to GPOs.

Physical components

The physical components are just as important as the logical components. These will be described in the following sections.

Domain controllers

The domain controller is the most important physical component of AD DS. Each domain controller contains a copy of the AD DS database and the SYSVOL folder. The domain controller uses multi-master replication to copy changed data from one domain controller to an other. As a replication mechanism, Windows Server 2016 can only use Distributed File Systems (DFS). The File Replication Service (FRS), which was used in earlier versions of Windows Server, was deprecated in Windows Server 2016.

Domain controllers host the Kerberos authentication service, which is used when a user or a computer account needs to sign in to the domain. The Key Distribution Center (KDC) issues the ticket-granting ticket (TGT) to the account that's signing in to the AD DS domain. Each domain controller can host a copy of the global catalog.

It's highly recommended that each domain has at least two domain controllers for availability purposes.

Read-only domain controllers

The read-only domain controller is a read-only installation of AD DS. By design, RODCs are ideal for branch offices that don't have appropriate physical security or dedicated IT support. By default, RODC doesn't cache any user passwords, but that's configurable.

Data stores

The data store is an AD DS database that's stored in C:\Windows\NTDS\ntds.dit. Each domain controller in the domain stores a copy of the AD DS database and all the related associated log files.

Global catalogs

The global catalog is a partial read-only copy of all objects in the forest. The purpose of the global catalog is to speed up searching for objects stored on different domains in the forest. Within a single domain, each query for objects is sent directly to the domain controllers in that domain, but if you want to include results from other domains in the forest, the query needs to be sent to the global catalog server. The global catalog server is the domain controller that hosts the global catalog, which, by default, is the first deployed domain controller in the forest root domain. The global catalog maintains the subset of attributes that are useful in cross-domain searches, such as givenName, displayName, and the mail.

It's highly recommended that the global catalog server and the infrastructure FSMO role are on separate servers. The infrastructure master communicates regularly with the global catalog server in order to keep cross-domain references up to date. When the infrastructure master detects that a cross-domain reference is out of date, it obtains the updated data from the global catalog server and replicates that to other DCs in its own domain. This process works well, but only in cases where the global catalog and the infrastructure master aren't on the same server.

You can find more information at https://support.microsoft.com/en-us/help/248047/phantoms-tombstones-and-the-infrastructure-master.

What's new in AD DS in Windows Server 2016

Like every new Windows Server version, Windows Server 2016 comes with several new features as part of AD DS:

  • Privileged Access Management (PAM): This allows you to separate the permissions required for specific administrative tasks. With PAM implemented, the user needs to request permission to perform some specific tasks, instead of having permanent access or a membership with granted access. PAM is based on the Microsoft Identity Manager.
  • Azure Active Directory Join (Azure AD Join): With Azure AD Join, you are now able to join on-premises devices to Azure AD and improve the management of cloud-only and hybrid environments. Azure AD Join allows you to join devices directly to the cloud, without having on-premise AD DS. For devices that are joined directly to the cloud, some MDM solutions need to be used for device management.
  • Microsoft Passport: Microsoft Passport is one of the new AD DS features supported in Windows Server 2016. Microsoft Passport provides a certificate-based authentication against on-premise AD DS and Azure AD that can replace the use of passwords.

AD DS administration tools

AD DS management is one of the most common daily tasks for administrators. There are a few different options to manage AD DS environments. You can sign in to the domain controller directly, you can manage AD DS through RDS, you can use RSAT from your domain-joined computer, you can use Server Manager for Remote Management, or you can use PowerShell remoting.

If you decide to use the GUI, several tools and Microsoft Management Consoles (MMC) are included by default in Windows Server 2016:

  • Active Directory Administrative Center: This GUI tool is natively Windows PowerShell-based. The improved functionalities of this management tool give you the ability to perform almost all known Active Directory tasks. The Active Directory Administrative Center can be installed on Windows Server 2008 R2 servers or later and Windows 7 or later operating systems. With Active Directory Administrative Center, you can perform the following actions:
    • Create and manage users, computers, and groups
    • Create and manage OUs
    • Manage multiple domains within a single instance of the Active Directory Administrative Center
    • Search and filter AD DS data
    • Configure fine-grained password policies
    • Recover objects from the Active Directory Recycle Bin
  • Active Directory Users and Computers: An MMC snap-in that gives you the ability to manage most common tasks and resources, including users, groups, and computers.
  • Active Directory Sites and Services: An MMC snap-in that manages replication, network topology, and other site-related services.
  • Active Directory Domains and Trusts: An MMC snap-in that configures and maintains trust relationships between domains and forests.
  • Active Directory Schema: An MMC snap-in that modifies the definitions of AD DS attributes and object classes.
  • Active Directory module for Windows PowerShell: Supports AD DS administration. This is one of the most important management components.
Although many administrators are familiar with Active Directory Users and Computers, the Active Directory Administrative Center replaces it and provides many more capabilities.

By default, the Active Directory Schema snap-in isn't fully installed. In order to enable the Schema snap-in, you need to start Command Prompt as an Administrator and run the regsvr32 schmmgmt.dll command.