In case you’ve noticed that the sIDHistory attribute isn’t very user friendly when viewing it with ADSI Edit, here’s a way to reverse-engineer the value to compare it with how we are normally used to seeing it displayed:
Find the SID for the source domain user or group by using the getsid.exe command:
Command Usage:
getsid \<source_dc> “<Source User/Group Name>” \<target_dc> “<Target User/Group Name>”
Example:
getsid \DA_PDC “Developers” \CORPCU1DC001 “Corp-CU-Developers”
The results should display that the SIDs are not a match, which is expected since the migrated account has a new SID and the getsid command does not check the sIDhistory attribute.
The SID for account DomainADevelopers does not match account DomainBCorp-CU-Developers
The SID for account DomainADevelopers is S-1-5-21-1620258971-428748344-1844936127-1370
The SID for account DomainBCorp-CU-Developers is S-1-5-21-702074188-2833732907-241959117-38230
The final grouping in the SID is the RID (Relative ID) and is unique for each object created by that domain. In the example above the decimal value 1370 is the RID of the group in the source domain that is going to be verified.
Using the ADSIEdit tool, view the sIDHistory attribute on the migrated user or group in hexadecimal format.
Re-order the last 4 HEX groupings back to front, keeping the paired characters the same:
5A 05 00 00 > 00 00 05 5A > 0000055A
Convert the re-ordered value from hexadecimal into decimal:
55A = 1370
The calculated decimal value 1370 is the same RID as shown by the getsid output against the source object.
The same procedure can be used to convert and verify the entire SID value, as outlined in this TechNet blog entry:
http://blogs.msdn.com/oldnewthing/archive/2004/03/15/89753.aspx
And if you’re already familiar with the Additional Account Info tab taht can be added to Active Directory Users and Computers, then you can skip all this 🙂 But it’s good to know how it works behind the scenes.
