5.1. Functional Level

Transcription

1 5.1. Functional Level A functional level is a set of operation constraints that determine the functions that can be performed by an Active Directory domain or forest. A functional level defines: Which Active Directory Domain Services (AD DS) capabilities are available to the domain or forest. Which Windows Server operating systems can be run on domain controllers in the domain or forest. Functional levels do not affect which operating systems you can run on workstations and servers that are joined to the domain or forest. The following table shows the features that are available at each domain functional level: Domain Functional Level Supported Domain Controller Operating Systems 2000 Native Features The following features are available in 2000 Native: Universal groups are available for security and distribution groups. Group nesting. Group converting (allows conversion between security and distribution groups). Security Identifier (SID) history, allowing security principals to be migrated among domains while maintaining permissions and group memberships. Windows Server 2003 includes all of the features available in 2000 Native mode, and adds the following features:

2 Domain controllers rename. Update logon time stamp. User password on InetOrgPerson object. User and computer container redirect. The redirect feature allows the definition of a new, well known location for the two default containers (cn=computers <domain root> and cn=users <domain root>) which are provided for housing computer and user accounts. Authorization Manager can store its authorization policies in AD DS. Constrained delegation allows applications to take advantage of the secure delegation of user credentials using Kerberos based authentication. Selective authentication allows you to specify the users and groups from a trusted forest who are allowed to authenticate to resource servers in a trusting forest R R2 Windows Server 2008 includes all of the features available in 2003 mode, and adds the following features: Distributed File System (DFS) replication for the Windows Server 2003 System Volume (SYSVOL). Advanced Encryption Standard (AES 128 and AES 256). Last Interactive Logon Information, which includes: o The time of the last successful interactive logon for a user. o The name of the workstation from which the user logged on. o The number of failed logon attempts since the last logon.

3 Fine grained password policies that allow you to specify password and account lockout policies for users and global security groups in a domain. The following table shows the features that are available at each forest functional level: Forest Functional Level Supported Domain Controller Operating Systems 2000 Native R R R2 Features Global catalog replication improvements are available if both replication partners are running Windows Server The following features are available in 2003: Global catalog replication improvements Defunct schema objects Forest trusts Linked value replication which allows you to change group membership to store and replicate values for individual members instead of replicating the entire membership as a single unit. Linked value replication: o Uses less network bandwidth and fewer processor cycles during replication. o Prevents you from losing updates when you add or remove multiple members concurrently at different domain controllers. RODC deployment capability Domain rename Improved Knowledge Consistency Checker (KCC) Improved AD replication algorithms

4 Dynamic auxiliary classes InetOrgPerson objectclass change The ability to create instances of new group types to support role based authorization Deactivation and redefinition of classes and attributes in the schema R R2 No additional features have been added to 2008, but it does include all of the features that are available at the 2003 level. Note: Windows Server 2003 and Windows 2000 Server domain controllers support additional domain and forest functional levels. The domain and forest functional level must be at a minimum Windows Server 2000 to install a Windows Server 2008 domain controller. Note: To upgrade an AD DS domain that is running at an older Windows Server functional level to an AD DS domain running at Windows Server 2012 functional level, you must first upgrade all the domain controllers to the Windows Server 2012 operating system. You can perform this upgrade by upgrading all of the existing domain controllers to Windows Server 2012, or by introducing new domain controllers that are running Windows Server 2012, and then phasing out the existing domain controllers. Note: Windows Server 2003 domain and functional levels of AD DS and the File Replication Service have been deprecated in Windows Server 2012 R2 Note: You can enable the Active Directory Recycle Bin only when the forest functional level is set to Windows Server 2008 R2 or newer. Note: To simplify and provide full automatic password and SPN management, we strongly recommend that the AD DS domain be at the Windows Server 2008 R2 functional level or higher.

5 5.2. Functional Level Management You should know the following about functional level management: To allow you to use as many Active Directory Domain Services (AD DS) features as possible, you should set the domain and forest functional levels to the highest value that your environment can support when you deploy AD DS. For example: o Select the Windows Server 2012 R2 functional level during the deployment process if you are sure that you will never add domain controllers that run Windows Server 2008/2008 R2 or 2012 to the domain or forest. This setting makes it possible for you to use all the features that are available in AD DS. o Select the Windows Server 2008 functional level during the deployment process if you are sure that you will never add domain controllers that run Windows Server 2003 to the domain or forest. This setting makes it possible for you to use all the features that are available in AD DS. o Select the Windows Server 2003 functional level if you might retain or add domain controllers that run Windows Server o Select the Windows Server 2000 functional level if you might retain or add domain controllers that run Windows Server Note: AD DS sets the functional levels by default when you deploy the first Windows Server 2008 domain controller in your forest root domain. You cannot reverse the operation of raising the functional level. If you have to revert to a lower functional level, you must rebuild the domain or forest, or restore it from a backup copy. The following guidelines apply to raising the domain or forest functional levels:

6 Type Details Use Active Directory Users and Computers or Active Directory Domains and Trusts to raise the domain functional level. Domain You must be a member of the Domain Admins group to raise the domain functional level. The domain functional level can only be raised on the Primary Domain Controller (PDC) emulator operations master. The AD DS administrative tools which are used to raise the domain functional level, such as the Active Directory Domains and Trusts snap in and the Active Directory Users and Computers snap in, will automatically target the PDC emulator when the domain functional level is raised. The functional level of a domain can only be raised if all domain controllers in the domain run the version or versions of Windows Server operating system that is supported by the new functional level. For example, before you raise the domain functional level to 2012 R2, you must upgrade all domain controllers in that domain to Windows Server 2012 R2. To use the Windows Server 2008 domain level features without upgrading your entire Windows 2000 forest to Windows Server 2008, raise only the domain functional level to Windows Server It is not possible to set the domain functional level to a value that is lower than the forest functional level. The Windows 2000 native and Windows Server 2003 domain functional level values are not available on the Set domain functional level page of the 2008 Active Directory Domain Services Installation Wizard. Use Active Directory Domains and Trusts to raise the forest functional level. Forest You must be a member of the Enterprise Admins group to raise the forest functional level. The forest functional level can only be raised on the schema operations master. The schema operations master is targeted by

7 the Active Directory Domains and Trusts when the forest functional level is raised. The functional level of a forest can only be raised if all domain controllers in the forest run the version or versions of Windows Server operating system that is supported by the new functional level. The following circumstances might prevent you from raising the functional level to Windows Server 2012 R2: Domain controllers that don't run the necessary operating system version Insufficient hardware A domain controller running an antivirus program that is incompatible with Windows Server 2012 R2 Use of a version specific program that does not run on Windows Server 2012 R2 The need to upgrade a program with the latest service pack Sergey Gorokhod MCT/MCSE/MCITP/MCTS/MCSA/CCSE/CCSA/CCNA/A+ E mail: sergey@infosec.co.il Mob: (+972)

8 5.3. Sites and Subnets Active Directory replication is the process of copying Active Directory database changes between domain controllers. Active Directory uses sites and subnets to represent the physical layout of the network and to optimize and customize replication traffic. Active Directory uses the following objects to represent the physical structure of the network and to control replication traffic. Object Description A subnet represents a physical network segment. Subnet The subnet object identifies the network address and mask. Both IPv4 and IPv6 are supported. Domain controllers are indirectly associated with a subnet based on the domain controller IP address. A site represents a group of well connected networks (networks that are connected with high speed links). Site Sites are linked to one or more subnets. All subnets within the site can communicate over high speed and reliable links. Domain controllers are associated with a specific site. You can specify the target site during installation, or move existing domain controllers into sites. When you install the first domain controller in a forest, a default site is created named Default Site First Name. Sites can host domain controllers from more than one domain, and a domain can be represented in more than one site. You typically create additional sites to identify locations separated by WAN links.

9 A site link is an Active Directory object that represents logical paths between sites that can be used for Active Directory replication. Site link Site links represent logical, not physical connections. For example, you can have all sites connected with a single site link. In most cases, you would match the site link design to the physical network, with a site link for each WAN link. When you install the first domain controller in a forest, a default site link named DEFAULTIPSITELINK is created. Sites are associated with a site link. Each site link can have multiple associated sites, and each site can be associated with more than one site link. In a simple scenario, you can have all sites associated to the default site link. The site link object controls the replication schedule between sites. When more than one logical route exists between two sites, the site link with the lowest cost determines the preference for using a specific site link for replication. The higher the site link cost, the slower the link speed. Site link bridge A site link bridge is a collection of two or more site links that can be grouped as a single logical link. The best way to understand site link bridging is to consider three sites, linked as follows: Site A (Site Link 1) Site B (Site Link 2) Site C Without bridging, Site A does not have a communication path to Site C. With bridging, the two site links in the example are transitive, allowing a connection from Site A to Site C. By default, site link bridging is enabled for all sites. If you disable site link bridging, you must manually specify site link bridges.

10 A bridgehead server is a domain controller in a site that replicates with domain controllers in other sites. Bridgehead server Replication between sites occurs only between bridgehead servers. The bridgehead server in one site contacts a bridgehead server in another site for replication information. Replication within a site does not use bridgehead servers. All domain controllers replicate with all other domain controllers in the site. Active Directory automatically identifies a bridgehead server in each site (typically it will be the first domain controller in the site). You can manually designate bridgehead servers to control which domain controllers participate in inter site replication. A connection is a logical communication channel between domain controllers. Connection Connections are created automatically, although you can manually create connections if desired. The connector is a property of a domain controller, and identifies one other domain controller from which replication changes will be received. Replication is always a pull configuration, meaning that the target domain controller contacts the source domain controller for replicated information. Connections are unidirectional (one way). For bidirectional communications, two connections must exist between the domain controllers (one configured on each domain controller).

11 5.4. AD Replication Sites and Services distinguishes between two types of replication: Intra site replication occurs between domain controllers within a site. Intra site replication is not compressed and happens automatically between all domain controllers within the site. You can modify the frequency to occur up to four times per hour. Inter site replication occurs between bridgehead servers between sites. Inter site replication is compressed, scheduled, and configured to use a specific networking protocol. Compressing replication data allows the data to be transferred over WAN links more quickly, thereby conserving network bandwidth. To customize inter site replication, configure sites and site links. Replication uses one of following transport protocols: Protocol Description Directory Services Remote Procedure Call (DS RPC), also known as IP in Active Directory Sites and Services, is used for intra site and inter site replication. Directory Services Remote Procedure Call (DS RPC) Remote Procedure Calls (RPC) runs over IP. IP replication adheres to replication schedules by default, although you may configure Active Directory replication to ignore schedules. IP replication does not require a Certification Authority (CA). Note: By default, both intra site and inter site transport for AD DS replication is RPC over IP.

12 Inter Site Messaging Simple Mail Transfer Protocol (ISM SMTP) Inter Site Messaging Simple Mail Transfer Protocol (ISM SMTP), also known as SMTP in Active Directory Sites and Services, allows replication within mail messages in environments where wide area network (WAN) links are not available. In this case, replication occurs according to the messaging schedule and not the site link schedule. SMTP replication: Is used for replication over site links (inter site). Is not used for replication within a site (intra site). Uses 56 bit encryption. Is used for high latency links where RPC over IP replication would probably fail. Can replicate only the configuration and schema directory partitions and global catalog read only replicas (not writable domain data). Requires an enterprise CA when you use it over site links. Sergey Gorokhod MCT/MCSE/MCITP/MCTS/MCSA/CCSE/CCSA/CCNA/A+ E mail: sergey@infosec.co.il Mob: (+972)

13 5.5. Replication Configuration Intra site replication occurs between domain controllers within a site. For intrasite replication, be aware of the following: By default, replication occurs once every hour. To modify the replication frequency, edit the NTDS Settings for the site. For each hour, you can configure the following options for the replication frequency: o None (replication does not take place) o Once per hour o Twice per hour o Four times per hour Bridgehead servers, site links, or site link bridging are not used. Connections are created automatically as necessary. Inter site replication occurs between bridgehead servers between sites. The following table describes configuration steps you can take when managing intersite replication. Configuration Description A preferred bridgehead server is a domain controller in a site that has been designated as a potential bridgehead server. Preferred bridgehead server To designate preferred bridgehead servers, edit the server properties and add the transport protocol to the preferred bridgehead server list. The preferred bridgehead server should be a global catalog server. You can designate more than one server as a preferred bridgehead server. If multiple servers in a site are preferred bridgehead servers, the replication process automatically selects one of the servers during replication. When at least one preferred bridgehead server exists in a site, replication will only use preferred servers for inter

14 site replication; non preferred servers will never be used. This means that: o To prevent a specific server from being used for inter site replication, configure one or more preferred bridgehead servers. o If all bridgehead servers in a site are unavailable, inter site replication will not occur. For this reason, you should assign more than one preferred bridgehead server. If no preferred bridgehead servers are designated, the system chooses which server to use for the bridgehead server from the list of servers in the site that are enabled for the transport protocol. The replication schedule identifies the hours of the day when replication is possible. Replication schedule To edit the replication schedule for inter site replication, edit the properties of the site link and click the Change Schedule... button. The schedule identifies which days and hours of the day that replication is allowed. By blocking replication, you give priority to other traffic, but you also increase replication latency. Domain controllers store time in Coordinated Universal Time (UTC). Time settings in site link object schedules conform to the local time of the site and computer on which the schedule is set. When a domain controller contacts a computer that is in a different site and time zone, the schedule on the domain controller displays the time setting according to the local time for the site of the computer. It is best to synchronize your SMTP site link replication schedule with the times your network's SMTP connections are available. Do not configure site link replication availability on SMTP site links unless the following is true:

15 o o o Scheduled connections are used by the site links. The SMTP queue is not on a schedule. Information is being exchanged directly from one server to another. This does not include exchanges that use intermediaries such as a network Ethernet backbone. The replication frequency identifies how often replication occurs (if it is allowed). The replication frequency works together with the replication schedule to control when replication occurs. Replication frequency To modify the replication frequency for inter site replication, edit the properties of the site link. The replication frequency is scheduled in 15 minutes intervals. The default replication interval is 180 minutes (3 hours). A small interval decreases latency but increases the amount of wide area network (WAN) traffic. To keep domain directory partitions up to date, low latency is preferred. The replication frequency is dependent upon the times when replication over this site link is scheduled to be available. For example, if the schedule allows replication between 02:00 am and 04:00 am: o If the replication interval is set for 30 minutes, replication can occur up to four times during the scheduled time. o If the replication interval is set for 180 minutes, replication might occur once, or not at all. To ensure that replication takes place, configure the replication frequency to be shorter than the scheduled time interval.

16 The site link cost is a number assigned to a site link that identifies the overall relative cost of using that site link. The cost is used to select the optimal path between sites when more than one path exists. Site link cost Cost is usually based not only on the total bandwidth of the link but also on the availability, latency, and monetary cost of the link. The cost value is a relative value. The number has meaning only in relation to other site link costs. The default link cost is 100. If you do not modify the site link cost, all site links will have an equal cost value. To force traffic over one link, set a lower cost. For example, set a lower cost for high speed links to force traffic over the high speed link. Configure a higher cost for dial up links that are used as backup links. To modify the cost, edit the properties of the site link object. Site link bridging enables transitivity between site links, so that replication between sites that are not directly connected together with a site link can still take place. Be aware of the following when planning for bridged sites: Bridged site replication By default, all site links are bridged. To prevent automatic bridging, edit the properties of the transport protocol (such as IP) and deselect the Bridge all site links option. By disabling this option, you must manually create site link bridges. To create a site link bridge, right click the transport protocol and select New Site Link Bridge... For replication between bridged sites to be successful, the following conditions must be met: o Schedules set on the site links between the two bridged sites must overlap. The intersection of the replication schedules on all the relevant links

17 o determines the connection schedule between the two sites. The replication frequency must be sufficient for replication to occur. The replication interval is the maximum interval along the minimum cost path of site link objects from one end of the connection to the other. An easy way to ensure replication occurs between bridged sites is to set the same replication schedule and frequency on all site links connecting the two bridged sites. Link costs are cumulative when multiple links are required between sites. If more than two paths are available (including bridged or non bridged paths), the one with the lowest cost is used (even if this path crosses more sites and site links). See Bridged Site Costs for an example below. You can force replication to take place using one of the following methods: Forced replication To force replication between two sites, right click the connection objects and choose Replicate Now. To force replication to or from a domain controller, rightclick the NTDS Settings object below the server and choose one of the following: o Replicate configuration from the selected domain controller o Replicate configuration to the selected domain controller Run repadmin.exe /replicate from a command prompt to force replication between a source and a destination domain controller. List the target system first, followed by the source system. Use /syncall to force replication between all domain controllers in a site.

18 Note: To configure sites, subnets, and replication, you must be a member of the Domain Admins group or the Enterprise Admins group. Bridged Site Costs Example: The following diagram shows three sites connected with site links. In this example, site link bridging is enabled. Be aware of the following: For replication between Site A and Site C, two paths exist. Replication can use: o The site link that connects Site A with Site C. o The bridged path from Site A to Site B, then Site B to Site C. If the default site link costs are used for all site links: o The link from Site A to Site C has a cost of 100. o The path from Site A to Site C through Site B has a cost of 200. Given the default site link costs, the link from Site A to Site C would be used. To force replication to use the bridged path from Site A to Site B and then to Site C, take one of the following actions: o Increase the site link cost between Site A and Site C to a value higher than 200. o Decrease the site link cost of the link from Site A to Site B and the link from Site B to Site C so that the total cost is below 100. Note: If two paths have an equal cost, the path with the fewer sites will be used.

19 5.6. DFS Replication The SYSVOL folder contains logon scripts, group policy templates, and other resources which are critical to the health and management of an Active Directory domain. Every domain controller should have the same contents in their respective SYSVOL folder; however, as these resources are modified and replicated to other SYSVOL folders throughout the domain, errors can occur. In previous version of Windows Server, the File Replication Service (FRS) was used to replicate the contents of the SYSVOL folder, but troubleshooting and configuring FRS is quite difficult. To overcome some of the limitations of FRS, domains with a functional level of Windows Server 2008 can use the Distributed File System (DFS) Replication engine to replicate the contents of the SYSVOL folder. Using DFS replication instead of FRS replication offers the following benefits: Faster replication and decreased network traffic through the use of differential replication with Remote Differential Compression (RDC). With RDC, only the changed blocks are replicated when a file is changed, not the entire file. Flexible scheduling and bandwidth throttling to limit the quantity of data transmitted and/or accepted within a specified period of time. Automatic self healing for many database errors. Improved support for read only domain controllers. Built in health monitoring tools. When you install a new forest with the Windows Server 2008 and later domain functional level, DFS Replication is used automatically. For domains using other domain functional levels, you can migrate from FRS replication to DFS replication as follows: 1. Upgrade all domain controllers to Windows Server 2008 and later. 2. Change the domain functional level to Windows Server 2008 and later. 3. Verify the current state of replication by running repadmin /ReplSum. Correct any problems that are noted. 4. Run the dfsrmig command to start and control the migration. The following states indicate stable stages in the migration process:

20 State Not initiated Start Prepared Redirected Eliminated Description If SYSVOL migration has not been started, the state will be Not initiated. Only FRS is used to replicate the SYSVOL contents. Run the dfsrmig /SetGlobalState 0 command to start DFS migration. Running this command contacts the domain controller with the PDC master and sets a migration directive in Active Directory. This directive is replicated to all other domain controllers through normal Active Directory replication. At this stage, DFS replication has not yet started, and only FRS replication is still being used. Run the dfsrmig /SetGlobalState 1 command to instruct domain controllers to begin DFS replication. During this stage, a copy of SYSVOL is created in a folder called SYSVOL_DFSR and is added to a DFS replication set. DFS Replication begins to replicate the contents of the SYSVOL_DFSR folders on all domain controllers. However, FRS continues to replicate the original SYSVOL folders. FRS replication is still the main replication method. Run the dfsrmig /SetGlobalState 2 command to shift the main responsibility for SYSVOL replication to DFS. The SYSVOL share is changed to refer to SYSVOL_DFS\sysvol. Clients now use the SYSVOL_DFSR folder to obtain logon scripts and Group Policy templates. FRS continues to operate, but the DFS replicated folder is used as the master SYSVOL folder. Run the dfsrmig /SetGlobalState 3 command to stop FRS replication and rely only on DFS replication. Be aware of the following when managing migration: The states listed above are stable migration states. Additional intermediary states exist during the transition from one stage to another. By using a staged migration approach, you can start the migration to DFS Replication, and proceed to the next step after you have verified that everything is working correctly. Run dfsrmig /GetGlobalState to view the current DFS Replication migration setting on the PDC. This command indicates the current setting, but might

21 not reflect the current state of each domain controller. Domain controllers may not be synchronized with each other due to the time it takes to notify the domain controller of the new migration state and the time for the domain controllers to make the changes required by the state. Run dfsrmig /GetMigrationState to view the current migration state of each domain controller in the domain. During the Start, Prepared, and Redirected stages, you can roll back (undo) the migration. o o After the system reaches the Eliminated stage, you cannot revert back to FRS replication. For this reason, do not initiate transition to the Eliminated stage unless you are confident that DFS Replication is working correctly. To roll back the migration, use the dfsrmig /SetGlobalState command with the desired rollback level (0 or 1). The changes will be removed back to the indicated stage. Sergey Gorokhod MCT/MCSE/MCITP/MCTS/MCSA/CCSE/CCSA/CCNA/A+ E mail: sergey@infosec.co.il Mob: (+972)

22 5.7. Global Catalog and UGMC In a multiple domain and multiple site design, user logon and forest wide searches require that multiple domains be contacted to identify user accounts and to identify membership in universal groups. To improve performance in these situations, use the following features: Feature Description The Global Catalog (GC) is a database that contains a partial replica of every object from every domain within a forest. A server that holds a copy of the Global Catalog is a global catalog server. By default, all domain controllers are global catalog servers. The Global Catalog facilitates faster searches because different domain controllers do not have to be referenced. The Global Catalog is distributed through multimaster replication. Global Catalog To designate a server as a global catalog server, use one of the following: In Active Directory Users and Computers, edit the domain controller computer account. On the General tab, click the NTDS Settings... button. In Active Directory Sites and Services, edit the NTDS Settings properties beneath the server object. Promoting a domain controller to be a global catalog server commonly takes a significant amount of time. Make sure that there is sufficient time for the account and the schema information to replicate to the new global catalog server.

23 As its name implies, the Universal Group Membership Caching feature caches the group membership of universal groups. During logon, universal group membership is checked for the user. By caching the group membership on a local domain controller: Universal Group Membership Caching (UGMC) The authenticating domain controller does not need to contact other domain controllers for the group membership information. Logon will still be allowed in the event of a WAN failure that separates a remote site from the remainder of the network. Edit the NTDS Site Settings of the site to enable UGMC. All domain controllers in a site must be running Windows Server 2003 or higher for universal group membership caching to work. Within a site, you will typically use a global catalog server or Universal Group Membership Caching (but not both). Place a global catalog server in the site if any of the following are true (use UGMC if all of the following are not true): The site has more than 100 users. The WAN link connecting the site to the rest of the network is reliable and fast. The location has roaming users. The location runs an application that requires a global catalog server. Lightweight Directory Access Protocol (LDAP) is the primary global catalog protocol that specifies directory communications. Be aware of the following LDAP details: LDAP runs directly over TCP/IP, and it can also run over User Datagram Protocol (UDP) connectionless transports. Clients use LDAP to query, create, update, and delete information that is stored in a directory service over a TCP connection through the TCP default port 389. When a search request is sent to port 389, the search is conducted on a single domain directory partition.

24 If the object is not found in that domain or the schema or configuration directory partitions, the domain controller refers the request to a domain controller in the domain that is indicated in the distinguished name of the object. Global catalog clients can use LDAP to query Active Directory over a TCP connection through the TCP port o When a search request is sent to port 3268, the search includes all directory partitions in the forest (i.e. the search is processed by a global catalog server). o Only global catalog servers receive LDAP requests through port Active Directory supports LDAP v2 and LDAP v3. LDAP v3 is an industry standard that can be used with any directory service that implements the LDAP protocol. LDAP v3 is backward compatible with LDAP v2. Sergey Gorokhod MCT/MCSE/MCITP/MCTS/MCSA/CCSE/CCSA/CCNA/A+ E mail: sergey@infosec.co.il Mob: (+972)

25 5.8. Operations Master Roles Operations master roles, also referred to as Flexible Single Master Operation (FSMO) roles, are specialized domain controller tasks assigned to a domain controller in the domain or forest. Operations master roles are useful because certain domain and enterprise wide operations are not well suited for the multimaster replication performed by Active Directory to replicate objects and attributes. A domain controller that performs an operations master role is known as an operations master or operations master role owner. Having a single operations master means that the operations master role owner must be available: When dependent activities in the enterprise or domain take place. To make directory changes associated with that specific operations master role. The following table lists the operation master roles at the domain and forest levels: Forest Roles Description The schema master maintains the Active Directory schema for the forest. Schema Master Schema updates are replicated from the schema master to all other domain controllers in the forest. Regardless of the number of domains, there is only one schema master in the forest. Only the schema master can perform write operations to the directory schema. All other domain controllers hold read only replicas of the schema.

26 The domain naming master adds new domains to and removes existing domains from the forest. The domain naming master: Domain Naming Master Ensures that domain names are unique Must be accessible to add or remove a domain from the forest Must also be a global catalog server if it resides in a multiple domain environment Domain Roles Note: The domain naming master is not essential in a singledomain environment. Description The RID master allocates pools or blocks of numbers (called relative IDs or RIDs) that are used by the domain controller when creating new security principles (such as user, group, or computer accounts). The RID is assigned to a new security principal when it is created, and is combined with the domain ID to create a security identifier (SID). The RID master: Relative ID (RID) Master Ensures domain wide unique relative IDs (RIDs). Because all RIDs are unique, each SID is also unique. Allocates pools of RIDs to each domain controller. Processes a new pool of RIDs when the domain controller has used all of the available RIDs. Note: RIDs (and therefore SIDs) are never reused. Deleting security principals on a domain controller will not free up additional RIDs for future use. Instead, the domain controller must get a new pool of RIDs when the pool is depleted.

27 The PDC emulator acts like a Windows NT 4.0 Primary Domain Controller (PDC) and performs other tasks normally associated with NT domain controllers. The PDC emulator: Primary Domain Controller (PDC) Emulator Replicates password changes within a domain Ensures synchronized time within the domain (and between domains in the forest) Acts as the domain master browser, creating browse lists of workgroups, domains, and servers Handles password discrepancies Acts as a focal point for all Group Policy changes to avoid Group Policy object conflicts The infrastructure master is responsible for updating changes made to objects. The infrastructure master: Infrastructure Master Tracks, moves, and renames objects Updates references from objects in its domain to objects in other domains Updates group membership changes You should know the following about operations master roles: Only one domain controller in the domain or forest performs each role. A forest with one domain has five operations master roles. Every additional domain in the forest adds three domain wide roles. The number of operations master roles in a forest and potential operations master role owners can be determined using the formula ((Number of domains * 3) + 2). Sergey Gorokhod MCT/MCSE/MCITP/MCTS/MCSA/CCSE/CCSA/CCNA/A+ E mail: sergey@infosec.co.il Mob: (+972)

28 5.9. Operations Master Roles Management As you add domain controllers to an existing forest, you can place the operations master roles load among the new and existing domain controllers. This will decrease single point of failure instances, accommodate planned downtime, and increase performance. Consider the following recommendations when designing operations master roles placement on various domain controllers: Place the schema master and domain naming master on a domain controller which is a global catalog server. If the domain naming master is not a global catalog server, certain operations that use the domain naming master, such as creating grand child domains, will fail. The schema master and domain naming master roles are rarely used and should be tightly controlled. With a few exceptions, the infrastructure master should not be placed on a global catalog server except in the following cases: o In a forest that contains a single Active Directory domain, the infrastructure master may be placed on any domain controller in the domain, regardless of whether that domain controller hosts the global catalog or not. o If every domain controller in a domain that is part of a multi domain forest also hosts the Global Catalog, the infrastructure master may be put on any domain controller in that domain. In other words, in a multi domain network, if the infrastructure master is placed on a global catalog server, all domain controllers in the domain must host the global catalog. Place the RID master and PDC emulator on a single domain controller. If you must separate the two roles, ensure they are well connected to each other (in the same domain and Active Directory site) and are direct replication partners. Place the operations masters in the site with the most users when you have multiple sites in a domain. If all sites have roughly equal numbers of users, make sure the operations master roles are in a site that can be accessed from all sites. One design option is to create the forest root domain without any other resources (users or computers), and then put the forest wide roles on

29 domain controllers in the forest root domain. This allows you to separate the forest wide masters from any other domains. When managing operations master role placement, be aware of the following: Before transferring a role, you must first connect to the destination domain controller. Use the netdom query fsmo or dcdiag /test:knowsofroleholders /v commands to identify the operations master role owners. If the domain controller with the role cannot be contacted, you will need to seize the role (instead of transfer the role). o You should only seize the role if the domain controller has failed and will not be returned to service in a reasonable period of time. o After seizing the schema, domain naming, or RID master operations master role, you must forcefully remove AD DS from the original domain controller. The PDC emulator and infrastructure operations master roles can be transferred back to the original domain controller if desired. It is easier to keep track of operations master roles if you cluster them on fewer machines. When managing operations master role placement, use the following tools: Tool Description MMC snap in management tools used for operations master role management include the following: MMC Snap in Management Tool Use Active Directory Users and Computers to transfer the RID master, PDC emulator, and infrastructure master roles. Use Active Directory Domains and Trusts to transfer the domain naming operations master. Use the Active Directory schema snap in to transfer the schema master role. By default, the Active Directory schema snap in must be registered and added to the console before you can make changes to the role. To register the Dynamic Link Library (DLL) for the AD

30 Schema snap in, type regsvr32 schmmgmt.dll at the command prompt. Use the following Ntdsutil.exe commands to transfer any of the operations master roles: Ntdsutil.exe 1. At the ntdsutil prompt, type roles. 2. Connect to the domain controller which will receive the seized operations master role. 3. At the fsmo maintenance prompts, type connections. 4. At the server connections prompt, use the DNS name of the controller and type connect to server <DNSName> 5. At the server connections prompt, type quit. 6. At the fsmo maintenance prompt, use the role name and type transfer <RoleName>. RoleName is one of the following: o schema master o domain naming master o RID master o PDC o infrastructure master 7. At the fsmo maintenance prompt, type quit. 8. At the ntdsutil prompt, type quit. Note: To seize the role, repeat the steps above, using seize RoleName instead of transfer RoleName in step 6. You cannot use a snap in management tool to seize a role. When you transfer a role, there might be a considerable delay as role data is transferred from one domain controller to another. When seizing a role, data loss is possible. To reduce these problems, you can designate a standby operations master. The standby operations master is configured as a direct replication partner with the primary operations master. If the primary operations master role owner needs to be taken offline, the standby operations master is as up to date as possible. Be aware of the following standby operations master details:

31 A single domain controller can be a standby operations master for multiple roles, or you can designate different standby domain controllers for each role. Use Active Directory Sites and Services to select direct replication partners. Manually create a connection from the standby server to the master, and another connection from the master to the standby server. Primary and standby operations master role owners should be selected on a per domain basis. Consider placing the standby operations master in the same site as the primary operations master for faster replication convergence consistency over a large group of computers. Consider placing the standby operations master in a remote site in the event of a site specific disaster at the primary location. Ensure remote site connections are configured for continuous replication over a persistent link. Sergey Gorokhod MCT/MCSE/MCITP/MCTS/MCSA/CCSE/CCSA/CCNA/A+ E mail: sergey@infosec.co.il Mob: (+972)

32 5.10. Trust A trust is an established relationship between different domains that allows mutual authentication, communication, and access to resources between the domains. You should understand the following properties of trusts: Characteristic Description The direction of the arrow identifies the direction of trust. For example, if Domain A trusts Domain B, the arrow would point from Domain A to Domain B. Domain A is the trusting domain, and Domain B is the trusted domain. The direction can be oneway or two way. One way Trust Two way Trust Direction of Trust Domain A trusts Domain B. Domain B does not trust Domain A. Domain A trusts Domain B. Domain B trusts Domain A. Note: A two way trust is the same as two one way trusts in opposite directions.

33 Direction of Resource Access Resource access is granted opposite of the direction of trust. For example, if Domain A trusts Domain B, users in Domain B have access to resources in Domain A (remember that users in the trusted domain have access to resources in the trusting domain). Transitivity defines whether trust between domains flows or is inherited to other trusted domains. A transitive trust allows the trust relationship to flow among domains. With a non transitive trust, trust relationships must be explicit between domains. Transitivity Domain A trusts Domain B. Domain A trusts Domain C. Therefore, Domain B trusts Domain C. Domain A trusts Domain B. Domain A trusts Domain C. Domain B does not trust Domain C.

34 5.11. Trust Types The following table shows the different types of trusts. Trust Type Characteristics and Uses The parent/child trust is established when a new child domain is added to an existing domain tree. Parent/child trusts are: Parent/child Created by default Transitive Two way Authentication requests flow upward from subordinate domains through their parent to the trusting domain. Tree root The tree root trust is a default trust type that is established when a domain tree is created in an existing forest. Tree root trusts are: Created by default Transitive Two way External External trusts provide access to resources located on a Windows NT 4.0 domain or a domain located in a separate forest that is not joined by a forest trust. External trusts are: Created manually Non transitive One way, although you can create two one way trusts to simulate a two way trust

35 Realm Realm trusts form a trust relationship between a non Windows Kerberos realm and a Windows Server 2008 and later domain. Realm trusts are: Created manually Transitive or non transitive Either one way or two way Forest trusts share resources between forests. Forest trusts are: Forest Created manually Transitive within the two forests, but non transitive between other forests (forest A trusts forest B and forest B trusts forest C, but forests A and C don't share trust) Either one way or two way Forest trusts can only be created if both forests are at a Windows Server 2003 or higher functional level. Shortcut Shortcut trusts improve user logon times between two domains within a forest by reducing the amount of Kerberos traffic on the network caused by authentication. The shortcut trust allows quicker response between the domains by enabling domains to pass authentication requests directly between themselves. Shortcut trusts are: Created manually Transitive Either one way or two way By default, Active Directory creates two way transitive trusts between parent and child domains in the tree or forest. These are known as Active Directory trusts or Kerberos trusts. You must manually create trusts with domains outside of the forest, or between other forests.

36 5.12. Trust Configuration You should know the following about configuring trusts: Only members of the Domain Admins group or the Enterprise Admins group can manage trust relationships. You can configure and validate a trust by using Active Directory Domains and Trusts or by using the Netdom command line tool. After a trust has been established, use Active Directory tools to validate the trust's connectivity, verify that it is working as designed, and ensure that communications over the trust are working. It is possible to validate all trusts that are made between domains, but you cannot validate realm trusts. It is possible to remove manually created trusts, but you cannot remove the default, two way, transitive trusts between domains in a forest. When removing trusts that were created manually, it is important to verify that they are successfully removed if you are planning to re create them. A two way trust is the same as two one way trusts in opposite directions. When creating external, shortcut, realm, or forest trusts, you have the option to create each side of the trust separately or to create both sides of a trust simultaneously. o If you choose to create each side of the trust separately, you will need to run the New Trust Wizard twice (once for each domain) and supply the same trust password for each domain. o If you choose to create both sides of the trust simultaneously, you will need to run the New Trust Wizard once and a strong trust password is automatically generated for you. You should be aware of the following authentication security settings that can be applied to trusts:

37 Setting Description Selective authentication is a security setting that can be enabled on trusts to provide Active Directory administrators with more control over which groups of users in a trusted forest can access shared resources in the trusting forest. Selective authentication: Selective authentication Allows administrators to grant access to shared resources in their organization s forest to a limited set of users in another organization s forest. Requires each user to be explicitly granted the Allowed to Authenticate permission on the security descriptor of the computer objects (resource computers) that reside in the trusting domain or forest. Domain wide authentication Forest wide authentication The domain wide authentication setting grants unrestricted access by all users in the trusted domain to all available shared resources in the trusting domain. Domain wide authentication is the default authentication setting for external trusts. The forest wide authentication setting grants unrestricted access by all users in the trusted forest to all available shared resources in any of the domains in the trusting forest. Forestwide authentication is the default authentication setting for forest trusts. Every time a user object moves from one domain to another, a new Security Identifier (SID) is generated and stored in the object SID property. The old SID is stored in the SID History attribute of the Active Directory security principal. It is possible for an attacker to compromise a domain controller in a trusted domain and use the SID history attribute to associate SIDs with new user accounts, thus granting the attacker unauthorized rights. This type of attack is prevented by enabling SID filter quarantining on all external trusts created by a domain controller.