{
	"id": "ab820046-81bd-4463-8c19-cee82050a134",
	"created_at": "2026-04-06T00:14:28.465286Z",
	"updated_at": "2026-04-10T03:21:41.429029Z",
	"deleted_at": null,
	"sha1_hash": "d8a3f0d749e2774c0df5c2262ccea95bf1113682",
	"title": "Using DsAddSidHistory - Win32 apps",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 84390,
	"plain_text": "Using DsAddSidHistory - Win32 apps\r\nBy GrantMeStrength\r\nArchived: 2026-04-05 16:42:11 UTC\r\nThe DsAddSidHistory function gets the primary account security identifier (SID) of a security principal from one\r\ndomain (the source domain) and adds it to the sIDHistory attribute of a security principal in another (destination)\r\ndomain in a different forest. When the source domain is in Windows 2000 native mode, this function also retrieves\r\nthe sIDHistory values of the source principal and adds them to the destination principal's sIDHistory.\r\nAdding SIDs to a security principal's sIDHistory is a security-sensitive operation that effectively grants to the\r\ndestination principal access to all resources accessible to the source principal, provided that trusts exist from\r\napplicable resource domains to the destination domain.\r\nIn a native mode Windows 2000 domain a user logon creates an access token that contains the user primary\r\naccount SID and group SIDs, as well as the user sIDHistory and the sIDHistory of the groups of which the user\r\nis a member. Having these former SIDs (sIDHistory values) in the user's token grants the user access to resources\r\nprotected by access-control lists (ACLs) containing the former SIDs.\r\nThis operation facilitates certain Windows 2000 deployment scenarios. In particular, it supports a scenario in\r\nwhich accounts in a new Windows 2000 forest are created for users and groups that already exist in an Windows\r\nNT 4.0 production environment. By placing the Windows NT 4.0 account SID in the Windows 2000 account\r\nsIDHistory, access to network resources is preserved for the user logging onto his new Windows 2000 account.\r\nDsAddSidHistory also supports migration of Windows NT 4.0 backup domain controllers (BDCs) resource\r\nservers (or DCs and member servers in a native mode Windows 2000 domain) to a Windows 2000 domain as\r\nmember servers. This migration requires the creation, in the destination Windows 2000 domain, of domain local\r\ngroups that contain, in their sIDHistory, the primary SIDs of the local groups defined on the BDC (or domain\r\nlocal groups referenced in ACLs on the Windows 2000 servers) in the source domain. By creating a destination\r\nlocal group containing the sIDHistory and all members of the source local group, access to the migrated server\r\nresources, protected by ACLs referencing the source local group, is maintained for all members.\r\nNote\r\nUse of DsAddSidHistory requires an understanding of its broader administrative and security implications in\r\nthese and other scenarios. For more information, see the white paper \"Planning Migration from Windows NT to\r\nMicrosoft Windows 2000\", delivered as Dommig.doc in the Windows 2000 Support Tools. This documentation\r\nmay also be found on the product CD under \\support\\tools.\r\nDsAddSidHistory requires administrator privileges in the source and destination domains. Specifically, the caller\r\nof this API must be a member of the Domain Administrators group in the destination domain. A hard-coded check\r\nfor this membership is performed. Also, the account provided in the SrcDomainCreds parameter must be a\r\nmember of either the Administrators or Domain Administrators group in the source domain. If NULL is passed in\r\nhttps://msdn.microsoft.com/library/ms677982.aspx\r\nPage 1 of 8\n\nSrcDomainCreds, the caller of the API must be member of either the Administrators or Domain Administrators\r\ngroup in the source domain.\r\nDomain and Trust Requirements\r\nDsAddSidHistory requires that the destination domain be in Windows 2000 native mode or later, because only\r\nthis domain type supports the sIDHistory attribute. The source domain may be either Windows NT 4.0 or\r\nWindows 2000, mixed or native mode. The source and destination domains must not be in the same forest.\r\nWindows NT 4.0 domains are by definition not in a forest. This inter-forest constraint ensures that duplicate SIDs,\r\nwhether appearing as primary SIDs or sIDHistory values, are not created in the same forest.\r\nDsAddSidHistory requires an external trust from the source domain to the destination domain in the cases listed\r\nin the following table.\r\nCase Description\r\nThe source domain is\r\nWindows 2000.\r\nThe source sIDHistory attribute, available only in Windows 2000 source\r\ndomains, may be read only using LDAP, which requires this trust for\r\nintegrity protection.\r\nThe source domain is\r\nWindows NT 4.0 and\r\nSrcDomainCreds is NULL.\r\nThe impersonation, required to support source domain operations using the\r\ncaller's credentials, depends on this trust. Impersonation also requires that\r\nthe destination domain controller has \"Trusted for Delegation\" enabled by\r\ndefault on domain controllers.\r\nHowever, there is no trust required between the source and destination domains if the source domain is Windows\r\nNT 4.0 and SrcDomainCreds is not NULL.\r\nSource Domain Controller Requirements\r\nDsAddSidHistory requires that the domain controller, selected as the target for operations in the source domain,\r\nbe the PDC in Windows NT 4.0 domains or the PDC Emulator in Windows 2000 domains. Source domain\r\nauditing is generated by way of write operations, therefore, the PDC is required in Windows NT 4.0 source\r\ndomains, and the PDC-only restriction ensures that DsAddSidHistory audits are generated on a single computer.\r\nThis reduces the need to review the audit logs of all DCs to monitor use of this operation.\r\nNote\r\nIn Windows NT 4.0 source domains, the PDC (target of operations in the source domain) must be running Service\r\nPack 4 (SP4) and later to ensure proper auditing support.\r\nThe following registry value must be created as a REG_DWORD value and set to 1 on the source domain\r\ncontroller for both Windows NT 4.0 and Windows 2000 source DCs.\r\nhttps://msdn.microsoft.com/library/ms677982.aspx\r\nPage 2 of 8\n\nHKEY_LOCAL_MACHINE\r\n System\r\n CurrentControlSet\r\n Control\r\n Lsa\r\n TcpipClientSupport\r\nSetting this value enables RPC calls over the TCP transport. This is required because, by default, SAMRPC\r\ninterfaces are remotable only on named pipes. Using named pipes results in a credential management system\r\nsuitable for interactively logged-on users making networked calls, but is not flexible for a system process that\r\nmakes network calls with user-supplied credentials. RPC over TCP is more suitable for that purpose. Setting this\r\nvalue does not diminish system security. If this value is created or changed, the source domain controller must be\r\nrestarted for this setting to take effect.\r\nA new local group, \"\u003cSrcDomainName\u003e$$$\", must be created in the source domain for auditing purposes.\r\nAuditing\r\nDsAddSidHistory operations are audited to ensure that both source and destination domain administrators are\r\nable to detect when this function has been run. Auditing is mandatory in both the source and destination domains.\r\nDsAddSidHistory verifies that the Audit Mode is on in each domain and that Account Management auditing of\r\nSuccess/Failure events is on. In the destination domain, a unique \"Add Sid History\" audit event is generated for\r\neach successful or failed DsAddSidHistory operation.\r\nUnique \"Add Sid History\" audit events are not available on Windows NT 4.0 systems. To generate audit events\r\nthat unambiguously reflect use of DsAddSidHistory against the source domain, it performs operations on a\r\nspecial group whose name is the unique identifier in the audit log. A local group, \"\u003cSrcDomainName\u003e$$$\",\r\nwhose name is composed of the source domain NetBIOS name appended with three dollar signs ($) (ASCII code\r\n= 0x24 and Unicode = U+0024), must be created on the source domain controller prior to calling\r\nDsAddSidHistory. Each source user and global group that is a target of this operation is added to and then\r\nremoved from the membership of this group. This generates Add Member and Delete Member audit events in the\r\nsource domain, which can be monitored by searching for events that reference the group name.\r\nNote\r\nDsAddSidHistory operations on local groups in a Windows NT 4.0, or Windows 2000 mixed-mode source\r\ndomain cannot be audited because local groups cannot be made members of another local group and therefore\r\ncannot be added to the special \"\u003cSrcDomainName\u003e$$$\" local group. This lack of auditing does not present a\r\nsecurity issue to the source domain, because source domain resource access is not affected by this operation.\r\nAdding the SID of a source local group to a destination local group does not grant access to source resources,\r\nprotected by that local group, to any additional users. Adding members to the destination local group does not\r\ngrant them access to source resources. Added members are granted access only to servers in the destination\r\ndomain migrated from the source domain, which may have resources protected by the source local group SID.\r\nhttps://msdn.microsoft.com/library/ms677982.aspx\r\nPage 3 of 8\n\nData Transmission Security\r\nDsAddSidHistory enforces the following security measures:\r\nCalled from a Windows 2000 workstation, the caller's credentials are used to authenticate and privacy-protect the RPC call to the destination domain controller. If SrcDomainCreds is not NULL, both the\r\nworkstation and the destination DC must support 128-bit encryption to privacy-protect the credentials. If\r\n128-bit encryption is not available and SrcDomainCreds are provided, then the call must be made on the\r\ndestination DC.\r\nThe destination domain controller communicates with the source domain controller using either\r\nSrcDomainCreds or the caller's credentials to mutually authenticate and integrity-protect the read of the\r\nsource account SID (using a SAM lookup) and sIDHistory (using an LDAP read).\r\nThreat Models\r\nThe following table lists the potential threats associated with the DsAddSidHistory call and addresses the security\r\nmeasures pertinent to the particular threat.\r\nPotential threat Security measure\r\nMan in the Middle Attack\r\nAn unauthorized user intercepts the lookup SID of\r\nsource object return call, replacing the source object\r\nSID with an arbitrary SID for insertion into a target\r\nobject SIDhistory.\r\nThe lookup SID of source object is an authenticated\r\nRPC, using the caller's administrator credentials,\r\nwith packet integrity message protection. This\r\nensures that the return call cannot be modified\r\nwithout detection. The destination domain\r\ncontroller creates a unique \"Add SID History\" audit\r\nevent that reflects the SID added to the destination\r\naccount sIDHistory.\r\nTrojan Source Domain\r\nAn unauthorized user creates a \"Trojan Horse\" source\r\ndomain on a private network that has the same domain\r\nSID and some of the same account SIDs as the\r\nlegitimate source domain. The unauthorized user then\r\nattempts to run DsAddSidHistory in a destination\r\ndomain to obtain the SID of a source account. This is\r\ndone without the need for the real source Domain\r\nAdministrator credentials and without leaving an audit\r\ntrail in the real source domain. The unauthorized user's\r\nmethod for creating the Trojan Horse source domain\r\ncould be one of the following:\r\nObtain a copy (BDC backup) of the source\r\ndomain SAM.\r\nAlthough there are many ways for an unauthorized\r\nuser to retrieve or create a desired source object\r\nSID, the unauthorized user cannot use it to update\r\nan account's sIDHistory without being a member\r\nof the destination Domain Administrators group.\r\nBecause the check, on the destination domain\r\ncontroller, for Domain Administrator membership\r\nis hard-coded, on the target DC, there is no method\r\nfor doing a disk modification to change the access\r\ncontrol data protecting this function. An attempt to\r\nclone a Trojan Horse source account is audited in\r\nthe destination domain. This attack is mitigated by\r\nreserving membership in the Domain\r\nAdministrators group for only highly trusted\r\nindividuals.\r\nhttps://msdn.microsoft.com/library/ms677982.aspx\r\nPage 4 of 8\n\nPotential threat Security measure\r\nCreate a new domain, altering the domain SID\r\non disk to match the legitimate source domain\r\nSID, then create enough users to instantiate an\r\naccount with the desired SID.\r\nCreate a BDC replica. This requires source\r\ndomain Administrator credentials. Then the\r\nunauthorized user takes the replica to a private\r\nnetwork to implement the attack.\r\nOn-disk Modification of SID History\r\nA sophisticated unauthorized user, with Domain\r\nAdministrator credentials and with physical access to a\r\nDC in the destination domain, could modify an\r\naccount sIDHistory value on disk.\r\nThis attempt is not enabled by use of\r\nDsAddSidHistory. This attack is mitigated by\r\npreventing physical access to domain controllers to\r\nall except highly trusted administrators.\r\nRogue Code Used to Remove Protections\r\nAn unauthorized user or rogue administrator with\r\nphysical access to the Directory Service code could\r\ncreate rogue code that:\r\n1. Removes the check for membership in the\r\nDomain Administrators group in the code.\r\n2. Changes the calls on the source domain\r\ncontroller that points the SID to a\r\nLookupSidFromName that is not audited.\r\n3. Removes audit log calls.\r\nSomeone with physical access to the DS code and\r\nknowledgeable enough to create rogue code has the\r\ncapability of arbitrarily modifying the sIDHistory\r\nattribute of an account. The DsAddSidHistory API\r\ndoes not increase this security risk.\r\nResources Vulnerable to Stolen SIDs\r\nIf an unauthorized user has succeeded in using one of\r\nthe methods described here to modify an account\r\nsIDHistory, and if the resource domains of interest\r\ntrust the unauthorized user account domain, then the\r\nunauthorized user can get unauthorized access to the\r\nstolen SID's resources, potentially without leaving an\r\naudit trail in the account domain from which the SID\r\nwas stolen.\r\nResource domain administrators protect their\r\nresources by setting up only those trust\r\nrelationships that make sense from a security\r\nperspective. Use of DsAddSidHistory is restricted,\r\nin the trusted target domain, to members of the\r\nDomain Administrators group who already have\r\nbroad permissions within the scope of their\r\nresponsibilities.\r\nRogue Target Domain\r\nAn unauthorized user creates a Windows 2000 domain\r\nThe unauthorized user requires Administrator\r\ncredentials for the source domain in order to use\r\nhttps://msdn.microsoft.com/library/ms677982.aspx\r\nPage 5 of 8\n\nPotential threat Security measure\r\nwith an account whose sIDHistory contains a SID that\r\nhas been stolen from a source domain. The\r\nunauthorized user uses this account for unauthorized\r\naccess to resources.\r\nDsAddSidHistory, and leaves an audit trail on the\r\nsource domain controller. The rogue target domain\r\ngains unauthorized access only in other domains\r\nthat trust the rogue domain, which requires\r\nAdministrator privileges in those resource domains.\r\nOperational Constraints\r\nThis section describes the operational constraints of using the DsAddSidHistory function.\r\nThe SID of SrcPrincipal must not already exist in the destination forest, either as a primary account SID or in the\r\nsIDHistory of an account. The exception is that DsAddSidHistory does not generate an error when attempting to\r\nadd a SID to a sIDHistory that contains an identical SID. This behavior enables DsAddSidHistory to be run\r\nmultiple times with identical input, resulting in success and a consistent end state, for tool developer ease-of-use.\r\nNote\r\nGlobal Catalog replication latency may provide a window during which duplicate SIDs may be created. However,\r\nduplicate SIDs can be easily deleted by an administrator.\r\nSrcPrincipal and DstPrincipal must be one of the following types:\r\nUser\r\nSecurity Enabled Group, including:\r\nLocal group Global group Domain local group (Windows 2000 native mode only) Universal group\r\n(Windows 2000 native mode only)\r\nThe object types of SrcPrincipal and DstPrincipal must match.\r\nIf SrcPrincipal is a User, DstPrincipal must be a User.\r\nIf SrcPrincipal is a Local or Domain Local Group, DstPrincipal must be a Domain Local Group.\r\nIf SrcPrincipal is a Global or Universal Group, DstPrincipal must be a Global or Universal Group.\r\nSrcPrincipal and DstPrincipal cannot be one of the following types: (DsAddSidHistory fails with an error in\r\nthese cases)\r\nComputer (workstation or domain controller)\r\nInter-domain trust\r\nTemporary duplicate account (virtually unused feature, a legacy of LANman)\r\nAccounts with Well Known SIDs. Well Known SIDs are identical in every domain; thus adding them to a\r\nsIDHistory would violate the SID uniqueness requirement of a Windows 2000 forest. Accounts with Well\r\nhttps://msdn.microsoft.com/library/ms677982.aspx\r\nPage 6 of 8\n\nKnown SIDs include the following local groups:\r\nAccount operators Administrators Backup operators Guests Print operators Replicator Server operators\r\nUsers\r\nIf SrcPrincipal has a well-known relative identifier (RID) and a domain specific prefix, that is, Domain\r\nAdministrators, Domain Users, and Domain Computers, then DstPrincipal must possess the same well-known\r\nRID in order for DsAddSidHistory to succeed. Accounts with well-known RIDs include the following users and\r\nglobal groups:\r\nAdministrator\r\nGuest\r\nDomain administrators\r\nDomain guests\r\nDomain users\r\nSetting the Registry Value\r\nThe following procedure shows how to set the TcpipClientSupport registry value.\r\nTo Set the TcpipClientSupport Registry Value\r\n1. Create the following registry value as a REG_DWORD value on the source domain controller and set its\r\nvalue to 1.\r\nHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\TcpipClientSupport\r\n2. Then, restart the source domain controller. This registry value causes the SAM to listen on TCP/IP.\r\nDsAddSidHistory will fail if this value is not set on the source domain controller.\r\nEnabling Auditing of User/Group Management Events\r\nThe following procedure shows how to enable auditing of User/Group management events in a Windows 2000 or\r\nWindows Server 2003 source or destination domain.\r\nTo enable auditing of User/Group management events in a Windows 2000 or Windows Server 2003 source\r\nor destination domain\r\n1. In the Active Directory Users and Computers MMC Snap-in, select the destination domain Domain\r\nControllers container.\r\n2. Right-click Domain Controllers and choose Properties.\r\n3. Click the Group Policy tab.\r\n4. Select the Default Domain Controllers Policy and click Edit.\r\n5. Under Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Audit Policy,\r\ndouble-click Audit Account Management.\r\nhttps://msdn.microsoft.com/library/ms677982.aspx\r\nPage 7 of 8\n\n6. In the Audit Account Management window, select both Success and Failure auditing. Policy updates\r\ntake effect after a restart or after a refresh occurs.\r\n7. Verify that auditing is enabled by viewing the effective audit policy in the Group Policy MMC Snap-in.\r\nThe following procedure shows how to enable auditing of User/Group management events in a Windows NT 4.0\r\ndomain.\r\nTo enable auditing of User/Group management events in a Windows NT 4.0 domain\r\n1. In User Manager for Domains, click the Policies menu and select Audit.\r\n2. Select Audit These Events.\r\n3. For User and Group Management, check Success and Failure.\r\nThe following procedure shows how to enable auditing of User/Group management events in a Windows NT 4.0,\r\nWindows 2000, or Windows Server 2003 source domain.\r\nTo enable auditing of User/Group management events in a Windows NT 4.0, Windows 2000, or Windows\r\nServer 2003 source domain\r\n1. In User Manager for Domains, click the User menu and select New Local Group.\r\n2. Enter a group name composed of the source domain NetBIOS name appended with three dollar signs ($),\r\nfor example, FABRIKAM$$$. The description field should indicate that this group is used to audit use of\r\nDsAddSidHistory or cloning operations. Ensure there are no members in the group. Click OK.\r\nThe DsAddSidHistory operation fails if source and destination auditing are not enabled as described here.\r\nSet up Trust if Required\r\nIf one of the following is true, a trust must be established from the source domain to the destination domain (this\r\nmust occur in a different forest):\r\nThe source domain is Windows Server 2003.\r\nThe source domain is Windows NT 4.0 and SrcDomainCreds is NULL.\r\nSource: https://msdn.microsoft.com/library/ms677982.aspx\r\nhttps://msdn.microsoft.com/library/ms677982.aspx\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://msdn.microsoft.com/library/ms677982.aspx"
	],
	"report_names": [
		"ms677982.aspx"
	],
	"threat_actors": [],
	"ts_created_at": 1775434468,
	"ts_updated_at": 1775791301,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d8a3f0d749e2774c0df5c2262ccea95bf1113682.pdf",
		"text": "https://archive.orkl.eu/d8a3f0d749e2774c0df5c2262ccea95bf1113682.txt",
		"img": "https://archive.orkl.eu/d8a3f0d749e2774c0df5c2262ccea95bf1113682.jpg"
	}
}