Security Between Replication Partners
Security of replication is important to ensure that an unauthorized program cannot act as a replication destination because replication destinations have access to secrets. Security must also prevent an unauthorized program from acting as a replication source because a rogue replication source can pretend to originate updates and thereby make unauthorized directory changes. Therefore, mutual authentication of replication partners and access control at the replication source are both required. The security technology that is used in replication depends on the replication transport.
RPC Transport Security
For authentication mutual authentication is performed either by the Kerberos v5 authentication protocol or by NTLM when authenticating to a Microsoft® Windows® NT version 4.0–based backup domain controller.
For authorization, the DS-Replication-Get-Changes control access right provides access control at the replication source. This control access right is granted in access control entries (ACEs) in the security descriptor on the topmost object in the directory partition. By default, this right is granted to Enterprise Domain Controllers and Domain Admins and is required in order to run the Active Directory Installation Wizard (Dcpromo.exe).
For information about Active Directory authentication, see "Authentication" in this book. For information about Active Directory authorization, see "Access Control" in this book. For information about the Active Directory Installation wizard, see "Active Directory Data Storage" in this book.
ISM Transport Security
The authentication and encryption mechanism that ISM uses is similar to that of Secure/Multipurpose Internet Mail Extensions (S/MIME), which is a standard that enables binary data to be published and read on the Internet. By using S/MIME, the sender always includes its own certificate in addition to the certificate-authority certificate chain that extends to the root certifying authority. Requests to the replication source are signed but not sealed. The request does not contain any secret data, so the domain controller does not require knowledge of the certificates for any other domain controllers. Responses to the replication destination are signed and sealed by using the local domain controller certificate plus the certificate that the requester included in its request message.
Authentication is possible because all certificates used for Active Directory replication (that is, "DomainController" certificates) contain an attribute ( altSubjectName ) that identifies the objectGuid attribute value of the owner's computer object. The mapping of the computer objectGuid to the server object can be done by any domain controller because the required information is stored in the configuration directory partition.
For authorization, the receiving domain controller verifies the validity of the certificate (including verifying the fact that it was issued by a trusted certificate authority, and so on), and then the receiving domain controller extracts the objectGuid value of the sender's computer object. It then attempts to map that GUID to a server object in its forest. If mapping succeeds, the receiving domain controller additionally verifies that the sending server is an Active Directory domain controller (on the basis of the sending server having a child NTDS Settings object of the proper object class, which can be created only by the directory service itself). Blanket replication access is thereby granted to all Active Directory domain controllers in the forest — and only to Active Directory domain controllers.
For information about certificate security, see "Windows 2000 Certificate Services and Public Key Infrastructure" in this book. For information about Active Directory authentication, see "Authentication" in this book. For information about Active Directory authorization, see "Access Control" in this book.