0.3 A Tenant You Control

Introduction

The practice in this course is configuring Entra ID: creating users and groups, writing Conditional Access policies, registering applications, assigning roles, and reading back what each change recorded. Almost all of that changes the whole tenant, so it needs a tenant you control and nobody else depends on.

This lesson covers why the practice needs its own tenant, how to get one when Microsoft restricts who can create them, which licenses each part of the course needs and what they cost, why the logs must be exported from the first day, how to do the course without a tenant, and how to delete the tenant when you finish.

Most of what an identity administrator configures applies to the whole tenant. A Conditional Access policy targets all users unless it excludes them. An authentication methods policy decides what every user may register. Consent settings decide what every user may grant. A role assignment gives someone power over everything in its scope, which for most roles is the whole directory.

That makes a production tenant the wrong place to practice. A policy written slightly wrong in a lab locks out a test user; the same policy in production locks out a company. It also makes a shared tenant a poor place: two learners writing Conditional Access policies at the same time each change what the other's sign-ins do, and neither can tell which result came from their own change.

A third reason is less obvious. Some of the course's builds are meant to break things on purpose, in order to read how Entra ID records the failure: a sign-in blocked by a policy, a user who is not assigned to an application, an activation that waits for an approver. Breaking things deliberately is only safe where the only people affected are the test users you created for it.

A tenant of your own avoids both. Its first account, the one that created it, is automatically a Global Administrator, so every build in the course is possible. Its users are test users, so a mistake costs nothing but a reset. And its logs record only your actions, so reading back a change shows that change and nothing else.

The tenant also keeps the course honest. Each build ends by reading what the change recorded, and in a tenant with nobody else in it, every sign-in and audit entry is yours to explain. That makes it an unusually clear place to learn what the records mean, before reading them in a tenant where thousands of people are signing in at once.

Keep the lab separate from everything else you use. Do not synchronize it with a production Active Directory, invite real colleagues into it, or connect it to real applications that hold real data. Each of those would bring someone else's dependency into a tenant whose value is that nothing depends on it.

Creating a tenant is not open to everyone. Microsoft's documentation states that only paid customers can create a new workforce tenant, and that customers on a free tenant or a trial subscription cannot create additional tenants from the admin center. Its suggested route for them is signing up for a free Azure account, which creates a tenant as part of signing up.

That restriction is why this course does not tell you to "create a free tenant". For many learners that instruction fails at the first screen. The routes that work depend on where you start:

If your organization is a paid Microsoft customer and allows it, creating a tenant from the admin center is the quickest route. The setting that allows ordinary users to create tenants is in the tenant's user settings; if it is off, the Tenant Creator role permits it. Either way, ask first: an organization that has switched creation off usually wants to know who is creating tenants and why.

If not, the free Azure account route gives you a tenant and an Azure subscription together, and the subscription is useful later for exporting logs and for the workload identity builds. Read its terms before signing up, so you know what is free, for how long, and what happens when the free period ends.

A tenant created for a course should be named so nobody mistakes it for anything else. An organization name with "Lab" in it, and an initial domain that says the same, keep it obviously separate from your employer's tenant in every sign-in prompt and account picker, which matters when you hold accounts in both and are about to make a tenant-wide change.

Whichever route you take, record the tenant ID and the initial domain name as soon as the tenant exists. The ID is what scripts connect to, and the initial domain, ending in onmicrosoft.com, is where the course's emergency and test accounts live.

A new tenant has Entra ID Free. That covers users, groups, application registration and assignment to individual users, and seven days of sign-in and audit logs. Much of the first part of the course works on Free.

Entra ID P1 adds Conditional Access, assignment of applications to groups, dynamic groups and thirty days of logs. P2 adds ID Protection's risk policies and full reports, Privileged Identity Management, and access reviews.

Entra ID Governance, which needs P1 or P2 alongside it, adds lifecycle workflows and the more advanced entitlement management features. Workload ID is licensed separately, per workload identity, and is needed only for Conditional Access and ID Protection applied to workloads.

These boundaries move. Microsoft adds features to each tier and occasionally moves one between tiers, and its licensing page is updated when it does. The build cards state the tier each build needed when the course was written; if a feature is unavailable in your tenant at the stated tier, the licensing page is the place to check before assuming a fault.

Mapped to the course: the tenant, lifecycle and authentication modules mostly run on Free and P1. Conditional Access needs P1. The risk and privileged access builds need P2. Lifecycle workflows need Governance. Every build card names the license it needs, so you buy what a module needs when you reach it rather than everything at the start.

Northgate's tenant shows how most organizations hold P2: inside a Microsoft 365 suite rather than as a separate purchase.

PS C:\> Connect-MgGraph -Scopes "Organization.Read.All" -NoWelcome
PS C:\> Get-MgSubscribedSku | Format-Table SkuPartNumber, ConsumedUnits,
    @{n="Enabled";e={$_.PrepaidUnits.Enabled}}

SkuPartNumber ConsumedUnits Enabled
------------- ------------- -------
SPE_E5                  811     840

Microsoft 365 E5 includes Entra ID P2, so every licensed Northgate user has it. It does not include Governance; Microsoft lists the Governance features as part of the Entra Suite and Microsoft 365 E7, not E5. A lab tenant reads the same way:

Licenses are added to a tenant from the Microsoft 365 admin center or the Azure portal, then assigned to users or to a group. Assigning them to a group of test users, rather than to each user, means a new test user picks up the right licenses by joining the group, which is the same pattern an organization uses at scale.

Licensing is per user who benefits in most cases, not per tenant. Privileged Identity Management, for example, needs a P2 or Governance license for each user with an eligible assignment and each user who approves activations. For a lab, that means licensing the handful of test users the builds use, not every account in the tenant.

When a license lapses, Microsoft does not always remove what it enabled. Conditional Access policies stay but can no longer be edited; eligible role assignments are removed while permanent ones remain. A lab that runs on a trial should be finished, or the trial converted, before the trial ends, or later builds meet configuration that half-works.

Microsoft lists Entra prices per user per month, paid yearly. On 3 November 2026 its pricing page showed P1 at $7, P2 at $10, Governance at $7 for customers who already have P1 or P2, the Entra Suite at $12, and Workload ID at $3 per workload identity. The page offers free trials of P1, P2 and Governance without stating their length on the page itself.

For a lab of 5 test users, the arithmetic is small:

Azure costs are separate and usage-based. Exporting logs to a Log Analytics workspace is billed by the volume ingested, and a lab with a few test users ingests very little. Azure Automation is billed by job run time, and a weekly runbook uses minutes a month. Neither needs to be bought in advance, and both can be capped with a budget alert on the subscription.

The cheapest order is to start on Free, add P2 for the test users when the course reaches risk and privileged access, and add Governance only for the lifecycle workflow builds. Trials can cover each stage if timed to it. Everything before Conditional Access can be done with no license purchase at all.

Compare that with what the same features cost an organization. Northgate's 840 Microsoft 365 E5 seats include P2 for every licensed user, which is why a company of its size rarely buys Entra ID licenses on their own: the identity features arrive with the productivity suite.

A lab is the opposite case, with a handful of users and no suite, so standalone licenses for a few accounts are the cheaper way to reach the same features.

Two costs are easy to miss. A license bought with an annual commitment is paid for the year even if you finish the course in two months, so check the terms before buying rather than after. And a trial converted automatically into a paid subscription keeps charging after the course ends, so put the trial end dates in a calendar on the day you start them.

Entra ID keeps sign-in and audit logs for seven days on Free and thirty days on P1 or P2. Upgrading does not recover anything older; it only lengthens how long new records are kept. Microsoft Graph activity logs, which record every Graph call made in the tenant, are not kept at all unless exported, and need P1 or P2.

For a course taken over several weeks, that is a practical problem. A build done in week one and read back in week four has no record left in Entra ID, even with P2. The fix is to export the logs to a Log Analytics workspace from the day the tenant is created, so every record of every build is kept for as long as the workspace keeps it:

The setting takes effect for new records only. Records already in Entra ID stay there for their seven or thirty days and are not copied across, so the earlier the setting exists, the more of the course's history the workspace holds.

A diagnostic setting needs Security Administrator and an Azure subscription to hold the workspace. Export at least the audit and interactive sign-in logs; the non-interactive, service principal and managed identity sign-in logs are worth adding when the course reaches workloads. Each category is a separate checkbox, and an unticked category is simply not kept.

The workspace has its own retention, set on the workspace, and its own cost, billed for what it ingests and for retention beyond the included period. For a lab, the default retention is plenty; for an organization, the retention is a decision about how far back an investigation needs to reach, which a later module makes for Northgate.

Exporting also gives you KQL. Several builds read the workspace rather than the portal, because a query can join sign-ins to audit events and filter them in ways the portal's log screens cannot. Having the workspace in place before those lessons means the data they query already exists.

Not everyone can get a tenant, and nobody should be shut out of the course for that. Every build card has a "Without a tenant" line that turns the build into a written plan, and every lesson shows Northgate's configuration in enough detail to check the plan against.

A build plan is a real deliverable. It is what an engineer writes before a change request is approved: what will be created, with which settings, in which order, and how anyone will know it worked. Writing one for each build practices the decisions even where it cannot practice the clicks.

Plans can also be checked more strictly than clicks. A setting chosen in a portal is easy to change without noticing; a setting written in a plan, with its reason beside it, can be read back weeks later and still makes sense. Several builds in the course ask for the reason as well as the value for exactly that reason.

The comparison is the learning step. Where your plan and Northgate's configuration differ, the difference is either a mistake, in which case the lesson shows why, or a choice you can defend, in which case you have understood the trade-off better than by copying. The exercises at the end of each module are analyzed from evidence in any case, so they work the same with or without a tenant.

Northgate's evidence also lets the plan be tested against outcomes. Where a lesson shows the sign-in a policy produced, or the audit entry a change wrote, a plan can be checked against that record: would your settings have produced the same result, or a different one, and why. That is as close to running the build as reading allows.

What the route cannot give is the experience of a change failing in an unexpected way and having to read the records to find out why. That experience is the main reason to get a tenant if you can, even a short-lived one for the modules you care about most.

A lab tenant that is finished with should be deleted, so that its licenses stop costing money and its accounts stop being a target. Deleting a tenant deletes everything in it, and Microsoft only allows it after a set of checks pass:

The checks are deliberate. Every user except the one Global Administrator doing the deletion must be removed, and synchronization turned off first if it was on. Every application must be removed. Every subscription, including Entra ID P1 or P2 and any Microsoft 365 trial, must be fully deprovisioned, not merely expired or canceled, which can take some time after cancellation.

The order matters in practice. Remove the users with Graph rather than one at a time in the portal, since the builds create several. Remove application registrations and the enterprise applications created by consent, including the one Graph PowerShell itself creates the first time you connect. Cancel the license subscriptions and wait for them to reach the deprovisioned state. Only then do the checks pass and the delete button complete.

A tenant created through a free Azure account is tied to that Azure subscription, which also has to be canceled or moved before the tenant can go. If you intend to keep the Azure subscription for other work, leaving the tenant in place, with its test users deleted and its licenses canceled, is a reasonable alternative to deleting it: an empty tenant with no paid products costs nothing.

Whichever you choose, check the emergency access accounts last. They are the accounts that let you back in if something in the teardown goes wrong, so they are removed only when nothing else is left.

Plan the teardown when you start. Keep a list of what you bought, with its end date, and of what you connected the tenant to, such as an Azure subscription or a test application elsewhere. The list turns teardown from a search into a checklist, and it is the same discipline a real identity team needs when it retires anything.

The build creates or chooses the tenant the rest of the course runs in, and starts its log export on the first day.

Keep the tenant ID, the license plan and the teardown list together, in one place you will still find at the end of the course. Every later build card assumes them.

The course needs a tenant you control, because the changes it teaches apply to the whole tenant. Only paid customers can create workforce tenants from the admin center, so the route depends on where you start.

Buy licenses module by module, for a handful of test users, and export the logs on the first day because retention is short and not retroactive. Without a tenant, write each build as a plan and compare it with Northgate's configuration. If you do one thing today, decide which route gets you a tenant and record its ID.

Resources

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

• Microsoft Learn: Create a new tenant in Microsoft Entra ID
• Microsoft Learn: Microsoft Entra licensing
• Microsoft Learn: Microsoft Entra data retention
• Microsoft: Microsoft Entra plans and pricing
• Microsoft Learn: Delete a tenant in Microsoft Entra ID