2.1 Managing Users, Groups & Objects in Multi-Domain and Multi-Forest Environments

Managing Users, Groups & Objects in Multi-Domain and Multi-Forest Environments

In enterprise Active Directory Domain Services (AD DS) deployments, identity and access management rests upon the proper configuration and lifecycle governance of security principals. A security principal is any entity that can be authenticated by the operating system and assigned permissions to access resources. Security principals include user accounts, computer accounts, and security groups. Each security principal is assigned an immutable, unique Security Identifier (SID) composed of a domain identifier and a Relative Identifier (RID).

When designing and administering complex multi-domain and multi-forest architectures, systems administrators must master group scopes, nesting strategies, cross-boundary object mapping, administrative toolsets, and disaster recovery mechanisms such as the Active Directory Recycle Bin.

---

1. AD DS Security Principals & Group Types

Active Directory distinguishes between two fundamental group types:

1. Security Groups: Assigned a unique SID and can be listed in Discretionary Access Control Lists (DACLs) to grant or deny permissions to file shares, printers, registry keys, and Active Directory objects. Security groups can also be mail-enabled in Microsoft Exchange or Exchange Online environments for email distribution.
2. Distribution Groups: Lack a SID and cannot be used in DACLs. They are strictly utilized by email systems (such as Exchange Server) to send messages to collections of recipients.

+-----------------------------------------------------------------------------------+
|                         ACTIVE DIRECTORY GROUP SCOPES                             |
|                                                                                   |
|  [DOMAIN LOCAL GROUP]                                                             |
|   - Purpose: Assign permissions to resources in the LOCAL domain.                 |
|   - Members: Users, Global Groups, Universal Groups from ANY domain in forest,    |
|              plus trusted external forest accounts (Foreign Security Principals). |
|   - Scope of Permissions: Local domain only.                                      |
|                                                                                   |
|  [GLOBAL GROUP]                                                                   |
|   - Purpose: Group users/computers sharing common business roles or job functions.|
|   - Members: Users and Global Groups from the SAME domain only.                   |
|   - Scope of Permissions: ANY domain in the forest or trusting external forests.  |
|                                                                                   |
|  [UNIVERSAL GROUP]                                                                |
|   - Purpose: Aggregate Global Groups across multiple domains for enterprise roles.|
|   - Members: Users, Global Groups, Universal Groups from ANY domain in forest.    |
|   - Scope of Permissions: ANY domain in the forest or trusting external forests.  |
|   - Replication: Membership is stored in the GLOBAL CATALOG (GC).                 |
+-----------------------------------------------------------------------------------+

---

2. Group Scopes: Membership, Conversion & Replication Impact

The three group scopes—Domain Local, Global, and Universal—serve distinct architectural purposes in single-domain and multi-domain environments.

Comprehensive Group Scope Comparison

Group Scope Conversion Rules

Active Directory permits converting group scopes under specific constraints, provided the functional level is at least Windows 2000 Native or higher:

• Global to Universal: Allowed only if the Global group is not a member of any other Global group.
• Domain Local to Universal: Allowed only if the Domain Local group does not contain another Domain Local group.
• Universal to Global: Allowed only if the Universal group does not contain another Universal group or members from another domain.
• Universal to Domain Local: Allowed only if the Universal group is not a member of any other Domain Local group.
• Global directly to Domain Local (or vice versa): Prohibited. Must first convert to Universal as an intermediate step.

Global Catalog and Replication Considerations

Because Universal group memberships are stored in the Global Catalog (GC), any modification to a Universal group's membership causes the entire membership attribute to replicate to every Global Catalog server across the entire multi-domain forest.

In contrast, modifications to Global or Domain Local group memberships replicate only to domain controllers within the group's local domain. Therefore, placing individual user accounts directly into Universal groups creates unnecessary wide-area network (WAN) replication overhead. The best practice is to place users into Global groups, and nest those Global groups into Universal groups, as Global group membership changes do not trigger forest-wide GC replication.

[!TIP] Universal Group Membership Caching (UGMC): In branch offices with domain controllers that do not host the Global Catalog role, enable Universal Group Membership Caching (UGMC) on the branch site. During initial user logon, the local DC queries a remote GC for the user's Universal group memberships and caches the token locally, allowing subsequent logons even across WAN outages without requiring a full local GC deployment.

---

3. Group Nesting Strategies: AGDLP and AGUDLP

To enforce the principle of least privilege and streamline access governance, Microsoft establishes standardized role-based group nesting models:

+-----------------------------------------------------------------------------------+
|                 AGUDLP NESTING ARCHITECTURE (MULTI-DOMAIN)                        |
|                                                                                   |
|  [A] Accounts       --> User objects (e.g., alice@na.contoso.com)                 |
|        |                                                                          |
|        v                                                                          |
|  [G] Global Group   --> Domain-specific role (e.g., G_NA_FinancialAuditors)       |
|        |                                                                          |
|        v                                                                          |
|  [U] Universal Group--> Forest-wide role (e.g., U_Enterprise_Auditors)            |
|        |                                                                          |
|        v                                                                          |
|  [DL] Domain Local  --> Resource permission group (e.g., DL_FinanceShare_Read)   |
|        |                                                                          |
|        v                                                                          |
|  [P] Permissions    --> Assigned to Access Control List (ACL) on File Share      |
+-----------------------------------------------------------------------------------+

AGDLP (Single-Domain Environments)

1. A (Accounts): User and computer accounts are created in their respective organizational units.
2. G (Global Groups): Accounts are placed into Global groups that represent business roles (e.g., G_MarketingStaff).
3. DL (Domain Local Groups): Domain Local groups are created to represent specific access permissions on specific resources (e.g., DL_MarketingShare_Modify).
4. P (Permissions): Permissions (Read, Modify, Full Control) are assigned to the Domain Local group on the resource's NTFS/Share DACL.
5. The Global group G_MarketingStaff is added as a member of DL_MarketingShare_Modify.

AGUDLP (Multi-Domain Forest Environments)

In multi-domain enterprises, the Universal group tier is added:

• Accounts in Domain A are placed into Global Group A (G_DomainA_Engineers).
• Accounts in Domain B are placed into Global Group B (G_DomainB_Engineers).
• Both Global groups are nested into a single Universal Group (U_Enterprise_Engineers).
• The Universal group is added to the Domain Local group in the resource domain (DL_CadFiles_ReadWrite).
• Permissions are assigned exclusively to DL_CadFiles_ReadWrite.

Key Benefit: When an employee joins or leaves a team, administrators only update membership in the user's local Global group. Resource ACLs never need modification, preventing token bloat and eliminating cross-domain administrative churn.

---

4. Cross-Forest Object Administration & Security

When two separate Active Directory forests establish a trust relationship (e.g., Forest Trust), administrators can grant access to resources in Forest B for users located in Forest A.

Foreign Security Principals (FSPs)

When a user or group from a trusted external forest is added to a Domain Local group in the trusting domain, Active Directory creates a Foreign Security Principal (FSP) object in the CN=ForeignSecurityPrincipals,DC=domain,DC=com container. The FSP stores the external object's foreign SID.

SID History and SID Filtering

During domain migrations using tools such as the Active Directory Migration Tool (ADMT), user and group accounts are migrated to a new target domain while retaining their historical SIDs in the sIDHistory attribute. This allows users to retain access to legacy resources without immediate ACL re-permissioning.

[!WARNING] SID Filtering on Forest Trusts: By default, cross-forest trusts enable SID Filtering (quarantining). SID Filtering strips any foreign SID from the Kerberos authorization data (PAC) that does not match the relative domain identifier of the trusted domain. This prevents malicious domain administrators in a trusted domain from injecting well-known privileged SIDs (such as Enterprise Admins S-1-5-21-...-519) into a user's sIDHistory to gain unauthorized access in the trusting forest.

---

5. Active Directory Administrative Center (ADAC) & PowerShell Automation

The Active Directory Administrative Center (ADAC) provides an administrative GUI built entirely on top of the ActiveDirectory PowerShell module. ADAC introduces advanced capabilities:

• PowerShell History Viewer: Displays the exact PowerShell cmdlets generated by every GUI operation in ADAC, providing an ideal mechanism for building automation scripts.
• Dynamic Access Control (DAC): Enables centralized claim-based authorization policies.
• Fine-Grained Password Policies (FGPP): Allows creating and assigning Password Settings Objects (PSOs) to specific users and global security groups without requiring separate domain boundaries.

Core PowerShell ActiveDirectory Cmdlets

# 1. Create a new department User account
New-ADUser -Name "Marcus Vance" `
           -SamAccountName "mvance" `
           -UserPrincipalName "mvance@contoso.com" `
           -AccountPassword (ConvertTo-SecureString "P@ssw0rd2026!" -AsPlainText -Force) `
           -Enabled $true `
           -Department "Finance" `
           -Path "OU=Finance,OU=Users,DC=contoso,DC=com"

# 2. Create Global and Domain Local groups
New-ADGroup -Name "G_Finance_Users" `
            -GroupScope Global `
            -GroupCategory Security `
            -Path "OU=Groups,DC=contoso,DC=com"

New-ADGroup -Name "DL_LedgerShare_Modify" `
            -GroupScope DomainLocal `
            -GroupCategory Security `
            -Path "OU=Groups,DC=contoso,DC=com"

# 3. Nest user into Global Group, and Global Group into Domain Local Group
Add-ADGroupMember -Identity "G_Finance_Users" -Members "mvance"
Add-ADGroupMember -Identity "DL_LedgerShare_Modify" -Members "G_Finance_Users"

# 4. Enumerate recursive group membership
Get-ADGroupMember -Identity "DL_LedgerShare_Modify" -Recursive | Select-Object Name, SamAccountName

# 5. Identify inactive accounts for security auditing
Search-ADAccount -AccountInactive -TimeSpan (New-TimeSpan -Days 90) -UsersOnly | `
    Select-Object Name, LastLogonDate, DistinguishedName

---

6. Active Directory Recycle Bin Lifecycle

The Active Directory Recycle Bin allows administrators to recover deleted objects without restoring backups from system state media or restarting domain controllers in Directory Services Restore Mode (DSRM).

+-----------------------------------------------------------------------------------+
|                    ACTIVE DIRECTORY OBJECT DELETION LIFECYCLE                     |
|                                                                                   |
|   [1. LIVE OBJECT]                                                                |
|          |                                                                        |
|          | Object is deleted by administrator                                     |
|          v                                                                        |
|   [2. DELETED OBJECT STATE]                                                       |
|          - Moved to 'CN=Deleted Objects,DC=contoso,DC=com'                        |
|          - Retains ALL attributes, group memberships, and SIDs                    |
|          - Remains for msDS-deletedObjectLifetime (Default: 180 days)             |
|          - CAN BE RESTORED WITH ONE POWERSHELL COMMAND                            |
|          |                                                                        |
|          | msDS-deletedObjectLifetime expires                                     |
|          v                                                                        |
|   [3. RECYCLED OBJECT STATE]                                                      |
|          - Most attributes are stripped (only GUID, SID, isRecycled remain)       |
|          - Stays in CN=Deleted Objects for tombstoneLifetime (Default: 180 days)   |
|          - CANNOT BE RESTORED VIA RECYCLE BIN (Requires authoritative backup)     |
|          |                                                                        |
|          | tombstoneLifetime expires                                              |
|          v                                                                        |
|   [4. PERMANENT PHYSICAL REMOVAL]                                                 |
|          - Garbage collection process removes record from NTDS.dit database       |
+-----------------------------------------------------------------------------------+

Enabling and Operating AD Recycle Bin

To enable the AD Recycle Bin, the forest functional level must be at least Windows Server 2008 R2 or higher. Enabling the feature is irreversible.

# Enable AD Recycle Bin across the forest
Enable-ADOptionalFeature -Identity "Recycle Bin Feature" `
                         -Scope ForestOrConfigurationSet `
                         -Target "contoso.com"

# Search for deleted user objects
Get-ADObject -Filter 'isDeleted -eq $true -and name -like "Marcus*"' `
             -IncludeDeletedObjects `
             -Properties distinguishedName, lastKnownParent, sAMAccountName

# Restore deleted object with full original attributes and group memberships
Get-ADObject -Filter 'isDeleted -eq $true -and sAMAccountName -eq "mvance"' `
             -IncludeDeletedObjects | `
             Restore-ADObject