Skip to content
Hermes Codex

Cross-Domain Group Membership and Foreign Security Principals

Concept

Section titled “Concept”

When an administrator grants permissions on Domain A resources to a user or group residing in Domain B (linked via a trust):

  1. The ForeignSecurityPrincipals Container: Located at the root of the domain naming context (CN=ForeignSecurityPrincipals,DC=domain,DC=local), this container stores objects of class foreignSecurityPrincipal.
  2. SID Representation: Each FSP object’s name is the raw string SID of the foreign security principal (e.g., CN=S-1-5-21-29482-1002,CN=ForeignSecurityPrincipals,DC=corp,DC=local).
  3. The AGUDLP Strategy:
    • Accounts $ ightarrow$ assigned to Global groups (Account Domain).
    • Global groups $ ightarrow$ assigned to Universal groups (optional, intra-forest).
    • Universal groups $ ightarrow$ assigned to Domain Local groups (Resource Domain, represented as FSPs).
    • Domain Local groups $ ightarrow$ assigned Permissions on securable objects (DACLs).

Why It Matters in DFIR

Section titled “Why It Matters in DFIR”

Auditing Foreign Security Principals is the fastest method to determine how external identities hold permissions in the local domain:

  • Uncovering Cross-Domain Backdoors: If an external forest’s global group is added to the local Administrators or Remote Desktop Users group, an FSP object is immediately created in the directory.
  • Orphaned Persistence (FSP Persistence): Even if a trust relationship is deleted, orphaned FSP objects and their nested group memberships persist in the local directory database.
  • BloodHound Cross-Domain Traversal: When an attack graph crosses a trust, the MemberOf relationship traverses through an FSP. Accurately resolving FSP SIDs to human accounts in the remote domain is essential during incident response.

How It Works

Section titled “How It Works”

Foreign Security Principal Lifecycle

Section titled “Foreign Security Principal Lifecycle”
DOMAIN B (Accounts)                          DOMAIN A (Resources)
┌─────────────────────────┐                  ┌──────────────────────────────────────────────┐
│ User Account:           │                  │ Container:                                   │
│ alice@domainB.local     │                  │ CN=ForeignSecurityPrincipals,DC=domA,DC=loc   │
│ SID: S-1-5-21-B-1005    │                  ├──────────────────────────────────────────────┤
└───────────┬─────────────┘                  │ Automatically generated FSP object:          │
            │                                │ CN=S-1-5-21-B-1005                           │
            │ Added into group               └──────────────────────┬───────────────────────┘
            │                                                       │
            │                                                       ▼ Member of
            │                                ┌──────────────────────────────────────────────┐
            └───────────────────────────────►│ Domain Local Group:                          │
                                             │ "DL_Server_Admins"                           │
                                             │ (Contains FSP S-1-5-21-B-1005)               │
                                             └──────────────────────────────────────────────┘
  1. On-Demand Instantiation: FSP objects are not created when establishing a trust: they are created dynamically the moment an external principal is added to a local group or DACL.
  2. LSA Name Lookup: When viewed via Windows Explorer or RSAT, LookupAccountSid contacts Domain B’s DC across the trust to translate S-1-5-21-B-1005 into DOMAINBlice. If the trust is severed, only the raw SID displays.

What Is Possible

Section titled “What Is Possible”
  • Nesting External Global Groups into Domain Local Groups: This represents Microsoft’s canonical role-delegation model for cross-domain resource access.
  • Enumerating All Foreign Permissions in a Single Query: Querying CN=ForeignSecurityPrincipals reveals every external identity ever granted rights in the domain.
  • Pre-Created Well-Known FSPs: Certain universal SIDs such as S-1-5-11 (Authenticated Users) have permanent default FSP entries.

What Is Not Possible

Section titled “What Is Not Possible”
  • Adding Foreign Users to a Local Global Group: Active Directory group scoping rules strictly forbid adding members from other domains into a group of Global scope. Only Domain Local groups accept cross-domain / cross-forest members.
  • Activating Rights for an Arbitrary FSP Without Authentication: An attacker cannot simply forge an FSP entry to obtain rights; the operating system requires a valid cryptographic token (Kerberos/NTLM) asserting that SID.
  • Moving FSPs to Other OUs: FSP objects must reside in the well-known container CN=ForeignSecurityPrincipals.

Common DFIR Confusions

Section titled “Common DFIR Confusions”
Frequent ConfusionVerifiable Forensic Reality
”The existence of an FSP proves that the foreign account has logged on.”No. An FSP is created when an external principal is added to a group or ACL, regardless of whether that user ever logs on.
”Deleting the user in Domain B deletes the FSP in Domain A.”No. The FSP remains as an orphaned SID in Domain A until manually removed.
”FSPs only exist for forest trusts.”FSPs are generated for all trust types: Parent-Child, External, Forest, and Realm.

Concrete Forensic Example

Section titled “Concrete Forensic Example”

During post-compromise persistence triage on a root domain (root.corp):

  1. The investigator inspects the local Administrators (S-1-5-32-544) group on the root DC.
  2. They identify an unresolved SID: S-1-5-21-99887766-500.
  3. In CN=ForeignSecurityPrincipals,DC=root,DC=corp, an object CN=S-1-5-21-99887766-500 shows whenCreated matching the day of initial compromise.
  4. Trust analysis confirms S-1-5-21-99887766 belongs to a development domain dev.local.
  5. Forensic Finding: The threat actor nested the local administrator of the development domain directly into the root domain’s Administrators group via an FSP, establishing persistent Tier 0 access from the dev environment.

Key Forensic Artefacts

Section titled “Key Forensic Artefacts”
  1. Directory Objects:
    • Container CN=ForeignSecurityPrincipals,DC=domain,DC=local.
    • FSP attributes: cn (SID), whenCreated, whenChanged, memberOf.
  2. DC Security Event Logs:
    • Event ID 4728 / 4732: A member was added to a security group (MemberName contains the FSP Distinguished Name).
    • Event ID 4729 / 4733: A member was removed from a security group.

Investigation Methods

Section titled “Investigation Methods”
  1. Enumerate All Foreign Security Principals in the Domain: Run Get-ADObject -Filter 'objectClass -eq "foreignSecurityPrincipal"' -Properties memberOf.
  2. Cross-Reference FSPs in High-Privilege Groups: Check for foreign SIDs in Administrators, Account Operators, Backup Operators, and Remote Desktop Users.
  3. Resolve SIDs Against Partner Domain Catalogs: Resolve FSP SIDs against partner DC catalogues or archived NTDS snapshots.

Investigative Tooling

Section titled “Investigative Tooling”
  • PowerShell AD Module:
    Terminal window
    Get-ADObject -SearchBase "CN=ForeignSecurityPrincipals,DC=domain,DC=local" -Filter * -Properties memberOf |
      Select-Object Name, whenCreated, memberOf
  • PowerView:
    Terminal window
    Get-DomainForeignUser
    Get-DomainForeignGroupMember
  • BloodHound Cypher Query: 
    MATCH (f:User)-[:MemberOf]->(g:Group) WHERE f.domain <> g.domain RETURN f, g

Key Takeaways

Section titled “Key Takeaways”
  • FSP objects represent external identities within the local resource domain.
  • Auditing CN=ForeignSecurityPrincipals provides a complete inventory of cross-domain privileges.
  • Only Domain Local groups can contain foreign members across trusts.
  • Group addition Event ID 4732 records the introduction of an FSP into local security groups.

References & Further Reading

Section titled “References & Further Reading”