AZ-305 Authentication and Authorization Design: Hybrid Sign-in, Conditional Access, External Identities, RBAC, PIM and Key Vault

For users synchronized from on-premises Active Directory, recommend password hash synchronization (PHS) by default, pass-through authentication (PTA) when on-premises account policies must apply at every sign-in, and federation only when a requirement can't be met natively in Microsoft Entra ID. The three methods differ in where the password is checked, what infrastructure you run and what keeps working when on-premises fails.

Seamless single sign-on works with both PHS and PTA, so domain-joined PCs on the corporate network sign in without a prompt either way. Choosing PTA or federation does not stop you also syncing hashes, and that is the usual design advice:

• Leaked-credential detection needs the hashes. Microsoft Entra ID Protection compares synchronized hashes with credentials found on the internet, so it works only when PHS is enabled, whatever the primary sign-in method.
• PHS is the fallback for an on-premises outage. If ransomware or a datacenter failure takes the domain controllers offline, a tenant that already syncs hashes can switch its sign-in method to PHS and users keep reaching Microsoft 365. The switch is a manual change, not an automatic failover.
• Adding more of the same infrastructure doesn't help. More authentication agents or federation servers still send every password to a domain controller for validation, so they fail together when the domain controllers do. A sync server in staging mode is only a standby for synchronization and provides no sign-in path at all.

Moving off federation gradually: staged rollout

For a federated domain, every user in that domain is sent to the federation server. Staged rollout lets you assign security groups to cloud authentication (PHS, PTA or certificate-based authentication) so those users sign in to Microsoft Entra ID directly, while the rest of the domain stays federated and nobody's UPN changes. Converting the domain to managed authentication is all-or-nothing, and moving pilot users to a second domain changes their sign-in names, so staged rollout is the tool for a pilot.

Microsoft Entra certificate-based authentication (CBA) lets users sign in with X.509 certificates, such as PIV or CAC smart cards, validated directly by Microsoft Entra ID, so smart-card sign-in no longer needs AD FS or any other federated identity provider. Smart cards were a classic reason to keep a federation farm; with CBA you can decommission AD FS and its perimeter servers and add no new on-premises infrastructure.

To set it up you:

1. Upload the issuing certificate authority chain to the tenant's trusted CA store, with the certificate revocation list (CRL) location so revoked cards are refused.
2. Configure username binding: which certificate field (for example the SAN principal name) maps to which user attribute (for example the UPN). This decides which account a certificate belongs to.
3. Configure authentication binding: whether a certificate counts as single-factor or multifactor.

The two binding policies are easy to confuse. Username binding identifies the user; authentication binding sets the protection level. By default a CBA certificate is single-factor, so a Conditional Access policy that requires MFA prompts a smart-card user for a second method. To let a hardware smart card satisfy MFA on its own, add an authentication binding rule that maps the card's issuer, its certificate policy OID, or both, to multifactor. Rules by issuer or OID let you raise PIV cards to multifactor while software certificates from another issuer stay single-factor, which changing the tenant-wide default would not allow.

CBA works whether the tenant's other users sign in with PHS or PTA, and it can be one of the methods a staged rollout moves groups to. Windows Hello for Business is a different answer: it replaces the smart card with a device-bound credential rather than keeping smart-card sign-in.

Conditional Access is the Microsoft Entra policy engine that decides, per sign-in, whether to allow access and what to require (MFA, a compliant device, an authentication strength), based on who is signing in, to which app, from where and with what risk. It is the only option when requirements differ by group, app or location.

The licensing split is the most tested detail: P1 includes Conditional Access but not risk conditions; the sign-in risk and user risk conditions need P2. A design with only P1 can approximate risk with static rules, such as a named location, but a named location is a fixed list of IP ranges or countries: it can mark the corporate egress ranges as trusted or block a country, but it can't recognise an anonymous proxy or a leaked password.

A typical location design uses two policies: one requiring MFA for administrator roles from all locations, and one requiring MFA for everyone else that excludes a named location built from the corporate public IP ranges.

Testing a policy safely

• Report-only mode evaluates the policy at every real sign-in and records the result ("Report-only: Success/Failure") in the sign-in logs and the Conditional Access insights and reporting workbook, without enforcing it. Use it to see who a policy would have blocked over days or weeks.
• The What If tool evaluates one hypothetical sign-in (a chosen user, app, location and device) against your policies. It answers "which policies apply to this sign-in?", not "how many real users would this policy affect over time?".
• A pilot group enforces the policy for real on a subset of users, so it does affect them.

Authentication strengths: MFA, passwordless and phishing-resistant

An authentication strength is a Conditional Access grant control that specifies which combinations of authentication methods satisfy a policy, rather than accepting any MFA. Use one when a requirement names the kind of method, such as "can't be relayed through a proxy site".

Why the right-hand column is narrower: an adversary-in-the-middle phishing kit proxies the real sign-in page, so any method where the user approves a prompt or types a code (push, number matching, phone sign-in, OATH, SMS) can be relayed, and the attacker captures the session token. Phishing-resistant methods use public-key credentials bound to the genuine site's origin: the authenticator signs only for the real domain, so a proxy on another domain can't use them.

The passwordless strength is the near-twin trap: it removes the password but still allows Authenticator phone sign-in, which can be relayed. Session controls such as sign-in frequency change how often a user must re-authenticate, not which method they use, so they don't stop token theft through a proxy. For administrators, require the built-in phishing-resistant MFA strength on a policy targeting their roles, and have them register passkeys or Windows Hello for Business before you enforce it. You can also build custom authentication strengths from specific methods.

Microsoft Entra Cloud Sync and Microsoft Entra Connect Sync both synchronize users, groups and contacts from Active Directory to Microsoft Entra ID; Cloud Sync is the lightweight, cloud-managed option, and Connect Sync is the full sync engine you still need for large or heavily customized deployments. Microsoft recommends Cloud Sync where it meets the requirements.

The two can coexist: a common design runs Connect Sync for an existing forest and Cloud Sync for an acquired, disconnected forest. When a requirement names a feature only the sync engine has (custom rules, cross-forest attribute merge, a domain above Cloud Sync's supported size), keep Connect Sync and protect it with a staging-mode server; two active Connect servers sharing a database isn't a supported design.

Microsoft Entra Domain Services for apps that need a domain

Microsoft Entra Domain Services is a managed domain that provides LDAP, Kerberos, NTLM, domain join and Group Policy to VMs in an Azure virtual network, with Microsoft running the domain controllers. Recommend it when a legacy app moved to Azure VMs needs traditional domain protocols but the organization doesn't want domain controllers to patch, back up or monitor. Joining VMs to Microsoft Entra ID doesn't help such an app, because Entra join provides neither LDAP binds nor Group Policy.

Domain Services authenticates with NTLM and Kerberos password hashes, which creates two design facts:

• Synchronized users need password hash synchronization so their legacy hashes reach Microsoft Entra ID, whatever method they use to sign in to Microsoft 365. A PTA or federated tenant must still enable PHS before those users can use the managed domain.
• Cloud-only users get the hashes only after they change or reset their password once Domain Services is enabled. Until then their LDAP binds and Kerberos sign-ins fail even with the correct password. No setting on the managed domain itself generates the hashes; only the password change does.

Microsoft Entra ID offers different models for people outside your workforce: B2B collaboration and B2B direct connect for partners, cross-tenant synchronization for your own organization's other tenants, and Microsoft Entra External ID external tenants for customers. Pick by who the users are and whether they should appear in your directory.

Cross-tenant access settings

Cross-tenant access settings control B2B collaboration and B2B direct connect with other Microsoft Entra tenants. There are default settings that apply to every external tenant and organization-specific settings for a named partner, each with inbound (their users accessing you) and outbound (your users accessing them) directions.

• Inbound trust settings let your Conditional Access accept MFA, compliant-device or Microsoft Entra hybrid joined claims from the user's home tenant. Trusting a partner's MFA keeps your MFA policy in force while removing the extra MFA registration guests otherwise face in your tenant. Configure it in the organization-specific settings for that partner so the default for every other tenant stays unchanged. Taking users out of a policy's scope to avoid prompts lowers protection, while trusting a home tenant's MFA keeps the requirement and removes only the duplicate registration.
• B2B direct connect works only when the resource organization allows the partner inbound and the partner allows the resource organization outbound.

Cross-tenant synchronization

Cross-tenant synchronization is a provisioning service configured in the source tenant that pushes scoped users into target tenants as B2B users. It replaces manual invitations, and it isn't Cloud Sync (which syncs from Active Directory). The target tenant must enable "Allow users sync into this tenant" in its inbound cross-tenant sync settings for the source, and both tenants enable automatic redemption (inbound in the target, outbound in the source) so synchronized users reach apps without a consent prompt. Trusting MFA from the source is optional and separate.

Customer identity with External ID

For a new customer-facing app, recommend a Microsoft Entra External ID external tenant: sign-up and sign-in user flows, social identity providers such as Google, Facebook and Apple, company branding, and a directory kept separate from employees. Azure AD B2C is no longer available to new customers since 1 May 2025; existing B2C tenants remain supported, but a greenfield design shouldn't choose it. When mobile apps must show sign-up and sign-in in their own native screens without redirecting to a browser page, use External ID native authentication through the MSAL native authentication SDKs (available for iOS and Android among others); browser-based user flows with branding still redirect to hosted pages.

A workload should authenticate to Azure with an identity whose credentials the platform manages, never with a client secret or certificate stored in configuration. Inside Azure that means a managed identity; outside Azure it means an Arc-enabled server's managed identity or workload identity federation.

Recommend system-assigned when one resource needs access and the identity should disappear with it. Recommend user-assigned when resources are created and deleted often (ephemeral, autoscaled or frequently redeployed resources), when several resources share the same access, or when access must exist from the first boot: a new system-assigned identity has no permissions until someone assigns a role.

Servers outside Azure: Azure Arc

Managed identities don't work for on-premises or other-cloud machines on their own. Onboarding a server to Azure Arc gives it a system-assigned managed identity with a local token endpoint (the Arc agent exposes it through the IDENTITY_ENDPOINT variable). User-assigned identities aren't supported on Arc-enabled servers. On Windows, the app's account must be a local administrator or a member of the Hybrid Agent Extension Applications group to request tokens. Grant the identity a role such as Key Vault Secrets User and remove the stored secret; there is then nothing to expire.

When many Arc servers need the same access and servers come and go, add their managed identities (which are service principals) to a Microsoft Entra security group and assign the role to the group once. Adding or removing a server becomes a membership change, not a new role assignment.

Workloads in other platforms: workload identity federation

Workload identity federation lets an external workload exchange a token from a trusted OpenID Connect issuer for a Microsoft Entra access token, so no long-lived credential exists. You add a federated identity credential to an app registration or a user-assigned managed identity (not a system-assigned one) that names the issuer and the exact subject.

• GitHub Actions: the credential trusts GitHub's OIDC issuer for a subject such as a repository plus branch, environment, tag or pull request. The workflow uses the azure/login action with OIDC; nothing is stored as a repository secret.
• Azure Kubernetes Service (Microsoft Entra Workload ID): enable the cluster's OIDC issuer and workload identity, create a Kubernetes service account, and add a federated credential whose subject is system:serviceaccount:<namespace>:<service-account>. Only pods using that service account receive the access. The kubelet identity is node-wide, so granting it a role gives every pod on the node the access, and Microsoft Entra pod-managed identity is deprecated in favour of Workload ID.

Azure role-based access control (RBAC) authorizes access to Azure resources by assigning a role definition to a security principal at a scope; assignments inherit downward and are additive, and only deny assignments subtract. Least privilege means the narrowest role at the narrowest scope.

Scopes, inheritance and planes

• Scopes are, from broadest: management group, subscription, resource group, resource. Some resources accept narrower scopes, such as a single blob container in a storage account.
• Inheritance and union: a user with Reader on a management group and Contributor on one resource group can read everything under the management group and manage resources only in that resource group. The Reader assignment doesn't limit the Contributor one.
• Control plane vs data plane: roles such as Owner, Contributor and Reader carry management actions. Reading blob contents or secret values is a data action, granted by data roles such as Storage Blob Data Reader/Contributor or Key Vault Secrets User. Reader reads no data; Contributor manages a storage account but, through RBAC alone, doesn't read blob data. Note that Contributor can list storage account keys, which is a reason to prefer data roles for apps.
• Assigning roles needs Microsoft.Authorization/roleAssignments/write, held by Owner, User Access Administrator and Role Based Access Control Administrator. Contributor can't grant access.

Delegating role assignment with conditions

To let teams grant access without the platform team, assign Role Based Access Control Administrator, a built-in role that manages role assignments without Owner's other permissions, and add a role assignment condition (an ABAC condition) that limits which roles it can assign and to which principal types. Examples:

• Constrain to specific roles and one principal type, for example a single narrow role that may be assigned only to service principals, so teams can grant their workloads' identities access but can't grant themselves anything.
• Use Microsoft's "Allow all except specific roles" template, excluding Owner, User Access Administrator and Role Based Access Control Administrator, so delegates can assign almost any role but can never hand someone else the power to assign roles. The exclusion list must be maintained if a new role that can write role assignments appears.

User Access Administrator can also carry a condition, but it is a broader role, so it isn't the least-privilege choice. Any role that can write role assignments without a condition lets its holder grant powerful roles, including to themselves, and controls that only detect or report assignments afterwards don't prevent that.

Just-in-time access with Privileged Identity Management

Microsoft Entra Privileged Identity Management (PIM) removes standing access by making privileged roles eligible instead of active. An eligible assignment grants nothing until the user activates it; an active assignment grants access immediately, even if it has an end date. PIM role settings control activation: maximum activation duration, required justification, ticket information, approval by named approvers, MFA, or a Conditional Access authentication context. PIM needs Microsoft Entra ID P2 or Microsoft Entra ID Governance licences.

• Stronger checks at activation only: requiring an authentication context in the role settings means the administrator must satisfy the Conditional Access policy targeting that context (for example a stronger authentication strength or a device requirement) at the moment of activation, without changing the policy that applies to their everyday sign-ins. The built-in "require MFA on activation" option can't specify method strength or device state.
• One activation, many scopes: with PIM for Groups, a group holds the role assignments (for example the same role on several specific subscriptions) and engineers are eligible members of the group. One activation grants all of them, without the breadth of an assignment at a shared management group.

Access reviews, entitlement management and lifecycle workflows belong to identity governance, covered with Design governance; entitlement management access packages grant access to resources through requests, but they aren't how you make an Azure role just-in-time.

To give remote users Microsoft Entra-protected access to on-premises apps without inbound firewall ports, publish web apps through Microsoft Entra application proxy and non-web apps through Microsoft Entra Private Access. Both use the same private network connector, a lightweight agent on an internal server that makes outbound connections only.

Application proxy also provides single sign-on to the back-end app, and the method must match how the app authenticates:

• Integrated Windows Authentication apps: Kerberos constrained delegation, where the connector obtains a Kerberos ticket on the user's behalf (the connector's computer account needs delegation rights to the app's service).
• Apps that read identity from HTTP headers: header-based SSO.
• Apps that accept SAML: SAML SSO; apps with their own login form: password-based SSO.

Private Access sits in Microsoft's Global Secure Access (security service edge) family next to Microsoft Entra Internet Access, which secures traffic to the internet and SaaS apps, not to private servers. Network-level answers, such as publishing an app through an internet-facing load balancer or reverse proxy, or a traditional VPN, don't give Microsoft Entra pre-authentication with per-app SSO and Conditional Access; they either open an inbound path or grant broad network access. Tools for administering Azure virtual machines don't reach servers that stay on-premises.

Other on-premises authorization patterns in this topic are covered above: Domain Services for apps that need LDAP or Kerberos in Azure, and Azure Arc so on-premises servers can be authorized to Azure resources with a managed identity.

Azure offers five generally available key-management choices; pick by tenancy, who controls the HSM, and what has to use the keys: Azure services, IaaS applications or payment systems. FIPS level rarely decides on its own. Key Vault Premium (for keys on HSM Platform 2), Managed HSM and Cloud HSM are validated to FIPS 140-3 Level 3; Premium keys still on HSM Platform 1 are FIPS 140-2 Level 2. Azure Payment HSM is FIPS 140-2 Level 3 with PCI HSM certification, so for payment work the PCI PIN and payment functions decide, not the FIPS level. A Payment HSM v2 validated to FIPS 140-3 Level 3 is in preview.

How to read the requirement: when Azure PaaS services must encrypt with customer-managed keys held in single-tenant HSMs the customer controls, the answer is Managed HSM, because Premium is multitenant and Cloud HSM has no PaaS integration. When software on virtual machines must reach the HSM through a local cryptographic interface such as PKCS#11, JCE or a Windows key storage provider, the answer is Cloud HSM, because Managed HSM exposes keys only through the Key Vault REST API. When the workload performs payment functions, the answer is Payment HSM, because the general-purpose HSMs don't provide payment HSM functions.

Use the Azure RBAC permission model on key vaults, grant each app's managed identity the narrowest data role on a vault per application per environment, and automate rotation with the mechanism that matches the object: rotation policies for keys, auto-renewal for certificates and event-driven code for secrets.

Permission model and roles

Microsoft recommends the Azure RBAC permission model over vault access policies. The difference matters for privilege escalation: under the access policy model, access policies are a property of the vault, so anyone who can write the vault, such as a Key Vault Contributor, can add a policy for themselves and read secrets. Under RBAC, data access comes only from role assignments, which Key Vault Contributor can't create, so an operations team can create vaults, configure firewalls, private endpoints and diagnostic settings, and delete vaults without any path to secret values.

A separate vault per application per environment limits the blast radius of a leaked identity or misconfigured role and keeps production secrets away from test identities.

Using secrets without code changes: Key Vault references

App Service and Azure Functions can resolve an app setting whose value is a Key Vault reference, @Microsoft.KeyVault(SecretUri=...) or the VaultName=...;SecretName=... form. The platform fetches the secret with the app's managed identity and the app reads the setting as before. The identity needs a role that reads secret values (Key Vault Secrets User on an RBAC vault); a role that reads only metadata isn't enough, and vault settings that let Azure platform features retrieve secrets (for example during template deployment) don't grant an app's identity runtime access. A reference without a version follows the latest version of the secret.

Rotation

App Service managed certificates are free and renewed automatically, but they don't cover wildcard domains, can't be exported and serve only App Service, so they don't fit a certificate shared with Application Gateway and VMs. Runbooks and functions can rotate keys too, but they are custom code where a rotation policy does the job natively.