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

Question

In my AD environment, there are lot of FSP objects belong to local Internal domain accounts instead of trusted external domain accounts showing under Foreign Security Principals container. I mean SID value of FSP objects (showing under Name column in FSP container) resolves to Internal Domain user accounts rather than trusted external domain user accounts. Moreover, Readable Name of FSP objects is also showing as "Internal Domain\samAccountName" rather than trusted external domain samAccountName. 
 Kindly let me know root cause and explain how did this happen. 
 Thanks in advance! 
 
 vladimir.knorr Jeff Shahan wally Enrico Mancini rmukan

Jeff Shahan · Accepted Answer

This will be my last post to this very long thread. If you have any other question, please post a new topic. As I understand correctly, migrated target users(sidhistory preserved) will experience denial of service even though sidhistory value of target user matched with orphaned SIDs because orphaned SIDs are not associated with any security principals. Am I correct? 
 The FSP is a member of a group, not the source objects. So if you delete the FSP, the users will lose membership to the group via sidhistory/fsp link. 
 Could you please share ADPW guide/article that can explain the process of resource processing? 
 The support portal is key. https://support.quest.com/migration-manager-for-ad/8.15 
 There is a whole knowledge base and technical documents on this https://support.quest.com/migration-manager-for-ad/8.15 
 Here is a direct link to the ADPW section of the documenation. https://support.quest.com/technical-documents/migration-manager-for-ad/8.15/resource-processing-guide/11#TOPIC-1174741 
 What about sidhistory removal after inter-forest migration? Is there any specific tool by Quest for performing this task automated way? 
 ADPW can do that too. 
 How do I removing sidhistory efficiently after migration? 
 Use ADPW to remove the sidhistory that was applied during the migration. 
 Is there is any guide/article of sidhistory removal that can explain the process? 
 See the documentation and links above

Jeff Shahan · Answer

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.

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

Top Replies