Link to home
Start Free TrialLog in
Avatar of Eric
EricFlag for Canada

asked on

SIDFiltering

Hi,

This is about Inter forest AD migration. Just like to confirm something.

in order to give migrated users to access to the domain they are migrated from,

the solution is to disable SID filtering on the trust so that migrated user can come with SIDhistory to access their things in their original domain

is there any other method to accomplished this with while keeping the SID Filtering enabled ?

Regards ,,Thanks

E.
Avatar of Robert
Robert
Flag of United States of America image

As you probably already know the main purpose of SIDhistory is to maintain permissions on things that use NTFS permissions. (i.e. File servers, sharepoint, AD etc.)

The only alternate I am aware of, to disabling filtering would bet to re ACL the source domain as you migrate which could be a bit of a pain if you are staggering the users and not migrating all at same time.
Avatar of Eric

ASKER

Hi Robert,

Thanks for the information. Yes I agree.

ReACL is not worthy to effort and complexity it will bring

Then  I think we can conclude that established/ recommended path which is to

disable SIDFiltering  on trust and let the ADMT create SIDHistory during migration so that migrated users can access to resources.

and lastly if you don't mind,  I am putting high level steps migration step.  which is deals with migration from a single ad/forest domain like x.y to a child ad domain like x.y.z.

please let me know if you think anything needed to be added if you have any information.
- Disable SIDFiltering
-migrate groups in the order of universal, local and global
-migrate users in the order of service accounts, user accounts. but avoid migrating service account in the favour of creating new/fresh service accounts manually and integrating to the application if needed
 When migrating users, tool will attach the SIDHistory value .
- migrate local profiles with Security Translation add operation
- migrate desktops
    -- Security translation with add
    -- Migrate desktop computer accounts

- Migrate Servers ( with the considerations of the apps that is hosting )
  -- Security Translation with add
  -- Migrate Server computer accounts

and before decom ,

 --Security Translation with remove  
 -- Remove SIDHistory attibute

Regards

E
ASKER CERTIFIED SOLUTION
Avatar of Robert
Robert
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Eric

ASKER

Thanks, absolutely l agree, Actually I have done few migration but it is always better to confirm.

I will deal with applications server by server when i will be checking all hard coded LDAP servers, service accounts. DB connection etc etc  and there is no exchange piece on my end. my order  would be roughy starting with users/groups ( finish all before everything ) and  finishing with servers/ apps leaving file servers etc last . Access from target to source domain  resource would be provided by using sidhistory and when executing server migrations, I will be adding the permissions for migrated ad accounts in the new target domain during or before server account migrationg and removed the permission for account from source domain just before decommission when everything is in target domain working fine and breake the trust and decom the domain

SIDHistory is only for migration phase ONLY. You need to translate SIDHistory to the actual SID


So

is there any other method to accomplished this with while keeping the SID Filtering enabled ?

Yes, translate the SID to the new SID