The sIDHistory attribute is a property of a security principal (users and groups, most commonly) that maintains the former value of an object's SID. SIDs are specific to each domain (since they consist of a domain portion and object portion), and when objects are migrated between domains, new SIDs are generated and the remaining attributes are copied or regenerated accordingly. Some attributes such as object GUIDs never change during the lifetime of an object, and since migration essentially creates a new object in the destination domain, attributes like a GUID cannot be copied.
A typical migration scenario involves setting up a trust relationship between source and destination domains, and moving groups, users, and servers gradually over time, in the sequence as indicated. If no SID history is maintained during migration, migrated users will lose access to resources that are still maintained in the source domain, because the new SID of the migrated user account will not be matched to any access control entries on the resources in the source domain.
Windows 2000 introduced the sIDHistory attribute as a way to enable these coexistence scenarios without having to modify resource permissions, which can be a daunting task even in relatively small environments. By allowing the migrated user account to "remember" its old SID from the source domain, Windows makes migration a breeze. The old SID is copied to the sIDHistory attribute during user and group account migration. When a migrated user account is used to log on, Windows constructs a token that includes both SIDs, new and old. When this token is presented to a file server in the source domain, the authorization process happens as if no changes were made to the user account.
As helpful as the SID history was, it presented a new security problem. Administrators and power users in the trusted domain, under certain circumstances, could obtain a SID of a privileged account from the trusting domain. These SIDs are not kept secret, and most of the time you can obtain this information by looking at the access control lists (ACLs) on the resources in the trusting domain. Once such a SID is obtained, it gets attached to any user object in the trusted domain, specifically to its sIDHistory attribute. When this modified account crosses an existing trust relationship, from the trusted domain into the trusting domain, it will effectively have all the privileges of the compromised account, possibly elevating all the way to the Domain Admin or Enterprise Admin level.
SID filtering comes to the rescue by filtering out all SID histories presented from within the trusting domain. Essentially, if a user is trying to elevate from a trusted domain, the user will add a SID from the trusting domain to that user's SID history. The trust link sees this as a potential compromise and filters from authentication requests all SIDs that are not from the trusted domain. If users in the trusted domain were migrated from another (third) domain, SID information from the third domain will not be allowed through the trust link.
Windows Server 2003 and 2008 automatically configure SID filtering on all trust relationships that are created on these servers. To disable SID filtering, you need to use the netdom trust command, but this is only recommended when and if administrators of the partnering domains can be trusted.
Was this article helpful?
Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.