I figure this out each and every time like it’s the first time.
I promise myself this time I’ll remember it.
I never do.
What is the deal with SID History and SID Filtering on Domain Trust Relationships.
OK, here it is in a nutshell, or as I’m sure they never actually say in the states, let me nutshell this for you.
You enable either, or both, or neither, from the end with the resources.
If you want access to my stuff, I get to decide, so I get to control the settings.
It’s slightly counterintuitive.
I remind myself to trust Ed.
Ed is a person. I want to trust him, so the domain he is in, is the Trust-Ed domain.
He wants access to my stuff, and I decide if I trust him to have that access, so I get to control the settings.
I set them on the outbound trust, which is where it’s counterintuitive, access to resources seems like it should be inbound, Ed comes into my house to drink my beer, so it’s tempting to want to set these settings on an inbound trust, but you don’t.
Think of a trust relationship as an arrow that points at the people you trust.
My outbound trust is pointing at the people I want to access my resources, the outbound trust controls what those users can do in my house.
So what do the settings actually do.
Well, in any kind of migration scenario, you may well have come across objectSID and sIDHistory.
The objectSID of the source account goes into the sIDHistory of the target account if you migrated them in a way that facilitates this.
Both SID Filtering and SID History are related to the sIDHistory attribute of the migrated (trusted) user.
SID filtering determines if any of the sIDHistory attribute values (the previous SID’s of migrated users) should be allowed in authentication requests over the trust.
It essentially only allows SID’s that match the trusted domain. It filters any that don’t match the domain that the trust points at.
If SID Filtering is not enabled, then the objectSID and sIDHistory attributes are all used in authentication.
SID History determines if the values in the sIDhistory attribute are permitted to be used over the trust for access to resources on the trusting domain.
Just remember this. If SID Filtering is enabled, SID History is irrelevant. Once SID filtering enters the picture, sIDHistory is filtered, blocked. If you intend to migrate, use or rely on sIDHistory, SID Filtering must be off.
Example 1. You Enable SID Filtering, but don’t enable SID History.
Users have to authenticate using their objectSID and can then only use objectSID for access to legacy resources. This is the default for new trusts post Windows Server 2003.
In this scenario, access to resources in the legacy (source) (trusting) domain has to be explicitly set for users or groups objects from the target domain. ACL’s on legacy data need to be updated.
Example 2. You disable both SID Filtering and SID History. Users can authenticate and then use only objectSID for access to legacy resources.
In this scenario access to resources in the legacy (source) (trusting) domain has to be explicitly set for users or groups objects from the target domain.
ACL’s on legacy data need to be updated.
Example 3. You enable SID Filtering, and also enable SID History. Users authenticate using objectSID, but want to use sIDHistory for access to legacy resources.
This doesn’t work.
SID filtering here effectively negates the effect of SID History being enabled. Any SID’s that don’t match the trusted domain are filtered, including those in sIDHistory.
Users will authenticate against the new (target) (trusted) domain, but will have no access to legacy (source) (trusting) domain resources via the sIDHistory attribute.
ACL’s on legacy data still need to be updated.
Example 4. You disable SID Filtering, and enable SID History.
Users can authenticate using any SID found in objectSID or sIDHistory, and then access legacy resources using any SID found in objectSID or sIDHistory.
This is as open as it get’s, and it’s typically what you need in a migration scenario.
Users can authenticate using any SID they have access to, and can access the resources that any of these SID’s can access.
So how do you set these options?
From the side of the trust where the resources are, not the side with the users, run the following from an elevated command prompt.
The lines below have been wrapped.
To enable the use of sIDHistory to access legacy resources:
“Netdom trust trustingdomain /domain:trusteddomain /enablesidhistory:yes /userd:administrator /passd:”
To disable SID Filtering so that sIDHistory works over the trust:
“Netdom trust trustingdomain /domain:trusteddomain /quarantine:no /userd:administrator /passd:”
Hopefully, I’ll remember that next time, and hopefully I’ve gotten it right!