70-412: Configuring Advanced Windows Server 2012 services Chapter 5 Configuring the Active Directory Infrastructure

Objective 5.1: Configuring a Domain and Forest

Active Directory Active Directory is a technology created by Microsoft that provides a variety of network services, including: Lightweight Directory Access Protocol (LDAP) Domain Name System (DNS) based naming and other network information Security mechanism for authentication that includes Kerberos-based and single sign-on authentication Security mechanism for authorization and auditing Central location for network administration and delegation of authority Policy-based management for user and computer accounts © 2013 John Wiley & Sons, Inc.

Logical Components of Active Directory Organizational units Containers in a domain that allow you to organize and group resources for easier administration, including delegating administrative rights. Domains An administrative boundary for users and computers, which are stored in a common directory database. A single domain can span multiple physical locations or sites and contain millions of objects. Domain trees Collections of domains that are grouped together in hierarchical structures and that share a common root domain. Can have a single domain or many domains. The domains within a tree have a contiguous namespace. © 2013 John Wiley & Sons, Inc.

Logical Components of Active Directory Forests Collections of domain trees that share a common AD DS directory schema. Can contain one or more domain trees or domains, all of which share a common logical structure, global catalog, directory schema, and directory configuration, as well as automatic two-way transitive trust relationships. The first domain in the forest is called the forest root domain. For multiple domain trees, each domain tree consists of a unique namespace. Trust relationships Allow users in one domain to access resources in another domain. Domains within a tree and forest are automatically created as two-way transitive trusts. A transitive trust is based on the following concept: If domain A trusts domain B, and domain B trusts domain C, then domain A trusts domain C. © 2013 John Wiley & Sons, Inc.

Active Directory Database An Active Directory database is logically separated into the following directory partitions: Schema partition (one per forest) Configuration partition (one per forest) Domain partition (one per domain) Application partition © 2013 John Wiley & Sons, Inc.

Single Domain versus Multiple Domains A single domain offers centralized management, where a set of administrators manage everything within the domain. Although multiple domains can be centrally managed, multiple domains also offer decentralized management, where different administrators manage each domain. If an organization establishes a presence in a foreign country and there are political or legal reasons to have separate security domains, you might consider implementing separate domains. © 2013 John Wiley & Sons, Inc.

User and Resource Domains Some companies define user domains and resource domains: User domains: Used to manage users. Administrators of the user domain have full administrative control over the user accounts, and can create, manage, and remove user accounts. Resource domains: Sometimes managed by different management teams that help secure resources. © 2013 John Wiley & Sons, Inc.

Multi-Forest Active Directory Environments Separate Active Directory forests also offer isolated security. By having separate forests, each forest root domain has the Schema Admins and Enterprise Admins AD DS forest. Separate forests are often deployed by government defense contractors and other organizations that require security isolation. © 2013 John Wiley & Sons, Inc.

Active Directory Schema The Active Directory schema defines the objects and attributes of those objects. Because the schema is shared between domains, the domain admins of the various domains must agree on the schema changes. Therefore, if you require different schemas, you can use multiple forests. © 2013 John Wiley & Sons, Inc.

Upgrading Existing Domains and Forests Because Active Directory is a key component for many organizations, you must maintain Active Directory and be careful when upgrading to a newer version. Depending on your needs, the current state of Active Directory, and the hardware that Active Directory is running on, there are several options you can use to upgrade the Active Directory environment. These options include: In-place upgrade Add servers running Windows Server 2012 and promote to domain controllers Create a new AD DS Windows Server 2012 domain and migrate the objects to the new domain or merge the domains together © 2013 John Wiley & Sons, Inc.

Upgrading Domain Controllers To upgrade from Windows Server 2008 or Windows Server 2008 R2 Active Directory Domain Services (AD DS), you can: Upgrade the operating system of the existing domain controllers to Windows Server 2012 (assuming the hardware can support it) Introduce Windows Server 2012 servers as domain controllers, and then decommission the older domain controllers © 2013 John Wiley & Sons, Inc.

Clean Installation If you have a server running an old operating system, and you want to move to the new operating system, you can choose to perform an upgrade or perform a clean install. An upgrade usually consists of starting the install program and letting the new files overwrite the old files. Although the upgrade tends to be simple, and quicker, the clean install allows you to start fresh with no old files or configuration on the machine. When you want the most reliable system, it is always best to perform a clean install. © 2013 John Wiley & Sons, Inc.

Upgrading the Schema For a domain running in Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2 functional level, you can install Windows Server 2012 and add the computer to the domain. However, before you promote a server running Windows Server 2012 to a domain controller, you must upgrade the schema. In previous versions of Windows, you would use the adprep.exe tool to upgrade the schema. While the Windows Server 2012 includes adprep32.exe, it has been deprecated. Instead, the Active Directory Domain Services Installation Wizard included in Server Manager incorporates the commands necessary to upgrade the AD DS forest schema. © 2013 John Wiley & Sons, Inc.

Objective 5.2: Configuring Trusts

Trusts Trusts are relationships between one Windows domain and another Windows domain or non-Microsoft Kerberos v5 realm. Trusts are created to allow users in one domain the ability to authenticate and then access resources on another domain, forest, or realm. © 2013 John Wiley & Sons, Inc.

Trust Types Two types of trusts can exist in a forest and domain environment: Automatically generated at forest/domain creation Manually created after forest or domain creation, these trusts connect directly to domains and forests inside or outside the existing enterprise. © 2013 John Wiley & Sons, Inc.

Trust Direction One-way incoming trust direction One-way outgoing trust direction Two-way trust © 2013 John Wiley & Sons, Inc.

Trust Types

Transitivity Transitivity determines how far the trust relationship authentication requests can traverse existing trust authentication paths: Transitive Trust authentication follows the flow of existing trust relationships that are part of the trusted domain. If a transitive trust is created with an external forest, the authentication can traverse the path of the forest's existing trusts. Nontransitive An explicit trust between two domains ignores any existing trusts in the external or internal domain or forest. The domains in the trust only trust each other and will not traverse any existing or future trust paths of either domain. © 2013 John Wiley & Sons, Inc.

Trust Authentication Trust authentication defines how explicit the authentication and access to the trusting domain will be. There are three scopes of trust authentication: selective authentication, domain-wide authentication, and forest-wide authentication. Trust authentication is configured on external and forest trusts. © 2013 John Wiley & Sons, Inc.

SID Filtering SID Filtering protects trusting domains from malicious users. Malicious users might attempt to inject SIDs of an elevated user or group in the trusting domain to the sIDHistory of a user in the trusted domain. When SID Filtering is disabled, the malicious user can successfully inject the sIDHistory and gain privileged administrative access to resources in the trusting domain. It is best practice to keep SID Filtering enabled unless absolutely necessary. © 2013 John Wiley & Sons, Inc.

Objective 5.3: Configuring Sites

Configuring Sites Sites are representative of the physical AD DS domain topology and contain domain controllers, clients, and services. At forest creation, the default site created is called Default-First-Site-Name, which contains all domain controllers added to the domain until new sites and subnets are created. Sites group domain controllers together at the same physical location to allow efficient replication between one another on high-speed internal networks before sending any directory changes to remote locations or branch offices. © 2013 John Wiley & Sons, Inc.

Intrasite and Intersite Replication All domain controllers within a site replicate with one another in a process called Intrasite replication, which is the replication of compressed data that occurs across site links between domain controllers located in different sites. Intersite replication, through the use of Bridgehead servers, replicates directory partitions from one site's bridgehead server to another site's bridgehead server. Each bridgehead server then replicates the changes internal to its replica domain controllers through Intrasite replication. © 2013 John Wiley & Sons, Inc.

Configuring Subnets Subnets are created to group and assign computers within the same network subnet to a site. Subnets can be assigned only to one site and can be IPv4 or IPv6 subnets. At logon, domain controllers assign clients to sites based on their network address and subnet. When designing an AD DS site topology, make sure all IP ranges used by clients and servers are added to a subnets list and assigned to a site for optimized service access and domain controller referencing. © 2013 John Wiley & Sons, Inc.

Site Links Site links define the logical replication link between sites to perform Intersite replication, allowing for faster and optimized replication between sites based on configured costs and frequencies. Site links manage the logical flow of replication between physical sites. The DEFAULTIPSITELINK site link object is created by default at forest creation. When new domains and domain controllers are added to the forest, if new sites links are not manually created, they will all become members of the DEFAULTIPSITELINK site. © 2013 John Wiley & Sons, Inc.

Site Links In large enterprise environments, spanning several physical locations, replication traffic is at the mercy of the WAN links between physical locations. This situation can cause replication issues when there is a mix of reliable and unreliable network paths between sites. Physical infrastructure between sites might differ and have different requirements about when to utilize bandwidth. To resolve the problem of costly bandwidth and timing restrictions of physical connections, you can implement site links. © 2013 John Wiley & Sons, Inc.

Intersite Transport Protocols IP Transport Replicates all AD DS partitions synchronously to domain controllers in well-connected sites. Is efficient, reliable, and the preferred method of replication between Intersite partners. SMTP Transport Is configured with the Simple Mail Transport Protocol (SMTP) Sends replication asynchronously via e-mail messages. Requires the implementation of Active Directory Certificate Services (AD CS). Replicates only the schema, configuration, and Global Catalog partitions. Using SMTP does not replicate the domain partition. Can be used in situations where RPC over TCP/IP is not configured between two sites. © 2013 John Wiley & Sons, Inc.

Bridgehead Servers Bridgehead servers Are automatically configured by AD DS. Take the changes made during Intrasite replication and then replicate those changes to the bridgehead server in a connected site. It is best practice to allow AD DS to handle the assignment of the bridgehead server tasks to specific domain controllers. In certain environments, you might need to manually configure a bridgehead server dedicated to the additional processing and traffic requirements. © 2013 John Wiley & Sons, Inc.

Bridgehead Servers © 2013 John Wiley & Sons, Inc.

Site Link Bridges Site link bridging allows transitive linking between all sites in the forest. Bridge All Site Links is enabled by default to permit site link bridging between all sites in the forest. © 2013 John Wiley & Sons, Inc.

Replication Interval The replication interval defines how often replication across the site link occurs. By default, replication on site links are configured to occur every 180 minutes and can be modified within the site link properties. Replication between sites might need to occur more frequently if there are constant changes to AD DS that need to be seen in branch offices immediately. The replication interval can be configured to allow replication every 15 minutes across site links. © 2013 John Wiley & Sons, Inc.

Objective 5.4: Managing Active Directory and SYSVOL Replication

Read-Only Domain Controllers Read-only domain controllers (RODCs) Are used in environments where there is a need for a domain controller in a branch office that does not have a secured physical environment. Are also used when there is a risk of theft, or even rarely, when there is an application requiring installation on a domain controller that users must log in to at the terminal or with terminal services. © 2013 John Wiley & Sons, Inc.

Read-Only Domain Controllers As the name "read-only domain controller" implies, its involvement with AD DS is truly read-only. Unidirectional replication means replication occurs in only one direction, from a writeable domain controller to the read-only domain controller. Implementing Filter Attribute Sets allows administrators to mark attributes as “Confidential” when being replicated to RODCs. Attributes marked as confidential and that are part of the Filtered Attribute Set will not be replicated to an RODC. © 2013 John Wiley & Sons, Inc.

Password Replication Policy To provide authentication of users and computers at a branch office that utilizes an RODC, the RODC must know and store the password of that user or computer. To prevent unwanted users from logging in to or authenticating against an RODC, only users that are members of the Allowed RODC Password Replication Group will be allowed to authenticate to the RODC. As an additional option, to prevent users from authenticating against the RODC, add the users or user group to the Denied RODC Password Replication Group. © 2013 John Wiley & Sons, Inc.

Upgrading SYSVOL Replication Many environments started off as an Active Directory environment running Windows Server 2003 or earlier, prior to the addition of Windows Server 2008 and Windows Server 2012. The replication process of recently upgraded domain’s SYSVOL folders could still be configured to use the File Replication Service (FRS). The SYSVOL folder on each domain controller contains a copy of logon scripts and Group Policies, and it is a repository for public access files used by domain controllers. © 2013 John Wiley & Sons, Inc.

Upgrading SYSVOL Replication To upgrade from File Replication Service (FRS) to Distributed File System Replication (DFSR), the domain functional level must be Windows Server 2008 or higher. This means all domain controllers in the domain must be at least Windows Server 2008 or higher. © 2013 John Wiley & Sons, Inc.

Upgrading SYSVOL Replication Each of the four Global States of an FRS to DFSR upgrade allows all domain controllers to balance and prepare for the next state: Start (State 0): Live AD DS SYSVOL replication between domain controllers is performed using FRS. Prepared (State 1): Live AD DS SYSVOL replication between domain controllers is performed using FRS. Redirected (State 2): Live AD DS SYSVOL replication between domain controllers is performed using DFSR. Eliminated (State 3): All Live AD DS SYSVOL replication between domain controllers is performed using DFSR. FRS SYSVOL replication is removed, including the SYSVOL folder and its contents. © 2013 John Wiley & Sons, Inc.