Foreign Security Principal Objects belongs to Local Internal Domain accounts instead of trusted external domain accounts

In a clean, new set of forests and domains with a two-way trust. There are NO FSP.

The source domain SID is S-1-5-21-4173298193-2051065138-1650543716
The target domain SID is S-1-5-21-818314195-1326715257-2966284822

I created a domain local group in the Target Domain and added a source users.
This created and FSP with a CN of S-1-5-21-4173298193-2051065138-1650543716-1123 along with 4 other built-in FSP (Short SIDs).

It should be noted that there is no attribute for "Readable Name", it is only visible in the UI of user and computers. The readable name is resolved at run time. 

Looking in Users and Computers, in the FSP container, the readable name for S-1-5-21-4173298193-2051065138-1650543716-1123 is Source\Ally.albert

Next I migrate Ally Albert from source to target with SidHistory (This is the key). 

I refresh the view of the FSP container in the Users and Computers. 

The Readable Name for S-1-5-21-4173298193-2051065138-1650543716-1123 is Target\Ally.albert however the Object;s whenChanged and WhenCreated date/time stamps are still the same. This proves that the FSP has not actually change. 

So the root cause for the Readable Name being displayed as Internaldomain\SameAccountName is SidHistory. 

FYI, Vladimir and Wally is the same person and no longer around. 

Thank you Jeff Shahan for explanation.

After adding Source users in Domain Local groups which resulted FSP object in target domain. There are 2 scenarios which also needs to be explained.

1. Suppose if source users are migrated(copied) without Sidhistory and AD account of source users still exist in source domain then what would it resolve and showing under Readable Name?

2. Suppose if source users are migrated(moved) without Sidhistory and AD account of source users no longer exist in source domain then what would it resolve and showing under Readable Name?

Few more questions:

1. Is this safe to delete those FSP objects showing as Target\SamAccountName from ForeignSecurityPrincipals Container in the target domain after source user migration with sidhistory is completed? Will it affect actual user account in target domain?

2. I've seen articles where it is mentioned that After a successful migration you have to remove Foreign Security Principals from the domain local groups. I need to understand and know the reason of the same. Is this safe to delete them and will it affect anyway?

3.  If I remove FSP object from Domain Local group members list, will it also remove the same FSP from ForeignSecurityPrincipals Container OR do I have to manually get rid of them from FSP container?

4. There are few domain local groups in my internal domain showing FSP object (from trusted external domains) as members. However, when I open that FSP object properties from ForeignSecurityPrincipals Container "MemberOf" tab is empty instead of showing Domain Local group. Why and how is this possible?

5. How do I determine unused FSPs (not orphaned FSPs) in my local internal domain(any script) and is this safe to delete them from both Domain Local groups and ForeignSecurityPrincipals Container as well?

6. What is the best way or how do I clean all stale FSP objects from groups and FSP container after migration is completed so that it does not affect negatively? Any script?

Kindly reply with explanation specific to all my queries mentioned above.

Thanks in advance! 

1. Suppose if source users are migrated(copied) without Sidhistory and AD account of source users still exist in source domain then what would it resolve and showing under Readable Name?

Source\user

2. Suppose if source users are migrated(moved) without Sidhistory and AD account of source users no longer exist in source domain then what would it resolve and showing under Readable Name? 

There is NOTHING that will "move" the object inter-forest. This can only be done intra-forest and only with sidhistory. So this is an invalid question. But in theory this would be the same as a copy object and delete source object. The result would be a NULL readable name as there is NOTHING to resolve the sid to. 

Few more questions:

1. Is this safe to delete those FSP objects showing as Target\SamAccountName from ForeignSecurityPrincipals Container in the target domain after source user migration with sidhistory is completed? Will it affect actual user account in target domain?

No. There are still more tasks to execute. 

• The target users should be made members of the group. This can be done using Migration Manager for AD's Active Directory Processing Wizard. This can add the target objects to the local groups and remove the FSP in one or two passes depending on tool's settings.
• SidHistory should be removed from the target objects. 

2. I've seen articles where it is mentioned that After a successful migration you have to remove Foreign Security Principals from the domain local groups. I need to understand and know the reason of the same. Is this safe to delete them and will it affect anyway?

No, it is not safe to remove them unless you have added the target object to the group. 

3.  If I remove FSP object from Domain Local group members list, will it also remove the same FSP from ForeignSecurityPrincipals Container OR do I have to manually get rid of them from FSP container?

You have to manually remove them. 

4. There are few domain local groups in my internal domain showing FSP object (from trusted external domains) as members. However, when I open that FSP object properties from ForeignSecurityPrincipals Container "MemberOf" tab is empty instead of showing Domain Local group. Why and how is this possible?

The member of tab is a calculated read only view. All you are seeing it that it cant be calculated. 

5. How do I determine unused FSPs (not orphaned FSPs) in my local internal domain(any script) and is this safe to delete them from both Domain Local groups and ForeignSecurityPrincipals Container as well?

You would need to report on group membership to insure that what if any FSP remain as members. 

6. What is the best way or how do I clean all stale FSP objects from groups and FSP container after migration is completed so that it does not affect negatively? Any script?

Define stale? Did you mean unused? i.e. A FSP not a member of any group, see above,

The larger issue you would deal with is sidHistory. If there was a migration and that migration is complete, sidhistory should be removed. Migration Manager for AD's Active Directory Processing Wizard can remove the sidhistory that we applied as part of a migration executed with Migration Manager for AD's. Next remove the trust to the source or delete the source domain. That will orphan all the the FSP from that domain. It would not be safe to delete all FSP with that domain sid. 

Thank you Jeff Shahan for your reply.

1. Let me explain specific to my environment. There is 2 way external trust relationship still established between source domain and target domain (in different forest). So basically user accounts have been migrated from source domain to target domain with sidhistory and those accounts no longer exist in source domain. Groups have been mirrored from source domain to target domain with sidhistory in order to retain access of resources in source domain.
So as you suggested sidhistory should be removed after migration is completed. My question is can I remove Sidhistory from all user accounts in target domain OR is there any criteria to delete sidhistory as per my environment situation keeping in mind that access of resources in source domain is retained?

2. What do you suggest post migration tasks as per my environment and how do I implement those tasks for cleanup? Please feel free to let me know if you need more information to answer this.

2. As you previously explained, readable name of FSP is changed from source\user to target\user once user account is migrated with sidhistory. My question is can I delete those SIDs of FSP objects whose Readable Name is showing as target\user after migration from ForeignSecurityPrincipals container. If I remove those SID of FSP from ForeignSecurityPrincipals container, will it remove FSP object as well automatically remove from group?

3. How do I determine which FSP objects should be removed from Domain Local groups?

4. Can I remove all orphaned FSP objects from Domain Local groups?

Kindly reply with explanation specific to all my queries mentioned above.

Thanks in advance!

My question is can I remove Sidhistory from all user accounts in target domain OR is there any criteria to delete sidhistory as per my environment situation keeping in mind that access of resources in source domain is retained?

Assuming all Source resources have been processes and the source sids replaced with target sids, sidhistory is providing not value. <-This is KEY!

I always inform customers that they should remove sidhistory as part of the migration project. It is only then will the teams who owned the project know if everything has been done to allow the clean up of sidhistory. Because if everything has not be processed, the net impact will be a denial of service to an unprocessed resource. The recovery is a recovery of the domain to restore sidhistory if you don't own a product like Quest Recovery Manager for Active Directory that can restore a single attribute. 

2. What do you suggest post migration tasks as per my environment and how do I implement those tasks for cleanup? Please feel free to let me know if you need more information to answer this.

I really can't make any suggestions. I don't know enough about what you did, what others have done, ect to understand the impact of what I would be suggesting. I can tell you what you should do as part of a normal migration. It is up to you to make assessment.

• Migrate objects with sidhsitory
• Resource process all resource to translate the permissions from source sids to target sids
  This includes files, folders, groups, ect.. ANYTHING that the source users could access. 
• Remove sidhistory

2. As you previously explained, readable name of FSP is changed from source\user to target\user once user account is migrated with sidhistory. My question is can I delete those SIDs of FSP objects whose Readable Name is showing as target\user after migration from ForeignSecurityPrincipals container? 

If you are asking me, I would say no. In order for you to make that decision. As I said, Quest's Migration Manager has a tool, the Active Directory Processing Wizard . It will change the FSP for the user object in the group. 

If I remove those SID of FSP from ForeignSecurityPrincipals container, will it remove FSP object as well automatically remove from group?

Yes when you delete an object it is remove from the member attribute. 

3. How do I determine which FSP objects should be removed from Domain Local groups?
Delete the FSP objects instead.

4. Can I remove all orphaned FSP objects from Domain Local groups?
Delete the FSP objects instead.

I have to ask why is this even a worry? What risk are you mitigating? 

Thank you Jeff Shahan for your reply.

As you said that ADPW will convert FSP to user object in the group.So as per my environment, FSP SID still resolves to Target\User in FSP container. So it means it is not converted yet to user object in the group because if it had converted, then FSP SID should also be removed by ADPW automatically from ForeignSecurityPricipals container and target\user had been member of group.

1. Is this possible that after user accounts are migrated, target\user became member of Domian Local groups without removing FSP SID from FSP container either by manually or by ADPW tool itself?

2. Migration project was completed in 2013. So if I run ADPW now, then how would I know which group should be choosen corresponding to which migrated target\user either manually by me or tool itself to convert FSP to user object in the group. Is ADPW allowed to convert FSP to user object in Domain Local group only (not Global and Universal groups)? Shall I proceed to run ADPW for automatic conversions of FSP to target user objects in Domain local groups and automatically get rid of FSP SISs showing as Target\user in ForeignSecurityPrincipals container?

As far as removal of sidhistory is concerned, mostly all resource had been migrated from all trusted source domains to Isilon NAS devices. Those NAS boxes are target domain joined now. Mostly all network shares, folders are located on those NAS boxes. Those Shares, folders brought ACL from source domain during migration.Those ACL contains groups from source and target domains for managing permissions. Those groups contains actual user objects and other global groups for granting access on resources. As I previous said that Groups have been migrated (mirrored) along with sidhistory. Those groups still exist in source domain. So target group contains sidhistory of source group. When user in target domain who is memeber of target group access resources on NAS, in his access token because of SID of group is compared again user's access token and because of sidhistory user is authenticated on NAS and since target group is member of source group then becauseof membership, user is granted access on resources. You suggested to remove sidhistory from all migrated objects post migration. So my question is

3. If I remove sidhistory from target group(mirrored), then how user will be able to access resources on NAS? So it means I should not removed sidhistory from groups.

4. Correct me if I am wrong. If I remove sidhistory from target user objects then it should be safe (assuming target user is member of target group and beacuse sidhistory of target group will be compared against source group sid on resource ACL) unless user object is applied on resource ACL directly?

5. So that's why I think I should remove sidhistory only from all user objects (not group objects) in target domain because as per my environment source sids were not replaced with target sids because resources are already migrated on target domain joined NAS devices and no longer in source domain servers. What is your opinion on this?

6. I think now I have provided enough information about my environment. So please suggest post migration tasks according to my current environment by ensuring access of resources on NAS is retained for all users and how do I implement those tasks for cleanup.

Kindly reply with explanation specific to all my queries mentioned above.

Thanks in advance!

So lets stop talking about FSP as that is really from wrong angle to be looking at this. If there is one or thousands of FSP, who cares? What impact are they presenting today? What risk will they expose you to tomorrow? I have now asked these questions twice. 

These are the facts

1. A migration completed in 2013
2. Source Security Principals were members of Target groups 
3. Sid history was used during that migration
4. Sid history was NOT removed post migration and has remained for 7 years
5. Source resources have been migrated to target hosts
6. Source users have been deleted from the source domain
7. The source domain will exists
8. I have no knowledge of your migration that was not posted to this thread.  

Here is what is unknown

1. Were all source resources were resource processed? (re-stamping permission/membership) 
   Based on this thread, NO everything was NOT processed. 
2. Was the data and permissions simply copied from source host to target host?
   Based on this thread, Yes. files, folders and permissions were copied as is from source to target hosts.  
3. Were all target groups that had source members resource processed?
   Based on this thread, NO everything was NOT processed. 
4. Were all trusting domains and host resource processed?
   What tool was used during the migration in 2013?
5. What tools you have access to today?
6. Why was sidhistory NOT removed back when the migration project ended? 
7. If Quest Migration Manager for AD was used during the migration and the migration project still exists?

6. I think now I have provided enough information about my environment. So please suggest post migration tasks according to my current environment by ensuring access of resources on NAS is retained for all users and how do I implement those tasks for cleanup.

You are wrong, I do not have enough to gauge the impact of my recommendations, so I will not be making any recommendations.

5. So that's why I think I should remove sidhistory only from all user objects (not group objects) in target domain because as per my environment source sids were not replaced with target sids because resources are already migrated on target domain joined NAS devices and no longer in source domain servers. What is your opinion on this?

This is telling me that the source data and permissions were copied as is to the target NAS host. These shares, files and folders should have been resource processed. Resource process it now. 

4. Correct me if I am wrong. If I remove sidhistory from target user objects then it should be safe (assuming target user is member of target group and beacuse sidhistory of target group will be compared against source group sid on resource ACL) unless user object is applied on resource ACL directly?

This is how permissions are granted. ObjectSID ->Access Control Entry (ACE) ->Access Control List (ACL)
This is how access is evaluated, Access Token = ObjectSID in ACE = ACE is access level
The Access Token contains the ObjectSIDs for the calling users and the groups it is a member. It also contains the SID in the sidhsitory for the calling user and the groups it is a member. 

If you remove sidhistory from the user objects, any ACE that contains the Source ObjectSID of the user, access will NOT be granted (or denied)

3. If I remove sidhistory from target group(mirrored), then how user will be able to access resources on NAS? So it means I should not removed sidhistory from groups.

You are correct. These shares, files and folders should have been resource processed. Resource process it now. 

2. Migration project was completed in 2013. So if I run ADPW now, then how would I know which group should be choosen? <SNIP>

ADPW is an automated process that uses the projects mapping data, source sid=target sid. It will enumerate a groups in scope of it processing task. The member attribute of a group contains the Distinguished Name (DNs) of the objects that are member. ADPW enumerates each member and does the following, if member in mapping data, if yes apply target mapped object, if not move next. There is more to it, but that is the key part for this conversation. All groups can be processed, there is no negative impact.

1. Is this possible that after user accounts are migrated, target\user became member of Domain Local groups? <SNIP>

Sure, I would expect this to happen as it is normal administration. 

In summary, if you have re-keyed all of the locks why throw away all of the old keys? Who cases if you have a list of all of the old keys? 

Thank you Jeff Shahan for your reply.

So basically there are 2 important things I just need to focus.

a) Resource processing of resources (which are migrated into target domain joined NAS devices)
b) sidhistory removal form target objects.

1. Let me clear in this inter-forest migration source domain still exists and there are 2303 active user objects out of total 4677 user objects. So this source domain is still functional and not going to be decommisioned. It means not all user objects and groups were migrated. So I think it was cross company migration project. Resources in target domain joined NAS devices most likely will also be accessed by these active user objects as well in source domain because as I said previously groups are mirrored(with sidhistory) and still exist in source domain and those source domain local group (brought during migration) objects are still applied on resource ACL and also I can apply other source groups (global and universal) on resource ACL. So this might be the reason source sids on ACL of resources had not been replaced by target sids post migration in order to retain access for acive user objects in source domain. Do you still think that I need to do resource processing? If I do resource processing don't you think that user objects still present in source domain lost access on resource? How do I overcome or tackle this situation keeping acces of resources by source objects intact?

2. Why resource processing is necesary prior removal of sidhistory as long as migrated objects in target domain are accessing resources using sidhistory because source domain is not going to be decommisioned? If I don't do resource processing, then sidhistory is the only way to access resources. So that's why I think resource processing is not performed. So if resource processing is not performed than sidhistory should not be removed. Correct?

3. As far as I think, sidhistory removal can still be done(without resource processing) on migrated user objects not migrated groups(mirrored) because access on resources is granted to migrated user objects by using groups because only groups are applied on ACL not migrated user objects. So no matter if I remove sidhistory from migrated user objects, those users will still be able to access resources if migrated user objects are member of traget groups, target groups contains sid value of actual source groups in sidhistory attribute and target groups is nested into source gropus as members. Corect? So that's the reason only sidhistory should be removed from migrated user objects only without resource processing. Is there any harm/disadvantages in doing this?

Looking forward to prompt reply with explanation specific to all my queries mentioned above.

Thanks in advance!

Jeff Shahan

Waiting for your reply as based on your reply I will be able to make correct decision what needs to be implemented

a) Resource processing of resources (which are migrated into target domain joined NAS devices)

No, it is not just on the target joined NAS, they are potentially EVERYWERE in the source domain AND since there was a trust prior to migration, and the FSP exist  

Do you still think that I need to do resource processing? 

Yes. You should always resource process. You can Append or Replace. It is common to Append and then Cleanup the source ACEs later. 

You stated that the migrated users objects were DELETED in the source. So a replace cleans up the orphaned sids too. 

If I do resource processing don't you think that user objects still present in source domain lost access on resource? 

How do I overcome or tackle this situation keeping access of resources by source objects intact? 

Resource process to Append.

2. Why resource processing is necesary prior removal of sidhistory as long as migrated objects in target domain are accessing resources using sidhistory because source domain is not going to be decommisioned?

The State of the Source domain has no bearing on this. 

For example. you migrated 100 users and 100 groups. The source users were deleted the source groups were not. That orphaned 100 user SIDs on any permissions that were on. These are NOW no longer manageable. Someone could deleted them and then you have a Denial of Service for the Target user trying to access a resource he should have access too. 

So for the above users objects, you could resource process and replace their sids in the ACLs. For the above groups, you would resource process and Append their SIDs in the ACLs.  

Let me rephrase, why should I rekey (ACEs/ACLs) the locks if everyone has a copy of the old key(sidHistory)? Answer: Because their key ring is now twice the size it used to be. <-This is call TOKEN bloat (https://support.microsoft.com/en-us/help/327825/problems-with-kerberos-authentication-when-a-user-belongs-to-many-grou)

 Sid history is A CRUTCH, it is not a long term solutions. It is a long term issue that will cause other issues that can take months to figure out the root cause and resolve.