 Hello, Windows Server Hybrid Administrator. Welcome to this Microsoft Learn training module, Introduction to Active Directory Domain Services, generally abbreviated to ADDS. This module functions as preparation for AZ800 Objective Domain 1, deploy and manage ADDS in on-premises and cloud environments. You can follow along with the contents of this module on Microsoft Learn at the address shown on the screen or listed in the video description. After completing this module, you'll be able to describe ADDS, describe ADDS users, groups and computers, identify and describe ADDS forests and domains, describe organizational units, and manage objects and their properties in ADDS. ADDS and its related services form the foundation for enterprise networks that run Windows operating systems. The ADDS database is the central store of all the domain objects such as user accounts, computer accounts and groups. ADDS provides a searchable hierarchical directory and a method for applying configuration and security settings for objects in an enterprise. ADDS includes both logical and physical components. You should understand how ADDS components work together so that you can manage your infrastructure efficiently. In addition, you can use ADDS options to perform actions such as installing, configuring and updating apps, managing security infrastructure, enabling remote access service and direct access as well as issuing and managing digital certificates. ADDS logical components are structures that you use to implement an ADDS design that is appropriate for an organization. The following table describes the types of logical components that an ADDS database contains. Partition. A partition or naming context is a portion of the ADDS database. Although the database consists of one file named ntds.dit, different partitions contain different data. For example, the schema partition contains a copy of the active directory schema. The configuration partition contains the configuration objects for the forest and the domain partition contains the users, computers, groups and other objects specific to the domain. Active directory stores copies of partitions on multiple domain controllers and updates them through directory replication. Schema. A schema is the set of definitions of the object types and attributes that you use to define the objects created in ADDS. Domain. A domain is a logical administrative container for objects such as users and computers. A domain maps to a specific partition and you can organize the domain with parent child relationships to other domains. Domain tree. A domain tree is a hierarchical collection of domains that share a common root domain and a contiguous domain name system, DNS namespace, forest. A forest is a collection of one or more domains that have a common ADDS root, a common schema and a common global catalog, OU. An OU is a container object for users, groups and computers that provides a framework for delegating administrative rights and administration by linking group policy objects, GPOs, container. A container is an object that provides an organizational framework for use in ADDS. You can use the default containers or you can create custom containers. You can't link GPOs to containers. Physical components in ADDS are those objects that are tangible or that describe tangible components in the real world. Some of the physical components of ADDS include domain controllers. A domain controller contains a copy of the ADDS database. For most operations, each domain controller can process changes and replicate the changes to all the other domain controllers in the domain. Datastore. A copy of the datastore exists on each domain controller. The ADDS database uses Microsoft Jet Database technology and stores the directory information in the ntds.dit file and associated log files. The c or windows, the ntds folder stores these files by default. Global catalog server. A global catalog server is a domain controller that hosts the global catalog which is a partial read-only copy of all the objects in a multiple domain forest. A global catalog speeds up searches for objects that might be stored on domain controllers in a different domain in the forest. Read-only domain controller, RODC, and RODC is a special, read-only installation of ADDS. RODCs are common in branch offices where physical security is not optimal. IT support is less advanced than in the main corporate centers or line of business applications need to run on a domain controller. Site. A site is a container for ADDS objects such as computers and services that are specific to a physical location. This is in comparison to a domain which represents the logical structure of objects such as users and groups in addition to computers. Subnet. A subnet is a portion of the network IP addresses of an organization assigned to computers in a site. A site can have more than one subnet. In addition to the high-level components and objects, ADDS contains other objects such as users, groups, and computers. Users, groups, and computers are the most basic types of objects stored within ADDS. These objects are also sometimes called security principles. In ADDS, you must provide all users that require access to network resources with a user account. With this user account, users can authenticate to the ADDS domain and access network resources. In Windows Server, a user account is an object that contains all the information that defines a user. A user account includes the username, a user password, group memberships. A user account also contains settings that you can configure based on your organizational requirements. The username and password of a user account serve as the user's signing credentials. A user object also includes several other attributes that describe and manage the user. You can use the following to create and manage user objects in ADDS. Active Directory Administrative Center. Active Directory Users and Computers. Windows Admin Center. Windows PowerShell. The DE's Ad command line tool. Many apps contain services that you install on the server that host the program. These services typically run at server startup or are triggered by other events. Services often run in the background and don't require any user interaction. For a service to start up and authenticate, you use a service account. A service account might be an account that is local to the computer such as the built-in local service network service or local system accounts. You also can configure a service account to use a domain-based account located in ADDS. To help centralize administration and to meet program requirements, many organizations choose to use a domain-based account to run program services. While this does provide some benefit over using a local account, there are a number of associated challenges such as the following. Extra administration effort might be necessary to manage the service account password securely. It can be difficult to determine where a domain based account is being used as a service account. Extra administration effort might be necessary to manage the service principal name SPN. Windows Server supports an ADDS object named a managed service account which you use to facilitate service account management. A managed service account is an ADDS object class that enables simplified password management, simplified service principal name SPN management. Group managed service accounts enable you to extend the capabilities of standard managed service accounts to more than one server in your domain. In server farm scenarios with network load balancing, NLB clusters, or internet information services servers, there often is a need to run system or program services under the same service account. Standard managed service accounts can't provide managed service account functionality to services that are running on more than one server. By using group managed service accounts you can configure multiple servers to use the same managed service account and still retain the benefits that managed service accounts provide like automatic password maintenance and simplified SPN management. To support group managed service account functionality, your environment must meet the following requirement. You must create a KDS root key on a domain controller in the domain using the add KDS root key powershell commandlet. You create group managed service accounts by using new ad service account windows powershell command with the principles allowed to retrieve managed password parameter. Although it might be practical to assign permissions and rights to individual user accounts in small networks this becomes impractical and inefficient in large enterprise networks. For example, if several users need the same level of access to a folder it's more efficient to create a group that contains the required user accounts and then assign the required permissions to the group. Best practice is to change users file permissions by adding or removing them from groups that are assigned permission to files rather than editing the file permissions directly to add and remove the users. Before you implement groups in your organization you must understand the scope of various ADDS group types. In addition you must understand how to use group types to manage access to resources or to assign management rights and responsibilities. In a windows server enterprise network there are two types of groups security groups. Security groups are security enabled and you use them to assign permissions to various resources. You can use security groups in permission entries in access control lists, ACLs to help control security for resource access. If you want to use a group to manage security it must be a security group. Distribution groups, email applications typically use distribution groups which are not security enabled. You also can use security groups as a means of distribution for email applications. Windows server supports group scoping. The scope of a group determines both the range of a group's abilities or permissions and the group membership. There are four group scopes. Local you use the local type of group for standalone servers or workstations on domain member servers that are not domain controllers or on domain member workstations. Local groups are available only on the computer where they exist. The important characteristics of a local group are you can assign abilities and permissions on local resources only meaning on the local computer. Members can be from anywhere in the ADS forest, domain local you use the domain local type of group primarily to manage access to resources or to assign management rights and responsibilities. Domain local groups exist on domain controllers in an ADDS domain and so the group scope is local to the domain in which it resides. The important characteristics of domain local groups are you can assign abilities and permissions on domain local resources only which means on all computers in the local domain. Members can be from anywhere in the ADDS forest. Global you use the global type of group primarily to consolidate users who have similar characteristics. For example you might use global groups to join users who are part of a department or a geographic location. The important characteristics of global groups are you can assign abilities and permissions anywhere in the forest. Members can be from the local domain only and can include users, computers, and global groups from the local domain. Universal you use the universal group type in multi-domain networks because it combines the characteristics of both domain local groups and global groups. Specifically the important characteristics of universal groups are you can assign abilities and permissions anywhere in the forest similar to how you assign them for global groups. Members of universal groups can be from anywhere in the ADDS forest. Computers like users are security principles in that they have an account with a sign-in name and password that windows changes automatically on a periodic basis. They authenticate with the domain. They can belong to groups and have access to resources and you can configure them by using group policy. A computer account begins its life cycle when you create the computer object and join it to your domain. After you join the computer account to your domain, day-to-day administrative tasks include configuring computer properties, moving the computer between OUs, managing the computer itself, renaming, resetting, disabling, enabling, and eventually deleting the computer object. The computer's container is a built-in container in an ADDS domain. This container is the default location for the computer accounts when a computer joins the domain. This container is not an OU. Instead it is an object of the container class. Its common name is CN equals sign computers. There are subtle but important differences between a container and an OU. You cannot create an OU within a container so you cannot subdivide the computer's container. You also cannot link a group policy object to a container. Therefore, Microsoft recommends that you create custom OUs to host computer objects instead of using the computer's container. An ADDS forest is a collection of one or more ADDS trees that contain one or more ADDS domains. Domains in a forest share a common root, a common schema, a global catalog. An ADDS domain is a logical administrative container for objects such as users, groups, and computers. A forest is a top-level container in ADDS. Each forest is a collection of one or more domain trees that share a common directory schema and a global catalog. A domain tree is a collection of one or more domains that share a contiguous namespace. The forest root domain is the first domain that you create in the forest. The forest root domain contains objects that don't exist in other domains in the forest. Because you always create these objects on the first domain controller, a forest can consist of as few as one domain with a single domain controller, or it can consist of several domains across multiple domain trees. The graphic displays contoso.com as the forest root domain. Beneath are two domains, additum.com in a separate tree, and seattle.contoso.com as a child of contoso.com. The following objects exist in the forest root domain, the schema master role, the domain naming master role, the enterprise admins group, and the schema admins group. Note that although the schema and domain naming master roles are assigned initially in the root domain on the first domain controller you create, you can move them to other domain controllers anywhere in the forest. An ADDS forest is often described as a security boundary. By default, no users from outside the forest can access any resources inside the forest. In addition, all the domains in a forest automatically trust the other domains in the forest. This makes it easy to enable access to resources for all the users in a forest, regardless of the domain to which they belong. A replication boundary. An ADDS forest is the replication boundary for the configuration and schema partitions in the ADDS database. Therefore, organizations that want to deploy applications with incompatible schemas must deploy additional forests. The forest is also the replication boundary for the global catalog. The global catalog makes it possible to find objects from any domain in the forest. Typically, an organization creates only one forest. The following objects exist in each domain, including the forest root, the rid master role, the infrastructure master role, the pdc emulator master role, and the domain admins group. An ADDS domain is a logical container for managing user, computer, group, and other objects. The ADDS database stores all domain objects, and each domain controller stores a copy of the database. The graphic displays an ADDS domain. It contains users, computers, and groups. The most commonly used objects are user accounts. User accounts contain information about users, including the information required to authenticate a user during the sign-in process and build the user's access token. Computer accounts. Each domain joined computer has an account in ADDS. You can use computer accounts for domain joined computers in the same way that you use user accounts for users. Groups organize users or computers to simplify the management of permissions and group policy objects in the domain. ADDS allows a single domain to contain nearly two billion objects. This means that most organizations need only deploy a single domain. An ADDS domain is often described as a replication boundary. When you make changes to any object in the domain, the domain controller where the change occurred replicates that change to all other domain controllers in the domain. If multiple domains exist in the forest, only subsets of the changes replicate to other domains. ADDS uses a multi-master replication model that allows every domain controller to make changes to objects in the domain. An administrative unit, the ADDS domain contains an administrator account and a domain admins group. By default, the administrator account is a member of the domain admins group, and the domain admins group is a member of every local administrator's group of domain joined computers. Also, by default, the domain admins group members have full control over every object in the domain. It is important to note that the administrator account in the forest root domain has additional rights. An ADDS domain provides authentication. Whenever a domain joined computer starts or a user signs into a domain joined computer, ADDS authenticates it. Authentication verifies that computer or user has the proper identity in ADDS by verifying its credentials. Authorization. Windows uses authorization and access control technologies to determine whether to allow authenticated users to access resources. In some cases, organizations with decentralized administrative structures or multiple locations will consider implementing multiple domains in the same forest to accommodate their administrative needs. ADDS trusts enable access to resources in a complex ADDS environment. When you deploy a single domain, you can easily grant access to resources within the domain to users and groups from the domain. When you implement multiple domains or forests, you should ensure that the appropriate trusts are in place to enable the same access to resources. In a multiple domain ADDS forest, two-way transitive trust relationships generate automatically between ADDS domains so that a path of trust exists between all the ADDS domains. The trusts that create automatically in the forest are all transitive trusts, which means that if domain A trusts domain B and domain B trusts domain C, then domain A trusts domain C. You can deploy other types of trusts in ADDS environments. These include parent and child, tree root, external realm, complete forest, selective forest, and shortcut. These have the following properties, parent and child. This type of trust is transitive in two ways, two-way. When you add a new ADDS domain to an existing ADDS tree, you create new parent and child trusts, tree root. This type of trust is also transitive and two-way. When you create a new ADDS tree in an existing ADDS forest, you automatically create a new tree root trust, external trust. This type of trust is non-transitive and can be either one way or two-way. External trusts enable resource access with a Windows NT 4.0 domain or an ADDS domain in another forest. You also can set these up to provide a framework for a migration. Realm trust can be transitive or non-transitive and one-way or two-way. Realm trusts establish an authentication path between a Windows server ADDS domain and a Kerberos version 5v5 protocol realm that implements by using a directory service other than ADDS, such as those in purely Linux environments, forest, complete or selective trusts, transitive and either one-way or two-way. Trusts between ADDS forests allow two forests to share resources, shortcut trusts, non-transitive and one-way or two-way. You configure shortcut trusts to reduce the time taken to authenticate between ADDS domains that are in different parts of an ADDS forest. No shortcut trusts exist by default and an administrator must create them if they are required. When you set up trusts between domains within the same forest, across forests or with an external realm, Windows Server creates a trusted domain object to store the trust's information, such as transitivity and type, in ADDS. Windows Server stores this trusted domain object in the system container in ADDS. An organizational unit, OU, is a container object within a domain that you can use to consolidate users, computers, groups and other objects. You can link group policy objects, GPOs, directly to an OU to manage the users and computers contained in the OU. You can also assign an OU manager and associate a comm plus partition with an OU. You can create new OUs in ADDS by using Active Directory Administrative Center, Active Directory Users and Computers, Windows Admin Center and Windows PowerShell with the Active Directory PowerShell module. There are two reasons to create an OU. To consolidate objects to make it easier to manage them by applying GPOs to the collective. When you assign GPOs to an OU, the settings apply to all the objects within the OU. GPOs are policies that administrators create to manage and configure settings for computers or users. You deploy the GPOs by linking them to OUs, domains or sites. To delegate administrative control of objects within the OU. You can assign management permissions on an OU, thereby delegating control of that OU to a user or a group within ADDS in addition to the domain admins group. You can use OUs to represent the hierarchical logical structures within your organization. For example, you can create OUs that represent the departments within your organization, the geographic regions within your organization, or a combination of both departmental and geographic regions. You can use OUs to manage the configuration and use of user, group and computer accounts based on your organizational model. ADDS has several built-in containers or generic containers such as users and computers. These containers store system objects or function as the default parent objects to new objects that you create. Don't confuse these generic container objects with OUs. The primary difference between OUs and containers is the management capabilities. Containers have limited management capabilities. For example, you can't apply a GPO directly to a container. Installing ADDS creates the domain controllers OU and several generic container objects by default. ADDS primarily uses some of these default objects which are also hidden by default. The following objects are displayed by default, domain, the top level of the domain organizational hierarchy, built-in container, a container that stores several default groups, computer's container, the default location for new computer accounts that you create in the domain, foreign security principles container, the default location for trusted objects from domains outside the local ADDS domain that you add to a group in the local ADDS domain, managed service accounts container, the default location for managed service accounts. ADDS provides automatic password management in managed service accounts, users container, the default location for new user accounts and groups that you create in the domain. The users container also holds the administrator, the guest accounts for the domain, and some default groups. Domain controllers OU, the default location for domain controllers computer accounts. This is the only OU that is present in a new installation of ADDS. There are several containers that you can review when you select advanced features. The following objects that are hidden by default, lost and found, a container holds orphaned objects, program data. This container holds active directory data for Microsoft applications, such as active directory federation services, ADFS, system. This container holds the built-in system settings, NTDS quotas. This container holds directory service quota data, TPM devices. This container stores the recovery information for trusted platform module, TPM devices. Remember that containers in an ADDS domain cannot have GPOs linked to them. To link GPOs to apply configurations and restrictions, create a hierarchy of OUs and then link the GPOs to them. The administrative needs of the organization dictate the design of an OU hierarchy. Geographic, functional resource, or user classifications could all influence the design. Whatever the order the hierarchy should make it possible to administer ADDS resources as effectively and flexibly as possible. For example, if you need to configure all IT administrators' computers in a certain way, you can group all the computers in an OU and then assign a GPO to manage those computers. You also can create OUs within other OUs. For example, your organization might have multiple offices, each with its own IT administrator who is responsible for managing user and computer accounts. In addition, each office might have different departments with different computer configuration requirements. In this situation, you can create an OU for each office and then within each of those OUs create an OU for the IT administrators and an OU for each of the other departments. Although there is no limit to the number of levels in your OU structure, limit your OU structure to a depth of no more than 10 levels to ensure manageability. Most organizations use five levels or fewer to simplify administration. Note that applications that work with ADDS can impose restrictions on the OU depth within the hierarchy for the parts of the hierarchy that they use. Managing the ADDS environment is one of the most common tasks an IT pro performs. There are several tools that you can use to manage ADDS. Active Directory Administrative Center. The Active Directory Administrative Center provides a GUI that is based on Windows PowerShell. This enhanced interface allows you to perform ADDS object management by using task-oriented navigation and it replaces the functionality of Active Directory users and computers. Asks that you can perform by using the Active Directory Administrative Center include creating and managing user, computer and group accounts, creating and managing OUs, connecting to and managing multiple domains within a single instance of the Active Directory Administrative Center, searching and filtering ADDS data by building queries, creating and managing fine-grained password policies, recovering objects from the Active Directory Recycle Bin and managing objects that the Dynamic Access Control feature requires. Windows Admin Center is a web-based console that you can use to manage server computers and computers that are running Windows 10. Typically you use Windows Admin Center to manage servers instead of using remote server administration tools, RSAT. Windows Admin Center works with any browser that is compliant with modern standards and you can install it on computers that run Windows 10 and Windows Server with desktop experience. Windows Admin Center supports most current Windows Server and Windows 10 administrative functionality. Microsoft intends that Windows Admin Center will eventually support all the administrative functionality that is presently available through RSAT, but you should check whether the functionality you want is actually supported rather than assuming that it is. RSAT is a collection of tools which enables you to manage Windows Server roles and features remotely. The RSAT tools, sometimes called the Microsoft Management Consoles, have been around since Windows 2000 and although other systems have attempted to replace them, most experienced administrators have them available because they have been used for ADDS administrative jobs done without fuss for decades. You can install the consoles available within RSAT on computers running Windows 10, Windows 11, or on server computers that are running the server with desktop experience option of a Windows Server installation. Until the introduction of Windows Admin Center, RSAT consoles were the primary graphical tools for administering the Windows Server operating system, and until Windows Admin Center catches up, probably will be for some time to come. Other management tools that you'll use to perform ADDS administration are described include Active Directory Module for Windows PowerShell. The Active Directory Module for Windows PowerShell supports ADDS administration and it's one of the most important management components. Server Manager and the Active Directory Administration Center are based on Windows PowerShell and use command lets to perform their tasks. Active Directory Users and Computers. Active Directory Users and Computers is a Microsoft Management Console, MMC Snap-In, that manages most common resources including users, groups, and computers. Although many administrators are familiar with the Snap-In, the Active Directory Administrative Center replaces it and provides more capabilities. Active Directory Sites and Services. The Active Directory Sites and Services MMC Snap-In manages replication, network topology, and related services. Active Directory Domains and Trusts. The Active Directory Domains and Trusts MMC Snap-In configures and maintains trust relationships at the domain and forest functional levels. Active Directory Schema Snap-In. The Active Directory Schema MMC Snap-In examines and modifies the definitions of ADDS attributes and object classes. You don't need to review or change it often. Therefore, by default, the Active Directory Schema Snap-In is not registered. In this module, you learned how to describe ADDS, describe users, groups, and computers, identifying, describe ADDS forests and domains, describe OUs, and manage objects and their properties in ADDS. If you want to learn more, you can take this module on Microsoft, learn, or read the official AZ-800 exam prep guide from Microsoft Press. Links available at a.k.a. Ms. Slash, AZ-800 study guide.