4.4 Group Policy in Microsoft Entra Domain Services & Fine-Grained Password Policies

Group Policy in Microsoft Entra Domain Services & Fine-Grained Password Policies

Modern hybrid enterprises frequently combine on-premises Active Directory Domain Services (AD DS) with Microsoft Entra Domain Services (a managed PaaS domain service providing Kerberos, NTLM, LDAP, and Group Policy compatibility in Azure). While traditional on-premises AD DS grants enterprise administrators full domain-level autonomy, Entra Domain Services enforces strict administrative boundaries to maintain managed platform integrity.

Simultaneously, securing identity infrastructure requires granular password and lockout governance. Traditional AD DS enforced a single domain-wide password policy via the Default Domain Policy. Fine-Grained Password Policies (FGPP) overcome this constraint by introducing Password Settings Objects (PSOs), allowing organizations to enforce strict password lengths and lockout thresholds for privileged accounts while maintaining standard baselines for general users.

1. Group Policy in Microsoft Entra Domain Services

In a Microsoft Entra Domain Services managed domain, domain controllers are deployed, patched, and managed entirely by Microsoft as a platform service. Administrators do not have access to domain controller VMs via RDP or SSH and are never granted Domain Admins or Enterprise Admins credentials.

+-----------------------------------------------------------------------------------+
|            ENTRA DOMAIN SERVICES OU LAYOUT & GPO PERMISSION BOUNDARIES            |
|                                                                                   |
|  [Managed Domain Root: DC=aadds,DC=contoso,DC=com]                                |
|   * Managed DCs: no sign-in. Never Domain / Enterprise / Schema Admins *          |
|   |   Managed domains are FLAT: every OU below hangs off the root.                |
|   |                                                                               |
|   +-- [Built-in: AADDC Computers]   <- domain-joined VMs land here                |
|   |      Linked GPO: AADDC Computers GPO   (edited in place)                      |
|   |                                                                               |
|   +-- [Built-in: AADDC Users]       <- users/groups synced from Entra ID          |
|   |      Linked GPO: AADDC Users GPO       (edited in place)                      |
|   |      Objects here CANNOT be moved into a custom OU.                           |
|   |                                                                               |
|   +-- [Custom OU: OU=WebServers]    <- created AT THE ROOT, not nested            |
|   |      Linked GPO: Custom-WebServer-GPO  (created + linked by admins)           |
|   |                                                                               |
|   +-- [Custom OU: OU=AppServiceAccounts]                                          |
|          Linked GPO: Custom-SvcAcct-GPO                                           |
+-----------------------------------------------------------------------------------+

Built-In GPOs & Delegation:

Entra Domain Services provides two built-in GPOs linked to the two default root containers:

1. AADDC Computers GPO: Linked to the OU=AADDC Computers container. Configures baseline computer settings for domain-joined VMs.
2. AADDC Users GPO: Linked to the OU=AADDC Users container. Configures baseline user environment settings.

Members of the AAD DC Administrators group have delegated permissions to edit these two built-in GPOs.

Platform Constraints & Custom GPO Linking:

• No domain controller access: Microsoft deploys, patches, and owns the two managed DCs. You cannot sign in to them to perform management tasks, and AAD DC Administrators is never granted Domain Admins, Enterprise Admins, or Schema Admins. Every task runs remotely from a domain-joined management VM.
• Custom OUs live at the domain root: Managed domains use a flat OU structure. The documented flow creates a custom OU directly under the domain — OU=WebServers,DC=aadds,DC=contoso,DC=com — and not as a child of OU=AADDC Computers or OU=AADDC Users.
• Custom GPOs: Members of AAD DC Administrators hold Group Policy administration privileges: they edit the two built-in GPOs in place, and they create custom GPOs and link them to the custom OUs they create.
• Objects cannot leave AADDC Users: Users and groups synchronized from Microsoft Entra ID stay in AADDC Users. Only accounts and resources created directly in the managed domain — typically application service accounts — can be moved into a custom OU.

[!WARNING] Exam trap: the tempting answer is to nest a child OU beneath OU=AADDC Computers and link the GPO there. The documented model is the opposite — create the custom OU at the domain root and link the custom GPO to it. Equally, an on-premises OU hierarchy and on-premises GPOs are never synchronized into a managed domain.

2. Remote Management Workflow via RSAT

Because direct access to managed domain controllers is restricted, all Group Policy authoring, OU configuration, and DNS management in Microsoft Entra Domain Services must be performed remotely from a domain-joined management workstation or Azure IaaS VM.

# Step 1: Install Remote Server Administration Tools (RSAT) on Azure IaaS Management VM
Install-WindowsFeature -Name RSAT-AD-Tools, GPMC -IncludeManagementTools

# Step 2: Verify Group Policy Management Module is Available
Get-Command -Module GroupPolicy

# Step 3: Create a Custom OU AT THE DOMAIN ROOT. Managed domains are flat --
#         do NOT nest the OU under OU=AADDC Computers.
$DomainDN = (Get-ADDomain).DistinguishedName
New-ADOrganizationalUnit -Name "WebServers" `
    -Path $DomainDN `
    -ProtectedFromAccidentalDeletion $true

# Step 4: Create a New Custom GPO and Link it to the Custom OU
$Gpo = New-GPO -Name "GPO_WebServers_SecurityBaseline" -Comment "Hardening for Web Tier VMs"
New-GPLink -Name $Gpo.Name -Target "OU=WebServers,$DomainDN" -LinkOrder 1

# Step 5: Move a managed-domain computer object into the custom OU.
# Objects synced from Entra ID into AADDC Users cannot be moved this way.
Get-ADComputer -Identity "WEBVM01" | Move-ADObject -TargetPath "OU=WebServers,$DomainDN"

Management Prerequisites:

1. Deploy a Windows Server Azure VM in a virtual network that has network line-of-sight and DNS resolution to the Entra Domain Services managed domain.
2. Join the VM to the managed domain (e.g., aadds.contoso.com).
3. Sign in using an account that is a member of the AAD DC Administrators group.
4. Open the Group Policy Management Console (gpmc.msc) or Active Directory Administrative Center (dsac.exe) to manage policies.

3. Fine-Grained Password Policies (FGPP) & Password Settings Objects (PSOs)

In standard Active Directory Domain Services, password complexity, minimum length, and lockout policies defined in the Default Domain Policy apply globally to all domain users. Historically, enforcing stronger password requirements for administrators required creating entirely separate Active Directory domains.

Fine-Grained Password Policies (FGPP) resolve this limitation by allowing multiple distinct password and account lockout policies to be defined within a single domain using Password Settings Objects (PSOs).

+-----------------------------------------------------------------------------------+
|                 FINE-GRAINED PASSWORD POLICIES (PSO) ARCHITECTURE                 |
|                                                                                   |
|  Active Directory Database (NTDS.DIT)                                             |
|  Path: CN=Password Settings Container,CN=System,DC=corp,DC=contoso,DC=com         |
|  Object Class: msDS-PasswordSettings                                              |
|                                                                                   |
|  +-------------------------------------+  +------------------------------------+  |
|  | PSO: PSO-Privileged-Admins          |  | PSO: PSO-Standard-Users            |  |
|  | - Precedence: 10                    |  | - Precedence: 50                   |  |
|  | - MinPasswordLength: 16             |  | - MinPasswordLength: 12            |  |
|  | - PasswordHistory: 24               |  | - PasswordHistory: 12              |  |
|  | - LockoutThreshold: 3 attempts      |  | - LockoutThreshold: 5 attempts     |  |
|  | - LockoutDuration: 30 mins          |  | - LockoutDuration: 15 mins         |  |
|  | - Applied To: SG-Domain-Admins      |  | - Applied To: SG-Standard-Users    |  |
|  +-------------------------------------+  +------------------------------------+  |
+-----------------------------------------------------------------------------------+

Critical Scope Rule — Why PSOs Do Not Apply to OUs:

[!IMPORTANT] PSOs Cannot Be Applied to Organizational Units (OUs): PSOs apply strictly to User objects and Global / Universal Security Groups via the msDS-PSOAppliesTo attribute. Linking or assigning a PSO to an Organizational Unit has zero effect and will not protect users inside that OU. This is one of the most heavily tested concepts on the AZ-800 exam.

Comparison: Default Domain Password Policy vs. Fine-Grained Password Policies (PSOs)

4. PSO Attributes, Precedence & Conflict Resolution Rules

When multiple PSOs are created within a domain, a user account might be assigned a direct PSO while simultaneously belonging to multiple security groups that each have different PSOs assigned. Active Directory uses a deterministic 4-step algorithm to calculate the Resultant Password Policy:

+-----------------------------------------------------------------------------------+
|                       PSO PRECEDENCE RESOLUTION ALGORITHM                         |
|                                                                                   |
|  [EVALUATION STEP 1: Direct User Assignment]                                      |
|   - Does the user account have a PSO assigned directly to its object?             |
|     --> YES: That PSO WINS IMMEDIATELY (Overrides ALL group PSOs).                |
|     --> NO:  Proceed to Step 2.                                                   |
|                                                                                   |
|  [EVALUATION STEP 2: Group Assignment Precedence Number]                          |
|   - Is the user a member of one or more groups with assigned PSOs?                |
|     --> Compare the 'msDS-PasswordSettingsPrecedence' integer on each group PSO.  |
|     --> The PSO with the LOWEST NUMERIC VALUE (e.g., 10 beats 20) WINS.           |
|                                                                                   |
|  [EVALUATION STEP 3: Tie-Breaker by Object GUID]                                  |
|   - If multiple group PSOs share the exact same precedence number:                |
|     --> The PSO with the lowest binary/alphabetical objectGUID WINS.              |
|                                                                                   |
|  [EVALUATION STEP 4: Default Domain Policy Fallback]                              |
|   - If NO PSOs are assigned directly or through group membership:                 |
|     --> The domain-wide Default Domain Policy applies.                            |
+-----------------------------------------------------------------------------------+

Key PSO Attributes (msDS-PasswordSettings Schema):

• msDS-PasswordSettingsPrecedence: Integer value determining priority (e.g., 10).
• msDS-PasswordReversibleEncryptionEnabled: Boolean ($false standard).
• msDS-PasswordHistoryLength: Number of past passwords remembered (e.g., 24).
• msDS-PasswordComplexityEnabled: Enforces 3 of 4 complexity categories (uppercase, lowercase, digits, symbols).
• msDS-MinimumPasswordLength: Minimum character length (e.g., 16).
• msDS-MinimumPasswordAge: Time before a user can change their password again (e.g., 1.00:00:00 for 1 day, preventing rapid cycling through history).
• msDS-MaximumPasswordAge: Password validity lifespan before expiration (e.g., 60.00:00:00 for 60 days).
• msDS-LockoutThreshold: Number of failed logon attempts before account lockout (e.g., 5).
• msDS-LockoutObservationWindow: Time window for tracking bad attempts (e.g., 00:30:00 for 30 minutes).
• msDS-LockoutDuration: Lockout duration (e.g., 00:30:00 for 30 minutes; 0 requires administrator unlock).

5. PowerShell Management of Fine-Grained Password Policies

Active Directory PowerShell module provides dedicated cmdlets to create, configure, link, and evaluate PSOs without requiring legacy ADSI Edit.

# 1. Create a New Fine-Grained Password Policy for Privileged Administrators
New-ADFineGrainedPasswordPolicy -Name "PSO-Privileged-Admins" `
    -Precedence 10 `
    -ComplexityEnabled $true `
    -MinPasswordLength 16 `
    -PasswordHistoryCount 24 `
    -MinPasswordAge "1.00:00:00" `
    -MaxPasswordAge "60.00:00:00" `
    -LockoutThreshold 3 `
    -LockoutObservationWindow "00:30:00" `
    -LockoutDuration "00:30:00" `
    -ProtectedFromAccidentalDeletion $true

# 2. Assign the PSO to a Global Security Group
Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-Privileged-Admins" `
    -Subjects "SG-Tier1-Admins", "SG-Domain-Admins"

# 3. Create a Secondary PSO for Service Accounts with Lower Precedence (Higher Number)
New-ADFineGrainedPasswordPolicy -Name "PSO-Service-Accounts" `
    -Precedence 50 `
    -ComplexityEnabled $true `
    -MinPasswordLength 20 `
    -PasswordHistoryCount 12 `
    -MinPasswordAge "00:00:00" `
    -MaxPasswordAge "180.00:00:00" `
    -LockoutThreshold 0 # No lockout for service accounts

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-Service-Accounts" `
    -Subjects "SG-App-ServiceAccounts"

# 4. CRITICAL DIAGNOSTIC: Evaluate the Resultant Password Policy for a Specific User
Get-ADUserResultantPasswordPolicy -Identity "ranchen"

# Output displays the winning PSO details:
# Name                         : PSO-Privileged-Admins
# Precedence                   : 10
# ComplexityEnabled            : True
# MinPasswordLength            : 16
# LockoutThreshold             : 3

[!TIP] Troubleshooting Effective Password Policies: When diagnosing why a user account was locked out prematurely or why an administrator cannot set an 8-character password, always execute Get-ADUserResultantPasswordPolicy -Identity <username>. If the cmdlet returns $null, the user is governed by the domain-wide Default Domain Policy GPO.