Assessing Active Directory and Azure AD Connect Environments for Azure PaaS Migration Readiness

Migrating classic on-premises Active Directory (AD) environments—often hosted on virtual machines and synchronized with Azure through Azure AD Connect—into Azure Platform-as-a-Service (PaaS) offerings such as Microsoft Entra ID (formerly Azure AD) and Azure AD Domain Services (Azure AD DS) is a complex undertaking. Success hinges on discovering and remediating any features, configurations, or dependencies in the current AD and AD Connect environment that are not natively supported by Microsoft’s cloud identity services.

This technical guide provides a comprehensive, step-by-step methodology for assessing AD and Azure AD Connect deployments for cloud readiness, focusing specifically on identifying unsupported or problematic features such as forest trusts, schema extensions, authentication protocol usage, advanced delegation models, synchronization rules, and more. Each section explores detection techniques, including PowerShell scripts and tools, and provides detailed analysis of cloud compatibility issues—backed by the latest guidance and extensive source material from technical communities and Microsoft documentation.

Forest Trusts and Trust Relationships

Overview of Forest Trusts in Azure AD DS

In traditional AD, forest and domain trusts allow for resource sharing and authentication across different AD forests or domains. Migrating to Azure AD DS fundamentally changes the trust model. While recent updates made it possible to establish one-way inbound, one-way outbound, and (in preview) two-way forest trusts between Azure AD DS and on-premises AD, there are concrete caveats and limitations:

• Only forest (not domain) trusts are supported.

• External trusts to child domains are not allowed.

• Network connectivity, DNS conditional forwarding, and functional level requirements must be satisfied.

• Changes are explicit and (with exceptions for the preview) irreversible.

Detecting Existing Trusts

To enumerate all current forest and domain trusts in an AD environment:

# Get all domain trusts in the current domain
Get-ADTrust -Filter *

# To view all trusts in a multi-domain/forest environment:
Get-ADForest | Select-Object -ExpandProperty Trusts

# Alternatively, using nltest
nltest /domain_trusts
nltest /trusted_domains

Analysis:

These commands will provide a full list of explicit (bidirectional, incoming, or outgoing), external, and forest-level trusts. Before migrating to Azure AD DS, confirm:

• All trusts are genuinely required (many environments contain legacy or unused trusts).

• Down-level (Windows 2000/2003) or unsupported trust types are identified and flagged for attention, as they will not be migrated into the Azure AD DS managed domain.

• If your environment relies on transitive trust relationships or any special trust paths (such as selective authentication), you must validate whether these are feasible within Azure AD DS.

Forest Trust Migration Summary Table:

Implications:

If your environment has child or domain-level trusts, or is relying on trust transitivity beyond what Azure AD DS supports, you must refactor the trust structure before migration. In addition, plans for mutual name resolution, network routability, and potentially upgrading forest functional levels will be required for successful trust creation.

Active Directory Functional Level Requirements

Importance of Functional Levels

The forest and domain functional levels govern the AD DS features that are available in your environment. Some Azure PaaS features (including Azure AD DS) require minimum functional levels (often Windows Server 2012 or above).

Detection Script

To determine the current functional level:

# Get forest and domain functional levels
Get-ADForest | Select-Object ForestMode
Get-ADDomain | Select-Object DomainMode

Analysis

Organizations running at functional levels below Windows Server 2012 (or in some cases 2016) must raise their domain/forest level prior to Azure AD DS deployment. This generally requires upgrading all domain controllers and demoting any legacy DCs.

Functional Level Matrix (Excerpt):

Note: Raising functional levels cannot be reversed except by restoring from backup.

Schema Extensions and Directory Extensions

Identifying Unsupported Schema Extensions

Azure AD DS does not permit arbitrary schema extensions. While a subset of extension attributes can be synchronized via Azure AD Connect (Directory Extensions or msDS-Attributes), true on-premises-style schema extension—such as adding custom object classes or large-numbered attributes—is prohibited.

Detection of Schema Extensions

To enumerate schema extensions:

# List all custom (non-default) schema classes/attributes
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
-LDAPFilter "(!(isMemberOfPartialAttributeSet=TRUE))" `
-Property lDAPDisplayName, schemaIdGuid, objectClassCategory

# Or, more specifically for OIDs above the standard range
Get-ADObject -LDAPFilter "(attributeID=1.2.840.113556.1.4.*)"

Azure AD Connect Directory Extensions Check

To view all enabled directory extensions:

# PowerShell: Requires Microsoft Graph PowerShell SDK
Get-MgDirectoryObjectAvailableExtensionProperty

# With Entra PowerShell module:
Get-EntraExtensionProperty | Where-Object {$_.AppDisplayName -eq 'Tenant Schema Extension App'}

Analysis

• If business applications rely on custom schema extensions that do not map to the supported extension attributes or directory extensions, those features will not be preserved post-migration.

• Azure AD DS supports syncing up to 100 directory extension attributes (multi-valued attributes have caveats), and the maximum length is 250 (or 256) characters per value.

• Constructed and non-replicated attributes (such as msDS-UserPasswordExpiryTimeComputed, badPwdCount, Last-Logon, etc.) are not synchronized.

• Only string, boolean, integer, and certain binary/binary-multi-valued datatypes are supported, not complex types or application-specific data.

Azure AD Connect Limitations (Sync Rules & Directory Extensions)

Directory Extension Synchronization

Azure AD Connect has explicit limitations:

• Up to 100 directory extension attributes per object (including single/multi-valued attributes).

• Only string, boolean, integer, and binary types are supported.

Checking Custom Sync Rules

Azure AD Connect’s Synchronization Rule Editor exposes all custom and default sync rules. To script and document custom rules, leverage PowerShell and tools like AADConnectConfigDocumenter:

• List All Custom Sync Rules:

# Using MIIS client (installed with Azure AD Connect)
Get-ADSyncRule | Where-Object {$_.Description -like "*custom*"}

# Or export all Sync Rules
Export-AdSyncRuleCollection -Path "C:\SyncRules.xml"

• PowerShell: Azure AD Connect Documenter

  • AzureADAssessment (AADConnectConfigDocumenter)

  • Generates comprehensive HTML reports that highlight custom rules, scoping filters, joins, and transformations.

Analysis

• Any custom sync rules not supported in the cloud (e.g., rules manipulating non-standard objects, complex transformations, or referencing custom attributes not mapped into Azure AD) must be reviewed and rewritten or removed.

• Sync rule precedence and attribute join conflicts should be carefully analyzed, as Azure AD DS will not replicate the same sync logic automatically.

• Directory extension sync is not “schema extension” in the classic AD sense; it enables only a subset of attributes for use in limited scenarios (dynamic group membership, token claims, and a few app integrations).

Authentication Protocols: Legacy and Modern Support

Protocol Compatibility Matrix

Azure AD DS is intended for backward compatibility with on-premises applications requiring NTLM and Kerberos. Microsoft Entra ID (Azure AD) natively supports only modern authentication protocols such as SAML, OAuth 2.0, WS-Federation, and OpenID Connect.

Concluding Recommendations and Next Steps

Before migrating to Azure PaaS:

1. Comprehensively audit all AD/AD Connect features and dependencies using the scripts and tools detailed in each section. Ensure all unsupported features are documented, and mitigation strategies are in place.

2. Upgrade forest and domain functional levels if required, after eliminating incompatible domain controllers.

3. Flatten and clean up trusts, delegations, and group structures to suit the Azure AD DS/Entra ID model.

4. Enable Password Hash Synchronization (PHS) if not already in place to meet Azure AD DS requirements.

5. Remediate all applications using unsupported protocol/authentication mechanisms, and plan for modern authentication migration (SAML, OIDC, OAuth 2.0) where possible.

6. Plan for post-migration governance and security—including reviews of new delegation models, privileged access, and audit logging.

Appendix: Example PowerShell Commands and Tool References

• Enumerate all trust relationships:
  Get-ADForest | Select-Object -ExpandProperty Trusts

• List custom schema attributes:
  Get-ADObject -SearchBase ((Get-ADRootDSE).schemaNamingContext) -LDAPFilter '(isDefunct=FALSE)' | Where-Object {$_.lDAPDisplayName -notmatch '^ms-'}

• Get sync rules (custom and default):
  Get-ADSyncRule | Format-Table Name, Direction, Description

• Check for unconstrained delegation:
  Get-ADComputer -Filter * -Properties TrustedForDelegation | Where-Object {$_.TrustedForDelegation}

• Detect insecure LDAP binds (run on each DC):
  Get-WinEvent -LogName 'Directory Service' -FilterXPath "*[System[(EventID=2889)]]" | Format-List

• List service accounts with SPNs:
  Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName

• Azure AD Assessment & Governance (Microsoft):

  • AzureADAssessment

  • AzureAD-Governance-Assessment

This guide aims to synthesize technical best practices, the latest Microsoft documentation, and the open-source tools and scripts required to confidently assess your AD and Azure AD Connect estate for migration readiness. By systematically addressing all unsupported features and configurations using validated PowerShell scripts for detection and inventory. You will significantly reduce risk and ensure a smoother, more predictable transition to a modern Azure PaaS identity platform.

(*) Legacy protocols in Azure AD DS are discouraged—see below.

Detecting Insecure/Legacy Authentication Use

1. LDAP vs LDAPS Bindings (Plain Text Detection):

   • Enable diagnostic logging for "16 LDAP Interface Events" on all Domain Controllers.

   • PowerShell to identify all non-SSL (insecure) bind attempts:

# Enable logging (run on all DCs)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\" -Name "16 LDAP Interface Events" -Value 2 -Type DWORD

# Get insecure bind events (Event ID 2889)
foreach ($DC in (Get-ADDomainController -Filter *)) {
$Events = Get-WinEvent -ComputerName $DC.HostName -FilterHashtable @{Logname='Directory Service';Id=2889;StartTime=(Get-Date).AddDays(-7)}
foreach ($Event in $Events) {
$xml = [xml]$Event.ToXml()
[PSCustomObject]@{
DC = $DC.HostName
Client = $xml.event.EventData.Data[0]
User = $xml.event.EventData.Data[1]
BindType = if ($xml.event.EventData.Data[2] -eq 0) { "Unsigned" } else { "Simple" }
}
}
}

1. Legacy Protocols (SMTP, IMAP, POP, ActiveSync, MAPI over HTTP):

   • Use Azure Portal: Azure AD → Monitoring → Sign-ins → filter by "Client App" and select all legacy clients.

2. Detecting Apps Using Basic Auth:

   • Same as above, or use Conditional Access Policy in Report-only mode to monitor legacy auth attempts.

Analysis

• Azure AD DS supports most legacy authentication for “lift-and-shift” legacy applications, but Entra ID (Azure AD) does NOT. Migrating applications that require NTLM/Kerberos and integrated Windows authentication requires careful mapping to either Azure AD DS or refactoring to use modern authentication.

• Basic authentication and other insecure protocols are best blocked at the source and must be identified before migration to enforce MFA and conditional access controls.

• LDAP over TCP/389 will eventually be deprecated in favor of LDAPS (SSL/TLS). Applications and devices not supporting LDAPS must be upgraded.

Kerberos Constrained Delegation and Advanced Delegation

Constrained Delegation in Managed Domains

Kerberos delegation allows services to impersonate users to access resources. Constrained delegation restricts which services/resources this applies to. In standard AD, you have both account-based and resource-based constrained delegation (RBCD). In Azure AD DS, only resource-based KCD (Windows Server 2012 and newer) is supported, and only for accounts/resources created in custom OUs (not for those synced from Entra ID).

Detecting Use of Kerberos Delegation

Check for Unconstrained Delegation (Security Risk):

# Find all accounts with unconstrained delegation
Get-ADComputer -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)" -Properties Name, userAccountControl

# Alternatively, for user/service accounts:
Get-ADUser -Filter * -Properties TrustedForDelegation | Where-Object {$_.TrustedForDelegation -eq $true}

Checking for Constrained Delegation (Classic and Resource-Based):

# Constrained delegation:
Get-ADComputer -Filter * -Properties msDS-AllowedToDelegateTo | Where-Object { $_.msDS-AllowedToDelegateTo -ne $null }

# Resource-based constrained delegation:
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity | Where-Object { $_.msDS-AllowedToActOnBehalfOfOtherIdentity -ne $null }

Verifying Delegation Settings on a Given Object:

# For a specific computer:
Get-ADComputer -Identity "WebAppServer" -Properties * | Select-Object Name, msDS-AllowedToDelegateTo, msDS-AllowedToActOnBehalfOfOtherIdentity, TrustedForDelegation, TrustedToAuthForDelegation

Configuring Resource-Based KCD in Azure AD DS

For custom OUs (created in and managed via Azure AD DS), use:

# Example - grant delegation from front-end to back-end
$ImpersonatingAccount = Get-ADComputer -Identity "FrontendServer"
Set-ADComputer -Identity "BackendServer" -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

Analysis and Limitations

• Sync Issues: User and computer accounts synced from Entra ID can’t be targeted for RBCD in Azure AD DS. Only locally created objects in the managed domain can be used.

• No Account-Based Delegation: Account-based classic KCD is not possible, and unconstrained delegation is strongly discouraged (and, on some trust relationships, blocked since 2019 for security reasons).

• Delegation Model Differences: Role-based delegation of permission, such as fine-grained administration of OUs, is reduced—see advanced delegation section below.

Advanced Delegation and Access Control List (ACL) Settings

Delegation in AD vs. Azure AD DS

Traditional Active Directory supports a broad range of delegated administrative permissions on OUs and objects, allowing precise granular delegation of tasks (e.g., password reset, machine join, GPO management) to groups or users.

AD Delegation Discovery

Graphical:

1. Open 'Active Directory Users and Computers' (enable Advanced Features).

2. On an OU → Properties → Security tab → Advanced.

3. Inspect all delegated permissions; export as needed for audit.

PowerShell: List Delegated Permissions for a Given OU:

# Specify DN of the OU
$OU = "OU=Helpdesk,DC=contoso,DC=com"
(Get-ADObject -Identity $OU -Properties ntSecurityDescriptor).ntSecurityDescriptor |
ForEach-Object { $_.Access |
Where-Object { $_.IsInherited -eq $false -and $_.ObjectType -ne [Guid]::Empty } |
Select-Object IdentityReference, ActiveDirectoryRights, ObjectType, InheritanceType }

# To dump all DACLs for users/OUs
Get-ADOrganizationalUnit -Filter * | ForEach-Object {
$ou = $_
(Get-Acl -Path ("AD:\" + $ou.DistinguishedName)).Access |
Select-Object @{Name="OU";Expression={$ou.Name}}, IdentityReference, ActiveDirectoryRights
}

Azure AD DS Delegation Limitations

• Azure AD DS supports only a limited delegation model.

• Only members of the Azure AD DC Administrators group can manage the directory using RSAT; fine-grained delegation (e.g., for helpdesk password resets on select OUs) is not mapped one-to-one from on-prem AD.

• Custom OUs allow some delegation (within the managed domain), but only for objects created inside those OUs after provisioning.

Third-Party Tools

For deep-hierarchy delegated permissions analysis and reporting, consider third-party AD delegated permissions reporting tools (e.g., Netwrix Auditor, PingCastle, or open source PowerShell scripts for ACL enumeration).

Group Scope, Nested Groups, and Membership Limitations

AD Group Models

• Traditional AD supports Domain Local, Global, and Universal Security Groups, with relatively flexible nesting.

• Azure AD DS supports universal and global groups, but with limitations on nesting and token size. Cross-forest, cross-domain group membership is only supported via domain local groups and only if trusts are present.

• Nested groups for access tokens (e.g., group membership claims in tokens for SAML/OIDC) are supported in Azure AD but with both size and usage restrictions.

Detecting Group Structure

# List all groups and their type (scope)
Get-ADGroup -Filter * -Properties GroupScope | Select Name, GroupScope

# Nested group memberships
Get-ADGroup -Identity "Finance Team" -Properties MemberOf

# For groups with more than N members (useful for claim size validation)
Get-ADGroup -Filter * -Properties Members | Where-Object { $_.Members.Count -gt 1000 }

Azure AD Nested Group Limitations Table

Analysis:

• Applications using deep group nesting structures or users members of thousands of groups may encounter token bloat or membership claim limitations in the cloud environment.

• Review and flatten group membership structures if possible.

• Some operations (e.g., licensing via group, group-based roles, etc.) are only supported for direct, not transitive/nested, group memberships in Azure AD.

Service Accounts and Service Principal Names (SPNs)

SPN Analysis

Service accounts and their associated SPNs are heavily used in enterprise AD environments for Kerberos and other integrated authentication scenarios. Azure AD DS supports use of SPNs, but transitioning these to cloud-based identity needs planning.

Detection Script

Enumerate all user/computer objects with registered SPNs:

# List all accounts with at least one SPN
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName | Select Name, ServicePrincipalName
Get-ADComputer -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName | Select Name, ServicePrincipalName

Or use built-in tool:

setspn -Q / # Lists all SPNs in the domain

Analysis

• Service accounts relying on legacy authentication or custom SPNs must be migrated with care.

• For applications requiring SSO via Kerberos/SPNs in Azure AD DS, maintain the accounts and their SPNs in custom OUs.

• Azure AD Service Principals (cloud applications)—used in Entra ID—are managed separately and cannot be directly migrated from classic AD service accounts.

Azure AD Connect Authentication Method Compatibility

Pass-Through Authentication vs. Password Hash Synchronization

Azure AD Connect supports two main authentication sync models: Pass-Through Authentication (PTA) and Password Hash Synchronization (PHS). Azure AD DS currently requires PHS to be enabled for directory synchronization!.

Script to Check Current Sync Method

Import-Module ADSync
Get-ADSyncScheduler | Select-Object PasswordSyncEnabled, StagingModeEnabled

# Check for PTA Connectors:
Get-ADSyncConnector | Where-Object {$_.ConnectorType -eq 'AAD_PASSWORD_SYNC'}

Analysis

• If your environment uses only PTA without PHS, Azure AD DS will not function correctly and you must enable PHS as a fallback or primary method.

• Failover between PTA and PHS is not automatic; operate both in parallel before transitioning.

• Security risks: PTA relies on on-premises agents. Compromise of these agents (particularly the associated certificates) could allow attackers to intercept password traffic or create authentication backdoors.

Application Authentication Protocol Discovery

Identifying Protocols in Use

Many applications continue to use LDAP binds, Kerberos, NTLM, or custom authentication modules. It is critical to discover which applications use legacy authentication before migration.

General Discovery Steps

1. Enable LDAP Bind Logging (Event 2889) to detect who is authenticating over plain LDAP.

2. Survey Application Inventories using Azure Migrate discovery tools or manual audit.

3. Review sign-in logs for legacy authentication attempts (see earlier "Detecting Insecure/Legacy Authentication Use" section).

4. Script to Discover All Computers Using Kerberos Constrained Delegation:

# Looks for msDS-AllowedToDelegateTo attribute
Get-ADComputer -Filter * -Properties msDS-AllowedToDelegateTo | Where-Object { $_.msDS-AllowedToDelegateTo -ne $null } | Select Name, msDS-AllowedToDelegateTo

1. Use AAD Connect Assessment and Governance Tools:

   • Azure AD Assessment module can inventory sync rules, authentication models, configuration drift, and guest/external user settings.

PowerShell Modules and Community Tools for Migration Readiness Assessment

Recommended PowerShell Modules

• Active Directory PowerShell module (Get-AD* cmdlets): For enumeration of users, groups, OUs, trusts, delegation settings, group policy, service accounts, etc.

• SetSPN (Windows Server in-built): To audit, add, remove, and check for duplicate SPNs.

• MSOnline/Entra/AzureAD PowerShell: Deprecated as of mid-October 2025. Use the [Microsoft Graph PowerShell SDK] or [Microsoft Entra PowerShell] instead.

• AADConnectConfigDocumenter: To export, diff, and document Azure AD Connect configurations—including custom sync rules, filters, and attribute flows.

• PingCastle: Open-source security auditor for Active Directory with in-depth delegation, trust, and protocol usage analysis.

• InvokeADCheck: PowerShell-based tool to detect misconfiguration in AD, including delegation flaws, protocol configuration, and account issues.

• ADFS to AzureAD App Migration Tool (Microsoft GitHub): For analyzing ADFS configuration and migration compatibility to Entra ID.

Migration Assessment Automation Scripting

• Automated Reporting:

  • Use PowerShell to export all enumerated AD data (trusts, groups, OUs, service accounts, ACLs, schema extensions).

  • Pipe outputs into files for review, or directly into security assessment/reporting tools (e.g., PowerBI).

Summary Table: Key AD/ADConnect Features and Cloud Support