Clean up orphaned Foreign Security Principals

• Author
• Recent Posts

Luc Fullenwarth

Luc is working as a system administrator since 1999 at Alcatel-Lucent, at HP, and currently for an European institution. He focuses on Active Directory, Group Policy, security and PowerShell.

Latest posts by Luc Fullenwarth (see all)

• How to configure computer delegation with PowerShell - Mon, Jul 23 2018
• Save on Azure costs for testing and training - Wed, Jun 6 2018
• Clean up orphaned Foreign Security Principals - Fri, Oct 20 2017

Especially if you have only one domain that has no trust relationship (and never had one), you will have very few FSPs. On the other hand, if you have several forests with trust relationships, you probably have plenty of FSPs.

FSPs in a nutshell

The very short definition: An FSP is an Active Directory (AD) security principal that points to a security principal (a user, computer, or group) from a domain of another forest. A red curly arrow represents these security principals:

These merely act like pointers.

AD automatically and transparently creates them in a domain the first time after adding a security principal from another forest to a group from that domain.

For example: When adding a user from domain A for the first time to a group from domain B from another forest, this creates an FSP in domain B and adds this FSP to the group from domain B.

A FSP points to a security principal from another forest

Why an FSP becomes an orphan

As we have seen above, AD creates FSPs in a domain the first time after adding a security principal of a domain from another forest to a group. And when someone removes the security principal the FSP is pointing to, the FSP becomes an orphan because it points to a non-existent security principal.

Given that:

• An FSP points to a security principal of another domain by its SID number
• After deletion and re-creation of a security principal, it has never the same SID

It is easy to understand that an orphan FSP will stay an orphan—forever!

And because there is no built-in mechanism in AD to monitor whether security principals matching FSPs still exist, orphan FSPs still remain, until someone removes them.

How to identify and clean up orphan FSPs with the GUI

You can find all FSPs in the Active Directory Users and Computers (ADUC) console in a container named ForeignSecurityPrincipals. However, you must first enable Advanced Features in the console. Otherwise the container won't show anything.

Active Advanced Features to see FSPs

You can recognize orphan FSPs by empty readable names in the ADUC console.

Orphan FPSs with empty readable names

To remove them you just have to select the FSPs without readable names, right-click them, and select Delete.

List and clean up orphan FSPs with Powershell

You can also list all FSPs with the Get-ADObject cmdlet.

Get-ADObject -Filter {ObjectClass -eq 'ForeignSecurityPrincipal'}

To remove orphan FSPs, you can use the Translate method.

$ForeignSecurityPrincipalList = Get-ADObject -Filter {ObjectClass ‑eq 'foreignSecurityPrincipal'}

foreach($FSP in $ForeignSecurityPrincipalList)
{
    Try
    {$null=(New-Object System.Security.Principal.SecurityIdentifier($FSP.objectSid)).Translate([System.Security.Principal.NTAccount])}
    Catch
    {Remove-ADObject -Identity $FSP}
}

However, there is a caveat: If, at the same time you are looking for FSPs, there is a network connectivity issue between your domain controllers and domain controllers from other trusted forests, you won't be able to see the readable names. Thus you will incorrectly deduce that they are orphans.

That's why I don't recommend automatically deleting all orphan FSPs without any control through the method above. Instead I wrote a little module named OrphanForeignSecurityPrincipals you can download from the Microsoft Gallery.

The module contains two cmdlets:

1. Get-OrphanForeignSecurityPrincipal, which displays the list of orphan FSPs and can also export the list to a tab-delimited file.
2. Remove-OrphanForeignSecurityPrincipal, which removes FSPs provided by the DistinguishedName parameter, the pipeline, or a tab delimited file.

Automate the process

To automate the removal of orphan FSPs, you can schedule a task.

However, considering the caveat above, and despite the fact it technically works fine, I would not recommend the following command-line cmdlets:

Get-OrphanForeignSecurityPrincipal | Remove-OrphanForeignSecurityPrincipal

Another method would be to compare the number of orphan FSPs to the average employee turnover of your company. If the first number is equal to or below the other, you can immediately remove the list of orphan FSPs. If the first number is above the other, you can email the list to the system administrator for further investigation.

For example, let's say the turnover of your company is 20 employees per month and you run your task every month. The scheduled script could look like this one:

Import-Module -Name OrphanForeignSecurityPrincipals

$MyCompanyTurnover = 20
$OrphanFSPListFilePath ='c:\temp\OFSP.txt'

$OrphanForeignSecurityPrincipalsList = Get-OrphanForeignSecurityPrincipal ‑TabDelimitedFile $OrphanFSPListFilePath

If ($OrphanForeignSecurityPrincipalsList)
{
    If ($OrphanForeignSecurityPrincipalsList.Count -gt $MyCompanyTurnover)
    {
        $MailParameters = @{
            SmtpServer = 'mail.mycompany.com'
            From       = 'NoReply@mycompany.com'
            To         = 'Administrator@mycompany.com'
            Subject    = "Orphan Foreign Security Principals found"
            Body       = 'Please check attached file.'
            Attachment = $OrphanFSPListFilePath
        }

        Send-MailMessage @MailParameters
    }
    else {
        Remove-OrphanForeignSecurityPrincipal -TabDelimitedFile $OrphanFSPListFilePath
    }
}

Of course, you can also decide to send the exported file always to the administrator.

Recover a deleted FSP

You can use one of the following methods to achieve this:

• Restore the FSP from the Recycle Bin. However, please note the Recycle Bin feature must have been active before any deletion occurred.
  Read more about activating the Recycle Bin here.
• Via Powershell:
  1. Find your object(s) with a query like this one:
     Get-ADObject -Filter 'IsDeleted -eq $TRUE' -IncludeDeletedObjects | Where-Object {$_.DistinguishedName -like "CN=S-*"}
  2. As soon as you've fine-tuned your query to return only the objects you want to restore, pipe the result to the Restore-ADObject
• Add the foreign account or group into all groups where it has formerly been.
  This will create the same ForeignSecurityPrincipal again.
  Hint: If you still have the exported file you used to export the ForeignSecurityPrincipals, a column inside it lists the group membership.