0.2 How a Tenant Is Put Together

Introduction

A tenant is a small number of object types related in a small number of ways. Users and groups are the people. Applications and service principals are the software. Roles say what administrators may change; policies say how everyone signs in.

Licenses decide which features exist at all. Reading a tenant means being able to say, for each of these, how many there are, where each came from and who controls it.

This lesson reads Northgate Engineering's tenant that way: the tenant and its domains, the users and where each comes from, the groups, the applications and service principals, roles and licenses, the policies, and the evidence this course reads. It ends with the same inventory taken of your own tenant.

A tenant is one dedicated instance of Entra ID, holding one directory of users, groups, applications and policies, and identified by a tenant ID that never changes. Every Microsoft cloud service an organization uses, from Microsoft 365 to Azure, trusts that one directory for sign-in.

The tenant was created in June 2017 and, like every tenant, began with a domain ending in onmicrosoft.com. Northgate later verified its own domains so that users sign in as name@ne.com:

PS C:\> Connect-MgGraph -Scopes "Directory.Read.All" -NoWelcome
PS C:\> Get-MgOrganization |
    Format-List DisplayName, Id, CreatedDateTime, OnPremisesSyncEnabled
PS C:\> Get-MgDomain | Format-Table Id, IsDefault, IsInitial, AuthenticationType

DisplayName           : Northgate Engineering
Id                    : b4c1e7a2-93f5-4d68-8e11-0c5a7f2d9b34
CreatedDateTime       : 6/12/2017 9:14:00 AM
OnPremisesSyncEnabled : True

Id                 IsDefault IsInitial AuthenticationType
--                 --------- --------- ------------------
ne.com             True      False     Managed
ne.co.uk           False     False     Managed
ne.onmicrosoft.com False     True      Managed

The initial domain cannot be removed, which is why it is useful: an account on ne.onmicrosoft.com does not depend on Northgate's own domain or on Active Directory, and the tenant's emergency access account uses it for exactly that reason. Both custom domains are managed, meaning Entra ID checks passwords itself rather than handing sign-in to a federation server.

OnPremisesSyncEnabled says the tenant receives objects from Active Directory. That one property explains much of what follows, because synchronized objects are mastered elsewhere and the tenant holds a copy.

Domains matter to identity in a second way: they decide what a user name looks like and who can be invited. A user whose name ends in a verified domain signs in with that name; a guest keeps the name from their own organization, and appears in the directory with an #EXT# name built on the initial domain.

Reading a user name therefore tells you, at a glance, whether you are looking at a member or a guest and which tenant mastered them.

A tenant can hold many verified domains, and Northgate's two are both Managed. A domain can also be federated, in which case Entra ID sends users with that domain to another identity provider to check their password. Federation changes where sign-in failures happen and which logs record them, so it is the first thing to establish about any domain before troubleshooting a sign-in that uses it.

The tenant ID is also how Northgate is known to other tenants. A partner who trusts Northgate's multifactor authentication, or an application registered by a vendor that Northgate's users sign in to, records this ID, not the name.

The name on the overview page is a label for people; the ID is the identity for systems, and it is the value any script in this course passes when it connects to one specific tenant.

An account in Entra ID is either a member, someone who belongs to the organization, or a guest, someone from outside invited to collaborate. Separately, an account is either synchronized from Active Directory or created directly in the cloud. Counting both at once shows how the tenant was built:

PS C:\> Connect-MgGraph -Scopes "User.Read.All" -NoWelcome
PS C:\> $u = Get-MgUser -All -Property UserType, OnPremisesSyncEnabled
PS C:\> $u | Group-Object UserType, OnPremisesSyncEnabled -NoElement |
    Format-Table Count, Name

Count Name
----- ----
  818 Member, True
    2 Member
    8 Guest

All but two of Northgate's 820 members come from Active Directory. The two cloud-only members are the emergency access account and the account the synchronization service itself uses. The 8 guests are partners and auditors, invited into the cloud directly, as guests always are.

Where an account comes from decides where it is changed. A synchronized user's name, department, manager and password are written in Active Directory, and the next synchronization copies them to the cloud; editing them in the admin center either fails or is overwritten. Disabling a leaver in Active Directory disables their cloud account only after that next cycle, which is normally within half an hour.

Cloud-only accounts are the opposite: they exist only in Entra ID, and nothing on premises can lock them out or change them. That independence is why the emergency account is cloud-only, and why administrator accounts are better cloud-only too. Northgate's two named administrator accounts are synchronized, which ties the tenant's most powerful accounts to Active Directory's own security; this course comes back to that choice.

Disabled accounts are counted too. The output above includes every account, enabled or not, because a disabled account still exists, still holds its group memberships and licenses until someone removes them, and can be enabled again. Counting disabled accounts separately is a later build; for now, the point is that an account's existence and its ability to sign in are two different things.

The member and guest distinction matters as much. Guests get fewer default permissions in the directory, cannot see the full list of users by default, and are the accounts most often forgotten after the work they were invited for ends. A tenant's guest count is worth knowing at all times, and the date each guest last signed in even more so.

Groups are how access is granted at scale. An application, a license, a policy exclusion or a role can be given to a group, and everyone in the group receives it. Northgate has 17 groups, of three kinds:

PS C:\> Connect-MgGraph -Scopes "Group.Read.All" -NoWelcome
PS C:\> Get-MgGroup -All | Group-Object -NoElement { if ($_.OnPremisesSyncEnabled) {
    "Synchronized" } elseif ($_.GroupTypes -contains "DynamicMembership") {
    "Dynamic" } else { "Assigned" } } | Format-Table Count, Name

Count Name
----- ----
   10 Synchronized
    6 Assigned
    1 Dynamic

The ten synchronized groups are Northgate's departments, maintained in Active Directory and copied up. The six assigned groups are cloud-only, with members added by hand: the Conditional Access exclusion groups, the group allowed to use temporary access passes, the passkey pilot, and the group assigned to the site reporting application. The one dynamic group, All Staff, has its members chosen by a rule:

The rule reads each user's type, whether the account is enabled and whether any license plan is enabled, three attributes that Entra ID maintains itself rather than ones a person types. A new member account with a license joins automatically; a disabled one leaves.

Nobody maintains the list, which is the point, and also the risk: a rule written slightly wrong includes or excludes people silently, and the only way to notice is to read the rule and check its result.

Each kind of group is managed in a different place, which matters for every change. A synchronized group's membership is changed in Active Directory. An assigned group's membership is changed in Entra ID by its owners or an administrator.

A dynamic group's membership is changed by editing the rule or the attributes it reads. Knowing which kind of group grants an access is the first step in changing who has it.

Groups can also be nested, a group as a member of another, but nesting does not carry through everywhere. Some features read only direct membership: an application assigned to a group, for example, grants access to that group's direct members and not to the members of groups nested inside it.

That rule surprises people often enough to be worth knowing before relying on any nested design. Assigning an application to a group at all needs P1 or P2; on the free tier, applications are assigned to users one at a time, which is one of the first places a growing tenant feels the difference between license tiers.

The exclusion groups deserve a particular eye. A group that exempts its members from a Conditional Access policy is effectively a permission, and adding someone to it weakens their sign-in without touching the policy. Who can change those groups' membership is as important as who can edit the policies.

Software that signs in to Entra ID, or that people sign in to, is represented by two objects. The application object is the definition: its name, its redirect addresses, the permissions it asks for, its credentials. It lives in the tenant where the application was registered. The service principal is the application's instance in a particular tenant: the object that consent, assignment and sign-in records refer to.

PS C:\> Connect-MgGraph -Scopes "Application.Read.All" -NoWelcome
PS C:\> Get-MgServicePrincipal -All | Group-Object ServicePrincipalType -NoElement |
    Format-Table Count, Name
PS C:\> (Get-MgApplication -All).Count

Count Name
----- ----
   24 Application
    3 Legacy
    1 ManagedIdentity

11

Northgate has 11 application registrations of its own and 28 service principals. Eleven of the service principals belong to those registrations. Five belong to Microsoft's own services, such as Exchange Online, SharePoint Online and Microsoft Graph.

Eight belong to vendors' applications that Northgate's users sign in to, from Zoom to Autodesk Construction Cloud, registered in the vendors' tenants and instanced here. The three legacy service principals predate the current model, and the one managed identity belongs to an Azure resource.

The managed identity is the one kind with no credential anyone can hold. Azure issues its tokens, and deleting the Azure resource deletes the identity with it, which is why the course prefers managed identities wherever a workload runs in Azure.

That split explains where each kind of change is made. A permission an application requests is changed on its registration, in its home tenant, by whoever owns it; for a vendor's application, that is the vendor. What Northgate grants it, who is assigned to it and whether it is enabled are all set on the service principal here, and are Northgate's to decide.

It also explains why a vendor's application can surprise an organization. The vendor can add a new permission request to its registration at any time. Nothing changes in Northgate's tenant until someone consents to the new request, but the next person to sign in may be shown a consent prompt for it, and whether they can accept it depends on Northgate's consent settings.

The default settings are generous. Northgate's authorization policy still allows any member to register applications, to create security groups and to create new tenants, and lets users consent to applications under Microsoft's legacy default rule. Each of those is a decision this course revisits, because each lets an ordinary account create something that later needs governing.

Administrators are given directory roles, as the previous lesson set out. Northgate has 9 active and 8 eligible role assignments, three of them Global Administrator held permanently, and every one assigned across the whole tenant rather than scoped to part of it.

Licenses decide which features exist. Northgate holds one product, Microsoft 365 E5, which includes Entra ID P2:

P2 is what makes Privileged Identity Management, ID Protection's risk policies and access reviews available. It does not include Entra ID Governance, which lifecycle workflows and the more advanced entitlement management features need, so those are a separate purchase that Northgate has not made.

Licensing also changes behavior over time, not only availability. With P1 or P2, sign-in and audit logs are kept for thirty days instead of seven. With P2, the risky users report shows full detail.

When a license lapses, some configuration remains but stops working; Microsoft documents, for example, that eligible role assignments are removed if a P2 license expires while permanent ones are unaffected. Knowing which license a feature depends on is part of designing anything that depends on it.

License assignment itself is a decision with a record. A license can be assigned to a user directly or through a group, and group-based assignment is how most tenants keep licensing consistent: membership of a group decides who is licensed, and a leaver removed from the group loses the license automatically. A user with a license assigned directly keeps it until someone removes it by hand.

The counts matter for planning as well. 811 of 840 seats are assigned, so the tenant has room for 29 more people before buying more. Many identity features are licensed per user who benefits, so a feature switched on for everyone assumes everyone is licensed for it, which is easy to check here and expensive to discover in an audit.

Sign-in policy in Entra ID comes from one of two places. Security defaults are a fixed set of protections Microsoft provides to every tenant: every user registers for multifactor authentication, administrators always use it and other users when necessary, legacy authentication and device code flow are blocked, and access to admin portals is protected.

Conditional Access replaces them with policies the organization writes itself, which needs P1. Security defaults can only be turned on in a tenant with no Conditional Access policies, so the two do not run together, and Northgate has security defaults turned off and 5 Conditional Access policies instead:

PS C:\> Connect-MgGraph -Scopes "Policy.Read.All" -NoWelcome
PS C:\> Get-MgIdentityConditionalAccessPolicy -All | Format-Table DisplayName, State

DisplayName                                       State
-----------                                       -----
Block legacy authentication                       enabled
Require MFA for all users                         enabled
Require MFA for guest access                      enabled
Require compliant device for Exchange             enabled
Require phishing-resistant MFA for administrators enabledForReportingButNotEnforced

Four policies are enforced and one is in report-only mode, which evaluates every sign-in and records what it would have done without enforcing anything. Report-only is how a new policy is tested on real traffic before it can lock anyone out, and the phishing-resistant policy for administrators is sitting in that state now.

Report-only results appear in every sign-in record, so the evidence for turning a policy on is already being collected. A sign-in that would have failed the policy is marked reportOnlyFailure; one it would have passed, reportOnlySuccess. Reading those results for a week or two shows exactly who the policy would block before anyone is blocked.

Policies do not run in an order. Every policy whose conditions match a sign-in applies at once, and the sign-in must satisfy all of their controls together.

A block in any policy that applies wins over everything else. So a new policy can never loosen what an existing one demands; it can only add to it, which makes adding policies safe in one direction and makes exclusions the only way any policy is relaxed.

Reading policies is reading conditions and exclusions as much as controls. A policy that requires multifactor authentication for all users is only as strong as its exclusion list, and Northgate's excludes three groups and the synchronization role. Each exclusion has a reason, and a later module reads every one of them.

That is the tenant as this course begins. Each count is a starting point that a later lesson examines and, in most cases, changes, and each module's evidence shows the tenant at the moment that lesson describes.

The configuration in each lesson comes from exports of Northgate's tenant in the form Microsoft Graph returns it, and the activity from its sign-in, audit and provisioning records. Graph PowerShell output is shown as the console prints it, including its column layout, so that what you see in your own tenant looks the same.

Every activity in the course carries one of two labels. A build card is done in a tenant you control. Everything else is analyzed from Northgate's supplied evidence. Nothing is presented as a demonstration you watch.

Where a lesson needs something the base exports do not contain, such as a particular failed sign-in or a provisioning entry, the lesson adds it and says so. The additions are consistent with the rest: the same users, the same groups, the same addresses and the same dates, so a person who appears in one lesson's evidence appears identically in another's.

Each lesson's evidence is fixed in time. A lesson early in the course shows the tenant before the changes later lessons make, and a later lesson shows the result of the earlier ones. That is why a count can differ between lessons: the tenant has moved on. Where a lesson relies on a state, it says when the state was read.

The evidence is also there to be challenged. Each lesson states what a record shows and what it does not, and the build cards ask you to check the same claim in your own tenant. Where your tenant behaves differently, the difference is worth understanding rather than dismissing, because Microsoft changes portals and defaults often and your tenant is newer than any course.

All names, domains and addresses are invented. The domains belong to no real organization, and IP addresses come from the ranges reserved for documentation, so nothing in the evidence points at a real system. The structure, the attribute names and the shape of every record are Entra ID's own.

The build takes the same inventory of your own tenant. Nothing in it changes anything.

PS C:\> Disconnect-MgGraph

Keep the baseline. Later builds change several of these counts, and comparing against the baseline is how you confirm each change did what it should and nothing more.

A tenant is users, groups, applications and service principals, roles, policies and licenses, each counted, each with a source and an owner. Synchronized objects are changed in Active Directory; cloud objects in Entra ID.

Applications are defined once and instanced in each tenant that uses them. Licenses decide which features exist and how long logs are kept. If you do one thing in your own tenant, count your Global Administrators and write down why each one needs the role.

Resources

Microsoft revises these pages; where a page and this lesson disagree, the page is newer.

• Microsoft Learn: Security defaults
• Microsoft Learn: Application and service principal objects
• Microsoft Learn: What is hybrid identity?
• Microsoft Learn: Microsoft Entra licensing