41,99 €
Written by an Azure MVP and Microsoft Certified Trainer with 20 years of experience in data center infrastructure, this AZ-800 study guide is an essential preparation tool for administrators who want to take the exam and acquire key skills that will help them thrive in their careers.
This book will guide you through all the ways Windows Server can be used to manage hybrid solutions on-premises and in the cloud, starting with deploying and managing Active Directory Domain Services (AD DS) in on-premises and cloud environments. You’ll then dive into managing virtual machines and containers and progress to implementing and managing an on-premises and hybrid networking infrastructure.
The later parts of the book focus on managing storage and file services, concluding with a detailed overview of all the knowledge needed to pass the AZ-800 exam with practical examples throughout the chapters. In the final chapter, you’ll be able to test your understanding of the topics covered with the help of practice exams to make sure that you’re completely prepared for the contents and structure of the exam.
By the end of the book, you’ll have gained the knowledge, both practical and conceptual, that's required to administer Windows Server hybrid core infrastructure confidently.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 454
Veröffentlichungsjahr: 2022
Design, implement, and manage Windows Server core infrastructure on-premises and in the cloud
Steve Miles
BIRMINGHAM—MUMBAI
Copyright © 2022 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Group Product Manager: Mohd Riyan Khan
Publishing Product Manager: Mohd Riyan Khan
Senior Content Development Editor: Sayali Pingale
Technical Editor: Shruthi Shetty
Copy Editor: Safis Editing
Book Project Manager: Neil Dmello
Proofreader: Safis Editing
Indexer: Sejal Dsilva
Production Designer: Prashant Ghare
Marketing Coordinator: Ankita Bhonsle
First published: December 2022
Production reference: 1181122
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham
B3 2PB, UK.
978-1-80323-920-0
www.packt.com
This book is my contribution to the worldwide technical learning community and I would like to thank all of you who are investing your valuable time in learning new skills and committing to reading this book.
Steve Miles, aka SMiles or Mr. Analogy, is a Microsoft Azure Hybrid MVP, MCT, and multi-cloud and hybrid technologies author and technical reviewer with over 20 years of experience in networking, data center infrastructure, managed hosting, and cloud solutions. His experience comes from working with end users and reseller channels and in vendor spaces and roles with a global network and app security vendor, with global telco hosters, in managed hosting, with colocation and data center service providers, and in hardware distribution. Currently, he is working for a multi-Cloud Solution Provider (CSP) distributor based in the UK and Dublin in a cloud and hybrid technology leadership role.
His current focus is on securing, protecting, and managing identities, Windows clients, and Windows Server workloads in hybrid and multi-cloud platform environments.
Most happy in front of a whiteboard, he prefers to communicate using illustrations. He is renowned for breaking down complex technologies with analogies and concepts into everyday, real-world scenarios.
His first Microsoft certification was on Windows NT and he is an MCP, MCITP, MCSA, and MCSE for Windows Server and many other Microsoft products. He also holds multiple Microsoft Fundamentals, Associate, Expert, and Specialty certifications in Azure Security, Identity, Network, and M365. He also holds multiple security and networking vendor certifications.
Finally, as part of the multi-cloud domain, he has experience with GCP, AWS, an Alibaba Cloud MVP, and is Alibaba Cloud-certified.
Peter De Tender has more than 25 years of experience in architecting and deploying Microsoft solutions, starting with Windows NT4/Exchange5.5 in 1996. In early 2012, he started shifting to cloud technologies and quickly embraced Azure, working as a cloud architect and trainer. In September 2019, Peter joined Microsoft’s prestigious Microsoft Technical Trainer team, providing Azure readiness workshops to their top customers and partners across the globe. Recently having relocated to Redmond, WA, Peter is continuing this role. Given his past status as Azure Hybrid MVP and his passion for the community, Peter is still actively involved in public speaking, technical writing, and mentoring and coaching. You can follow Peter on Twitter at @pdtit.
Thanks Steve, for trusting my love for Azure. Also, a big thanks to my wife for supporting me in realizing my dreams.
Cloud computing is a technology commonly seen as a platform and mechanism to provide organizations with an enabler for digital transformation. However, the cloud computing journey need not be a binary decision; it need not be a broad sweeping decision to move all your workloads to the cloud and decommission everything on-premises.
While it may be appropriate and the best direction of travel for some, there are equally those that, for reasons such as data locality, compliance, control, performance, and so on, this will not be the case. There will be, for many, a need to remain with an appropriate amount of on-premises computing, storage networking, and other related resources to deliver the technology needs to their organizations. It is not for us to judge or rule on what is right or wrong for an organization but to provide options to meet and support all required outcomes that are mandated, or need to be delivered to an organization.
With that outlook and mindset on the changing face of cloud computing, we may look to extend the capabilities of cloud computing into our data centers to enhance and enrich the services operated from these facilities. It could be considered as much about managing from the cloud as it is about moving to the cloud.
We acknowledge that undeniably there are solid cases for digital transformation and, for many, being cloud native is the foremost approach; however, for many, the first step in the journey will be data center modernization through a hybrid cloud computing approach. Many a year’s life is left in data centers, and Windows Server is a computing and core infrastructure platform that should be enriched and enhanced through cloud computing capabilities.
The content of this book intends to provide complete coverage of the exam requirements to prepare you for the AZ-800: Administering Windows Server Hybrid Core Infrastructure Microsoft Certification exam.
The exam is intended for candidates with extensive experience working with the Windows Server operating system in hybrid environments and implementing and managing the core hybrid infrastructure technologies of computing, storage, networking, identity, and management.
In addition, this book’s added value is that it aims to go beyond the exam objectives, providing an extra depth of knowledge with practical hands-on skills to master, which will be of value in a day-to-day hybrid Windows Server environment role.
This book closes with exam preparation tests.
This book is for those in technical implementation and administration roles looking to pass the AZ-800: Administering Windows Server Hybrid Core Infrastructure exam.
Chapter 1, Implementing and Managing Active Directory Domain Services, includes content on creating and managing Active Directory Domain Services (AD DS) in a hybrid environment.
Chapter 2, Implementing and Managing Azure Active Directory Domain Services, includes content on creating and managing Azure Active Directory Domain Services (AAD DS).
Chapter 3, Managing Users and Computers with Group Policy, includes content on implementing and managing group policy in AD DS and AAD DS.
Chapter 4, Implementing and Managing Hybrid Identities, includes content on implementing and managing hybrid identities using Azure AD Connect and Azure AD cloud sync.
Chapter 5, Implementing and Managing On-Premises Network Infrastructure, includes content on implementing and managing on-premises network infrastructure in a hybrid environment.
Chapter 6, Implementing and Managing Azure Network Infrastructure, includes content on implementing and managing Azure network infrastructure in a hybrid environment.
Chapter 7, Implementing Windows Server Storage Services, includes content on implementing Windows Server storage services in a hybrid environment.
Chapter 8, Implementing a Hybrid File Server Infrastructure, includes content on implementing Azure storage services in a hybrid environment.
Chapter 9, Implementing and Managing Hyper-V on Windows Server, includes content on implementing and managing Hyper-V on Windows Server in a hybrid environment.
Chapter 10, Implementing and Managing Windows Server Containers, includes content on implementing and managing containers in a hybrid environment.
Chapter 11, Managing Windows Server Azure Virtual Machines, includes content on managing Azure virtual machines.
Chapter 12, Managing Windows Server in a Hybrid Environment, includes content on managing Windows Server in a hybrid environment.
Chapter 13, Managing Windows Servers Using Azure Services, includes content on managing Windows Servers and workloads by using Azure services.
Chapter 14, Exam Preparation Practice Tests, provides practice tests for each skill section for Exam AZ-800: Administering Windows Server Hybrid Core Infrastructure.
For this book, the following are required:
A device with a browser, such as Edge or Chrome, to access the Azure portal: https://portal.azure.comAn Azure AD tenancy and Azure subscription; you can use an existing account or sign up for free: https://azure.microsoft.com/en-us/freeAn Owner role for the Azure subscriptionWe also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://packt.link/Mc8to.
There are a number of text conventions used throughout this book.
Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “The primary server is set with the Delay configuration attribute in the Scope properties on the secondary server.”
A block of code is set as follows:
Install-WindowsFeature Web-Application-Proxy -IncludeManagementToolsBold: Indicates a new term, an important word, or words that you see on screen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: “Launch DNS Manager from Server Manager under the Tools menu.”
Tips or important notes
Appear like this.
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata, select your book, click on the Errata Submission Form link, and enter the details.
Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Once you’ve read Administering Windows Server Hybrid Core Infrastructure AZ-800 Exam Guide, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.
Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.
Thanks for purchasing this book!
Do you like to read on the go but are unable to carry your print books everywhere? Is your eBook purchase not compatible with the device of your choice?
Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.
Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.
The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily
Follow these simple steps to get the benefits:
Scan the QR code or visit the link belowhttps://packt.link/free-ebook/9781803239200
Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directlyThis part will provide complete coverage of the knowledge and skills required for the skills measured in the Deploy and manage AD DS in on-premises and cloud environments section of the exam.
This part of the book comprises the following chapters:
Chapter 1, Implementing and Managing Active Directory Domain ServicesChapter 2, Implementing and Managing Azure Active Directory Domain ServicesChapter 3, Managing Users and Computers with Group PoliciesChapter 4, Implementing and Managing Hybrid IdentitiesThis chapter covers the AZ-800 Administering Windows Server Hybrid Core Infrastructure exam learning objective: Deploy and manage AD DS in on-premises and cloud environments.
We will start this first chapter with an understanding of Active Directory concepts and its portfolio of services. We will focus on Active Directory Domain Services (AD DS). We will look at each component of AD DS in more detail and then move on to understanding how to create and manage an instance of AD DS in on-premises environments. We will then conclude with a hands-on exercise to develop your skills further.
The following main topics will be covered in this chapter:
What is Active Directory?What is Active Directory Domain Services?Active Directory Domain Services componentsCreating Active Directory Domain ServicesManaging Active Directory Domain ServicesExercise – installing AD DS on Windows ServerThis chapter aims to take your knowledge beyond the exam objectives to prepare you for a real-world, day-to-day hybrid environment-focused role.
Before we dive into creating or configuring any services, we will look at some definitions and concepts to set a baseline and foundation of knowledge for you to build from. We will start this chapter by defining Active Directory (AD), which forms the basis of Windows Server identity, access management, and information protection services.
AD is part of Microsoft’s identity, access, and information protection solutions. It runs as an installed service as part of Windows Server and was introduced in Windows 2000.
As its name suggests, AD is a directory service and an identity provider (IDP) whose primary function is to manage access to domain resources through authentication and authorization. It is used to control, centrally organize, locate, and secure access to these resources on a network.
At a simple level, you can think of it as an identity store and digital address book for resources on a network. It comprises a list of identities and their access rights to resources in the directory.
AD is not a single function service or solution; it is a collective or umbrella term for a portfolio of directory-based and identity-driven services, including domain services, federation services, certificate services, and rights management services. It provides capabilities such as single sign-on (SSO).
From a technical perspective, it is an X.500 compatible directory service and can be accessed using the Lightweight Directory Access Protocol (LDAP). It is based on a hierarchical, multi-master distributed database model that comprises partitions and an extensible schema.
This section introduced AD as the Microsoft solution for the foundation of identity, access, and information protection for on-premises and hybrid environments. In the next section, we will understand and define Active Directory Domain Services (AD DS).
AD DS is organized as a distributed and searchable hierarchical directory that controls access to network resources and allows settings and configurations to be applied through policies.
AD DS is a server role installed on Windows Server and is included with the operating system (OS); no software needs to be downloaded. A server with an installed AD DS role is referred to as a domain controller (DC).
AD DS provides access to resources by authenticating and authorizing domain object resources.
Accessing domain resources is based on a two-stage concept that consists of authenticating and then authorizing; in a nutshell, it involves identifying who you are and determining what you can do:
Authentication, also referred to as AuthN, is the identity component; it is the process of establishing the identity of a person (or service) and proving they are who they say they are. This can be done by validating access credentials against stored or known identifying information.Authorization, also referred to as AuthZ, is the access component; it is the process of establishing what level of access the authenticated person (or service) has to the resource, what they can access, and what actions they may take.The concept of authenticating and authorizing is shown in the following diagram:
Figure 1.1 – Understanding authentication and authorization
The terms Active Directory and Domain Services (abbreviated to their short forms of AD and DS) are often used interchangeably to mean the same thing. When people refer to AD, they often mean just the DS component, mainly since it is the most common and foundational identity and access management service component to be implemented.
For this book and the exam, we will refer to AD in the context of the DS component only; we will refer to it simply as AD DS for brevity. For additional learning content on the other services that are part of AD, please refer to the Further reading section at the end of this chapter.
AD DS contains a list of objects, such as user accounts, along with their attributes, such as passwords and their assigned access rights to resources. This list can be queried to validate the identity and access rights to a resource in the domain that is created as an object in the information store database. This is shown in the following diagram:
Figure 1.2 – Domain resource access
AD DS functions by classifying everything stored in its information store (database) as an object. Objects can be user accounts, computer accounts, groups (security principals), printers, network appliances, applications, or services. These objects are hierarchical, meaning that objects can contain other nested objects; these types of objects are called containers. We will look at these terms in more detail later inthis chapter.
Each object stored in the database has a set of attributes that match the object’s context; this is defined in a schema. The directories information data store is a database structure with a schema that is extensible and can store attributes that suit the business requirement. Being a directory service means every object can be searched, queried, access controlled, managed, and configured in a centralized and policy-driven manner.
The foundation of identity and access management (IAM) is that access to objects is controlled through role-based access control (RBAC) and the principle and practice of least privilege. This means providing the proper scope of control. Just enough access is given to perform a required task without unnecessarily providing elevated access rights that may give a broader scope than required and privileged lateral access if an account were to be compromised. The control mechanism is a group policy and provides group scoping for identities.
AD DS comprises a logical structure that often maps to the organization’s operating model and a physical structure that should map to the network topology.
The following can be considered as the logical components:
DomainDomain treeForestOUPartitionSchemaContainerThe following can be considered as thephysical components:
Data storeGlobal catalogDomain controllerRead-only domain controllerSiteSubnetThese components will be covered in more detail later in this chapter.
This section introduced us to DS, one of AD’s services, which provides a centralized mechanism for authenticating and authorizing resources in a domain.
In summary, AD DS is built around a directory service that is a replicated information store (database) for all domain objects. It primarily provides authentication and authorization for accessing domain objects and configuration and management access.
In this section, we will look closer at the individual components of AD DS.
Objects refer to any element in the AD DS directory; examples of objects include printers, computers, users, groups, subnets, and so on. Objects have attributes that describe them; each will have required attributes and optional attributes. A name and an object identifier (OID) are two examples of required attributes.
In this section, we will look at the different classes of AD DS objects.
These are built-in objects for logically grouping and holding other objects; think of these as hierarchical folder structures containing objects belonging to the same category or class.
When AD DS is installed, a set of default object containers are created; these will be visually represented as hierarchal folders. The following screenshot shows the default containers; some are hidden by default:
Figure 1.3 – Containers for objects
These default containers inherit a default set of permissions that are assigned to allow proper service administration and operations. These containers cannot be deleted, and you should not change the assigned permissions or delegate control of these; instead, you should create containers to meet your needs.
The essential containers to be aware of are as follows:
The Domain container acts as the root container for the container hierarchy.The Builtin container provides a container that holds several default groups and default service admin accounts that are created when AD DS is installed.The Computers container provides a container that holds all computer account objects; it is the default location for all created computer accounts.The Users container provides a container that holds all user and group objects; it is also the default location for all created users and groups, some of which are automatically placed in this container location when AD DS is installed.The Domain Controllers OU container provides a container that holds the computer accounts for all DCs; it is the default location for all created DCs.These default containers are automatically created when you install AD DS. They cannot be deleted, and assigned permissions and access control should not be modified. Still, custom containers can be created to meet your needs.
You can only apply policies to OU containers; to apply policies and delegate control over users or computers, you should create your own OU containers and move objects to those containers so that the policies and permissions can be applied.
The domain controllers container is an organizational unit (OU) container and is the only OU created by default when AD DS is installed. It is recommended that DCs not be moved out of their default location of the Domain Controllers OU container and not delegate control to non-service administrators.
The OU functions as a container object and is used to collectively organize users, groups, and computers, providing a framework for targeting administrative control and policies on objects in the container.
An example of where OUs could be helpful is where you need to apply common administrative control to a group of resources that are part of the same workload (such as all Azure Virtual Desktop objects), environment (such as dev, test, prod, and so on), business unit, or region.
It is important to note that you can only link group policy objects (GPOs) to OU containers and not regular containers.
OUs can be created via the following methods:
AD Users and ComputersAD Admin CenterPowerShell with the AD moduleWindows Admin Center (WAC), which is rapidly becoming the most widely adopted tool in hybrid environmentsAn OU structure can be hierarchal and map to organizational structures such as department, business group, or geography. These can be mapped to functions, projects, or resources such as workstations, servers, and so on.
OUs should group all those objects that need the same administration and policy settings and move them into an OU that can be controlled with Group Policy. If there are objects in an OU that you don’t want to have the policy applied to, then you can create a new OU and move the objects out to that OU so that the policy does not apply.
Hierarchal grouping is supported; you can nest OUs within OUs (just like any hierarchal folder structure). However, you should carefully plan the object grouping and hierarchy so that it isn’t too complex. Typically, five levels or less is optimum, and 10 is the recommended maximum to ease the admin burden and reduce complexity. You may also be constrained by a domain object resource that will only work with an OU structure of a supported method/configuration.
When a user account (an identity) is created in the directory, it’s classed as an object. It is one of the core and foundation object classes in the directory, along with computer objects. Hence, we will look at an AD DS management tool known as Active Directory Users and Computers later in this chapter.
For a user to be able to authenticate to domain resources, they must use a user account that AD DS provides. AD DS stores user accounts in its database with object-specific identity information and attributes such as the login username and password; these are used for the user to sign in to access domain resources.
In addition, other attributes include any organization-specific information that needs to be stored, such as job title, department, office, email, phone number, and more.
Regarding access management, the groups the user is a member of are listed. These group memberships are used to determine the level of access to resources in the domain; this is the concept of who you are and what access you have.
The recommended practice is that access rights are not given to user objects directly but to group objects. Users are members of groups, so they inherit their access permissions from their group memberships; this simplifies administration and makes troubleshooting access issues much easier and quicker.
Every user account object has a critical and primary attribute known as the User Principal Name (UPN). This is in an internet communication standard format typically recognized and expressed as an email address format – name@domain. However, it is essential to understand that it is not an email address. We recognize that a user’s email address could match their UPN and vice versa, but it’s not an explicit rule.
The user’s UPN is derived from a combination of the user’s login name and the domain name. The @ symbol is a form of join or delimiter between these two names; for example, the user Steve Miles in the milesbetter.solutions AD domain may have a UPN of [email protected], where smiles is the user login attribute for the user account of Steve Miles.
Two other terms are the UPN prefix and UPN suffix; the UPN prefix is the part of the name before the @ symbol, while the suffix is the part of the name after the @ symbol. The UPN prefix and suffix components are shown in the following screenshot:
Figure 1.4 – UPN format
As in the previous user account example, the smiles login name attribute is then termed the UPN prefix, whereas the UPN suffix would be milesbetter. solutions, which refers to the domain part of the name.
Service accounts are non-user-based account object classes used for applications and services that run in the background and require no user interaction. However, they still need to be authenticated to the directory service.
Managed Service Accounts (MSAs) are AD DS object classes that provide this service account capability; they benefit from lowering admin effort for Service Principal Name (SPN) management and service account password management.
There are two types of MSAs, as follows:
Standard Managed Service Accounts (sMSAs) are local to a computer, service, or application and cannot be shared across other resources in the network. This limits their efficiency and adds an administrative burden. Needing to implement multiple local sMSAs increases the threat, security, and configuration drift surface area and exposure.Further information about sMSAs can be found at https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-standalone-managed.
Group Managed Service Accounts (gMSAs) have domain scopes and capabilities and can be used across multiple computers, services, and applications; NLB clusters and IIS are examples.gMSAs require you to create a key distribution services (KDS) root key on a DC to creategMSA accounts.
The following are some AD PowerShell cmdlets that can be used to manage gMSAs:
Get-ADServiceAccountInstall-ADServiceAccountNew-ADServiceAccountRemove-ADServiceAccountSet-ADServiceAccountTest-ADServiceAccountUninstall-ADServiceAccountFurther information about gMSAs can be found at https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-group-managed.
Just as users have an account in the directory service so that we can search for and locate these users, we need the same mechanism to search for and locate computers in the domain. A computer object provides an account for a computer; it represents a computer resource on the network and allows it to uniquely identify itself and authenticate. Once a computer has a computer account, it can be managed as a domain resource and configured using Group Policy.
User account objects and computer account objects are the two foundation building block object classes in AD DS.
Group object classes in the directory form the basis for access management.
Once you have been authenticated through your user account, your group object membership defines what you are authorized to access in the domain. The permissions assigned to the group define what actions you can carry out on that network resource.
Permissions shouldn’t be set at the user account level; this is an admin burden, inefficient, prone to configuration drift, and becomes a governance and security posture issue.
All permissions should be assigned to a group, and users should be made members of the appropriate groups to give them the required permissions. This makes it easier to govern and control policies such as joiners, leaver policies, or where people change roles and now require different access levels. Rather than change individual resource permissions directly for what they can now do/not do based on their new role definition, we can add or remove them to the appropriate groups based on their new role’s permissions requirements. This is much more efficient, less error-prone, and provides much better control and governance.
Adding user accounts to groups is an RBAC approach. The principle of least privilege should be adopted, meaning you only need just enough access to perform the tasks/activities required without the need for elevated permissions. This should be the cornerstone of protecting against lateral attacks following an account compromise.
In summary, by adopting the practice of creating groups, assigning permissions to groups, and then making user accounts members of those groups, we can efficiently manage access to resources for multiple users that all need the same access type.
There are two types of groups: security groups and distribution groups. Let’s look at these in more detail:
Security groups are used as security-enabled logical containers to collectively group users to assign access permission to resources. This is a much more efficient way to assign a set of permissions to resources than assigning them individually to each user. For example, to control access to a network resource, we would create any number of groups, each with different levels of access permissions. Then, users can be added to the appropriate group(s), depending on what level of access they should have. We should ensure we follow the least privilege approach when assigning users to groups – that is, if they only need read access, then don’t make them members of a group with full-control permissions.Two default security groups are created automatically when AD DS is installed; these groups are located in the Builtin and Users containers.
Distribution groups are used as non-security enabled logical containers, that is, no permissions can be assigned to these groups, and are used for grouping users for providing some other form of non-security related administration, and to target a subset of users, often a business unit, team, or project focus. Most commonly used for email applications, for sending emails to target all group members.Groups also have a scope. This defines where they can exist/be effective, the types of members that can be added, and the capabilities and permissions that the group supports.
Four types of group scopes are supported in Windows Server: local groups, domain-local groups, global groups, and universal groups. Let’s look at these in more detail:
Local groups are effective only on the local machines they are created on and cannot be created on DCs; for clarity, these are not domain objects and exist only on local machines. The following are characteristics of local groups:Abilities and permissions: Can be assigned to local (non-domain) resources onlyMembers: Any user account of the forestDomain-local groups only apply locally to the domain created within and exist on the AD DS DCs for that domain. They are the primary means of managing access rights and responsibilities to resources within the local domain. The following are characteristics of domain-local groups:Abilities and permissions: Can only be assigned to domain-local resourcesMembers: Any user account of the forestGlobal groups are used to collectively group user accounts that share similar functions; this could be based on geographic location or business unit. The following are characteristics of global groups:Abilities and permissions: Can be assigned to any forest resourceMembers: Local domain onlyUniversal groups are used in multi-domain environments and combine the functions of the domain-local and global groups. The following are characteristics of universal groups:Abilities and permissions: Can be assigned to any forest resourceMembers: Any user account of the AD DS forestYou set the group type and scope at the time of creation and choose based on your needs and requirements for each group; this must be given adequate planning.
This section looked at AD DS objects. The next section will look at the AD DS domain and domain tree topology.
As inferred by the name Domain Services, a domain is the core foundation component and the building block of AD DS. A domain is a logical container of objects in the directory for management purposes. AD DS directory objects could be user accounts, computer accounts, groups, printers, and so on; all objects within that domain are bound by and share the same admin and security policies.
The domain is an administrative and replication boundary for AD objects; security boundaries are only implemented at the forest level. We will explore this in the Forests section.
A domain has one or more DCs. This is a Windows Server role responsible for authenticating requests to access resources in the domain, such as authenticating and authorizing a login request to a computer or accessing a storage file share. The DCs hold a copy of the AD DS database that is writeable; we will look at the concept of RODC and its use cases later.
Domains have a hierarchal topology, referred to as a domain tree. It consists of domains in a parent/child relationship that share a parent root domain; they also share a contiguous namespace in DNS.
The AD DS domain and domain tree are shown in the following diagram:
Figure 1.5 – Domain topology
AD DS uses a multi-master replication model, meaning that any DC can make changes to objects in the directory stored in the AD database. When changes to the domain are made on a DC, such as adding, removing, or changing an object, these changes are replicated to all other DCs in the domain. In a multi-domain case, only a subset of changes is replicated to all domains.
When the AD DS role is installed on Windows Server, a deployment option is provided for creating a new domain in an existing forest or a new domain in a new forest. The first domain in a new forest becomes what is known as the forest root domain; this is analogous to saying whether you would like to create a city in an existing state or whether you would like to create a new state and make this the first and parent/founding/capital city in that state – that is, the first domain in the new forest becomes the capital city, also known as the forest root domain.
This section looked at the AD DS domain and domain tree topology. The next section will look at the AD DS forest topology.
A forest is a top-level logical container definition. It is a collection of one or more domains that share a common parent root domain, schema, and global catalog that has a contiguous namespace; it is considered a security and administrative boundary.
To implement a security boundary for objects, they must be placed in different forests; all objects in a forest share the same security controls. It is a common misunderstanding that placing objects in different domains will isolate them between domains. It is essential to note this is not the case; only placing them in different forests can provide this isolation. The following diagram shows a visual representation of a forest:
Figure 1.6 – Forest topology
The forest topology (structure or layout) means that a forest can contain one domain or multiple domains across multiple domain trees, much like a country can contain many states, which are collections of independent and autonomous cities. Each state would contain a state capital city; we refer to this as the forest root domain.
In this section, we looked closely at various AD DS components. In the next section, we will look at the function of AD DS trusts.
Trusts are implemented to access resources when multiple domains and forests exist within an environment. Depending on the type of trust, these trusts can be one way or two way.
A trusted domain object is stored in the system container in AD DS and provides information on the trust types that have been created.
The most common trust types that can be implemented are as follows:
Parent and child trust: This is created when a new domain is added to an existing tree. It is a transitive, two-way trust.Tree-root trust: This is created when a new tree is added to an existing forest. It is a transitive, two-way trust.Forest trust: This is a trust between forests and allows two forests to share resources. It is a transitive one-way or two-way trust.Shortcut trust: This is a trust created manually when authentication time between domains in different parts of the forest needs to be reduced. It is a nontransitive one-way or two-way trust.External trust: This is a trust that allows access to resources from a domain in another forest or an NT 4.0 domain. It is a nontransitive one-way or two-way trust.Realm trust: This is a trust between AD DS and a directory service other than AD DS that implements a Kerberos version 5 protocol realm. It is a transitive or nontransitive one-way or two-way trust.These trust relationships are shown in the following diagram:
Figure 1.7 – Trusts
All automatically created two-way trusts in the forest are transitive. If domain B is trusted by domain A, and domain D is trusted by domain C, then domain A trusts domain C and D. This is a complex way of saying all the domains trust all the other domains in the forest.
However, in contrast, trusts between forests are not transitive, which means that if there are trusts between forests A and B and forests B and C, then C is not implicitly trusted by forest A.
Note that when a trust is set up between forests or domains, a function known as SID filtering is enabled by default. The purpose is to remove all foreign security identifiers (SIDs) from a user’s access token when using a trust in the trusting domain to access resources. Although it should be disabled to allow access to resources via the trust, you can disable this on the outgoing trust of the trusting domain.
When it comes to SID filtering and resource access across trusts, it is important to understand the trust direction and its relationship to the direction of access and which way the trust relationship is set up – that is, outgoing or incoming. This can be unclear; the core concept is that the direction of trust will be the opposite of the direction of access. This is shown in the following diagram:
Figure 1.8 – Trust direction
This means that if you want to access resources in another forest, there must be an outgoing trust; conversely, an incoming trust allows outgoing access.
One final concept to note is that of the trust authentication types. External and forest trusts provide two modes of authentication: forest-wide authentication and selective authentication.
Further information about trusts can be found at https://docs.microsoft.com/en-us/azure/active-directory-domain-services/concepts-forest-trust.
In this section, we looked at AD DS trusts. Now, let’s look at the AD DS data store.
A directory information store holds the AD database, which uses the Extensible Storage Engine (ESE) based on the Jet database engine.
The database is made up of two files – the database file itself (named NTDS.DIT and located in C:\Windows\NTDS directory by default) and the transaction log file (named EDB.LOG and also located in C\:Windows\NTDS directory by default). These files are stored on each DC. The group policy files for the group policy objects are stored in the SYSVOL folder.
The AD DS database file (NTDS.DIT) contains four partitions (or naming contexts) that contain all the domain-related information. Different data is stored in each partition, and each partition is replicated between DCs with a dependent replication scope and schedule.
These partitions are shown in the following diagram:
Figure 1.9 – AD DS database partitions
Let’s look at these four directory partitions in more detail:
The schema partition is where the AD DS schema is stored; this defines what can be stored in the AD databaseThe configuration partition is where the configuration information for the forest and domain trees is stored, such as site and replication informationThe domain partition is where object information for the domain is stored – that is, information about the user and computer objectsThe application partition is where applications can store data in AD; multiple application partitions may existIn this section, we looked at the AD DS data store, which contains the AD DS database. We also looked at the partitions for the AD database. In the next section, we will look at the AD DS schema.
The schema is a partition of the AD database; it provides the definitions for the object classes (categories) that can be stored in the directory and the object-describing attributes. The object classes and object attributes are schema objects; in other technology areas, they would be referred to as metadata – that is, data describing the data.
The schema can be edited and allows you to create, modify, and disable object categories and attributes of objects. The schema is forest-wide, so any change is replicated to every domain in the forest. Understand the impact before committing any changes to the schema. In addition, be aware that deletions are not supported in the schema.
The default built-in group schema administrators control access to the schema; you must be a member of this group to make changes to the schema.
In this section, we looked at the AD schema. In the next section, we will look at AD DS DCs.
A DC is a server with the AD DS role installed; it holds a writeable copy of the AD database and functions through the multi-master replication model for this information store. It also provides a store for GPOs. It ensures that the configuration settings are applied to domain-managed objects.
The DC is also a Kerberos Key Distribution Center (KDC). Kerberos is the mechanism for all authentication and authorization within AD; a Kerberos key identifies an object (authentication – that is, who you are) and outlines what resources an object can access (authorization – that is, what you can do and access).
DCS must be highly available to process logon requests; they are required to authenticate requests for access to domain resources and apply policies for managing and configuring objects in the directory stored in the AD database.
All computers and users that wish to access objects in an AD DS domain must be authenticated by a DC, so their placement, operation, and availability are crucial.
In Windows Server 2008, the read-only domain controller (RODC) concept was introduced as a deployment option. An RODC server holds a copy of the AD database and supports one-way, incoming replication. No direct changes can be made to the directory (such as LDAP writes); the only changes that can occur are those that are made via replication. A change should be made on a DC, allowing replication to push those changes to the RODC.
The RODC role was intended as a branch office for other locations that may not have adequate security to protect against Kerberos system components being compromised, such as the KDC, which is a database of keys, and the Ticket Granting Service (TGS), which is used to obtain Kerberos session keys. Unlike DCs, which share a Kerberos key, RODCs each have a unique key, minimizing the risk of exposing remote sites that may be isolated from secured and controlled corporate networks.
RODCs have two other use cases. The first is where locations, such as branch offices, don’t have a lot of bandwidth for replication traffic. The other scenario is to support the principle of least privilege so that the local server admin account does not need to have domain admin accessto function.
This section looked at DCs and their role in AD DS. Now, let’s look at the global catalog and its purpose.
The global catalog (GC) runs as a service on DCs and provides an index that allows you to look up information for every object listed in the AD forest (such as group memberships).
The GC holds a list of every object in the directory, but not every attribute for those objects; the schema defines what attributes of the objects are stored in the GC. The schema can be modified to allow those object attributes you want to appear in the GC so that they can be looked up in the GC.
When a user logs in, a GC must be contactable to look up a user’s universal group membership; however, when universal group caching is enabled, contacting a DC with a copy of the GC is less critical.
As part of the DC deployment, the first DC created in a forest holds a copy of the GC by default; this is for hybrid environments. GC placement should be designed for availability in each site, and perform local site searches to optimize network traffic. A DC that does not have a copy of the GC will have to send traffic over a WAN link to a site with a copy of the GC. GC placement is an important design decision; we will cover sites later in this chapter.
In this section, we looked at the purpose of the AD DS Global Catalog service. In the next section, we will look at the function of the operations master roles.
Although AD DS runs on a multi-master model, some single master operation roles are known as Flexible Single Master Operations ((FSMO), pronounced fizmo) roles and run on DCs.