Identity Tenant identity premium

Directory

Directory is the Microsoft Entra identity container that holds users, groups, applications, service principals, devices, and tenant configuration. In Azure, it helps teams organize identities, connect subscriptions to a tenant, enforce access policy, and give administrators one identity boundary to govern. Plainly, it is a named part of the architecture that operators can point to when they need evidence, ownership, and a safe change path. A useful glossary entry should explain where it appears, what it controls, what depends on it, and which signal proves it is healthy.

Back to glossary browser Open Microsoft Learn source
Aliases
Microsoft Entra directory, tenant directory, identity directory, Azure AD directory
Difficulty
fundamentals
CLI mappings
4
Last verified
2026-05-13

Microsoft Learn

A directory is the Microsoft Entra identity container associated with users, groups, applications, service principals, devices, and tenant-level identity configuration.

Microsoft Learn: Associate or add an Azure subscription to a Microsoft Entra directory2026-05-13

Technical context

Technically, Directory appears in Microsoft Entra tenant settings, subscription directory association, users, groups, app registrations, enterprise applications, service principals, and role assignments and interacts with Microsoft Entra ID, Azure subscription, App registrations, and Service principals. Configuration is reviewed through tenant ID, subscription association, user and group membership, and app registrations, while operators validate live state through tenant ID, visible tenants, group membership, and application registration list. Scope determines which permissions, logs, commands, and dependencies matter.

Why it matters

Directory matters because a small Azure design choice can shape customer experience, security posture, operational visibility, and incident recovery. When it is shallowly documented, teams may troubleshoot the wrong tenant, policy, storage account, migration project, disk, telemetry path, or SQL table while the real dependency remains hidden. In enterprise Azure work, the value is shared language: application, platform, security, data, finance, and operations teams can discuss the same object without guessing. That reduces incident time, improves audit quality, clarifies ownership, and makes production changes safer because failure modes and graph relationships are visible before change. Treat Directory as production owned when customer traffic, regulated data, migration planning, shared infrastructure, or release automation depends on it.

Where you see it

Signals, screens, and Azure surfaces where this term usually becomes operational.

Signal 01

In the Azure portal, a directory appears when switching tenants, managing Microsoft Entra ID, or changing which tenant a subscription belongs to during production review.

Signal 02

In access reviews, it appears when administrators verify users, groups, app registrations, service principals, and enterprise applications inside the tenant during production review when operators collect repeatable evidence.

Signal 03

In troubleshooting, it appears when a subscription, app registration, managed identity, or role assignment belongs to a different tenant than expected during production review when operators collect repeatable evidence.

When this becomes relevant

Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.

  • Confirm which tenant owns a subscription before access changes.
  • Audit users, groups, applications, and service principals in one identity boundary.
  • Troubleshoot resources that are connected to the wrong tenant.

Real-world case studies

Different enterprise-style examples that show the term being used to hit measurable objectives.

Case study 01

Directory in action for regional banking

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

AltaBridge Finance, a regional banking organization, needed to address developers were deploying workloads into subscriptions associated with different identity tenants, causing failed managed identity access. The architecture team used Directory as the control point for a measurable production improvement.

Business/Technical Objectives
  • Identify the correct tenant for 18 production subscriptions
  • Reduce failed identity deployments by 70 percent
  • Standardize owner groups for application registrations
Solution Using Directory

The platform team inventoried subscription tenant IDs, mapped each subscription to the approved Microsoft Entra directory, and moved unsupported workloads into governed landing zones. App registrations and managed identities were reviewed against owner groups, and release pipelines were blocked when the tenant context did not match the target environment. The team validated Directory in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Directory in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Results & Business Impact
  • Failed identity deployments dropped 82 percent
  • Every production subscription had a documented tenant owner
  • Application ownership gaps were reduced from 41 to 6
Key Takeaway for Glossary Readers

A directory is the identity boundary that keeps subscriptions, applications, and operators aligned.

Case study 02

Directory in action for healthcare services

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Harborline Health, a healthcare services organization, needed to address audit teams could not prove which tenant contained clinical application identities and administrator groups. The architecture team used Directory as the control point for a measurable production improvement.

Business/Technical Objectives
  • Document tenant ownership for regulated applications
  • Connect app registrations to accountable owner groups
  • Cut identity-audit preparation from weeks to days
Solution Using Directory

Security architects treated the directory as the evidence container for clinical identity controls. They cataloged app registrations, service principals, groups, and privileged directory roles, then connected each regulated application to a named owner group and access-review cadence. Azure Policy and tags referenced the same tenant ownership model. The team validated Directory in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Directory in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Results & Business Impact
  • Audit preparation dropped from 12 days to 4 days
  • All critical app registrations gained named owners
  • Access review exceptions were tracked in one directory-owned process
Key Takeaway for Glossary Readers

Directory documentation turns identity governance from scattered screenshots into repeatable evidence.

Case study 03

Directory in action for industrial manufacturing

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

NorthRidge Manufacturing, a industrial manufacturing organization, needed to address an acquisition left engineers switching between several tenants without knowing which directory controlled factory subscriptions. The architecture team used Directory as the control point for a measurable production improvement.

Business/Technical Objectives
  • Map acquired subscriptions to the right tenant
  • Avoid accidental changes in retired directories
  • Create a clear migration plan for identities
Solution Using Directory

Cloud architects created a tenant map that listed subscriptions, users, groups, app registrations, managed identities, and enterprise applications per directory. Workloads stayed operational while teams migrated role assignments and app ownership into the target tenant, using CLI checks to confirm context before every production change. The team validated Directory in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Directory in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Results & Business Impact
  • No production access outage occurred during tenant cleanup
  • Retired directories were reduced from five to two
  • Support tickets about wrong-tenant access fell 64 percent
Key Takeaway for Glossary Readers

Understanding the directory prevents identity confusion during mergers, migrations, and landing-zone consolidation.

Why use Azure CLI for this?

CLI checks for Directory are useful because they turn portal assumptions into repeatable evidence. Start with read-only commands that show scope, state, owner, permissions, destinations, configuration, metrics, or discovered inventory. Run mutating, security-impacting, or cost-impacting commands only after approval, because the wrong scope can affect production availability, spend, access, or telemetry.

CLI use cases

  • Confirm which tenant owns a subscription before access changes.
  • Audit users, groups, applications, and service principals in one identity boundary.
  • Troubleshoot resources that are connected to the wrong tenant.

Before you run CLI

  • Run az account show, confirm tenant and subscription, and verify the operator identity has approved read access for the exact Azure scope.
  • Confirm resource group, service name, resource ID, environment, owner, and change record before collecting evidence or modifying production configuration.
  • Prefer read-only commands first; review any command that changes access, policy evaluation, disk state, migration discovery, telemetry, or data distribution before running it.

What output tells you

  • Whether the target tenant, policy, storage account, migration project, disk, trace resource, or SQL pool exists at the expected Azure scope.
  • Which state, assignment, property, identity, key reference, attachment, metric, trace, table design, or discovered inventory value is visible to the operator.
  • Whether the issue is wrong scope, stale configuration, missing permissions, weak evidence, failed discovery, disk pressure, trace sampling, or table distribution skew.

Mapped Azure CLI commands

Directory operational checks

direct
az account tenant list --output table
az account tenantdiscoverManagement and Governance
read-only Microsoft docs
az account show --query tenantId --output tsv
az accountdiscoverIdentity
read-only Microsoft docs
az ad group list --filter "displayName eq '<group-name>'"
az ad groupdiscoverIdentity
read-only Microsoft docs
az ad app list --display-name <application-name>
az ad appdiscoverIdentity
read-only Microsoft docs

Architecture context

Directory belongs to Identity architecture decisions where identity, monitoring, cost ownership, reliability, and production support need shared evidence.

Security

Security for Directory starts with least privilege, trusted configuration, and evidence that access matches workload risk. Review tenant boundary, administrator role review, group membership, application registrations, and conditional access coverage before approving production use. A common failure is assuming that a working feature, successful deployment, visible resource, or populated dashboard proves the configuration is safe. Use Microsoft Entra groups, managed identities, RBAC, private connectivity, diagnostic logging, source-controlled definitions, and approval records where applicable. Keep exceptions ticketed, time-bounded, and owned. For regulated workloads, align the term with classification, retention, break-glass, and incident-response procedures. Remove broad access, stale keys, unreviewed contributors, and undocumented exception paths before Directory becomes an incident path.

Cost

Cost for Directory appears through licensing impact, compute capacity, transaction volume, diagnostic retention, policy remediation, storage consumption, migration assessment effort, disk performance choices, and the human effort required to recover from mistakes. Review duplicate tenants, orphaned applications, support escalations, identity governance licensing, and manual access reviews before expanding production use. Some costs are direct, such as retained logs, provisioned disks, storage transactions, or SQL pool capacity; others are indirect, such as failed releases, duplicated troubleshooting, emergency restores, and support escalation. Tag related resources, monitor usage, and separate exploratory work from production. A cost review should connect spend to a real owner and measurable value.

Reliability

Reliability for Directory depends on repeatable configuration, tested dependencies, and clear failure signals. Watch subscription-directory association, identity lookup availability, group membership drift, application owner continuity, and break-glass access because drift often appears later as failed releases, blocked sign-ins, missing telemetry, slow migration assessments, VM disk pressure, or poor query behavior. Use lower environments, source-controlled definitions where possible, deployment validation, monitoring, and recovery notes before changing production. Operators should know which tenant, endpoint, policy, appliance, VM, dependency, or downstream application fails first and which metric or log proves the failure. The goal is predictable recovery: detect Directory drift, preserve service, restore safely, and explain the incident without guessing.

Performance

Performance for Directory depends on workload shape, service limits, data volume, network path, diagnostic destination, policy evaluation, disk throughput, trace sampling, SQL distribution, and the monitoring path used to confirm success. Review identity lookup latency, token issuance dependency, large group evaluation, application sign-in patterns, and cross-tenant management before increasing capacity or retrying blindly. The better fix might be correcting access scope, reducing log noise, improving discovery cadence, choosing a different disk SKU, tuning trace collection, or changing table distribution. Measure under representative production conditions. Operators should connect symptoms to evidence: latency, throttling, backlog, failed operations, dropped logs, skew, or stale state.

Operations

Operations for Directory should focus on ownership, observability, and safe repeatability. Standardize names, tags, owner groups, environment labels, diagnostic destinations, runbook links, approval records, and change windows so support teams do not reverse-engineer the platform during incidents. Use read-only CLI, API, policy, diagnostic, or portal checks first, then compare live state with intended configuration. For production, connect alerts, audit events, cost records, graph links, and release notes to the same term. The support question should be simple: who owns it, what changed, and what proves the current state?. Capture owner, scope, evidence, and recovery procedure before changing Directory in a production environment.

Common mistakes

  • Changing production before checking the exact Azure scope, owner, identity, dependency, and rollback or recovery procedure.
  • Treating a portal screenshot as sufficient evidence when CLI output, Activity Logs, diagnostics, and source-controlled configuration are repeatable.
  • Assuming a name match proves the correct resource when tenants, subscriptions, disks, storage accounts, workspaces, and SQL pools can look similar.