Windows Active Directory Series---AD sites (2)

What is topology builder between sites (intersite topology generator ISTG)?

When configuring multiple sites, the KCC specifies a single DC in each site as the intersite topology generator. No matter how many domains or directory partitions a site has, there can be only one ISTG per site. ISTG is responsible for calculating the best site replication topology for cross-site links, and when you add a site to the forest, the ITSG of each site confirms which directory partition the new site appears in, and ISTG calculates how many new linked objects are required to replicate information for the new site.

In some networks, you may want to specify a DC for replication between sites, and we can configure the bridgehead server to meet this requirement. The bridgehead server is responsible for all inbound and outbound replication of the site. ISTG will establish a connection protocol in its directory and later replicate this protocol to the bridgehead server, and the bridgehead server will establish a replication connection with the bridgehead server at the remote site and begin copying the information through this replication connection. If one of the replication partners is unavailable, ISTG will automatically select another DC as the ISTG in that site, but if you manually specify a bridgehead server and the bridgehead server is unavailable, ISTG will not automatically select the other DC as ISTG for that site.

By default, ISTG automatically selects the bridgehead server and then creates a replication topology between sites to ensure that change data is replicated correctly between bridgehead servers that share a site link. Each directory partition has a bridgehead server, so one of the DCs in the site may be the bridgehead server for the schema partition, and the other DC may be the bridgehead server for the configuration partition, but usually a DC as the bridgehead server for all directory partitions, unless the site has an application partition or domain partition for the other domain. If this is the case, there will be multiple bridgehead servers. When you have firewalls between sites, and firewalls allow replication between only the specified DCs, configuring the bridgehead server manually is a good fit for this scenario.

Optimize DC coverage in a multi-site environment

When you add a DC to a domain, the new DC publishes its service by establishing an SRV record in DNS. It differs from the host's a record, where the A record of the host maps the hostname to the IP address, and the SRV record maps the service and host name. For example, to publish a service that provides authentication and directory access, a DC is required to register the Kerberos V5 protocol and the SRV records for LDAP, which are written to several folders in the forest DNS zone.

In the DNS domain zone, the SRV records for all DCs in the domain are saved in a folder with the name _tcp, and a _site folder in the domain area, which holds the subfolders created for each site in the domain, and the SRV records for the available services for this site are saved in each site's files. For example, in a site loaded with a DC, then in the _site\ site name \_tcp, there will be an SRV record corresponding to this DC.

The following information is generally included in the SRV record:

1. Service name and port. The SRV record indicates the fixed port used by the service and service it represents, which is not necessarily a well-known port. In Windows 2012, the SRV record contains port 88,kerberos for LDAP Port 389,kerberos, port 464 for the password protocol, and port 3268 for the GC service.

2. Agreement. TCP and UDP are two transport protocols for the service, and the same service can use the two transport protocols for each of the two different SRV records, such as Kerberos records, which register SRV records with either protocol. Windows clients only use TCP protocols, but UNIX clients can use both TCP and UDP two protocols.

3. Host name. The hostname corresponds to the server a record that hosts the service, and when the client queries the service, the DNS server returns the SRV record and the associated a record to the client, so the client does not need to submit a separate query to resolve the service's IP address.

The server names in the SRV record follow the standard DNS component hierarchy, through the "." To divide the components. For example, a DC's Kerberos service registration record is kerberos._tcp. Site name. _sites. Domain name. A domain name refers to a domain or DNS zone, for example, Contoso.com,_site is a site registered in all DNS, the station name is the site that hosts the service's DCs, and _tcp is all TCP protocol-based services within the site. Kerberos is the Kerberos key issuance center that uses TCP as the creation protocol.

On certain occasions, some branch areas have computer equipment but no DC, or do not need to install a DC to it, this situation we can establish a site without DCs, but in this case the site name of the _sites\ site \_ The following directory for TCP is not listed for the SRV record for the corresponding DC. There are several ways to solve this problem, for example, if you are concerned about the security maintenance of DC and AD domain databases, you can deploy an RODC, or use automatic site overrides, in an empty site (referring to a site without a DC), the DCs in the site closest to this empty site will automatically process information from two sites ( Self-site and empty site), and writes its own SVR records to an empty site, which can be configured through Group Policy. Or if the site has fewer computers and the network is in good condition, in order to save the cost of deploying the server, you can add a subnet for the local site to a central site with more than one DC, at which point the client computer is located at the remote site, and the site location without DCs is considered to be subordinate to the central site. The problem occurs only if the DCs in the hub site are not available for the site without DCs. In this case, the client uses cached credentials for local authentication, but because site link automatic bridging is turned on by default, domain validation is always done through site links that bridge multiple sites.

How does a client computer discover a DC?

When you join a Windows operating system computer to a domain and reboot, the client completes the discovery and client registration process for the DC. The purpose of the registration process is to find the closest DC to the client, based on the information of the IP subnet.

The client discovers the DC process as follows:

1. The new client will query all DCs in the domain. When the client of the new domain restarts, it receives an IP address from DHCP and prepares the domain for authentication, but the client does not know where the DC is, so the client goes to find the _tcp folder to query the Dc,_tcp folder for the SRV records that hold all DCs in the domain.

2. The client tries an LDAP ping command to go to ping all DCs sequentially. After the client queries DNS for the _TCP folder, DNS returns a manifest to the client that contains all the satisfied DCs, and then the client attempts to connect to all DCs in the manifest at the first boot.

3. The first DC responds to the ping command. The first DC that responds to the ping command checks the client's IP address and references the client's IP address and the subnet objects in the site, then sends back the site information that the client is affiliated to to the client, and the client receives the message, saves the site name in the local registry, and then to the specified site _ The TCP folder queries DC information.

4. The client queries all DCs in the owning site. After the query action in the 3rd step occurs, DNS returns a list of DCs in the client's site.

5. The client sequentially pings the LDAP to all DCs in the site. The DC sends a response to the first authentication client.

6. The client generates a affinity density. The client will form an intimacy with the DC that responds first, and subsequent validations will attempt to contact the DC first, and if the DC is unavailable, the client will requery the _tcp folder within the site and then bind to the DC that responds first.

If the client moves to another site, such as a mobile client, a laptop, and so on, the client tries to connect to its preferred DC to verify that the preferred DC notifies the client that its IP address is not the site, and then references a new site to the client. The client queries the DC in the site to which the IP belongs through DNS.

Automatic site Coverage:

As mentioned earlier, you can configure a site to guide users to a local copy of a replicated resource, such as a shared folder in a DFS namespace. Sometimes you may not need a DC, only require the service localization, then the non-site of the recent DC will be its SVR record in this site, this process is called site coverage.

When a site that does not have a DC is overwritten, it is generally the DC in the site that is least expensive with site links to this site, and of course you can manually configure site overrides and SRV record priorities to specify the DCs in the site you want to use to provide authentication services for sites that do not have DCs.

For information on how to evaluate site coverage, please refer to the link:

http://go.microsoft.com/fwlink/?LinkId=168550

This article is from the "Dry Sea Sponge" blog, please be sure to keep this source http://thefallenheaven.blog.51cto.com/450907/1587551

Windows Active Directory Series---AD sites (2)