Entra Id

---
name: entra-id
description: "Expert agent for Microsoft Entra ID (formerly Azure AD). Provides deep expertise in Conditional Access, PIM, Identity Protection, Entra Connect, B2B/B2C, app registrations, managed identities, and Entra ID Governance. WHEN: \"Entra ID\", \"Azure AD\", \"Conditional Access\", \"PIM\", \"Identity Protection\", \"Entra Connect\", \"B2B\", \"B2C\", \"app registration\", \"service principal\", \"managed identity\", \"passkeys Entra\", \"Entra Permissions Management\"."
license: MIT
---

# Entra ID

This skill covers Microsoft Entra ID (formerly Azure Active Directory). It has deep knowledge of tenant architecture, Conditional Access policies, Privileged Identity Management, Identity Protection, hybrid identity (Entra Connect / Cloud Sync), B2B/B2C, application registrations, managed identities, and the full Entra ID Governance suite.

## Identity and Scope

Entra ID is Microsoft's cloud-based identity and access management service. It provides:
- Authentication and SSO for Microsoft 365, Azure, and thousands of SaaS applications
- Conditional Access as the zero trust policy engine
- Privileged Identity Management (PIM) for JIT privileged access
- Identity Protection for risk-based authentication
- Hybrid identity with on-premises AD via Entra Connect
- B2B and B2C for external identity scenarios
- Entra ID Governance for lifecycle, access reviews, and entitlement management

## How to Approach Tasks

When you receive a request:

1. **Classify** the request:
   - **Conditional Access** -- Load `references/best-practices.md` for CA policy design
   - **Architecture** -- Load `references/architecture.md` for tenant internals
   - **Hybrid identity** -- Entra Connect, Cloud Sync, pass-through auth, PHS, federation
   - **Governance** -- Access reviews, entitlement management, lifecycle workflows
   - **App integration** -- App registrations, service principals, managed identities
   - **Security** -- Identity Protection, risky users, risky sign-ins

2. **Identify license tier** -- Features vary dramatically by license (Free, P1, P2, Governance):
   - **Free / M365:** Basic SSO, MFA (security defaults), self-service password reset
   - **P1:** Conditional Access, Entra Connect, dynamic groups, application proxy
   - **P2:** PIM, Identity Protection, access reviews, entitlement management
   - **Governance:** Lifecycle workflows, advanced access certifications, SOD

3. **Analyze** -- Apply Entra ID-specific reasoning, not generic cloud identity advice.

4. **Recommend** -- Provide actionable configuration with Azure portal paths and PowerShell/Graph API examples.

## Core Expertise

### Tenant Architecture

An Entra ID tenant is a dedicated instance of the directory service:
- **Tenant ID (GUID)** -- Globally unique identifier
- **Primary domain** -- `<tenant>.onmicrosoft.com`
- **Custom domains** -- Verified DNS domains associated with the tenant
- **Objects** -- Users, groups, applications, service principals, devices
- **Flat structure** -- No OUs. Use Administrative Units for delegation.

### Conditional Access

Conditional Access (CA) is the zero trust policy engine. Every access decision evaluates:

**Signals (inputs):**
- User/group membership
- Application being accessed
- Device platform and compliance state
- Location (named locations, IP ranges, countries)
- Sign-in risk level (from Identity Protection)
- User risk level (from Identity Protection)
- Client application type

**Controls (outputs):**
- Block access
- Grant access with requirements: MFA, compliant device, Entra joined device, approved app, app protection policy, password change, terms of use, authentication strength
- Session controls: sign-in frequency, persistent browser, MCAS integration, disable resilience defaults

**CA policy design principles:**
1. **Start with block** -- Block legacy authentication first
2. **Require MFA for all users** -- Foundation policy. Use authentication strength for phishing-resistant MFA.
3. **Require compliant devices** -- For corporate resources
4. **Risk-based policies** -- Require MFA or block based on sign-in risk and user risk
5. **Application-specific** -- Stricter policies for sensitive applications
6. **Named locations** -- Define trusted networks (use cautiously -- not a security boundary)
7. **Test with Report-Only** -- Always deploy CA policies in report-only mode first

```powershell
# Microsoft Graph PowerShell SDK
# List all Conditional Access policies
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State, Conditions, GrantControls

# Create a CA policy via Graph API (example: require MFA for all users)
$params = @{
    DisplayName = "Require MFA for all users"
    State = "enabledForReportingButNotEnforced"
    Conditions = @{
        Users = @{ IncludeUsers = @("All") }
        Applications = @{ IncludeApplications = @("All") }
    }
    GrantControls = @{
        Operator = "OR"
        BuiltInControls = @("mfa")
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params
```

### Privileged Identity Management (PIM)

PIM provides JIT privileged access:

- **Eligible assignments** -- User CAN activate the role (not active until requested)
- **Active assignments** -- User HAS the role (permanent or time-bound)
- **Activation** -- User requests role activation, provides justification, optionally requires approval
- **Time-limited** -- Activations expire (default: 8 hours, configurable)

**PIM configuration best practices:**
- Make all privileged roles eligible, not permanently active
- Require MFA on activation
- Require justification and optionally approval for sensitive roles
- Set maximum activation duration (4-8 hours)
- Enable notifications for role activations
- Configure access reviews for role assignments

**Key roles to protect with PIM:**
- Global Administrator
- Privileged Role Administrator
- Exchange Administrator
- SharePoint Administrator
- Security Administrator
- Conditional Access Administrator
- Application Administrator

### Identity Protection

Automated risk detection and remediation:

**Risk detections:**

| Detection | Type | Description |
|---|---|---|
| Anonymous IP address | Sign-in risk | Sign-in from known anonymous proxy |
| Atypical travel | Sign-in risk | Impossible travel between locations |
| Malware-linked IP | Sign-in risk | Sign-in from IP associated with malware |
| Unfamiliar sign-in properties | Sign-in risk | Sign-in with unusual properties for the user |
| Password spray | Sign-in risk | Multiple accounts targeted with common passwords |
| Token anomaly | Sign-in risk | Unusual token characteristics |
| Leaked credentials | User risk | Credentials found in breach databases |
| Azure AD Threat Intelligence | Both | Microsoft's threat intelligence signals |

**Risk-based CA policies:**
- **Sign-in risk = Medium+** --> Require MFA
- **Sign-in risk = High** --> Block access
- **User risk = Medium+** --> Require password change + MFA
- **User risk = High** --> Block access

### Hybrid Identity

**Synchronization options:**

| Method | Use Case | Architecture |
|---|---|---|
| **Entra Connect** (formerly Azure AD Connect) | Full-featured hybrid sync | On-premises agent, rich filtering/transformation |
| **Cloud Sync** | Simple sync, multi-forest | Cloud-managed, lightweight agent, limited transformation |

**Authentication methods:**

| Method | Password Location | Latency | Dependency |
|---|---|---|---|
| **Password Hash Sync (PHS)** | Cloud (hash of hash) | None | No on-premises dependency after sync |
| **Pass-Through Auth (PTA)** | On-premises only | Per-auth | Requires on-premises agent availability |
| **Federation (AD FS)** | On-premises | Per-auth | Requires AD FS farm availability |

**Recommendation:** PHS + Seamless SSO is the recommended approach for most organizations. PHS provides cloud resilience (authenticates even if on-premises is down) and enables Identity Protection risk detections.

### B2B and B2C

**B2B (Business-to-Business):**
- Guest users from external organizations
- Uses cross-tenant access settings (inbound/outbound policies)
- Authentication: home tenant authenticates the user
- Licensing: up to 5 guests per P1/P2 license (MAU-based for Entra External ID)

**B2C (Business-to-Consumer):**
- Customer identity for consumer-facing applications
- Now part of Entra External ID (External Identities)
- User flows for sign-up/sign-in, password reset, profile editing
- Social identity providers (Google, Facebook, Apple)
- Custom policies (Identity Experience Framework) for complex flows

### Application Model

**App registrations vs. Enterprise applications (Service Principals):**
- **App registration** -- The application definition (client ID, redirect URIs, permissions, certificates/secrets)
- **Service principal** -- An instance of the application in a specific tenant (what users consent to, what CA policies apply to)
- Multi-tenant apps: one registration, service principal in each tenant

**Managed identities:**
- **System-assigned** -- Tied to a specific Azure resource lifecycle. Deleted when resource is deleted.
- **User-assigned** -- Independent lifecycle. Can be shared across resources.
- **Use for:** Azure resource-to-resource authentication. Eliminates secrets/certificates.

### Entra ID Governance

**Access reviews:**
- Periodic review of group memberships, app assignments, role assignments
- Reviewers: managers, self-review, specific reviewers
- Auto-remediation: remove access if not approved

**Entitlement management:**
- Access packages: bundles of resources (groups, apps, SharePoint sites)
- Catalogs: organize access packages
- Policies: approval, expiration, access review requirements
- Self-service request portal for users

**Lifecycle workflows:**
- Automate JML (Joiner-Mover-Leaver) processes
- Triggers: employee hire date, department change, termination date
- Tasks: generate TAP, send email, add to groups, remove access
- Pre-built templates for common scenarios

### Passwordless Authentication

**Methods (strongest to weakest):**
1. **FIDO2 security keys** -- Hardware keys (YubiKey, Feitian). Phishing-resistant. Works cross-platform.
2. **Passkeys in Microsoft Authenticator** -- Device-bound passkeys. Phishing-resistant.
3. **Windows Hello for Business** -- Biometric or PIN bound to device. Phishing-resistant.
4. **Certificate-based authentication** -- Smart cards, virtual smart cards. Phishing-resistant.
5. **Microsoft Authenticator push** -- With number matching. Resists MFA fatigue.
6. **TOTP** -- Authenticator app codes. Phishable.
7. **SMS/Voice** -- Last resort. SIM swap vulnerable.

**Authentication strength policies:**
- Define which MFA methods satisfy a CA policy
- "Phishing-resistant MFA" = FIDO2 + Windows Hello + Certificate
- "Passwordless MFA" = FIDO2 + Windows Hello + Authenticator passwordless
- Custom strength policies for specific requirements

### Entra Permissions Management (CIEM)

Cloud Infrastructure Entitlement Management:
- Discover, remediate, and monitor permissions across Azure, AWS, and GCP
- Permissions Creep Index (PCI): measures gap between granted and used permissions
- Right-size permissions based on actual usage
- On-demand permissions: JIT access for cloud resources

## Common Pitfalls

1. **Emergency access accounts** -- Always have 2+ break-glass accounts excluded from ALL CA policies, with MFA but not conditional on device/location. Store credentials in a physical safe.
2. **CA policy gaps** -- A user not covered by any CA policy gets unrestricted access. Use a "catch-all" policy requiring MFA for all users to all apps.
3. **Report-only vs. enabled** -- Deploying CA policies directly in "On" mode without testing in "Report-only" first causes lockouts.
4. **PIM notifications ignored** -- Global Admin activations should trigger alerts. Monitor and investigate every activation.
5. **Over-consented applications** -- App registrations with excessive Graph API permissions (e.g., `Directory.ReadWrite.All`). Audit and restrict.
6. **Stale guest accounts** -- B2B guests accumulate and are rarely cleaned up. Use access reviews for guest accounts.
7. **Cloud-only emergency without PHS** -- If using PTA or federation and on-premises goes down, nobody can authenticate. Enable PHS as a backup.

## Reference Files

Load these for deep knowledge:
- `references/architecture.md` -- Entra ID internals: tenant model, token issuance, directory sync, authentication flows, licensing tiers, and Graph API patterns.
- `references/best-practices.md` -- Entra ID hardening: CA policy framework (baseline + targeted), PIM configuration, app registration security, B2B governance, monitoring and alerting.

## Diagnostic Scripts

Ready-made Microsoft Graph PowerShell audits (read-only scopes) in `scripts/`. Defensive posture review, no changes made.

- `scripts/01-privileged-roles-audit.ps1` -- Members of high-privilege directory roles (standing-privilege surface)
- `scripts/02-conditional-access-review.ps1` -- CA policy inventory with MFA coverage and report-only gaps
- `scripts/03-stale-guests-and-apps.ps1` -- Dormant guests and expiring/no-expiry app credentials