Module 3 ended with an uncomfortable list: passwords typed in by hand, secrets inside connection strings and broad permissions "because it was the quick way". Today the work of paying off that debt begins, and it begins in the right place. In classic infrastructure, security was built on the perimeter: if you were inside the Barcelona office network, you were trusted. In Azure that perimeter does not exist — Marta Ríos administers production from a laptop in an airport, and app-contoso-reservas-pro runs in a data center no one at Contoso Airlines has ever set foot in — so identity becomes the perimeter. Every call to the Azure API, every query against db-reservas and every read of a blob in sttarjetascontosopro is authorized according to who is making it. And that "who" is defined by a single service: Microsoft Entra ID. All the security in the rest of the module — RBAC, managed identities, Key Vault, Defender for Cloud — rests on what you build today.

Important warning: the identity decisions in this lesson (Conditional Access, mandatory MFA, geographic blocks, privileged roles) affect who can get into the company's systems and carry legal and compliance implications. Before applying any configuration of this kind in production, it must be reviewed by a security professional or by your organization's compliance team. A badly judged policy can lock out your entire workforce or open a door you thought was closed.

1. Identity as the perimeter
2. What Microsoft Entra ID is and how it differs from Active Directory
3. Tenant, directory and subscriptions
4. Identity types in Entra ID
5. Contoso's users and groups with Azure CLI
6. Dynamic groups by attribute
7. Authentication: passwords, MFA and passwordless
8. Conditional Access: the decision engine
9. Privileged Identity Management and roles on demand
10. Entra ID roles versus Azure roles: clearing up the confusion
11. Entra External ID for passengers
12. Access reviews and hybrid identity
13. Common Mistakes and Tips
14. Exercises
15. Conclusion

The zero trust model boils down to three principles worth keeping in mind throughout the module:

• Verify explicitly: authenticate and authorize using every available signal (user, device, location, risk), not just a correct password.
• Least privilege: grant the smallest permission that lets someone work, and for the shortest possible time.
• Assume breach: design as though the attacker were already inside, segmenting and logging everything.

Translated into Contoso's terms: Diego Salas knowing the database password should not be enough to read the bookings, and an attacker stealing portal credentials should not hand them access to the production subscription. The three principles will take concrete shape in concrete tools: authentication today, authorization and passwordless identities in 04-02, and in 04-06 the rules nobody can sidestep.

Microsoft Entra ID (the service known for years as Azure AD; stop using that name) is Microsoft's cloud identity and access service. It is what authenticates the people who open the Azure portal, the people who use Microsoft 365 and the applications that call protected APIs.

The most widespread conceptual error is thinking that Entra ID is "Active Directory hosted in the cloud". It is not: they are different products, with different protocols and different models.

The practical consequence for Contoso: the on-premises AD in the Barcelona office is still needed for the printers, the file shares and the domain-joined machines; Entra ID does not replace it. What it does is coexist with it and become the identity authority for everything that lives in Azure and on the internet. How the two are synchronized is section 12.

Three concepts that get confused daily:

• Tenant: a dedicated instance of Entra ID belonging to one organization. Contoso has one: contosoairlines.example, with its identifier (a GUID). It is the identity boundary.
• Directory: the contents of the tenant — users, groups, applications, devices. In practice the two words are used interchangeably.
• Subscription: a billing and resource container in Azure. Contoso Airlines - Producción and Contoso Airlines - Desarrollo are two separate subscriptions.

The key relationship: a subscription trusts exactly one tenant, and that tenant authenticates whoever tries to get in. A tenant, on the other hand, can hold many subscriptions. Contoso's two subscriptions trust the same tenant, which is why Marta Ríos has a single identity for both, even though her permissions in each one differ.

If you move a subscription to another tenant (a real, occasional operation during mergers), every role assignment is lost, because they pointed at identities in the previous tenant. The resources are still there; the access is not.

Anything that can authenticate is called a security principal. There are four families:

Two distinctions that save mistakes:

• App registration versus service principal: the registration is the global definition of the application (its identifier, its permissions, its redirect URIs); the service principal is the instance of that application inside one specific tenant, and it is the service principal that receives role assignments. An app registered at Contoso and used by another company has one registration and two service principals.
• Security groups versus Microsoft 365 groups: only the former can be used to assign Azure permissions. And if a group is going to receive directory roles, it has to be created with isAssignableToRole turned on; that property cannot be changed afterwards and it means only privileged administrators can modify the group's membership.

Managed identities are the piece that removes passwords from applications, and they deserve a lesson of their own: they are covered in full in 04-02. Here it is enough to know they exist and that they are service principals whose lifecycle Azure manages.

Contoso organizes access around four security groups. Contoso-DBA-Reservas has existed since lesson 03-02, where it was designated as the Microsoft Entra ID administrator of sql-contoso-reservas-pro.

--force-change-password-next-sign-in true is mandatory on any account creation: the password you type must not survive the first sign-in. Note too that --department is not decorative: it will be used in section 6 for dynamic membership.

The golden rule, which will come up again in 04-02: permissions are assigned to groups, never to people. When Diego Salas moves to another team, his access changes with a group member remove, not by reviewing fifty role assignments scattered across two subscriptions.

A dynamic group works out its membership from a rule over the user's attributes. Nobody adds or removes anyone: when HR changes the department on the record, membership is recalculated on its own (within minutes, not instantly).

Watch out for two things: dynamic groups require an Entra ID P1 license, and a badly written rule can empty the group (and with it the permissions of half a team) without warning. Contoso uses them for broad, descriptive memberships — "everyone in the development department" — and keeps manual assignment for groups with real privilege, such as Contoso-Infraestructura.

The real recommendation, without decoration: MFA for 100% of users and phishing-resistant passwordless methods for anyone with privileges. SMS is not genuine MFA against a determined attacker, but it is infinitely better than nothing. Contoso issues FIDO2 keys to the four members of Contoso-Infraestructura and passwordless Authenticator to everyone else.

Complements worth knowing: self-service password reset (SSPR), which takes 30% of its tickets away from the help desk; password protection with a banned-terms list (contoso, airlines, reservas); and Identity Protection (a P2 license), which scores the risk of every sign-in — impossible travel, anonymous IP, leaked credentials — and feeds the policies in the next section.

Conditional Access is a rules engine evaluated after successful authentication and before the token is granted. Its structure is always the same: if these signals are present, then I require these controls.

The usual grant controls are: require MFA, require a compliant or hybrid Microsoft Entra joined device, require an approved client app, require terms of use, or block outright. There are also session controls: sign-in frequency and non-persistent browser session.

Two concrete Contoso policies:

Policy 1 — mandatory MFA for administrators. It applies to the privileged directory roles (Global Administrator, Security Administrator, Application Administrator) and to Contoso-Admins-Entra, across all cloud apps, requiring MFA and a sign-in frequency of 8 hours.

Policy 2 — geographic block. Contoso Airlines operates in Spain, Portugal, France and Italy, and its staff travel to those destinations. A named location is created with those countries and access from anywhere else is blocked, applied only to employees (not to guests, who are handled separately). It is not foolproof — a VPN gets around it — but it wipes out the background noise of automated attempts from other continents in one move.

The rule you must never skip: always create an emergency access account (break-glass) that is excluded from every Conditional Access policy. Two accounts, in fact: with no phone-based MFA, with an extremely long password kept in a sealed envelope or a safe, with a permanent Global Administrator role, and with an alert that notifies the whole team if it is used. The reason is simple: a badly written policy, an MFA provider outage or a federation failure can lock you out of your own tenant with no way back in to fix it. It has happened to large organizations and there is no quick fix.

Every new policy is deployed first in report-only mode, which evaluates it and logs the result without enforcing it. You review the affected sign-ins for a week or two, correct the exclusions you need, and only then turn it on. It is the same "detect before you block" pattern you will see in 04-04 with the WAF and in 04-06 with Azure Policy.

Marta Ríos being Owner of the production subscription permanently means that if her session is stolen on any given Tuesday at three in the afternoon, so is the attacker. Privileged Identity Management (PIM), included in Entra ID P2, changes the model: roles go from assigned to eligible, and whoever needs them activates them for a limited period.

PIM works with both Entra ID roles and Azure roles (RBAC), and it is complemented by alerts (too many Global Administrators, roles activated outside working hours) and by the access reviews in section 12. Contoso applies it to Owner, User Access Administrator and Global Administrator: nobody holds those at rest.

This is the classic confusion, and it is worth breaking right now with a single sentence: they are two completely separate permission systems that do not inherit from each other.

The example that settles it: an Entra ID Global Administrator cannot, by default, read a blob in sttarjetascontosopro. They govern the directory, not the resources. (They can grant themselves that access by turning on the elevate-access option, and that is logged — precisely because it is exceptional.) And the reverse: the Owner of the production subscription cannot create users or change MFA policies. Azure roles and their whole authorization model are the entire subject of lesson 04-02.

The thousands of passengers who register on Contoso Bookings must not be users of the corporate tenant. Mixing customers and employees in the same directory is a design error with immediate consequences: the Conditional Access policies designed for staff would apply to customers, licensing costs would explode and the user list would be unmanageable.

The answer is Microsoft Entra External ID in its customer configuration (CIAM), a separate tenant dedicated to external identities:

B2B (guest) users are the third category, and they should not be confused with the other two: the external PCI DSS auditor who turns up in 04-05 is invited into the corporate tenant as a guest, with her own identity at her own company, without Contoso managing her password.

Permissions accumulate: somebody joins a project, gets access, the project ends and the access stays. Access reviews (P2) automate the cleanup: every quarter, the owner of Contoso-Infraestructura receives the list of members and has to approve or remove each one, with the option of automatically removing anyone who gets no response. Contoso schedules them over the four groups, over the B2B guests and over PIM's privileged roles.

That leaves the on-premises AD in Barcelona. Microsoft Entra Connect (and its successor, Entra Cloud Sync) synchronizes users and groups from the on-premises AD into Entra ID, so that every employee has a single identity. There are three authentication models — password hash synchronization (recommended for simplicity and resilience), pass-through authentication and federation with ADFS — and one golden rule: synchronization is one-way towards the cloud for user objects, so the on-premises AD remains the source of truth and changes are made there. This is deliberately an introduction: setting up Entra Connect is a project in itself, and here you only need to know where it fits.

• Not having an emergency access account. This is the mistake that can lock you out of your tenant permanently. Create it today, document where the credential lives and test it every six months.
• Turning on a Conditional Access policy straight into production. Always use report-only mode first. A policy requiring a compliant device before any devices have been enrolled locks out the whole workforce in five minutes.
• Assigning permissions to people instead of groups. It works on day one and it is ungovernable by month twelve.
• Confusing Entra ID roles with Azure roles. If somebody "is an administrator" and cannot read a blob, that is not a bug: they are different systems (section 10).
• Registering customers in the corporate tenant. Use Entra External ID; separating now is far cheaper than migrating later.
• Having ten permanent Global Administrators. The target is between two and four, and with PIM none of them at rest.
• Creating an ordinary group and finding out later that you needed it role-assignable. isAssignableToRole cannot be changed: the group has to be recreated.
• Tip: turn on smart lockout and password protection before anything else; they are free and they stop the cruder brute-force attacks.
• Tip: Entra ID sign-in logs are only kept for 7 or 30 days depending on the license. Send them to Log Analytics (07-02) from day one; the day you investigate an incident, you will be grateful for six months of history.

The "Contoso Miles" project (centro-coste=CC-2077) is starting with: five in-house developers, two consultants from an external company who will work for six months, an application service that has to read a blob, and around 80,000 customers who will check their miles on a public website.

1. State which identity type corresponds to each of the four groups of people.
2. Which groups would you create, and which of them would be dynamic?
3. What measure would you schedule for the external consultants, knowing the project runs for six months?

Contoso wants to require MFA from all administrative staff and block access from outside Spain, Portugal, France and Italy.

1. List the signals and the controls for each of the two policies.
2. Which identities would you exclude without exception, and why?
3. Describe the rollout process so that nobody is blocked by mistake.

Explain the cause and the fix for each situation:

1. Marta Ríos is a Global Administrator and cannot download a boarding pass from sttarjetascontosopro; the portal tells her she is not authorized.
2. A developer who left the company four months ago still shows up with access to rg-contoso-reservas-dev.
3. After the geographic block policy is turned on, the nightly deployment pipeline starts failing with an authentication error.

Solution 1:

1. The five developers, member users of the corporate tenant. The two consultants, guest (B2B) users: they keep their identity at their own company and Contoso manages neither their passwords nor their joiners and leavers. The service that reads the blob, a managed identity (04-02), never a user with a password. The 80,000 customers, an Entra External ID tenant separate from the corporate one.
2. Contoso-Millas-Desarrollo with the five in-house people and Contoso-Millas-Externos with the two consultants, kept apart because they will have different permissions and because the second is reviewed separately. The first can be dynamic on department plus a project extensionAttribute; the external one, manual, because privilege and a fixed end date demand explicit control.
3. A quarterly access review over the external group with automatic removal if the reviewer does not respond, plus an expiry date on the B2B invitation. What matters is that offboarding does not depend on somebody remembering.

Solution 2:

1. MFA policy: signals = membership of privileged directory roles and of Contoso-Admins-Entra, across all cloud apps; controls = require MFA and a sign-in frequency of 8 hours. Geographic policy: signals = all member users, any application, a location other than the named location "Countries of operation"; control = block.
2. The emergency access accounts, always and in both policies. On top of that, the service principals of the automated pipelines, which cannot do MFA and whose source IP is a Microsoft-hosted agent in whatever region it happens to be; for those you use workload identity policies with trusted IPs, not user policies.
3. Create both in report-only mode, wait one to two weeks and analyze the sign-in logs to see who would have been blocked. Correct the exclusions, tell the workforce about the change, turn on the MFA policy first (less disruptive) and the geographic one a week later. And check beforehand that the emergency account works.

Solution 3:

1. This is not a fault: Entra ID roles do not grant access to resource data. Global Administrator governs the directory. She needs the Azure role Storage Blob Data Reader on the account or the container (04-02), or to use elevate access, which is logged and is exceptional.
2. Lifecycle governance is missing: the HR leaver did not propagate to Azure. Immediate fix, remove the assignment and disable the account; structural fix, synchronize joiners and leavers from the HR system, use groups instead of individual assignments and schedule periodic access reviews.
3. The pipeline authenticates with a service principal that the policy, applied to "all users", also evaluates; its traffic leaves from an agent hosted outside the permitted countries. Fix: explicitly exclude that service principal, or move to self-hosted agents with a fixed IP declared as a trusted location. This is the underlying reason for report-only mode.

Identity is the perimeter, and you now know why: in Azure there is no trusted network inside which anything goes, so every access is decided by who is asking. You have seen that Microsoft Entra ID is not Active Directory in the cloud but a different service — flat, based on OAuth 2.0, OpenID Connect and Microsoft Graph — that coexists with the on-premises AD in Barcelona instead of replacing it. You can tell tenant, directory and subscription apart, and you know a subscription trusts exactly one tenant. You know the security principals — member users and B2B guests, security groups and role-assignable groups, app registrations and service principals — and you have created the groups Contoso-Infraestructura, Contoso-Desarrollo, Contoso-Operaciones and Contoso-Admins-Entra alongside the existing Contoso-DBA-Reservas, with the rule that governs everything ahead: permissions are assigned to groups, not to people.

On authentication you have the real recommendation — MFA for everyone and phishing-resistant passwordless methods for anyone with privileges — plus Conditional Access with its signals and controls, Contoso's two policies, and the warning that admits no exceptions: an emergency access account excluded from everything, and deployment in report-only mode before enforcing. With Privileged Identity Management you understand why nobody should be a permanent Owner and what activating a role on demand means. And you have cleared up the classic confusion: Entra ID roles govern identities and Azure roles govern resources, with no inheritance between them. The lesson closes with Entra External ID for passengers, the access reviews that prevent permissions accumulating silently, and Entra Connect as the bridge to the on-premises AD.

Well-governed identities now exist, but they still say nothing about what each one may touch: Contoso-Desarrollo still has no permissions, and app-contoso-reservas-pro still connects to db-reservas and to sttarjetascontosopro with secrets in its configuration. In the next lesson, RBAC and managed identities, you will build Azure's authorization system — the triad of principal, role and scope — discover why the Contributor role does not let you read a blob, create the custom role "Operador de Reservas de Contoso" and give the application a managed identity it can authenticate with without a single password.