use Sid_history to be the king of the forest
how to use sid_history to have full access to other trusted domains
We have a forest with several domains in it. a user with a user_account of u1 from domain “a.com” is going to domain “b.com”
-first of all, why he has to do it?
because he will have a new manager and he has to follow the policies of domain b.com
-ok, then what options do we have ?
a noob admin will suggest that we remove u1 from domain a.com and add a new user named u1 in b.com
-don’t you think it will solve our problem?
no because :
u1 has many rights and permission that we have to set them again.
parameters like SID and GUID will be changed.
u1 has different “user profiles” on different computers that will be useless case a new user cant use non of them anymore.
-so what a likable admin will do?
we have a parameter named sid_history that can be very useful. SID is a parameter that given to any object in a domain by a domain controller. when our user from domain a.com moves to domain b.com, it stores its previous SID in sid_history and replaces its SID with the given SID from its new DC.
-so how will the u1 use his previous resource in domain a.com?
when he login into domain b.com, the dc of the b.com domain will give him a ticket to use his resource. when he goes to a.com, the dc of a.com will let him in. his ticket is accepted in a.com, not because he was an a.com user before but because he used a ticket of b.com, a domain that has two-way trust with b.com and his ticket is accepted here. when u1 tries to use his old resource dc of a.com, check his sid_history and then let him use the resources.
this parameter is empty by default, and after moving user will be filled by the old SID. this parameter can have several SID in it.
-so, does Microsoft let us use this option?
yes, but we have to enable it .
by default, Microsoft filtered this option because it has a bit of vulnerability.
-really, what is that?
ok, so listen. Consider our example, can a.com users see the SID of b.com users? can b.com users see the SID of a.com users?
yes, they can cause two domains to be in the same forest, so they have two-way trust and can see each other’s information. each user of a.com is an authenticated user for domain b.com, and each user of b.com is an authenticated user of a.com. and it means they have permission to READ.
we know that AD has several partitions like domain data partition and configuration data partition and etc. SID is stored in the domain data partition.
if I am an admin of a.com or any user that has permission to write in the domain data partition, I can easily write SID as the admin of domain b.com and use all resources or do whatever I like ;-) in the b.com domain.
so if you are a user in a forest that did not use Sid_history_filter and have a user that has permission to write in Domain Data Partition, you can use all of the other domain’s resources as well, just by adding their administrators SID in your user account.
