Single Sign-On (SSO) lets users access multiple applications by signing in once with a single set of credentials. This removes the need to remember and manage multiple passwords, and it reduces the administrative work of managing user access across different applications. SSO works especially well with SaaS applications like Microsoft 365 and Salesforce, where it creates a seamless integration and boosts user productivity.
Multifactor Authentication (MFA) adds an extra layer of security by requiring users to verify their identity using more than one method. Typically, this involves something the user knows (a password) and something they have (a mobile device). Azure MFA supports several verification methods, including SMS text messages, phone calls, and notifications through a mobile app.
Managed Identities are identities that Azure manages automatically. They allow a resource to authenticate to any service that supports Azure AD authentication without needing to manage any credentials. There are two types:
Service Principals are used by applications, services, and automation tools to access Azure resources securely. They function similarly to managed identities but require you to explicitly manage their credentials, such as certificates or client secrets.
Azure AD supports OAuth 2.0 and OpenID Connect, which are modern authentication protocols. OAuth 2.0 provides secure access delegation, allowing a third-party application to access resources on behalf of a user without sharing the user's password. OpenID Connect builds on OAuth 2.0 to provide identity information, verifying who the user is. These protocols enable secure access for third-party applications while keeping the user's credentials private.
For organizations with complex hybrid environments that span on-premises and cloud resources, integrating federation services such as Active Directory Federation Services (AD FS) can provide seamless identity management. Federation allows users to sign in to cloud applications using their existing on-premises Active Directory credentials. This creates a consistent authentication experience while maintaining security and compliance, because the organization retains control over authentication policies on-premises.
Conditional Access policies enhance security by controlling how and when users can access applications based on conditions like user location, device health, or sign-in risk. For example, you can enforce MFA only when a user signs in from an untrusted location or uses a device that does not meet compliance standards. This ensures that only compliant and secured access is granted, balancing security with user convenience.
The foundation of any identity solution is verifying who someone is and what they are allowed to do. Authentication is the process of proving an identity, using methods like passwords or certificates. Once authenticated, authorization determines the specific actions that identity is permitted to perform on resources. These two processes work together to control access.
For organizations with existing on-premises infrastructure, a hybrid identity model connects local systems to the cloud. Azure AD Connect is a key service that synchronizes user accounts and groups from an on-premises Active Directory to Microsoft Entra ID, creating a single identity for accessing both environments. For more complex authentication needs, such as using smart cards, you can deploy Active Directory Federation Services (AD FS) to establish a federation trust. Alternatively, Pass-through Authentication allows passwords to be validated directly against the on-premises directory without storing them in the cloud, simplifying the user experience while keeping password validation on-premises.
In a cloud-native approach, Microsoft Entra ID acts as the sole, primary identity provider. All identities are created and managed directly in the cloud. This model enables direct use of advanced cloud security features like Conditional Access, which applies rules based on user, device, or location to gate access, and multi-factor authentication (MFA), which adds a critical extra layer of security beyond just a password.
Security policies must be integrated into the identity architecture. Conditional Access policies evaluate signals like user risk, location, and device compliance in real-time to dynamically allow or block access to applications. Identity Protection uses machine learning to detect risky sign-ins and compromised credentials, automating responses like requiring password changes or blocking access. These features work together to protect resources regardless of whether the underlying identity is hybrid or cloud-native.
Maintaining security requires constant monitoring. Identity systems generate detailed logs of all authentication and authorization events. These logs must be collected and analyzed to track user activities, especially for privileged accounts, and to conduct regular access reviews. This auditing is essential for detecting anomalies, investigating incidents, and proving compliance with security standards.
Selecting an architecture involves analyzing specific requirements. A key decision is whether to maintain a hybrid connection using Azure AD Connect or AD FS, or to adopt a cloud-only Microsoft Entra ID implementation. This choice depends on existing infrastructure, application dependencies, and specific authentication needs. Compliance constraints will dictate security controls like MFA and logging. The final design must balance security objectives, operational complexity, and the need for a seamless user experience across all accessed resources.
Azure RBAC controls who can access Azure resources, what actions they can perform, and which areas they can reach. Instead of giving every admin full control, organizations create custom roles that match specific job needs, so a user might be able to view storage accounts without being able to delete them. Azure RBAC assigns these roles to users, groups, or applications at different scopes such as a subscription, resource group, or individual resource. The system also records every action in audit logs, so administrators can review who used which permissions and flag any unusual activity. This approach directly supports least-privilege by ensuring permissions are scoped narrowly and regularly reviewed.
Privileged Identity Management (PIM) adds a time-based layer to access by using just-in-time role activation, which means privileged roles are active only when someone actually needs them. Instead of granting permanent admin access, PIM requires users to request elevation and receive approval before they can perform sensitive tasks. Administrators set a maximum duration for each elevated session, and the system automatically revokes access when time expires. This dramatically reduces the window of opportunity for attackers because even compromised accounts cannot instantly cause widespread damage. The approval workflow also adds a human checkpoint before powerful permissions are used.
Conditional access policies apply security controls based on conditions such as where the user is located, what device they are using, and how risky the sign-in appears. For example, an organization might block all access from countries where it has no employees, or require that devices meet security standards before they can access sensitive data. If a sign-in looks suspicious, such as coming from an unknown IP address, the policy can force additional verification through multi-factor authentication (MFA) before granting access. These policies evaluate each sign-in in real time and can combine multiple conditions, so access is granted or denied dynamically rather than using a single static rule.
Azure Policy enforces organizational standards by evaluating existing and new resources against defined rules and flagging any that do not comply. For instance, a policy might require that all storage accounts use encryption or that virtual machines must exist in specific regions. When a user tries to create a non-compliant resource, Azure Policy can block the creation entirely or apply automated remediation to bring the resource into compliance. Policies can be grouped into initiatives to address complex governance scenarios, and they integrate with Azure RBAC so that permission to create resources can be tied to compliance status. This ensures that security standards are applied automatically rather than relying on manual checks.
Managed identities give Azure resources their own automatically managed identity in Azure Active Directory, eliminating the need to store credentials in code or configuration. An application running on a virtual machine can use its managed identity to authenticate to Azure Key Vault, Azure SQL, or any other service that supports Azure AD authentication. Because Azure handles the credential lifecycle, there is no risk of credentials being exposed in source code or left in configuration files. This simplifies the authentication flow while reducing the attack surface, since the identity exists only as long as the resource exists and cannot be hijacked separately.
When designing access to on-premises resources, choosing the right authentication method depends on security requirements and infrastructure complexity. Password Hash Synchronization (PHS) synchronizes a cryptographic hash of user passwords from on-premises Active Directory to Microsoft Entra ID, enabling authentication to occur entirely in the cloud. Conversely, Pass-through Authentication (PTA) relies on an on-premises PTA agent to validate credentials directly against your on-premises domain controller, keeping password validation local without storing hashes in the cloud. Active Directory Federation Services (AD FS) redirects authentication requests directly to on-premises federation servers, providing advanced sign-on controls but requiring the most complex on-premises infrastructure.
Azure AD Connect acts as the primary integration engine that synchronizes user accounts, groups, and credential states from on-premises environments to the cloud. This synchronization engine establishes a dependency where changes in the on-premises directory propagate up to Microsoft Entra ID. When implementing PHS, the synchronization process runs on a recurring cycle to update password hashes in the cloud database. PTA and AD FS bypass cloud-based credential storage during synchronization, acting instead as trust boundaries where Microsoft Entra ID hands off authentication verification to local systems.
Microsoft Entra Application Proxy publishes on-premises web applications to external users without opening inbound firewall ports or using a virtual private network (VPN). The request flow begins when an external user requests the application, which Microsoft Entra ID authenticates and passes through a secure cloud endpoint. The on-premises Application Proxy connector polls the cloud service for requests, retrieves them over an outbound connection, and forwards them to the internal web server. For organizations using existing security appliances, Microsoft Entra ID integrates with Secure Hybrid Access partners like F5 BIG-IP and Zscaler to extend cloud-based identity protections to legacy traffic. To achieve seamless single sign-on for legacy systems, the connector or partner appliance can use certificate-based Kerberos constrained delegation (KCD) to safely impersonate the authenticated user to local resources.
Conditional Access acts as the policy decision point that evaluates signals before granting access to published on-premises applications. These policies apply strict controls based on user identity, group membership, device compliance, and geographical location. If a user attempts to access an on-premises application through the Application Proxy, the system can enforce multifactor authentication (MFA) or block access from unmanaged devices. This creates a secure boundary where access is continuously evaluated, ensuring that only trusted users on compliant devices can reach internal corporate resources.
Vault architecture begins with choosing between Azure Key Vault and Managed HSM (Hardware Security Module). Managed HSM provides a fully managed, highly available, single-tenant hardware security module that meets strict compliance standards such as FIPS 140-2 Level 3. Use a standard Key Vault for most secrets and certificates; choose Managed HSM when you need higher key isolation, your own security domain, or adherence to regulatory requirements that mandate dedicated hardware. The vault itself is a resource that resides in a specific Azure region, and its data is replicated within that region for durability. Traffic between an application and the vault always flows over HTTPS, and the vault’s control plane (management operations) is separate from its data plane (secret retrieval operations).
Access to the vault is governed by two layers: Azure AD role-based access control (RBAC) for management operations and the vault’s own access policy for data operations. Use Azure AD roles (such as Key Vault Contributor) to control who can create or delete vaults and set firewall rules. Use a Key Vault access policy to define exactly which users, groups, or applications can perform operations on secrets, keys, or certificates—for example, Get or Set on secrets. This two-layer approach lets you enforce the least privilege principle: a security admin might get management access to configure the vault, while an application’s managed identity gets only the data-plane permissions needed to read its own secret. No identity ever inherits more than what the policy explicitly grants.
Manual secret and certificate management is error-prone and difficult to scale, so Azure Key Vault supports automation through Azure DevOps and Azure Logic Apps. For example, you can build a DevOps pipeline that triggers a certificate renewal when the certificate’s expiration date approaches, then updates the variables in your application’s deployment. A Logic App can periodically call the vault’s REST API to rotate a secret—such as a storage account key—and push the new value back into the vault while updating consuming services. The automation sequence depends on the lifecycle: a secret moves from created → active → expired (or disabled); rotation re-creates it at a set interval. By chaining these actions, you ensure that certificates are re-issued before they expire and that leaked or deprecated secrets are replaced without manual intervention.
Every operation on a vault—reading a secret, creating a key, renewing a certificate—can be sent to Azure Monitor as diagnostic logs. These logs are collected in a Log Analytics workspace or an Azure Storage account, forming an audit trail that shows who accessed what and when. Azure Policy applies organizational rules to the vault itself: you can enforce that all vaults require soft-delete and purge protection, that network access is restricted to a specific virtual network, or that access policies must not grant wildcard permissions. Policy violations are flagged in real time and can block non-compliant vault creation or trigger remediation. Together, Azure Monitor and Azure Policy give you the visibility and enforcement needed to meet compliance frameworks such as SOC 2, PCI DSS, or GDPR. By integrating Azure Key Vault with Managed HSM, granular access control, automated rotation, and continuous monitoring, you create a closed-loop management system where secrets, certificates, and keys are protected, regularly refreshed, and legally auditable—satisfying both security and operational requirements within an Azure architecture.
Venture into the world of Azure Infrastructure, where design meets functionality. Harness your skills and gain mastery over complex cloud structures to ace the AZ-305 Designing Microsoft Azure Infrastructure Solutions exam!
Prepare and test your skills
Prepare and test your skills
System-assigned managed identities are tied directly to a specific Azure resource and are deleted automatically when that resource is deleted. In contrast, user-assigned managed identities are standalone resources created independently that can be assigned to and reused across multiple Azure resources.
Password Hash Synchronization (PHS) synchronizes cryptographic password hashes to Microsoft Entra ID so authentication takes place entirely in the cloud. Pass-through Authentication (PTA) validates credentials directly against an on-premises domain controller using a local agent, allowing authentication to remain on-premises without storing password hashes in the cloud.
An organization should choose Managed HSM when regulatory requirements mandate dedicated single-tenant hardware, a custom security domain, higher key isolation, or compliance with FIPS 140-2 Level 3 standards. Standard Azure Key Vault is recommended for most typical secret, key, and certificate workloads that do not require dedicated hardware.
StudyCerts
StudyCerts