Active Directory trust relationships

Transcription

1 Active Directory trust relationships A trust relationship consists of two domains and provides the necessary configuration between them to grant security principals on one side of the trust permission to use the resources that exist in the domain on the other. The trust is necessary because, in the world of Windows and other similar technologies, a domain does not unconditionally accept a user's credentials from other domains. Therefore, it is cumbersome or impossible to, for example, grant users from one domain the ability to print to a printer in another. The two sides of a Windows compatible trust relationship can consist of any of the following collective entities: A Windows NT domain An Active Directory domain An Active Directory forest A Kerberos realm A number of possible combinations of these four collective entities exists; the typical combinations are named and described below: Intra-forest trusts * created automatically between contiguously named Active Directory domains within the same forest *created automatically between a new Active Directory domain-tree root (a discontiguous namespace) and the forest root within a forest Shortcut trusts * administratively created between discontiguously named Active Directory domains within the same forest * administratively created between Active Directory domain-tree roots within the same forest (peer root domains) * administratively created between contiguously named Active Directory domains separated by an intermediary domain (grandparent domain to grandchild domain) External trusts * administratively created between two Active Directory domains either not in the same forest or when one or both of the domains is hosted by Windows NT Cross-forest trust * administratively created between two Active Directory forests * the trust must be created between the two forest root domains * the two forests must both be hosted by Windows 2003 or later domain controllers and the forest functional level must be raised to a minimum of two Realm trust * created between a Windows domain and a Kerberos realm

2 Other components of a trust relationship In addition to the two halves that make up a trust relationship, three additional properties of a trust must also be understood: Trust transitivity ("A" "B" "C") * a trust relationship is considered transitive if it permits trusting domains to, in turn, trust who it trusts. For example, if domain "A" trusts domain "B" and domain "B" trusts domain "C," then the trusts between domains "A & B" and domains "B & C" are deemed transitive only if domain "A" can be said to trust domain "C" without the need for a third explicit trust between "A" and "C" Trust directions ( or or ) * a trust relationship can be expressed as uni- or bi-directional Supported authentication protocols (NTLM and/or Kerberos) *a trust relationship is capable of supporting only those authentication protocols for which it was designed * a modern Windows trust relationship supports either NTLM or both NTLM and Kerberos * legacy Windows NT trusts supported only NTLM Enhancing the security of a trust relationship Two trust-related security enhancement technologies exist: SID filtering and the authentication firewall. SID filtering was introduced in the early days of Windows 2000 while the authentication firewall is available only with Windows In the next article, we'll delve into the specifics of SID filtering including its configuration, scope and some specific behavioral oddities.

3 Active Directory Replication As mentioned in an earlier section, the Active Directory database is replicated between domain controllers. The data replicated between controllers called "data" are also called "naming context". Only the changes are replicated, once a domain controller has been established. Active Directory uses a multimaster model which means changes can be made on any controller and the changes are sent to all other controllers. The replication path in Active Directory forms a ring which adds reliability to the replication. How Replication is Tracked USN - Each object has an Update Sequence Number (USN), and if the object is modified, the USN is incremented. This number is different on each domain controller. Stamps - Each object has a stamp with the version number, timestamp, and the GUID of the domain controller where the change was made Domain controllers each contain a "replica" which is a copy of the domain directory. The "directory update type" indicates how the data is replicated. The two types are: Origination update - A change made by an administrator at the local domain controller. Replicated update - A change made to the replica because of a replication from a replication partner. Replication Sequence Terms: Latency - The required time for all updates to be completed throughout all comain controllers on the network domain or forest. Convergence - The state at which all domain controllers have the same replica contents of the Active directory database. Loose consistency - The state at which all changes to the database are not yet replicated throughout all controllers in the database (not converged). 1. A change is made to the Active Directory database on a domain controller. The attribute of the object and the new USN is written to the database. The entire object is NOT replicated. This is called an atomic operation becuase both changes are done, or neither change is done. This is an origination update. There are four types: o o Add - An object is added to the database. Delete - An object is deleted from the database.

4 o Modify - An object in the database has its attributes modified. o Modify DN - An object is renamed or moved to another domain. 2. The controller the change was made on (after five minutes of stability), notifies its replication partners that a change was made. It sends a change notification to these partners, but only notifies one partner every 30 seconds so it is not overwhelmed with update requests. Each controller, in turn, when it is updated, sends a change notice to its respective replication partners. 3. The replication partners each send an update request with a USN to the domain controller that the change was made on. The USN identifies the current state of the domain controller making the change. Each change has a unique USN. This way the domain controller that has the change knows the state of the domain controller requesting the changes and only the changes are required to be sent. The time on each controller, therefore, does not need to be synchronized exactly although timestamps are used to break ties regarding changes. Changes are made through replication partners until all partners are replicated. At some point, replication partners will attempt to replicate partners that are already updated. This is where propagation dampening is used. If no changes have been performed in six hours, replication procedures are performed to be sure no information has been missed. Information sent during an update includes: Updated object The GUID and USN of the domain server with the originating update. A local USN of the update on the updated object. Replication Path The replication path that domain controller Active Directory replicated data travels through an enterprise is called the replication topology. Connection objects are used to define the replication paths between domain controllers. Active Directory, by default, sets up a two way ring replication path. The data can travel in both directions around the ring which provides redundancy and reliability. Two types of replication occur in the path: Direct replication - When replication is done from a primary source of data. Transitive replication - When replication is done from a secondhand or replicated source of data. The Knowledge Consistency Checker (KCC) (running on all domain controllers) generates the replication topology by specifying what domain controllers will replicate to which other domain controllers in the site. The KCC maintains a list of connections,

5 called a replication topology, to other domain controllers in the site. The KCC ensures that changes to any object are replicated to all site domain controllers and updates go through no more than three connections. Also an administrator can configure connection objects. The KCC uses information provided by the administrator about sites and subnets to automatically build the Active Directory replication topology. Propagation Dampening Terms: Propagation dampening is used to prevent unnecessary replication by preventing updates from being sent to servers that are already updated. Each domain controller keeps a list of other known domain controllers and the last USN received from each controller. Two up-to-date vector numbers support this: o Replica GUID o Update Sequence Number (USN) - Mentioned earlier it is incremented anytime an origination or replicated update is received. The USN stored is from the originating server. It is stored as metadata with: An attribute indicating "added" or "changed" for the object being updated. The GUID (above). A local USN for the object attribute changed. The changed data. The up-to-date vector numbers are incremented when replication occurs with the originating server. Each domain controller has its own different USN (They may not start at the same number). The highest USN from each domain controller that is stored in other domain controllers is called the high watermark for that domain controller. Propagation delay describes the amount of time required for a change to be replicated to domain controllers throughout the domain. Ring Topology - The Active Directory replication process uses a ring topology where the replication partners form a ring. This adds reliability to the process and also helps decrease propagation delay. The information sent in an update request includes the high water mark entry for the originating server for the last change received. If the highwater mark received from the server that sent the update request is the same as the highwatermark for the originating server on the server receiving the request, the receiving server will not send the replicated information. The usnchanged parameter is the highest USN number for any object. Replication Partitions Types of Active Directory data storage categories which are called partitions:

6 Schema partition - Defines rules for object creation and modification for all objects in the forest. Replicated to all domain controllers in the forest. Replicated to all domain controllers in the forest, it is known as an enterprise partition. Configuration partition - Information about the forest directory structure is defined including trees, domains, domain trust relationships, and sites (TCP/IP subnet group). Replicated to all domain controllers in the forest, it is known as an enterprise partition. Domain partition - Has complete information about all domain objects (Objects that are part of the domain including OUs, groups, users and others). Replicated only to domain controllers in the same domain. o Partial domain directory partition - Has a list of all objects in the directory with a partial list of attributes for each object. These partitions are all replicated between domain controllers by Active directory. Different partitions may be replicated between different replication partners. Replication Conflict Replication conflict occurs when changes are made to the same object and attribute before the changes can be replicated throughout all domain controller's copies of the database. Additional data (metadata) stored for each object attribute includes (not related to USN): Time stamp of the last change. Attribute version number - For each object's attributes, this value is the same on all domain controllers. When an Active Directory database update is received on a domain controller, one of the following happens: If the update attribute version number is higher than the current version number on the controller, the new value of the attribute is stored and the version number is updated. If the update attribute version number and stored attribute version number are the same, timestamps are used to resolve the conflict. If the both version numbers and both timestamps are the same, the update from the controller with the highest GUID is used. File Replication Service In Windows 2000, the SYSVOL share is used to to authenticate users. The SYSVOL share includes group policy information which is replicated to all local domain controllers. File replication service (FRS) is used to replicate the SYSVOL share. The

7 "Active Directory Users and Computers" tool is used to change the file replication service schedule. Intrasite Replication Replication that happens between controllers inside one site. All of the subnets inside the site should be connected by high speed network wires. Replication between two sites may need to be sent over a slower WAN link or leased line. Intrasite replication data is sent uncompressed. Site replication is done using Remote Procedure Call (RPC). If a change is made, replication occurs within five minutes, and replication is done every six hours if no changes were made. Domain controllers that receive updates replicate that information to other domain controllers on their route list. All changes are therefore completed within a site within 15 minutes since there can only be three hops. The topology used here is the ring topology talked about earlier and this replication is automatically set up by Active Directory, but may be modified by an administrator. DNS Replication The DNS IP address and computer name is stored in Active Directory for Active Directory integrated DNS zones and replicated to all local domain controllers. DNS information is not replicated to domain controllers outside the domain. Intersite Replication Intrasite replication is replication between sites and must be set up by an administrator. Replication Management The administrative tool, "Active Directory Sites and Services", is used to manage Active Directory replication. Replication data is compressed before being sent to minimze bandwidth use. There are two protocols used to replicate AD: Normally Remote Procedure Call (RPC) is used to replicate data and is always used for intrasite replication since it is required to support the FRS. RPC depends on IP (internet protocol) for transport. Simple Mail Transfer Protocol (SMTP) may be used for replication between sites. SMTP can't replicate the domain partition, however. Therefore the remote site would need to be in another domain to be able to effectively use SMTP for carrying replication data.

8 Bridgehead server - A domain controller that is used to send replication information to one or more other sites. Flexible Single Master Operations (FSMO) (discussed in an earlier section) can be transferred manually to various domain controllers. Roles and tools used to transfer are: Schema Master - Use "Active Directory Domains and Trusts". Makes changes to the database schema. Applications may remotely connect to the schema master. Domain Naming Master - Use the MMC "Active Directory Schema Snap-in". Adds or removes domains to or from the forest. Primary Domain Controller (PDC) Emulator - Use the "Active Directory Users and Computers" administrative tool. When Active Directory is in mixed mode, the computer Active Directory is on acts as a Windows NT PDC. Mixed mode occurs when Active Directory interfaces with NT 4.0 BDCs or ones without Windows 2000 Directory Service client software. In mixed mode, computers without Windows 2000 client software must contact the PDC emulator to change user account information. Relative ID Master (RID Master) - Use the "Active Directory Users and Computers" administrative tool. All objects have a Security Identifier (SID) and a domain SID. The RID assigns relative IDs to each domain controller. Infrastructure Master - Use the "Active Directory Users and Computers" administrative tool. Updates group membership information when users from other domains are moved or renamed. Any master role can be transferred by using the command line program, ntdsutil.exe. When a server performing a master role fails and goes offline, you can perform "seizing master operations" to have another server perform that role. Only the ntdsutil.exe program can perform this function. Commands include: connections - A connections prompt appears: o connect to server "FQDN of server to connect to" o quit sieze "name of role to transfer". Role names are: o PDC o RID master o schema master o domain naming master o infastructure master Example: "sieze RID master" Replication Associated Performance Monitor Counters DRA Inbound Bytes Not Compressed - Replicated uncompressed bytes that are probably from a Directory Services Agent (another controller sending data) in the same site. DRA Inbound Bytes Compressed (Before Compression) - Replicated bytes received (as though in uncompressed form).

9 DRA Inbound Bytes Not Compressed (After Compression) - Replicated bytes received (as in compressed form). DRA Inbound Bytes Total The sum of the DRA Inbound Bytes Not Compressed plus the DRA Inbound Bytes Not Compressed (After Compression). DRA Outbound Bytes Not Compressed - Replicated uncompressed bytes that are being sent to another domain controller in the same site. Schema Cache A schema cache which is a copy of the schema in memory can be used to speed up schema queries but should be used sparingly due to the high memory requirements. If the schemaupdatenow attribute is added to the RootDSE a schema cache update is done immediately. Normally the schema cache is stored in memory when the system boots and updated every five minutes. Active Directory FSMO Roles Windows 2000/2003 Multi-Master Model A multi-master enabled database, such as the Active Directory, provides the flexibility of allowing changes to occur at any DC in the enterprise, but it also

10 introduces the possibility of conflicts that can potentially lead to problems once the data is replicated to the rest of the enterprise. One way Windows 2000/2003 deals with conflicting updates is by having a conflict resolution algorithm handle discrepancies in values by resolving to the DC to which changes were written last (that is, "the last writer wins"), while discarding the changes in all other DCs. Although this resolution method may be acceptable in some cases, there are times when conflicts are just too difficult to resolve using the "last writer wins" approach. In such cases, it is best to prevent the conflict from occurring rather than to try to resolve it after the fact. For certain types of changes, Windows 2000/2003 incorporates methods to prevent conflicting Active Directory updates from occurring. Windows 2000/2003 Single-Master Model To prevent conflicting updates in Windows 2000/2003, the Active Directory performs updates to certain objects in a single-master fashion. In a single-master model, only one DC in the entire directory is allowed to process updates. This is similar to the role given to a primary domain controller (PDC) in earlier versions of Windows (such as Microsoft Windows NT 4.0), in which the PDC is responsible for processing all updates in a given domain. In a forest, there are five FSMO roles that are assigned to one or more domain controllers. The five FSMO roles are: Schema Master: The schema master domain controller controls all updates and modifications to the schema. Once the Schema update is complete, it is replicated from the schema master to all other DCs in the directory. To update the schema of a forest, you must have access to the schema master. There can be only one schema master in the whole forest. Domain naming master: The domain naming master domain controller controls the addition or removal of domains in the forest. This DC is the only one that can add or remove a domain from the directory. It can also add or remove cross references to domains in external directories. There can be only one domain naming master in the whole forest. Infrastructure Master: When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to security principals), and the DN of the object being referenced. The infrastructure FSMO role holder is

11 the DC responsible for updating an object's SID and distinguished name in a crossdomain object reference. At any one time, there can be only one domain controller acting as the infrastructure master in each domain. Note: The Infrastructure Master (IM) role should be held by a domain controller that is not a Global Catalog server (GC). If the Infrastructure Master runs on a Global Catalog server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a Global Catalog server holds a partial replica of every object in the forest. As a result, cross-domain object references in that domain will not be updated and a warning to that effect will be logged on that DC's event log. If all the domain controllers in a domain also host the global catalog, all the domain controllers have the current data, and it is not important which domain controller holds the infrastructure master role. Relative ID (RID) Master: The RID master is responsible for processing RID pool requests from all domain controllers in a particular domain. When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal SID created in a domain. Each DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC's allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain's RID master. The domain RID master responds to the request by retrieving RIDs from the domain's unallocated RID pool and assigns them to the pool of the requesting DC. At any one time, there can be only one domain controller acting as the RID master in the domain. PDC Emulator: The PDC emulator is necessary to synchronize time in an enterprise. Windows 2000/2003 includes the W32Time (Windows Time) time service that is required by the Kerberos authentication protocol. All Windows 2000/2003-based computers within an enterprise use a common time. The purpose of the time service is to ensure that the Windows Time service uses a hierarchical relationship that controls authority and does not permit loops to ensure appropriate common time usage. The PDC emulator of a domain is authoritative for the domain. The PDC emulator at the root of the forest becomes authoritative for the enterprise, and should be configured to gather the time from an external source. All PDC FSMO role holders follow the hierarchy of domains in the selection of their in-bound time partner. In a Windows 2000/2003 domain, the PDC emulator role holder retains the following functions:

12 Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator. Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to the PDC emulator before a bad password failure message is reported to the user. Account lockout is processed on the PDC emulator. Editing or creation of Group Policy Objects (GPO) is always done from the GPO copy found in the PDC Emulator's SYSVOL share, unless configured not to do so by the administrator. The PDC emulator performs all of the functionality that a Microsoft Windows NT 4.0 Server-based PDC or earlier PDC performs for Windows NT 4.0-based or earlier clients. This part of the PDC emulator role becomes unnecessary when all workstations, member servers, and domain controllers that are running Windows NT 4.0 or earlier are all upgraded to Windows 2000/2003. The PDC emulator still performs the other functions as described in a Windows 2000/2003 environment. At any one time, there can be only one domain controller acting as the PDC emulator master in each domain in the forest.