Active Directory and Entra ID Configuration for Copilot: Pre-Deployment Requirements

A global manufacturing company deployed Microsoft 365 Copilot to 500 pilot users and immediately received complaints: "Copilot says it can't find any documents about Project Phoenix, but I know there are hundreds of them in SharePoint." The IT team verified SharePoint permissions were correct, DLP policies were configured properly, and users had appropriate licenses. The issue persisted for three weeks until a consultant discovered the root cause: Azure AD Connect was synchronizing users but not nested security groups, meaning that SharePoint permissions granted to "Project Phoenix Team" (a nested group) weren't being honored by Copilot.

The remediation required reconfiguring Azure AD Connect to sync nested groups, forcing a full directory sync, and waiting 48 hours for permissions to propagate throughout Microsoft 365. Total cost: $47,000 in consultant fees, lost productivity, and emergency infrastructure changes. The issue could have been prevented with proper Entra ID configuration validation before deployment.

Identity and access management is the foundation of Microsoft 365 Copilot security. When configured correctly, Entra ID (formerly Azure Active Directory) ensures Copilot respects permission boundaries, honors conditional access policies, and provides audit trails for compliance. When misconfigured, Entra ID creates invisible failures: queries return no results, users access data they shouldn't, or authentication loops prevent Copilot from launching.

This guide provides comprehensive technical requirements for configuring Entra ID and hybrid identity for Copilot deployment, including validation scripts, troubleshooting procedures, and common failure modes.

Understanding Entra ID vs. Active Directory

Before diving into configuration requirements, understand the relationship between on-premises Active Directory and cloud-based Entra ID.

Active Directory (On-Premises)

Active Directory Domain Services (AD DS) has been the identity backbone for Windows environments for 20+ years:

• Centralized user authentication and authorization
• Group Policy management for Windows devices
• LDAP directory for user, computer, and group objects
• Kerberos authentication protocol

Key Characteristics:

• On-premises infrastructure (domain controllers)
• Full control over schema and configuration
• Low latency for on-premises resources
• No native cloud application support

Azure Active Directory / Entra ID (Cloud)

Microsoft Entra ID (rebranded from Azure AD in 2023) is the cloud-native identity platform for Microsoft 365:

• Cloud-based user authentication and authorization
• OAuth 2.0 and OpenID Connect protocols
• Native integration with SaaS applications
• Conditional access policies for modern security

Key Characteristics:

• Cloud-hosted service (no infrastructure to manage)
• Limited schema customization
• Global scale and availability
• Designed for cloud and mobile applications

Hybrid Identity: Connecting AD and Entra ID

Most enterprises operate in hybrid mode: on-premises Active Directory for legacy systems, Entra ID for cloud services. Azure AD Connect synchronizes identity data between the two environments.

What Azure AD Connect Synchronizes:

• User accounts (username, display name, email, attributes)
• Security groups (group membership, nesting)
• Password hashes (for password hash synchronization) or authentication tokens (for pass-through authentication)
• Device objects (for hybrid Azure AD join)

What Copilot Requires from Hybrid Identity:

• User accounts synchronized: Copilot authenticates against Entra ID, so on-premises users must be synced
• Security groups synchronized: SharePoint and Teams permissions often use on-premises groups, so group membership must be accurate in Entra ID
• Nested groups supported: If on-premises uses nested groups (Group A contains Group B, Group B has permissions), nesting must sync to Entra ID
• Consistent UPNs: User Principal Names must match between on-premises AD and Entra ID (user@company.com, not user@company.local)

Most Common Copilot Identity Failure: Azure AD Connect configured to sync users but not groups, or to sync groups but not nested membership. Result: Copilot can't resolve permissions correctly, leading to "access denied" or "no results" errors.

Azure AD Connect: Configuration Requirements for Copilot

If your organization uses hybrid identity, Azure AD Connect configuration is critical.

Prerequisite: Verify Azure AD Connect is Installed and Healthy

Check Azure AD Connect status:

# Connect to Azure AD (Entra ID)
Connect-AzureAD

# Check directory synchronization status
$syncStatus = Get-AzureADTenantDetail | Select-Object -ExpandProperty CompanyInformation
Write-Output "Directory sync enabled: $($syncStatus.DirectorySynchronizationEnabled)"
Write-Output "Last sync time: $($syncStatus.DirSyncServiceAccount)"

# Get detailed sync status (run on Azure AD Connect server)
Import-Module ADSync
Get-ADSyncScheduler | Format-List

# Check for sync errors
Get-ADSyncCSObject -ConnectorName "company.com" |
    Where-Object {$_.Error -ne $null} |
    Select-Object DistinguishedName, Error

Pass Criteria:

• Directory sync enabled: True
• Last sync within past 30 minutes (default sync cycle is every 30 minutes)
• No sync errors for users or groups that will use Copilot

Common Issues:

• Sync not running (Azure AD Connect service stopped or failed)
• Sync errors due to duplicate attributes (conflicting proxyAddresses or UserPrincipalNames)
• Firewall blocking outbound HTTPS to Azure AD endpoints

Configuration 1: Sync All Security Groups

Verify that Azure AD Connect is configured to sync all security groups, not just specific OUs.

Check current sync scope:

# On Azure AD Connect server, check sync scope
Import-Module ADSync
Get-ADSyncConnectorPartition -Connector "company.com" |
    Select-Object Name, IncludedContainers, ExcludedContainers

# List all synced groups
Get-ADSyncCSObject -ConnectorName "company.com" -SearchType ContainsAny -SearchValue "group" |
    Select-Object DistinguishedName, ObjectType

Recommended Configuration:

• Sync all OUs containing security groups used for SharePoint, Teams, or OneDrive permissions
• Do not exclude distribution groups (Copilot may need to resolve membership for email-based permissions)
• Include nested groups explicitly

How to Expand Sync Scope (if groups are excluded):

1. Open Azure AD Connect configuration wizard (run as administrator)
2. Select "Customize synchronization options"
3. Navigate to "Filter domains and OUs"
4. Ensure all OUs containing relevant groups are selected
5. Complete wizard and trigger full sync:

Start-ADSyncSyncCycle -PolicyType Initial

Warning: Full sync can take hours in large directories (100K+ objects). Schedule during maintenance window.

Configuration 2: Enable Nested Group Membership Sync

Nested groups are groups that contain other groups as members. Example:

• "Project Phoenix Team" (parent group, has SharePoint permissions)
• "Phoenix-Engineering" (child group, members are engineers)
• User "Alice" is member of Phoenix-Engineering

For Copilot to recognize Alice has permissions via Project Phoenix Team, Azure AD Connect must sync nested group membership.

Verify nested group sync is enabled:

# Check if nested groups are syncing correctly
Import-Module AzureAD
Connect-AzureAD

# Test a known nested group scenario
$parentGroup = Get-AzureADGroup -Filter "DisplayName eq 'Project Phoenix Team'"
$members = Get-AzureADGroupMember -ObjectId $parentGroup.ObjectId -All $true

# Check if child groups appear in membership
$childGroups = $members | Where-Object {$_.ObjectType -eq "Group"}
Write-Output "Child groups in parent: $($childGroups.Count)"

# For each child group, verify members are synced
foreach ($childGroup in $childGroups) {
    $childMembers = Get-AzureADGroupMember -ObjectId $childGroup.ObjectId -All $true
    Write-Output "Group $($childGroup.DisplayName) has $($childMembers.Count) members"
}

Common Problem: Azure AD Connect syncs parent group and child group separately, but doesn't establish parent-child relationship in Entra ID. Result: SharePoint sees "Project Phoenix Team" has 0 direct members, doesn't expand nested groups.

Solution: Ensure Azure AD Connect synchronization rules include nested group membership. This typically requires custom sync rules:

1. Open Synchronization Rules Editor (installed with Azure AD Connect)
2. Find rule "In from AD - Group Join" (or similar)
3. Verify "member" attribute is included in attribute flow
4. If not present, add custom sync rule:

Source Attribute: member
Destination Attribute: member
Flow Type: Direct

1. Trigger full sync after rule change

Alternative Solution: Microsoft recommends flattening nested groups for cloud services if possible. Create "Project Phoenix Team - All Members" group with all users as direct members (no nesting). This is more reliable for Copilot but requires group management process changes.

Configuration 3: User Principal Name Consistency

Copilot authenticates users via Entra ID using their User Principal Name (UPN). If UPN is inconsistent between on-premises AD and Entra ID, authentication fails or permissions don't resolve correctly.

Common UPN Mismatch Scenarios:

• On-premises: user@company.local (non-routable domain)
• Entra ID: user@company.com (verified domain)

Azure AD Connect can sync accounts with mismatched UPNs, but this creates issues:

• User logs into Windows as user@company.local
• User logs into Microsoft 365 as user@company.com
• SharePoint permissions granted to user@company.local aren't recognized in Entra ID

Verify UPN Consistency:

# On-premises AD
Import-Module ActiveDirectory
Get-ADUser -Filter * -Properties UserPrincipalName |
    Where-Object {$_.UserPrincipalName -notmatch "@company.com$"} |
    Select-Object SamAccountName, UserPrincipalName

# Entra ID
Connect-AzureAD
Get-AzureADUser -All $true |
    Where-Object {$_.UserPrincipalName -notmatch "@company.com$"} |
    Select-Object DisplayName, UserPrincipalName

Remediation:

1. Standardize on routable domain (company.com, not company.local)
2. Update on-premises AD UPNs:

# Bulk update UPNs in on-premises AD
Import-Module ActiveDirectory
$users = Get-ADUser -Filter {UserPrincipalName -like "*@company.local"}

foreach ($user in $users) {
    $newUPN = $user.SamAccountName + "@company.com"
    Set-ADUser -Identity $user -UserPrincipalName $newUPN
    Write-Output "Updated: $($user.SamAccountName) to $newUPN"
}

1. Force Azure AD Connect sync to update Entra ID:

Start-ADSyncSyncCycle -PolicyType Delta

1. Verify users can log in with new UPN

Timeline: Allow 2-4 hours for UPN changes to propagate through Microsoft 365. Users may need to sign out and back in.

Configuration 4: Password Synchronization or Pass-Through Authentication

Copilot requires users to authenticate to Entra ID. Two primary hybrid authentication methods:

Password Hash Synchronization (PHS):

• Azure AD Connect syncs password hashes from on-premises AD to Entra ID
• Authentication happens in cloud (fast, reliable)
• Password changes sync within 2 minutes
• Recommended for Copilot: Lowest latency, most reliable

Pass-Through Authentication (PTA):

• Authentication requests forwarded from Entra ID to on-premises AD
• Password validation happens on-premises
• No passwords stored in cloud
• Requires PTA agents installed on-premises (dependency on on-premises infrastructure)

Verify Current Authentication Method:

Connect-AzureAD
$authMethod = Get-AzureADDomain | Where-Object {$_.IsDefault -eq $true} |
    Select-Object AuthenticationType
Write-Output "Authentication method: $($authMethod.AuthenticationType)"

Result Interpretation:

• Managed: Password Hash Synchronization enabled
• Federated: ADFS or third-party federation (not recommended for Copilot due to added complexity)

Recommendation for Copilot: Use Password Hash Synchronization unless security requirements mandate pass-through authentication. PHS provides better performance and reliability.

Switch from PTA to PHS:

1. Open Azure AD Connect configuration wizard
2. Select "Change user sign-in"
3. Select "Password Hash Synchronization"
4. Complete wizard (passwords will sync over next 24 hours)
5. Monitor sync status

Entra ID-Only Environments (No On-Premises AD)

Organizations without on-premises Active Directory (cloud-native or startups) have simpler configuration requirements.

Configuration 1: Verify All Users Have Entra ID Accounts

Connect-MgGraph -Scopes "User.Read.All"

# List all users
$users = Get-MgUser -All
Write-Output "Total users: $($users.Count)"

# Check for guest users (may need special permissions)
$guestUsers = $users | Where-Object {$_.UserType -eq "Guest"}
Write-Output "Guest users: $($guestUsers.Count)"

# Check for unlicensed users
$licensedUsers = $users | Where-Object {$_.AssignedLicenses.Count -gt 0}
Write-Output "Licensed users: $($licensedUsers.Count)"

Pass Criteria:

• All employees have Entra ID accounts
• All users who will use Copilot have appropriate licenses (E3/E5)
• Guest user access properly scoped (reviewed quarterly)

Configuration 2: Groups for Permission Management

Even in cloud-native environments, security groups are essential for SharePoint, Teams, and OneDrive permissions.

Verify Security Groups Exist and Are Populated:

Connect-MgGraph -Scopes "Group.Read.All"

# List all security groups
$groups = Get-MgGroup -All | Where-Object {$_.SecurityEnabled -eq $true}
Write-Output "Total security groups: $($groups.Count)"

# For critical groups, verify membership
$criticalGroups = @("Engineering", "Finance", "Legal")
foreach ($groupName in $criticalGroups) {
    $group = Get-MgGroup -Filter "DisplayName eq '$groupName'"
    if ($group) {
        $members = Get-MgGroupMember -GroupId $group.Id -All
        Write-Output "Group $groupName has $($members.Count) members"
    } else {
        Write-Warning "Group $groupName not found"
    }
}

Recommendation: Avoid using individual user permissions in SharePoint/Teams. Always use security groups for permission grants. This makes permission auditing and Copilot troubleshooting significantly easier.

Conditional Access Requirements for Copilot

Conditional access policies control under what conditions users can access Copilot. Misconfigured policies can block legitimate usage.

Recommended Conditional Access Configuration

Policy 1: Require MFA for All Users

# Create conditional access policy requiring MFA
Connect-MgGraph -Scopes "Policy.Read.All", "Policy.ReadWrite.ConditionalAccess"

$params = @{
    DisplayName = "Require MFA for All Users"
    State = "enabled"
    Conditions = @{
        Users = @{
            IncludeUsers = @("All")
            ExcludeUsers = @()  # Exclude break-glass accounts
        }
        Applications = @{
            IncludeApplications = @("All")
        }
    }
    GrantControls = @{
        Operator = "OR"
        BuiltInControls = @("mfa")
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Policy 2: Block Legacy Authentication (legacy auth doesn't support MFA, creates security risk)

$params = @{
    DisplayName = "Block Legacy Authentication"
    State = "enabled"
    Conditions = @{
        Users = @{
            IncludeUsers = @("All")
        }
        Applications = @{
            IncludeApplications = @("All")
        }
        ClientAppTypes = @("exchangeActiveSync", "other")
    }
    GrantControls = @{
        Operator = "OR"
        BuiltInControls = @("block")
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Policy 3: Require Compliant Device for Copilot Access (optional, for high-security environments)

$params = @{
    DisplayName = "Require Compliant Device for Copilot"
    State = "enabledForReportingButNotEnforced"  # Start in report-only mode
    Conditions = @{
        Users = @{
            IncludeUsers = @("All")
        }
        Applications = @{
            IncludeApplications = @("M365Copilot-AppId")  # Replace with actual app ID
        }
    }
    GrantControls = @{
        Operator = "OR"
        BuiltInControls = @("compliantDevice", "domainJoinedDevice")
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Testing Conditional Access Policies:

Before enforcing policies, test in report-only mode:

1. Create policy with State = "enabledForReportingButNotEnforced"
2. Monitor sign-in logs for 1-2 weeks
3. Review "Conditional Access" column in sign-in logs to see if policy would have blocked legitimate users
4. Adjust policy as needed
5. Enable enforcement: Set State = "enabled"

Common Conditional Access Issues with Copilot:

• Policy blocks mobile access: User can use Copilot on desktop but not mobile—indicates device compliance requirement not met
• Policy blocks home networks: User can access Copilot from office but not home—indicates location-based policy that needs adjustment for hybrid work
• Policy requires MFA every session: MFA configured without session persistence—adjust session controls to "remember MFA on trusted devices"

Permission Inheritance in Entra ID

Entra ID has flatter permission model than on-premises AD. Understanding inheritance is critical for Copilot permissions.

Security Groups and Direct Assignments

Best Practice: Use security groups for all permission grants in SharePoint, Teams, and OneDrive. Avoid direct user assignments.

Why This Matters for Copilot:

• Copilot resolves permissions by checking user's group memberships
• If permissions granted directly to users, Copilot must query every user-resource relationship (slow)
• If permissions granted to groups, Copilot queries user's groups once, then checks group-resource relationships (fast)

Check for Excessive Direct User Permissions:

# Connect to SharePoint Online
Connect-PnPOnline -Url "https://company-admin.sharepoint.com" -Interactive

# Get all site collections
$sites = Get-PnPTenantSite

foreach ($site in $sites) {
    Connect-PnPOnline -Url $site.Url -Interactive

    # Get unique permissions
    $permissions = Get-PnPWebPermission

    # Count direct user vs group assignments
    $userPermissions = $permissions | Where-Object {$_.Member -match "@company.com"}
    $groupPermissions = $permissions | Where-Object {$_.Member -notmatch "@company.com"}

    Write-Output "Site: $($site.Url)"
    Write-Output "  Direct user permissions: $($userPermissions.Count)"
    Write-Output "  Group permissions: $($groupPermissions.Count)"

    if ($userPermissions.Count -gt 50) {
        Write-Warning "  Excessive direct user permissions detected - consider consolidating to groups"
    }
}

Remediation: Convert direct user permissions to group-based permissions. This improves Copilot performance and simplifies permission management.

Dynamic Groups

Entra ID supports dynamic groups: membership determined by user attributes rather than manual assignment.

Example: "All Finance Department" group with rule:

user.department -eq "Finance"

Benefits for Copilot:

• Automatic group membership as users join/leave departments
• Consistent permission grants without manual group management

Limitations:

• Dynamic group membership updates have latency (can take 1-24 hours)
• Complex rules can be hard to audit
• Not all SharePoint scenarios support dynamic groups

Verify Dynamic Group Configuration:

Connect-MgGraph -Scopes "Group.Read.All"

# Find dynamic groups
$dynamicGroups = Get-MgGroup -All | Where-Object {$_.GroupTypes -contains "DynamicMembership"}

foreach ($group in $dynamicGroups) {
    Write-Output "Group: $($group.DisplayName)"
    Write-Output "  Rule: $($group.MembershipRule)"
    Write-Output "  Rule processing state: $($group.MembershipRuleProcessingState)"
}

Best Practice: Use dynamic groups for broad categories (all employees in department) but static groups for specific projects or teams.

Multi-Factor Authentication (MFA) Configuration

Copilot requires MFA to be enabled for all users accessing production data.

Verify MFA Enforcement

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All", "Policy.Read.All"

# Check MFA registration status for all users
$users = Get-MgUser -All
$mfaStatus = @()

foreach ($user in $users) {
    $authMethods = Get-MgUserAuthenticationMethod -UserId $user.Id
    $hasMFA = $authMethods | Where-Object {
        $_.AdditionalProperties."@odata.type" -match "phone|oath|microsoftAuthenticator"
    }

    $mfaStatus += [PSCustomObject]@{
        UserPrincipalName = $user.UserPrincipalName
        MFARegistered = $hasMFA.Count -gt 0
    }
}

# Summary
$totalUsers = $mfaStatus.Count
$mfaUsers = ($mfaStatus | Where-Object {$_.MFARegistered -eq $true}).Count
$percentage = [math]::Round(($mfaUsers / $totalUsers) * 100, 2)

Write-Output "MFA Registration Status:"
Write-Output "  Total users: $totalUsers"
Write-Output "  MFA registered: $mfaUsers ($percentage%)"

# Export non-MFA users for follow-up
$mfaStatus | Where-Object {$_.MFARegistered -eq $false} |
    Export-Csv -Path ".\NonMFA-Users.csv" -NoTypeInformation

Pass Criteria: 100% of users who will use Copilot must have MFA registered and enforced

Common Issues:

• Service accounts without MFA (need app passwords or certificate-based auth instead)
• Users registered for MFA but not enforced via conditional access
• SMS-based MFA (vulnerable to SIM-swapping attacks—prefer authenticator apps)

Enforcement via Conditional Access (see section above for policy creation)

Troubleshooting Common Entra ID Issues with Copilot

Issue 1: "Copilot can't find any documents" Despite Correct SharePoint Permissions

Symptoms:

• User has verified SharePoint access (can browse documents manually)
• Copilot returns "I couldn't find any relevant documents"
• Issue affects only some users, not all

Root Cause: Group membership not syncing correctly from on-premises AD to Entra ID

Troubleshooting Steps:

1. Verify user's group membership in Entra ID matches on-premises AD:

# On-premises
Import-Module ActiveDirectory
Get-ADUser -Identity "alice" -Properties MemberOf | Select-Object -ExpandProperty MemberOf

# Entra ID
Connect-AzureAD
$user = Get-AzureADUser -Filter "UserPrincipalName eq 'alice@company.com'"
Get-AzureADUserMembership -ObjectId $user.ObjectId | Select-Object DisplayName

1. If groups differ, check Azure AD Connect sync errors:

# On Azure AD Connect server
Get-ADSyncCSObject -ConnectorName "company.com" -DistinguishedName "CN=alice,OU=Users,DC=company,DC=com"

1. Force sync and verify:

Start-ADSyncSyncCycle -PolicyType Delta
# Wait 10 minutes for sync to complete
# Re-check group membership in Entra ID

1. If issue persists, check if group is excluded from sync scope (see Azure AD Connect configuration section above)

Issue 2: "Sign-in Loop" When Launching Copilot

Symptoms:

• User clicks Copilot icon in Microsoft 365 apps
• Sign-in prompt appears
• After entering credentials, returns to sign-in prompt (loop)
• Eventually times out with authentication error

Root Cause: Conditional access policy blocking Copilot or UPN mismatch

Troubleshooting Steps:

1. Check sign-in logs for failures:

Connect-MgGraph -Scopes "AuditLog.Read.All"

# Get recent failed sign-ins for user
$signIns = Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'alice@company.com' and status/errorCode ne 0" -Top 10

foreach ($signIn in $signIns) {
    Write-Output "Timestamp: $($signIn.CreatedDateTime)"
    Write-Output "App: $($signIn.AppDisplayName)"
    Write-Output "Error: $($signIn.Status.ErrorCode) - $($signIn.Status.FailureReason)"
    Write-Output "Conditional Access: $($signIn.ConditionalAccessStatus)"
    Write-Output ""
}

1. Look for conditional access failures:

   • "ConditionalAccessStatus: failure" indicates policy blocking access
   • Review policy name in details
   • Adjust policy or grant user exception

2. Check for UPN mismatch:

   • If error mentions "user not found" or "invalid user," UPN may not match between on-premises and cloud
   • Follow UPN consistency section above

Issue 3: Guest Users Can't Access Copilot

Symptoms:

• External collaborators invited as guests
• Guests can access SharePoint sites and Teams channels
• Copilot returns "access denied" for guest users

Root Cause: Copilot requires specific guest access permissions or guest users don't have Copilot licenses

Troubleshooting Steps:

1. Verify guest has Copilot license:

Connect-MgGraph -Scopes "User.Read.All"

$guest = Get-MgUser -Filter "userPrincipalName eq 'guest@external.com'"
$licenses = Get-MgUserLicenseDetail -UserId $guest.Id

$licenses | Select-Object SkuPartNumber

1. Check if Copilot licensing supports guests (as of 2025, Copilot licenses typically restricted to employees, not guests):

   • If Copilot not available for guests, communicate limitation
   • Consider alternative collaboration methods for external partners

2. If guests should have access, check external sharing settings:

Connect-SPOService -Url "https://company-admin.sharepoint.com"

Get-SPOTenant | Select-Object SharingCapability, DefaultSharingLinkType

Issue 4: Copilot Performance Slow for Specific Users

Symptoms:

• Most users get Copilot responses in 2-5 seconds
• Specific users wait 30-60 seconds or time out
• Issue persists across different queries and applications

Root Cause: User has excessive group memberships or complex permission structure causing slow permission resolution

Troubleshooting Steps:

1. Check user's group membership count:

Connect-AzureAD

$user = Get-AzureADUser -Filter "userPrincipalName eq 'bob@company.com'"
$groups = Get-AzureADUserMembership -ObjectId $user.ObjectId -All $true

Write-Output "User is member of $($groups.Count) groups"

# List groups
$groups | Select-Object DisplayName, ObjectType

Recommendation: Users should be in <100 groups. If user is in 500+ groups, performance will degrade.

1. Audit and clean up unnecessary group memberships:
   • Remove from groups related to completed projects
   • Consolidate multiple department groups into single group
   • Use dynamic groups to reduce manual membership churn

Security Baseline for Entra ID

Before deploying Copilot, validate that Entra ID meets minimum security baselines.

Security Checklist

Authentication:

• [ ] MFA enabled and enforced for all users
• [ ] Legacy authentication protocols blocked via conditional access
• [ ] Password policies meet NIST guidelines (minimum 12 characters, no forced rotation)
• [ ] Self-service password reset enabled with MFA verification

Identity Protection:

• [ ] Azure AD Identity Protection enabled (E5 or standalone license)
• [ ] Risk-based conditional access policies deployed
• [ ] Sign-in risk policy: Require MFA for medium/high risk
• [ ] User risk policy: Require password change for medium/high risk

Privileged Access:

• [ ] Privileged Identity Management (PIM) deployed for admin roles
• [ ] Just-in-time admin access (not persistent admin privileges)
• [ ] Admin accounts separate from daily-use accounts
• [ ] Emergency access (break-glass) accounts configured and tested

Monitoring and Auditing:

• [ ] Sign-in logs retained for minimum 90 days (365 days for compliance)
• [ ] Audit logs exported to SIEM for long-term retention
• [ ] Alerts configured for suspicious sign-ins (impossible travel, unfamiliar locations)
• [ ] Regular access reviews for groups with sensitive permissions

Guest Access:

• [ ] Guest access policies defined and enforced
• [ ] Guest users reviewed quarterly
• [ ] Expired guest accounts automatically disabled
• [ ] Guest permissions limited to specific resources

Validation Script

# Comprehensive Entra ID security check
Connect-MgGraph -Scopes "Directory.Read.All", "Policy.Read.All", "AuditLog.Read.All"

Write-Output "=== Entra ID Security Baseline Check ==="

# 1. MFA Status
$users = Get-MgUser -All
$mfaUsers = 0
foreach ($user in $users) {
    $authMethods = Get-MgUserAuthenticationMethod -UserId $user.Id -ErrorAction SilentlyContinue
    if ($authMethods.Count -gt 1) { $mfaUsers++ }  # More than password = MFA registered
}
$mfaPercentage = [math]::Round(($mfaUsers / $users.Count) * 100, 1)
Write-Output "MFA Registered: $mfaPercentage% ($mfaUsers of $($users.Count) users)"

# 2. Conditional Access Policies
$caPolicies = Get-MgIdentityConditionalAccessPolicy
Write-Output "Conditional Access Policies: $($caPolicies.Count)"
$enabledPolicies = $caPolicies | Where-Object {$_.State -eq "enabled"}
Write-Output "  Enabled: $($enabledPolicies.Count)"

# 3. Legacy Auth Blocking
$legacyBlockPolicy = $caPolicies | Where-Object {
    $_.Conditions.ClientAppTypes -contains "exchangeActiveSync" -or
    $_.Conditions.ClientAppTypes -contains "other"
}
if ($legacyBlockPolicy) {
    Write-Output "Legacy authentication blocked: YES"
} else {
    Write-Warning "Legacy authentication blocked: NO - REMEDIATION REQUIRED"
}

# 4. Guest Users
$guests = $users | Where-Object {$_.UserType -eq "Guest"}
Write-Output "Guest accounts: $($guests.Count)"

# 5. Admin Roles (should be minimal)
$adminRoleUsers = Get-MgDirectoryRoleMember -DirectoryRoleId (Get-MgDirectoryRole | Where-Object {$_.DisplayName -eq "Global Administrator"}).Id
Write-Output "Global Administrators: $($adminRoleUsers.Count)"

Write-Output "`n=== Recommendations ==="
if ($mfaPercentage -lt 100) {
    Write-Warning "- Enforce MFA for remaining $([math]::Round(100 - $mfaPercentage, 1))% of users"
}
if (-not $legacyBlockPolicy) {
    Write-Warning "- Deploy conditional access policy to block legacy authentication"
}
if ($adminRoleUsers.Count -gt 5) {
    Write-Warning "- Review and minimize Global Administrator role assignments (current: $($adminRoleUsers.Count))"
}

Common Questions: Entra ID Configuration FAQ

Do I need Azure AD Connect for Copilot?

If you have on-premises Active Directory: Yes, Azure AD Connect is required to sync users and groups to Entra ID. Copilot authenticates against Entra ID and resolves permissions using Entra ID group memberships.

If you're cloud-native (no on-premises AD): No, Azure AD Connect not needed. Users and groups are created directly in Entra ID.

Hybrid alternative: Some organizations use third-party identity providers (Okta, Ping Identity) instead of Azure AD Connect. These tools can sync to Entra ID, but Microsoft's official support and documentation assume Azure AD Connect. Use alternatives only if you have strong IAM team with deep expertise.

How do I sync permissions to Entra ID?

Permissions themselves don't sync—only users and groups sync. Here's how permission resolution works:

1. On-premises: Create security group "Finance Team" in AD, add users as members
2. Azure AD Connect: Syncs "Finance Team" group and its members to Entra ID
3. SharePoint: Grant "Finance Team" permissions to finance SharePoint site
4. Copilot: When user queries for finance documents, Copilot checks if user is member of "Finance Team" in Entra ID, allows access if yes

Key Point: The permission grant happens in SharePoint/Teams/OneDrive (cloud services), but group membership is synced from on-premises AD. Both must be accurate for Copilot to work correctly.

What if I have hybrid identity issues?

Most hybrid identity issues stem from:

• Azure AD Connect configuration errors (groups not syncing, nested groups not supported)
• UPN mismatches between on-premises and cloud
• Stale group memberships (users removed from on-premises group but change not synced)

Troubleshooting approach:

1. Verify Azure AD Connect is healthy and syncing (check sync status, error logs)
2. Verify specific user and group are syncing correctly (compare on-premises vs. Entra ID)
3. Force sync and wait for propagation (30 minutes to 2 hours)
4. If issues persist, engage Microsoft support or identity specialist consultant

Nuclear option: If hybrid identity is fundamentally broken (years of configuration drift, unsupported scenarios), consider:

• Clean Entra ID tenant and re-sync from scratch (major undertaking)
• Migrate to cloud-native identity (no on-premises AD)
• These are months-long projects—only pursue if hybrid issues are pervasive

Can I deploy Copilot before fixing all identity issues?

Depends on severity of issues:

Minor issues - Can proceed with caution:

• Small number of users with UPN mismatches (<5% of population)
• Specific groups not syncing but workarounds available (flatten nested groups temporarily)
• MFA not enforced for 10-15% of users (can enforce progressively)

Major issues - Must remediate before deployment:

• Azure AD Connect not syncing at all
• Majority of users with authentication problems
• Critical security groups missing from Entra ID
• No MFA enforcement for any users

Use our readiness assessment to determine if identity issues are blockers.

How often should I review Entra ID configuration?

Continuous monitoring:

• Azure AD Connect sync status: Daily (automated monitoring)
• Failed sign-ins: Daily review of anomalies
• MFA registration: Weekly (for new users or gaps)

Regular reviews:

• Guest user access: Quarterly
• Group memberships for critical groups: Quarterly
• Conditional access policies: Semi-annually or after significant changes
• Security baseline compliance: Annually

Event-driven reviews:

• After any Azure AD Connect configuration changes
• After organization restructuring (department changes, acquisitions)
• After security incidents involving identity
• Before major Copilot deployment expansions

Next Steps: Preparing Entra ID for Copilot

To ensure identity infrastructure is Copilot-ready:

1. Complete readiness assessment: Use our 12-point checklist to identify gaps
2. Remediate critical issues: Focus on Azure AD Connect sync, UPN consistency, MFA enforcement
3. Validate with test users: Deploy Copilot to 5-10 test users, verify authentication and permission resolution work correctly
4. Monitor during pilot: Track identity-related support tickets during pilot phase, iterate on configuration
5. Scale with confidence: Expand to broader user base once identity foundation is solid

For organizations needing support with identity configuration, consider engaging a Microsoft identity specialist to accelerate remediation and reduce deployment risk.

About the Author: Errin O'Connor is Chief AI Architect at EPC Group, with 25+ years of Microsoft ecosystem experience including deep expertise in Active Directory and Entra ID architecture. EPC Group has helped clients remediate complex hybrid identity issues for 50+ Copilot deployments across Fortune 500 enterprises.

Need help with Entra ID configuration? EPC Group offers comprehensive identity services including Azure AD Connect optimization, UPN remediation, and hybrid identity troubleshooting. Contact us for a complimentary identity readiness assessment.