Directory Services

Using DsAddSidHistory

The DsAddSidHistory function retrieves the primary account security identifier (SID) of a security principal from one domain (the source domain) and adds it to the sIDHistory attribute of a security principal in another (destination) domain in a different forest. When the source domain is in Windows® 2000 native mode, this function also retrieves the sIDHistory values of the source principal and adds them to the destination principal's sIDHistory.

Adding SIDs to a security principal's sIDHistory is a security-sensitive operation that effectively grants to the destination principal access to all resources accessible to the source principal, provided that trusts exist from applicable resource domains to the destination domain.

In a native mode Windows 2000 domain a user logon creates an access token that contains the user's primary account SID and group SIDs, as well as the user's sIDHistory and the sIDHistory of the groups of which the user is a member. Having these former SIDs (sIDHistory values) in the user's token grants the user access to resources protected by access-control lists (ACLs) containing the former SIDs.

This operation facilitates certain Windows 2000 deployment scenarios. In particular, it supports a scenario in which accounts in a new Windows 2000 forest are created for users and groups that already exist in an Windows NT 4.0 production environment. By placing the Windows NT 4.0 account SID in the Windows 2000 account sIDHistory, access to network resources is preserved for the user logging onto his new Windows 2000 account.

DsAddSidHistory also supports migration of Windows NT 4.0 backup domain controllers (BDCs) resource servers (or DCs and member servers in a native mode Windows 2000 domain) to a Windows 2000 domain as member servers. This migration requires the creation, in the destination Windows 2000 domain, of domain local groups that contain, in their sIDHistory, the primary SIDs of the local groups defined on the BDC (or domain local groups referenced in ACLs on the Windows 2000 servers) in the source domain. By creating a destination local group containing the sIDHistory and all members of the source local group, access to the migrated server resources, protected by ACLs referencing the source local group, is maintained for all members.

Note  Use of DsAddSidHistory requires an understanding of its broader administrative and security implications in these and other scenarios. For more information, see the white paper "Planning Migration from Microsoft Windows NT to Microsoft Windows 2000", delivered as Dommig.doc in the Windows 2000 Support Tools. This documentation may also be found on the product CD under \support\tools.

Authorization Requirements

DsAddSidHistory requires administrator privileges in the source and destination domains. Specifically, the caller of this API must be a member of the Domain Administrators group in the destination domain. A hard-coded check for this membership is performed. Also, the caller or the account provided in the SrcDomainCreds parameter, if not NULL, must be a member of either the Administrators or Domain Administrators group in the source domain.

Domain and Trust Requirements

DsAddSidHistory requires that the destination domain be in Windows 2000 native mode, because only this domain type supports the sIDHistory attribute. The source domain may be either Windows NT 4.0 or Windows 2000, mixed or native mode. The source and destination domains must not be in the same forest. Windows NT 4.0 domains are by definition not in a forest. This inter-forest constraint ensures that duplicate SIDs, whether appearing as primary SIDs or sIDHistory values, are not created in the same forest.

DsAddSidHistory requires an external trust from the source domain to the destination domain in the following cases.

Case Description
The source domain is Windows 2000. The source sIDHistory attribute, available only in Windows 2000 source domains, may be read only using LDAP, which requires this trust for integrity protection.
The source domain is Windows NT 4.0 and SrcDomainCreds is NULL. The impersonation, required to support source domain operations using the caller's credentials, depends on this trust. Impersonation also requires that the destination domain controller has "Trusted for Delegation" enabled by default on domain controllers.

However, there is no trust required between the source and destination domains if the source domain is Windows NT 4.0 and SrcDomainCreds is not NULL.

Source Domain Controller Requirements

DsAddSidHistory requires that the domain controller, selected as the target for operations in the source domain, be the PDC in Windows NT 4.0 domains or the PDC Emulator in Windows 2000 domains. Source domain auditing is generated by way of write operations, therefore, the PDC is required in Windows NT 4.0 source domains, and the PDC-only restriction ensures that DsAddSidHistory audits are generated on a single computer. This reduces the need to review the audit logs of all DCs to monitor use of this operation.

Note  In Windows NT 4.0 source domains, the PDC (target of operations in the source domain) must be running service pack (SP) 4 or later to ensure proper auditing support.

The following registry value must be created as a REG_DWORD value and set to 1 on the source domain controller for both Windows NT 4.0 and Windows 2000 source DCs.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\TcpipClientSupport

Setting this value enables RPC calls over the TCP transport. This is required because, by default, SAMRPC interfaces are remotable only on named pipes. Using named pipes results in a credential management system suitable for interactively logged-on users making networked calls, but is not flexible for a system process that makes network calls with user-supplied credentials. RPC over TCP is more suitable for that purpose. Setting this value does not diminish system security. If this value is created or changed, the source domain controller must be rebooted for this setting to take effect.

A new local group, <SrcDomainName>$$$, must be created in the source domain for auditing purposes.

Auditing

DsAddSidHistory operations are audited to ensure that both source and destination domain administrators are able to detect when this function has been run. Auditing is mandatory in both the source and destination domains. DsAddSidHistory verifies that the Audit Mode is on in each domain and that Account Management auditing of Success/Failure events is on. In the destination domain, a unique "Add Sid History" audit event is generated for each successful or failed DsAddSidHistory operation.

Unique "Add Sid History" audit events are not available on Windows NT 4.0 systems. To generate audit events that unambiguously reflect use of DsAddSidHistory against the source domain, it performs operations on a special group whose name is the unique identifier in the audit log. A local group, <SrcDomainName>$$$, whose name is composed of the source domain's NetBIOS name appended with three dollar signs ($) (ASCII code = 0x24 and Unicode = U+0024), must be created on the source domain controller prior to calling DsAddSidHistory. Each source user and global group that is a target of this operation is added to and then removed from the membership of this group. This generates Add Member and Delete Member audit events in the source domain, which can be monitored by searching for events that reference the group name.

Note  DsAddSidHistory operations on local groups in a Windows NT 4.0, or Windows 2000 mixed-mode source domain cannot be audited because local groups cannot be made members of another local group and therefore cannot be added to the special SrcDomainName$$$ local group. This lack of auditing does not present a vulnerability to the source domain, because source domain resource access is not affected by this operation. Adding the SID of a source local group to a destination local group does not grant access to source resources, protected by that local group, to any additional users. Adding members to the destination local group does not grant them access to source resources. Added members are granted access only to servers in the destination domain that have been migrated from the source domain, which may have resources protected by the source local group's SID.

Data Transmission Security

DsAddSidHistory enforces the following security measures:

Threat Models

The following table lists the potential threats associated with the DsAddSidHistory call and addresses the security measures pertinent to the particular threat.

Potential threat Security measure
Man in the Middle Attack

An unauthorized user intercepts the lookup SID of source object return call, replacing the source object's SID with an arbitrary SID for insertion into a target object's SIDhistory.

 The lookup SID of source object is an authenticated RPC (using the caller's administrator credentials) with packet integrity message protection. This ensures that the return call cannot be modified without detection. The destination domain controller creates a unique "Add SID History" audit event that reflects the SID added to the destination account sIDHistory.
Trojan Source Domain

An unauthorized user creates a "Trojan" source domain on a private network that has the same domain SID and some of the same account SIDs as the legitimate source domain. The unauthorized user then attempts to run DsAddSidHistory in a destination domain to obtain the SID of a source account. This is done without the need for the real source Domain Administrator credentials and without leaving an audit trail in the real source domain. The unauthorized user's method for creating the Trojan source domain could be one of the following:

  1. Obtain a copy (BDC backup) of the source domain SAM.
  2. Create a new domain, altering the domain SID on disk to match the legitimate source domain SID, then create enough users to instantiate an account with the desired SID.
  3. Create a BDC replica. This requires source domain Administrator credentials. Then the unauthorized user takes the replica to a private network to implement the attack.
 Although there are many ways for an unauthorized user to retrieve or create a desired source object SID, the unauthorized user cannot use it to update an account's sIDHistory without being a member of the destination Domain Administrators group. Because the check, on the destination domain controller, for Domain Administrator membership is hard-coded (on the target DC), there is no method for doing a disk modification to change the access control information protecting this function. An attempt to clone a Trojan source account is audited in the destination domain. This attack is mitigated by reserving membership in the Domain Administrators group for only highly-trusted individuals.
On-disk Modification of

A sophisticated unauthorized user, with Domain Administrator credentials and with physical access to a DC in the destination domain, could modify an account sIDHistory value on disk.

 This attempt is not enabled by use of DsAddSidHistory. This attack is mitigated by preventing physical access to domain controllers to all but highly-trusted administrators.
Patch Code to Remove Protections

An unauthorized user or rogue administrator with physical access to the Directory Service code could create a patch that:

  1. Removes the check for membership in the Domain Administrators group in the code.
  2. Changes the calls on the source domain controller that points the SID to an unaudited LookupSidFromName.
  3. Removes audit log calls.
 Someone with physical access to the DS code and knowledgeable enough to create code patches has the capability of arbitrarily modifying the sIDHistory attribute of an account. The DsAddSidHistory API does not increase this vulnerability.
Resources Vulnerable to Stolen SIDs

If an unauthorized user has succeeded in using one of the methods described here to modify an account sIDHistory, and if the resource domains of interest trust the unauthorized user's account domain, then the unauthorized user can get unauthorized access to the stolen SID's resources, potentially without leaving an audit trail in the account domain from which the SID was stolen.

 Resource domain administrators protect their resources by setting up only those trust relationships that make sense from a security perspective. Use of DsAddSidHistory is restricted, in the trusted target domain, to members of the Domain Administrators group who already have broad permissions within the scope of their responsibilities.
Rogue Target Domain

An unauthorized user creates a Windows 2000 domain with an account whose sIDHistory contains a SID that has been stolen from a source domain. The unauthorized user uses this account for unauthorized access to resources.

 The unauthorized user requires Administrator credentials for the source domain in order to use DsAddSidHistory, and leaves an audit trail on the source domain controller. The rogue target domain gains unauthorized access only in other domains that trust the rogue domain, which requires Administrator privileges in those resource domains.

Operational Constraints

This section describes the operational constraints of using the DsAddSidHistory function.

The SID of SrcPrincipal must not already exist in the destination forest, either as a primary account SID or in the sIDHistory of an account. The exception is that DsAddSidHistory does not generate an error when attempting to add a SID to a sIDHistory that contains an identical SID. This behavior allows DsAddSidHistory to be run multiple times with identical input, resulting in success and a consistent end state, for tool developer ease-of-use.

Note  Global Catalog replication latency may provide a window during which duplicate SIDs may be created. However, duplicate SIDs can be easily deleted by an administrator.

SrcPrincipal and DstPrincipal must be one of the following types:

The object types of SrcPrincipal and DstPrincipal must match.

SrcPrincipal and DstPrincipal cannot be one of the following types: (DsAddSidHistory fails with an error in these cases)

If SrcPrincipal has a well-known relative identifier (RID) and a domain specific prefix, that is, Domain Admins, Domain Users, and Domain Computers, then DstPrincipal must possess the same well-known RID in order for DsAddSidHistory to succeed. Accounts with well-known RIDs include the following users and global groups:

To Set the TcpipClientSupport Registry Value

Create the following registry value as a REG_DWORD value on the source domain controller and set its value to 1.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TcpipClientSupport

Then, reboot the source domain controller. This registry value causes the SAM to listen on TCP/IP. DsAddSidHistory will fail if this value is not set on the source domain controller.

Enabling Auditing of User/Group Management Events

To enable auditing of User/Group management events, perform the following steps depending on the type of domain

  1. In the Active Directory® Users and Computers MMC Snap-in, select the destination domain Domain Controllers container.
  2. Right click Domain Controllers and choose Properties.
  3. Click the Group Policy tab.
  4. Select the Default Domain Controllers Policy and click Edit.
  5. Under Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy, double-click Audit Account Management.
  6. In the Audit Account Management window, select both Success and Failure auditing. Policy updates take effect after a reboot, or after waiting up to 15 minutes for a refresh to occur.
  7. Verify that auditing has been enabled by viewing the effective audit policy in the Group Policy MMC Snap-in.
  1. In User Manager for Domains, click the Policies menu and select Audit.
  2. Select Audit These Events.
  3. For User and Group Management, check Success and Failure.
  1. In User Manager for Domains, click the User menu and select New Local Group.
  2. Enter a group name composed of the source domain NetBIOS name appended with three Dollar Signs, for example, FABRIKAM$$$. The description field should indicate that this group is used to audit use of DsAddSidHistory or cloning operations. Ensure there are no members in the group. Click OK.

    The DsAddSidHistory operation fails if source and destination auditing are not enabled as described here.

Set up Trust if Required

If one of the following is true, a trust must be established from the source domain to the destination domain (this must occur in a different forest):