Identity in Azure: Microsoft Entra ID, sign-in methods, external identities and Conditional Access

Why this matters

In the cloud, the network edge is no longer the main thing standing between an attacker and your data. Staff sign in from home, from phones and from partner offices, to applications that run in Microsoft's datacenters and in other companies' clouds. What decides whether a request gets in is the identity behind it. If that identity is a reused password with nothing else checking it, one phishing email is enough. Identity is where most cloud security starts, and Microsoft Entra ID is where Azure keeps it.

A manager needs this lesson to understand why "one account per person" makes a leaver's last day safe. A salesperson needs it to answer a customer who asks how partners and members of the public will sign in to a new application. A junior administrator needs to know which service gives a legacy server its domain, which sign-in method suits shared hospital workstations, and how to demand a second factor only when a sign-in looks unusual. Without it, companies either lock everyone out with friction or let everyone in with a password.

The lesson

Directory services: Microsoft Entra ID and Microsoft Entra Domain Services

Microsoft Entra ID is Microsoft's cloud-based identity and access management service. It was renamed in 2023, so older material may use its former name, but the service is the same. Each organisation gets its own instance, called a tenant, which holds its users, groups and application registrations.

What Entra ID does:

• Authenticates users who sign in to Azure, Microsoft 365 and thousands of other cloud applications.
• Provides single sign-on to those applications (see the next section).
• Registers and manages the devices people use, so policies can check whether a device belongs to the organisation.
• Supports identity protection, spotting risky sign-ins such as one from an unfamiliar place moments after another.

Many companies already run Active Directory Domain Services on premises. To give staff one identity in both places, Microsoft Entra Connect synchronises users and groups, and optionally password hashes, from the on-premises directory into Entra ID. Microsoft Entra Cloud Sync is a lighter agent for the same job.

Entra ID is built for modern sign-in over the web. It does not, on its own, give servers a traditional domain to join or apply group policy to them. Legacy line-of-business applications often need exactly that: domain-joined servers, Kerberos or NTLM authentication, LDAP lookups and group policy.

That is the job of Microsoft Entra Domain Services. It provides a managed domain with domain join, group policy, LDAP and Kerberos authentication, and Microsoft deploys, patches and runs the domain controllers. A company moving a legacy application onto Azure virtual machines can use it without building domain controllers of its own.

Two facts about how the two services relate:

• Domain Services builds on an existing Entra tenant. It does not replace Entra ID for cloud application sign-in.
• Synchronisation runs one way, from Entra ID into the managed domain. Users, groups and credentials flow in, so people keep the same password. Changes made inside the managed domain do not flow back. No administrator has to recreate users by hand.

Ways to sign in: single sign-on, multifactor and passwordless

These are three different ideas, and the exam likes to swap them.

Single sign-on (SSO) means a user authenticates once, with one identity, and then reaches every application that trusts that identity without signing in again. An employee signs in each morning and opens Microsoft 365, the Azure portal and several SaaS applications with no further prompts. SSO also helps security teams. When an employee leaves, disabling that one Entra account cuts off every connected application at once. With separate accounts in every app, someone has to find and remove each one, and applications do not tidy up stale accounts on their own.

Multifactor authentication (MFA) asks for two or more different kinds of evidence:

• Something you know: a password or PIN.
• Something you have: a phone that receives an approval request, or a hardware key.
• Something you are: a biometric such as a fingerprint or face scan.

A password followed by an approval in a phone app combines something you know with something you have. Two passwords are still only one kind of factor. MFA does not remove repeated sign-ins across applications; that is SSO.

Passwordless authentication removes the password altogether and replaces it with something the user has, combined with a biometric or PIN. Organisations adopt it because passwords are what attackers phish, guess and reuse, and because it is quicker for users. Entra ID supports three main passwordless methods.

So a hospital whose staff share workstations and cannot carry phones in some wards would choose FIDO2 keys. Windows Hello is tied to a device the user enrolled, and the Authenticator app and SMS codes both need a phone.

Watch for imposters. A password plus a voice call or an SMS code is MFA that still uses a password, not passwordless. Password hash synchronisation copies on-premises password hashes into the cloud; it is a sync feature, not a sign-in method. Security questions are a weak recovery check, not passwordless.

External identities

Not everyone who needs access works for you. Microsoft Entra External ID is the umbrella for letting outside people in, and it covers three patterns.

• B2B collaboration. Consultants from a partner firm need a SharePoint site and an internal application. The company invites them as guest users. They sign in with their own work, school or social identities, so the company creates and manages no passwords for them. Their guest accounts appear in the company's directory, and the company controls what the guests can reach. Creating ordinary member accounts instead would leave the company issuing and resetting credentials for every consultant.
• B2B direct connect. Two companies that both use Entra ID set up a mutual, two-way trust. Their users can work together, for example in Microsoft Teams shared channels, without being added to each other's directories as guests.
• An external tenant for customers. A retailer building a shopping app wants members of the public to sign up with an email address or a social account, on sign-in pages carrying the retailer's branding. External ID can run in an external tenant built for consumer and business customers, with self-service sign-up and social identity providers. This is separate from the workforce tenant that holds the company's own staff.

Remember the difference between external identities and Entra Connect. Connect brings the company's own staff from on premises into the cloud. External ID is for people outside the organisation.

Microsoft Entra Conditional Access

Conditional Access is the policy engine of Entra ID. It looks at the circumstances of each sign-in and decides what should happen. It needs an Entra ID premium licence (P1 or above), and policies that use sign-in risk need P2. Think of each policy as an "if this, then that" rule with three parts.

1. Signals (the "if"): who the user is and which groups they belong to; the IP location of the sign-in, such as a named trusted range for the office; the device, including whether it is marked compliant or joined to the organisation; the application being opened; and the real-time sign-in risk that identity protection calculates.
2. Decisions (the "then"): block access; grant it; or grant it only after a requirement is met, such as require MFA or require a compliant device.
3. Enforcement: the decision is applied at sign-in, before the user reaches the application.

Some examples:

• Require MFA only when staff sign in from outside the corporate network, with no extra prompt in the office.
• Allow the finance application only from company-managed devices that meet compliance rules, and block personal devices.
• Block sign-ins whose risk is high, or demand MFA when risk is medium.

The relationship between Conditional Access and MFA is a frequent question. MFA is a way of proving identity. Conditional Access is what decides when to ask for it. Conditional Access is not itself a second factor, and the two are not the same feature.

Also keep Conditional Access apart from two tools in other lessons. Azure role-based access control (lesson 11) decides what an already signed-in identity may do with Azure resources at a chosen scope. Azure Policy (lesson 13) decides how resources may be configured. Neither looks at where or how a person is signing in.

What the exam is really asking

Most questions in this area hand you a scenario and ask which identity feature fits. Sort them like this.

• Entra ID versus Entra Domain Services. Cloud sign-in, SSO, device registration: Entra ID. Domain join, group policy, LDAP or Kerberos for legacy servers, with no domain controllers to run: Domain Services. Sync between them is one way, from Entra ID into the managed domain.
• Entra Connect versus External ID. Your own staff from on-premises Active Directory: Connect. Partners or the public: External ID.
• SSO, MFA or passwordless. One sign-in for many apps: SSO. More than one kind of evidence: MFA. No password at all: passwordless. A question can involve more than one; read which problem the scenario is solving.
• Which passwordless method. Own Windows laptop: Windows Hello for Business. Own phone: Authenticator app. Shared machine, no phone: FIDO2 key.
• Which external pattern. Guests using their own accounts: B2B collaboration. Two Entra organisations trusting each other without guest accounts: B2B direct connect. Public sign-up with branding: an external tenant.
• Signal or decision. Location, device, application, user and risk are signals. Block, grant and require MFA are decisions.

The commonest trap is choosing Conditional Access where the question is about permissions on resources (that is RBAC), or choosing Azure Policy where the question is about how someone signs in (that is Conditional Access).