Azure Tenants and Directories

An Azure tenant is a dedicated and isolated instance of Azure Active Directory (Azure AD) that an organization receives when it signs up for a Microsoft cloud service, such as Azure, Microsoft 365, or Dynamics 365. Think of the tenant as the top-level container for identity and security—it holds all user accounts, groups, and application registrations for that organization. Every Azure subscription must be associated with exactly one tenant, and that tenant provides the identity backbone for all resources within those subscriptions.

The business problem an Azure tenant solves is identity federation and centralized management. Without a tenant, each Azure subscription would need its own separate user database, making it impossible to have single sign-on (SSO), consistent security policies, or unified auditing across subscriptions. The tenant enables organizations to manage identities once and apply access controls across all their Azure resources.

The mechanism starts when an organization signs up for Azure. Microsoft creates a new Azure AD directory for that organization, which is the tenant. This directory is a cloud-based identity store that implements the same core protocols as on-premises Active Directory (Kerberos, LDAP, etc.) but is fully managed by Microsoft. When a user authenticates to Azure, they are actually authenticating against their tenant’s Azure AD instance.

Behind the scenes, Azure AD uses OAuth 2.0 and OpenID Connect for authentication and authorization. When a user logs in, Azure AD issues a token that contains claims about the user’s identity and group memberships. Azure resources (like VMs, storage accounts, or databases) trust these tokens because they are configured to use Azure AD as their identity provider. The token is passed to the resource, which validates it using Azure AD’s public keys. This process happens automatically and is transparent to the user.

Azure AD comes in four editions: Free, Office 365 Apps, Premium P1, and Premium P2. The Free edition, included with any Azure subscription, provides user and group management, SSO, and basic security reports. P1 adds advanced administration tools like Conditional Access and dynamic groups. P2 adds Identity Protection and Privileged Identity Management (PIM).

A tenant is the identity container, while a subscription is the billing and resource container. A single tenant can have multiple subscriptions, and each subscription is associated with exactly one tenant. Resources (VMs, databases, etc.) live inside a subscription. When you assign a user access to a resource, you are actually granting that user’s tenant-level identity permission to the resource via Azure RBAC (Role-Based Access Control). This separation allows an organization to have multiple subscriptions (e.g., dev, test, prod) while using the same user identities across them.

On-premises Active Directory (AD DS) is a directory service that runs on Windows Server, typically in a corporate data center. It uses Kerberos for authentication and a hierarchical domain structure. Azure AD is a cloud-based identity service that uses REST APIs and modern protocols (OAuth, OpenID Connect, SAML). Unlike on-premises AD, Azure AD does not support computer objects, group policies, or NTLM authentication. It is designed for cloud applications and services, not for managing on-premises computers. However, Azure AD Connect can synchronize users and passwords between on-premises AD and Azure AD, providing a hybrid identity model.

In the Azure portal, you can manage your tenant by navigating to Azure Active Directory (the service name). Here you can create users, groups, register applications, and configure security features like Conditional Access and Identity Protection.

Using the Azure CLI, you can query tenant information:

# List all tenants associated with your account
az account list --query "[].{Name:name, TenantId:tenantId}" --output table

# Get details of your current tenant
az account show --query tenantId

To create a new user in Azure AD via CLI:

az ad user create --display-name "John Doe" --user-principal-name johndoe@contoso.com --password "P@ssw0rd!"

Consider a company called Contoso with 5,000 employees. They have three Azure subscriptions: one for development, one for testing, and one for production. Without a tenant, each subscription would need its own user database, and employees would need separate accounts for each subscription. With an Azure tenant, Contoso creates all user accounts once in Azure AD. They then assign RBAC roles (e.g., Contributor, Reader) to users or groups at the subscription or resource group level. When a new developer joins, they are added to the “Developers” group, which automatically grants them Contributor access to the dev subscription. No manual permission setup is needed per subscription. This centralization reduces administrative overhead and improves security by ensuring consistent identity policies.

A large enterprise like Contoso has 10,000 employees, 4 Azure subscriptions (dev, test, prod, shared services), and multiple departments (HR, Finance, Engineering). The IT team manages all identities in a single Azure AD tenant. They create security groups for each department (e.g., HR-Group, Finance-Group) and assign RBAC roles at the subscription level. For example, HR-Group gets Reader access to the prod subscription, while Engineering-Group gets Contributor access to the dev subscription. When an employee moves from Finance to Engineering, the IT team simply updates their group membership—no need to touch permissions on individual subscriptions. This saves hundreds of hours per year and reduces security risks from stale permissions.

What goes wrong? If the tenant is accidentally deleted (which requires special permissions and confirmation), all users and groups are lost, and all subscriptions become orphaned—they cannot be accessed until a new tenant is associated. Recovery is extremely complex. Therefore, Microsoft requires at least two Global Administrators per tenant and recommends using Privileged Identity Management (PIM) for just-in-time access.

A mid-size company, Fabrikam, uses Salesforce, Slack, and a custom expense application. They want employees to sign in once with their corporate credentials. Fabrikam registers each SaaS application in their Azure AD tenant as an Enterprise Application. They configure SAML-based SSO between Azure AD and Salesforce. When an employee logs into the Azure portal, they see a tile for Salesforce. Clicking it triggers a SAML authentication flow: Azure AD issues a SAML assertion, which the employee’s browser posts to Salesforce. Salesforce validates the assertion using a certificate from Azure AD and logs the user in. No separate username/password for Salesforce is needed.

Cost consideration: Azure AD Free supports up to 10 enterprise applications per user. For more apps or advanced features like Conditional Access, they need Azure AD Premium P1. If they skip licensing, users may face MFA prompts every time, or the SSO integration may not work for all apps.

Company A acquires Company B. Both have separate Azure AD tenants. To collaborate, they can use Azure AD B2B collaboration to invite users from Tenant B into Tenant A as guest users. This allows Tenant A users to share resources (like a storage account) with Tenant B users without requiring Tenant B to migrate. However, guest users have limited permissions by default (e.g., they cannot browse the tenant directory). If the companies eventually merge their IT systems, they can migrate identities from Tenant B to Tenant A using Azure AD tenant-to-tenant migration tools. This is a complex project that involves re-creating users, groups, and RBAC assignments. A common mistake is to assume guest access is sufficient for long-term collaboration, but guest users cannot be assigned Azure roles that require directory-level permissions (like Global Admin).