š Azure Application Gateway: Smart Load Balancing & Security
Ensuring high availability and efficient load balancing is crucial for web applications. Azure offers several traffic management solutions, including Application Gateway, Front Door, Load Balancer, and Traffic Manager. Today, let's focus on why Application Gateway stands out as a powerful tool for managing web traffic. š Why we should use Azure Application Gateway? š¹ Layer 7 Load Balancing: Unlike Layer 3 or 4 solutions, Application Gateway makes intelligent routing decisions based on HTTP request properties. For example, requests to /images/ can be directed to dedicated image servers, while /videos/ traffic is routed to specialized video servers. š¹ SSL/TLS Termination (Offloading): Reduces processing load on backend servers by decrypting traffic at the gateway before forwarding it unencrypted. Note: This might conflict with compliance requirements, so verify your appās security needs !! š¹ Autoscaling: Dynamically scales up or down based on traffic patterns, ensuring cost-effective resource utilization. š¹ Zone Redundancy: Operates across multiple Availability Zones, enhancing fault tolerance without needing separate gateways in each zone. š¹ Web Application Firewall (WAF): Provides centralized security against common exploits like SQL injection and cross-site scripting (XSS). Built on OWASP 3.1 (WAF_v2), it can function in Detection Mode (alerting admins) or Prevention Mode (blocking threats proactively). š¹ URL-Based Routing: Enables smart traffic distribution by directing different types of content to the most appropriate backend pools. Example: http://contoso.com/video/* ā VideoServerPool š¹ Multiple-Site Hosting: Hosts multiple web applications on a single gateway, routing requests based on hostname or domain. Example: http://contoso.com ā ContosoServerPool š¹ Redirection & Rewrite Capabilities: ā Redirect HTTP ā HTTPS to enforce encrypted traffic. ā Rewrite HTTP headers & URLs to enhance security (e.g., add HSTS or remove sensitive response headers). š¹ Cookie-Based Session Affinity: Ensures users maintain session continuity by always connecting to the same backend server. Useful when session state is stored locally. āļø How to Deploy & Configure Azure Application Gateway āļø ā Dedicated Subnet: Create a subnet (e.g., myAGSubnet) within a Virtual Network. ā Frontend IP: Define whether to use a public or private IP or both (If you configured multiple listeners) to receive client requests. ā Backend Pool: Assign backend servers via NICs, Virtual Machine Scale Sets, public/internal IPs, or FQDNs. ā HTTP/HTTPS Listener: Specify which port (e.g., 80, 443) will handle incoming requests. ā Routing Rules: Set up domain-based (host-based routing) or path-based routing logic. š¹ Host-Based Routing means routing traffic based on the hostname in the HTTP request header š¹ Path-based Routing allows you to direct traffic to different backend pools based on the URL path in the request. ā Health Probes: Ensure backend servers are online using TCP or HTTP-based monitoring.š„The Power of Azureās Security Arsenal š„
ā Using a Public IP without securing your Azure applications and resources exposes you to security threats. Today, weāll explore the most powerful security solutions from Azureās arsenal. ā Azure provides a multi-layered approach (more than one layer of protection) to secure your resources when using a Public IP. Organizations can now transform this open gateway into a fortified checkpoint. Hereās how these tools work together to mitigate risks: š Azure DDoS Protection š ā Protects your resources and services from being overwhelmed by malicious traffic. This excellent service is available for Network & IP Protection SKUs. ā Uses Machine Learning to distinguish between normal traffic patterns and malicious flooding attempts (such as SYN floods or UDP amplification attacks) before they impact your applications and services ensuring availability. š Azure Web Application Firewall (WAF) š ā Adds application-layer protection, intercepting HTTP/HTTPS traffic for inspection. ā Blocks suspicious attacks like SQL injection or XSS by applying OWASP core rule sets, which define how attacks occur and how to defend against them, with continuous updates. ā Enhances security for customer-facing services, ensuring trust and protection for your website and users. š Network Security Groups (NSGs) š ā Acts as a virtual firewall at the subnet or network interface level, filtering traffic based on predefined rules. ā Can allow only trusted HTTPS (port 443) connections while blocking unsolicited RDP or SSH attempts. ā Implements the critical security principle of reducing attack surface, ensuring only authorized traffic reaches your target resources. š Azure Private Link š ā In some scenarios, avoiding Public IPs altogether is the best security approach. This powerful service allows secure access to Azure SQL Database or Storage via Private Endpoints inside your virtual network. ā Helps organizations minimize external exposure while maintaining secure, private connections to necessary services. š Azure Bastion š ā Provides secure access to Azure VMs without Public IPs, using RDP/SSH over encrypted TLS 1.2 traffic. ā Uses a browser-based HTML5 web client to establish RDP/SSH sessions over TLS on port 443, fully compatible with any firewall. ā Connects to VMs via Private IPs while enforcing NSG rules to allow access only through Azure Bastion. If you found this valuable, consider sharing so more professionals can benefit. Let's keep the conversation growing! šš Mastering Azure Management with Global Admin Elevation š
ā Microsoft Entra ID and Azure resources are secured independently from one another. ā Microsoft Entra role assignments do not grant access to Azure resources. ā Azure role assignments do not grant access to Microsoft Entra ID. ā As a Global Administrator in Microsoft Entra ID, you can assign yourself access to all Azure subscriptions and management groups in your tenant. ā Use this capability if you don't have access to AzureāÆsubscription resources, such as virtual machines or storage accounts, andāÆyouāÆwant to use your Global Administrator privilege to gain access to those resources. ā When you elevate your access, you are assigned the User Access Administrator role in Azure at root scope (/).āÆThis allows you to view all resources and assign access in any subscription or management group in the tenant. ā User Access Administrator role assignments can be removed using Azure PowerShell, Azure CLI, or the REST API. š Why would you need to elevate your access? If you are a Global Administrator, there might be times when you want to do the following actions: ā Regain access to an Azure subscription or management group when a user has lost access ā Grant another user or yourself access to an Azure subscription or management group ā See all Azure subscriptions or management groups in an organization ā Allow an automation app (such as an invoicing or auditing app) to access all Azure subscriptions or management groups # Perform steps at root scope # Follow these steps to elevate access for a Global Administrator using the Azure portal. (1) Sign in to the Azure portal as a Global Administrator. Note : If you are using Microsoft Entra Privileged Identity Management, activate your Global Administrator role assignment !! (2) Browse to Microsoft Entra ID > Manage > Properties. (3) Under Access management for Azure resources, set the toggle to Yes. (4) Select Save to save your setting. If you found this valuable, consider sharing so more professionals can benefit. Let's keep the conversation growing! š
How to Fix Azure Event Grid Entra Authentication issue for ACS and Dynamics 365 integrated Webhooks
Introduction: Azure Event Grid is a powerful event routing service that enables event-driven architectures in Azure. When delivering events to webhook endpoints, security becomes paramount. Microsoft provides a secure webhook delivery mechanism using Microsoft Entra ID (formerly Azure Active Directory) authentication through the AzureEventGridSecureWebhookSubscriber role. Problem Statement: When integrating Azure Communication Services with Dynamics 365 Contact Center using Microsoft Entra ID-authenticated Event Grid webhooks, the Event Grid subscription deployment fails with an error: "HTTP POST request failed with unknown error code" with empty HTTP status and code. For example: Important Note: Before moving forward, please verify that you have the Owner role assigned on app to create event subscription. Refer to the Microsoft guidelines below to validate the required prerequisites before proceeding: Set up incoming calls, call recording, and SMS services | Microsoft Learn Why This Happens: This happens because AzureEventGridSecureWebhookSubscriber role is NOT properly configured on Microsoft EventGrid SP (Service Principal) and event subscription entra ID or application who is trying to create event grid subscription. What is AzureEventGridSecureWebhookSubscriber Role: The AzureEventGridSecureWebhookSubscriber is an Azure Entra application role that: Enables your application to verify the identity of event senders Allows specific users/applications to create event subscriptions Authorizes Event Grid to deliver events to your webhook How It Works: Role Creation: You create this app role in your destination webhook application's Azure Entra registration Role Assignment: You assign this role to: Microsoft Event Grid service principal (so it can deliver events) Either Entra ID / Entra User or Event subscription creator applications (so they can create event grid subscriptions) Token Validation: When Event Grid delivers events, it includes an Azure Entra token with this role claim Authorization Check: Your webhook validates the token and checks for the role Key Participants: Webhook Application (Your App) Purpose: Receives and processes events App Registration: Created in Azure Entra Contains: The AzureEventGridSecureWebhookSubscriber app role Validates: Incoming tokens from Event Grid Microsoft Event Grid Service Principal Purpose: Delivers events to webhooks App ID: Different per Azure cloud (Public, Government, etc.) Public Azure: 4962773b-9cdb-44cf-a8bf-237846a00ab7 Needs: AzureEventGridSecureWebhookSubscriber role assigned Event Subscription Creator Entra or Application Purpose: Creates event subscriptions Could be: You, Your deployment pipeline, admin tool, or another application Needs: AzureEventGridSecureWebhookSubscriber role assigned Although the full PowerShell script is documented in the below Event Grid documentation, it may be complex to interpret and troubleshoot. Azure PowerShell - Secure WebHook delivery with Microsoft Entra Application in Azure Event Grid - Azure Event Grid | Microsoft Learn To improve accessibility, the following section provides a simplified step-by-step tested solution along with verification steps suitable for all users including non-technical: Steps: STEP 1: Verify/Create Microsoft.EventGrid Service Principal Azure Portal ā Microsoft Entra ID ā Enterprise applications Change filter to Application type: Microsoft Applications Search for: Microsoft.EventGrid Ideally, your Azure subscription should include this application ID, which is common across all Azure subscriptions: 4962773b-9cdb-44cf-a8bf-237846a00ab7. If this application ID is not present, please contact your Azure Cloud Administrator. STEP 2: Create the App Role "AzureEventGridSecureWebhookSubscriber" Using Azure Portal: Navigate to your Webhook App Registration: Azure Portal ā Microsoft Entra ID ā App registrations Click All applications Find your app by searching OR use the Object ID you have Click on your app Create the App Role: Display name: AzureEventGridSecureWebhookSubscriber Allowed member types: Both (Users/Groups + Applications) Value: AzureEventGridSecureWebhookSubscriber Description: Azure Event Grid Role Do you want to enable this app role?: Yes In left menu, click App roles Click + Create app role Fill in the form: Click Apply STEP 3: Assign YOUR USER to the Role Using Azure Portal: Switch to Enterprise Application view: Azure Portal ā Microsoft Entra ID ā Enterprise applications Search for your webhook app (by name) Click on it Assign yourself: In left menu, click Users and groups Click + Add user/group Under Users, click None Selected Search for your user account (use your email) Select yourself Click Select Under Select a role, click None Selected Select AzureEventGridSecureWebhookSubscriber Click Select Click Assign STEP 4: Assign Microsoft.EventGrid Service Principal to the Role This step MUST be done via PowerShell or Azure CLI (Portal doesn't support this directly as we have seen) so PowerShell is recommended You will need to execute this step with the help of your Entra admin. # Connect to Microsoft Graph Connect-MgGraph -Scopes "AppRoleAssignment.ReadWrite.All" # Replace this with your webhook app's Application (client) ID $webhookAppId = "YOUR-WEBHOOK-APP-ID-HERE" #starting with c5 # Get your webhook app's service principal $webhookSP = Get-MgServicePrincipal -Filter "appId eq '$webhookAppId'" Write-Host " Found webhook app: $($webhookSP.DisplayName)" # Get Event Grid service principal $eventGridSP = Get-MgServicePrincipal -Filter "appId eq '4962773b-9cdb-44cf-a8bf-237846a00ab7'" Write-Host " Found Event Grid service principal" # Get the app role $appRole = $webhookSP.AppRoles | Where-Object {$_.Value -eq "AzureEventGridSecureWebhookSubscriber"} Write-Host " Found app role: $($appRole.DisplayName)" # Create the assignment New-MgServicePrincipalAppRoleAssignment ` -ServicePrincipalId $eventGridSP.Id ` -PrincipalId $eventGridSP.Id ` -ResourceId $webhookSP.Id ` -AppRoleId $appRole.Id Write-Host "Successfully assigned Event Grid to your webhook app!" Verification Steps: Verify the App Role was created: Your App Registration ā App roles You should see: AzureEventGridSecureWebhookSubscriber Verify your user assignment: Enterprise application (your webhook app) ā Users and groups You should see your user with role AzureEventGridSecureWebhookSubscriber Verify Event Grid assignment: Same location ā Users and groups You should see Microsoft.EventGrid with role AzureEventGridSecureWebhookSubscriber Sample Flow: Analogy For Simplification: Lets think it similar to the construction site bulding where you are the owner of the building. Building = Azure Entra app (webhook app) Building (Azure Entra App Registration for Webhook) āā Building Name: "MyWebhook-App" āā Building Address: Application ID āā Building Owner: You āā Security System: App Roles (the security badges you create) āā Security Team: Azure Entra and your actual webhook auth code (which validates tokens) like doorman Step 1: Creat the badge (App role) You (the building owner) create a special badge: - Badge name: "AzureEventGridSecureWebhookSubscriber" - Badge color: Let's say it's GOLD - Who can have it: Companies (Applications) and People (Users) This badge is stored in your building's system (Webhook App Registration) Step 2: Give badge to the Event Grid Service: Event Grid: "Hey, I need to deliver messages to your building" You: "Okay, here's a GOLD badge for your SP" Event Grid: *wears the badge* Now Event Grid can: - Show the badge to Azure Entra - Get tokens that say "I have the GOLD badge" - Deliver messages to your webhook Step 3: Give badge to yourself (or your deployment tool) You also need a GOLD badge because: - You want to create event grid event subscriptions - Entra checks: "Does this person have a GOLD badge?" - If yes: You can create subscriptions - If no: "Access denied" Your deployment pipeline also gets a GOLD badge: - So it can automatically set up event subscriptions during CI/CD deployments Disclaimer: The sample scripts provided in this article are provided AS IS without warranty of any kind. The author is not responsible for any issues, damages, or problems that may arise from using these scripts. Users should thoroughly test any implementation in their environment before deploying to production. Azure services and APIs may change over time, which could affect the functionality of the provided scripts. Always refer to the latest Azure documentation for the most up-to-date information. Thanks for reading this blog! I hope you found it helpful and informative for this specific integration use case šš Securing Azure Workloads: From Identity to Monitoring
Hi everyone š ā following up on my journey, I want to share how I approach end-to-end security in Azure workloads. - Identity First ā Microsoft Entra ID for Conditional Access, PIM, and risk-based policies. - Workload Security ā Defender for Cloud to monitor compliance and surface misconfigurations. - Visibility & Monitoring ā Log Analytics + Sentinel to bring everything under one pane of glass. Through my projects, Iāve been simulating enterprise scenarios where security isnāt just a checklist ā itās integrated into the architecture. Coming soon: - A lab demo showing how Defender for Cloud highlights insecure configurations. - A real-world style Conditional Access baseline for Azure workloads. Excited to hear how others in this community are securing their Azure environments! #Azure | #AzureSecurity | #MicrosoftLearn | #ZeroTrust | #PerparimLabs
Azure Key Vault Replication: Why Paired Regions Alone Donāt Guarantee Business Continuity
As customers modernize toward multiāregion architectures in Azure, one question comes up repeatedly: āIf my region goes down, will Azure Key Vault continue to work without disruption?ā The short answer: it depends on what you mean by āwork.ā Azure Key Vault provides strong durability and availability guarantees, but those guarantees are often misunderstoodāespecially when customers assume pairedāregion replication equals full disaster recovery. In reality, Azure Key Vault replication is designed for survivability, not uninterrupted write access or customerācontrolled failover. This post explains: How Azure Key Vault replication actually works (per Microsoft Learn) Why pairedāregion failover does not equal business continuity Two reference architectures that implement true multiāregion Key Vault availability, with Terraform How Azure Key Vault Replication Works (Per Microsoft Learn) Azure Key Vault includes multiple layers of Microsoftāmanaged redundancy. InāRegion and Zone Resiliency Vault contents are replicated within the region. In regions that support availability zones, Key Vault is zoneāresilient by default. This protects against localized hardware or zone failures. PairedāRegion Replication If a Key Vault is deployed in a region with an Azureādefined paired region, its contents are asynchronously replicated to that paired region. This replication is automatic and cannot be configured, observed, or tested by customers. MicrosoftāManaged Regional Failover If Microsoft declares a full regional outage, requests are automatically routed to the paired region. After failover, the vault operates in readāonly mode: ā Read secrets, keys, and certificates ā Perform cryptographic operations ā Create, update, rotate, or delete secrets, keys, or certificates This is a critical distinction. Pairedāregion replication preserves access ā not operational continuity. Why PairedāRegion Replication Is Not Business Continuity From a reliability and DR perspective, several limitations matter: Failover is Microsoftāinitiated, not customerācontrolled No write operations during regional failover No secret rotation or certificate renewal No way to test DR Accidental deletions replicate No pointāinātime recovery without backups Microsoft Learn explicitly states that critical workloads may require custom multiāregion strategies beyond builtāin replication. For many customers, this means Azure Key Vault becomes a singleāregion dependency in an otherwise multiāregion application design. The MultiāRegion Key Vault Pattern The two GitHub repositories below implement a common architectural shift: Multiple independent Key Vaults deployed in separate regions, with customerācontrolled replication and failover. Instead of relying on invisible platform replication, the vaults become firstāclass, regionāscoped resources, aligned with application failover. Solution 1: Private, LockedāDown MultiāRegion Key Vault Replication Repository: š https://github.com/jclem2000/KeyVault-MultiRegion-Replication-Private Architecture Highlights Independent Key Vault per region Private Endpoints only No public network exposure Terraformābased deployment Controlled replication using Event Based synchronization What This Enables ā Full read/write access during regional outages ā Continued secret rotation and certificate renewal ā Customerādefined failover and RTO ā DR testing and validation ā Strong alignment with zeroātrust and regulated environments Tradeāoffs Higher operational complexity Requires automation and application awareness of multiple vaults Solution 2: LowāCost Public MultiāRegion Key Vault Replication Repository: š https://github.com/jclem2000/KeyVault-MultiRegion-Replication-Public Architecture Highlights Independent Key Vault per region Public endpoints Minimal networking dependencies Terraformābased Controlled replication using Event Based synchronization Optimized for simplicity and cost What This Enables ā Full read/write availability in any region ā Clear and testable DR posture ā Lower cost than private endpoint designs ā Suitable for many nonāregulated workloads Tradeāoffs Public exposure (mitigated via firewall rules, RBAC, and conditional access) Not appropriate for all compliance requirements Requires automation and application awareness of multiple vaults Azure Native Replication vs CustomerāManaged MultiāRegion Vaults Capability Azure Paired Region MultiāRegion Vaults Read access during outage ā ā Write access during outage ā ā Secret rotation during outage ā ā Customerācontrolled failover ā ā DR testing ā ā Isolation from accidental deletion ā ā Predictable RTO ā ā Azure Key Vaultās native replication optimizes for platform durability. The multiāregion pattern optimizes for application continuity. When to Use Each Approach PairedāRegion Replication Is Often Enough When: Secrets are mostly static Readāonly access during outages is acceptable RTO is flexible You prefer Microsoftāmanaged recovery MultiāRegion Vaults Are Recommended When: Secrets or certificates rotate frequently Applications must remain writable during outages Deterministic failover is required DR testing is mandatory Regulatory or operational isolation is needed Closing Thoughts Azure Key Vault behaves exactly as documented on Microsoft Learnābut itās important to be clear about what those guarantees mean. Pairedāregion replication protects your data, not your ability to operate. If your application is designed to survive a regional outage, Key Vault must follow the same multiāregion design principles as the application itself. The reference architectures above show how to extend Azureās native durability model into true operational resilience, without waiting for a platformālevel failover decision.
Service Principals in Microsoft Power Platform
Shared Passwords Are a Ticking Time Bomb Letās be blunt: if your Power Platform automation runs on a shared service account password that three people know, you are one resignation away from every flow going dark, one password reset, one MFA changeā¦ That is all it takes. The fix? A service principal, a nonāhuman application identity in Microsoft Entra ID that authenticates with certificates, never logs in interactively, and keeps running no matter who leaves. In Power Platform, it shows up as an Application User in Dataverse and can own flows, manage Power BI datasets, run Dataverse operations, and power your CI/CD pipelines. Unlike a traditional shared service account (which carries the risk of password expiration, MFA prompts breaking automation, and credentials being overshared), a service principal authenticates using certificates or client secrets, has no mailbox, no interactive login, and cannot be accidentally used by a person. For organizations running Power Automate flows, calling APIs, running Power Platform Pipelines or managing environments programmatically, service principals offer a fundamentally more secure, auditable, and manageable identity. They enable least-privilege access, integrate cleanly with Conditional Access policies, and eliminate the single point of failure that comes with tying critical automation to an individual employee's account. This lack of tether to an individual account means workloads do not need to be reassigned once someone leaves your organization. Put more simply, if your Power Platform workloads are still running under a named user or a shared "svc_powerautomate@company.com" account, it's time to reconsider. Microsoft Advisory: āBest practice is to use service principals as the preferred identity model for Power Automate wherever supported, because shared userābased service accounts introduce security, audit, and operational risks.ā In this blog, we will highlight opportunities to strengthen your security posture across the Power Platform with Service Principals alongside ideas for when a Service Principal may not be applicable for your scenario. Getting Started: Setting up a service principal is straightforward. Everything is documented on Microsoft Learn: šRegister an app in Entra ID ā Microsoft Learn šManage application users ā Microsoft Learn šService principal owned flows ā Microsoft Learn There are also many good blogs about step-by-step setup of the service principal, assigning permissions and assigning to an application user we won't be covering the setup here. Let's go into detail how you can utilize a Service Principal to secure your Power Platform workloads. Where Service Principals Shine in the Power Platform ā” Power Automate In Power Automate, service principals establish durable ownership and authentication for enterprise automation. Flows run under a nonāhuman application identity, eliminating dependency on individual users and preventing failures caused by password rotation, MFA enforcement, or user departure. Flow Ownership: Assign the service principal as the primary owner to ensure flows continue running regardless of personnel changes. Service Principalāowned flows require either a Process license (~$150/flow/month, stackable up to 10 for 2.5M actions/day) or payāasāyouāgo billing via Azure. Authentication: Service principals authenticate using client credentials, removing the standard 90āday connection expiry. Only the client secret or certificate has an expiration, which can be configured (up to 24 months). For production workloads, store secrets in Azure Key Vault with rotation alerts. Dataverse Connector: Dataverse is the only standard connector with native service principal signāin. Selecting Connect with Service Principal ensures all Dataverse actions execute under the application identity with full audit attribution. NonāService Principal Connectors: Connectors such as SharePoint, Outlook, and Teams require delegated user context by design. Where appāonly execution is required, the HTTP connector can be used to call Microsoft Graph with application permissions, introducing a premium dependency. ā Service PrincipalāFriendly ā Microsoft Dataverse (native SP signāin) ā Custom connectors (appāonly OAuth) ā HTTP via Graph API (app permissions) ā Requires User Context ā SharePoint (standard connector) ā Outlook / Office 365 ā Teams (many actions) ā Planner, OneDrive šSupport for service principal owned flows - Power Automate | Microsoft Learn š Manage connections to Dataverse ā Microsoft Learn š± Power Apps and Dataverse Your Service Principalās Application User executes Dataverse operations from flows triggered by modelādriven apps. Audit logs clearly separate automated changes from human activity. Assign custom security roles scoped to exact tables (skip System Admin), use separate Service Principalss per solution area, and know that canvas apps can trigger Service Principalābacked flows behind the scenes. šCreate a Dataverse application user ā Microsoft Learn š Power BI This is where Service Principals quietly save organizations from one of the most common Power BI failures: dataset refresh breaking because the owner left. Take over semantic model ownership via the REST API and refreshes never fail from expired tokens again. Workspace access: add Service Principal as Member or Admin Semantic model ownership takeover via REST API Automated refresh from PowerShell, Logic Apps, Azure Data Factory, or custom apps XMLA endpoint access for model deployment and DAX queries (Premium/Fabric) App Owns Data embedding for external users without Power BI licenses Requirement: Tenant admin enables āService principals can use Fabric APIsā. Service Principal added to workspace. API refresh needs Premium, Premium Per User, or Fabric capacity. šAutomate Premium tasks with Service Principals ā Microsoft Learn šEnhanced refresh REST API ā Microsoft Learn š ļø Application Lifecycle Management (ALM) with Pipelines Power Platform Pipelines are a built-in option for application lifecycle management native to the Power Platform. Pipelines bring ALM automation and continuous integration and continuous delivery (CI/CD) functionality into a native service that's designed to be usable by all members of your low-code team, regardless of technical capability. To learn how to set up pipelines in Power Platform, Microsoft has some fantastic documentation as well as a learning path on Learn.microsoft to guide you through the process. We can utilize Service Principals in Pipelines as well. By default, a pipeline deploys as the requesting maker, meaning the maker needs elevated permissions to deploy to the target environment. Delegated deployments with Service Principals allow deployment without the maker needing elevated permissions in the downstream environment. The pipeline can run as a service principal (or pipeline stage owner), allowing makers to deploy without needing elevated permissions in target environments like production. Approvals may be required for security reasons, and can be automated or manual depending on your security requirements. šPAC CLI: createserviceprincipal - Microsoft Learn š”ļø Alternatives for Secure Workloads While service principals offer an avenue to securing most workload scenarios on the Power Platform, they cannot cover all workload scenarios. In these cases, there are alternative approaches. Azure Logic Apps support system-assigned and user-assigned managed identities, allowing workflows to authenticate directly to Azure resources without storing or managing any login credentials. This can offer an option when your workload can live outside Power Automate. Some teams opt to retain shared service accounts. This is not best practice, but when undertaken, there are steps to harden these accounts. Dedicated Entra Conditional Access policies to enforce MFA, restricting sign in locations and devices can provide additional protection. For password rotation, Azure Key Vault centralizes credential storage and enables automatic secret rotation, reducing the risk of stale or exposed passwords. Each of these approaches can be layered or combined with service principals depending on your organization's risk tolerance, licensing constraints, and connector support limitations. šGoverning Entra service accounts ā Microsoft Learn All Your Options at a Glance Not sure which approach fits? Here is every option compared ā from the gold standard to the fallback you hope to leave behind: Option MS Rec? Key Benefit Main Tradeoff Security SP + Process License Yes Gold standard. Certificate auth, clean audit. ~$150/flow/mo. Solutions required. Highest SP + Flow Groups Yes (GA May ā26) 1 license across up to 25 flows. Shared 250K/day action pool. Highest SP + Pay-as-you-go Yes Available today. No upfront cost. Variable cost. Azure sub needed. Highest Hybrid: SP + SA Pragmatic SP owns; SA for delegated connectors. SA still exists for connections. MedāHigh Hardened SA Only No Simplest and no migration needed. Interactive login risk. MS discourages. Low Logic Apps + MI Yes (diff product) Zero credentials. Consumption billing. Full platform migration required. Highest ā All costs are approximate and vary by enterprise agreement. Verify with your Microsoft representative. Microsoftāvalidated: The dedicated service account fallback is a supported approach, not a workaround. Any alternative to service principals would need to be designed and accepted at the customerās own risk. Summary Service principals replace shared, userābased accounts with a nonāhuman application identity that is secure, auditable, and resilient. Eliminating password risk, improving governance, and ensuring Power Platform workloads continue running independent of employee lifecycle events across the entire platform. The result is higher security, operational stability, and governance consistency. The Bottom Line Service principals are not optional polish. They are how Microsoft expects you to run enterprise automation in 2026. One Entra ID app registration. Four products. Zero shared passwords. ā Blocking interactive admin logins is correct. No supported scenario requires it. ā Hybrid model when needed. Service Principals where supported, hardened service accounts where not. Both documented by Microsoft. ā Start with payāasāyouāgo. Pilot a batch. Measure costs. Then commit. No upfront purchase needed. Authors: Sheldon Dsouza + Marc Lotorto | Contributors: Rasha Al-Silmi, Ahmed Shaalan, Josh Flicker All guidance aligned with Microsoft Learn and validated by Microsoft Advisory, April 2026Enterprise Security Assessment: A Strategic Lens for Mission Critical Environments
Understanding Enterprise Security at Scale Understanding security posture at scale requires more than isolated control reviews or pointāinātime assessments. The Enterprise Security Assessment (ESA) helps organizations understand their security posture across Azure, Microsoft 365, and hybrid environments from a true enterprise perspective. Instead of assessing individual services or workloads in isolation, ESA provides a single, enterpriseāwide view of security. By examining identity, data security, endpoints, threat protection, and cloud infrastructure together, ESA helps uncover gaps that often span multiple teams and platforms. This broader perspective enables clearer prioritization, stronger alignment across security teams, and a more resilient foundation for longāterm security improvement. ESA complements other Microsoft assessments, such as workloadāspecific reviews, by connecting the bigger picture - to align security priorities across teams and platforms, fostering a more cohesive and resilient security approach. From Standard Engagement to Strategic Partnership An Enterprise Security Assessment is typically delivered as a focused engagement designed to establish an enterpriseāwide view of security posture. At Microsoft, we begin by reviewing Secure Score insights, analyzing a defined set of core security datasets, and correlating those signals across Azure and Microsoft 365. For many organizations, this approach works well. Collecting and evaluating these datasets provides a highālevel understanding of security posture, highlights common gaps, and identifies priority improvement areas. In standard enterprise environments, ESA delivers actionable insights with minimal disruption and sets a solid foundation for security improvements. How ESA Evolves in MissionāCritical Environments In large or missionācritical environments, security is often distributed across multiple teams and tools. Operational constraints, regulatory requirements, and business dependencies introduce complexity that standard assessments cannot fully capture. For missionācritical customers, ESA goes beyond a baseline review and becomes more consultative. This typically includes: š Structured discovery sessions across multiple security domains š¤ Deepādive workshops with specialized teams šÆ Validation of findings against realāworld operating models š Iterative analysis to validate findings against real operational conditions This ensures recommendations reflect how security is actually managed, not just how it is documented. Why Going Deeper Matters to Customers For organizations operating at scale, this consultative ESA approach delivers significantly more than a standard readout: A realistic, enterpriseāwide understanding of security posture, grounded in actual configurations and operating models Clear visibility into crossāteam dependencies and systemic risks Prioritized recommendations aligned to existing licenses, thirdāparty tools, and regulatory requirements A realistic, phased security roadmap focused on adoption, not theory The result is a clear starting point for security improvements that teams can execute with confidence. A Continuous Improvement Model ESA is not a oneātime exercise. For most customers, it becomes the foundation for ongoing security maturity. Once a baseline is established, future ESAs are faster and more efficient, allowing organizations to track progress, validate improvements, and maintain alignment as environments evolve. Over time, ESA functions as an annual enterprise security health check, supported by followāup reviews and continuous improvement. In missionācritical environments, this means: The first ESA requires deeper engagement investment Building cross-team alignment takes time Future assessments become smoother and more efficient once a baseline is established Over time, ESA functions as an enterprise security health check that supports continuous improvement. It works best when treated as a starting point for continuous improvement, and Enterprise Security Alignment. What Customers Gain from an Enterprise Security Assessment A true enterprise view Visibility across identity, data, devices, cloud workloads, and threat signals - without losing sight of critical details. A customized security roadmap Recommendations aligned to existing licenses, thirdāparty tools, hybrid footprints, and regulatory requirements - making adoption realistic, not aspirational. Momentum and measurability Many organizations track progress using dashboards or scorecards to measure improvement and sustain focus over time. Repeatability Once a baseline is established, future ESAs become easier and more efficient - serving as a regular health check rather than a brandānew effort. A consultative model ESA delivers far more value than a oneātime assessment by fostering collaboration, shared understanding, and longāterm alignment. A Foundation for Continuous Improvement Enterprise security is complex, especially at scale. In missionācritical environments, security success depends on embracing complexity, aligning teams, and moving beyond a standard assessment playbook. An Enterprise Security Assessment is more than a snapshot. Itās an opportunity to build alignment, inform strategy, and create a resilient security foundation that evolves with the organization.
Building a Production-Ready Azure Lighthouse Deployment Pipeline with EPAC
Recently I worked on an interesting project for an end-to-end Azure Lighthouse implementation. What really stood out to me was the combination of Azure Lighthouse, EPAC, DevOps, and workload identity federation. The deployment model was so compelling that I decided to build and validate the full solution hands-on in my own personal Azure tenants. The result is a detailed article that documents the entire journey, including pipeline design, implementation steps, and the scripts I prepared along the way. You can read the full article hereConditional Access for Canvas Apps with Entra
In today's Power Platform landscape, administrators have a tough task securing the ever-increasing inventory of Canvas Apps across their tenant. Canvas apps often connect to sensitive data, run on a variety of devices, and serve diverse groups of users. That is why Conditional Access has become one of the most powerful tools in an adminās toolkit, giving you fine grained control over how, where, and under what conditions users can access your apps. āÆ In this post, I will walk through what Conditional Access means for canvas apps, how it empowers admins to maintain strong security without adding friction for legitimate users, and example steps to apply your own conditional access policies to an app with PowerShell. āÆ What Conditional Access Brings to Canvas Apps Conditional Access brings granular, app-level security controls from Microsoft Entra ID directly into Power Apps. Instead of applying blanket restrictions across the entire tenant, you can enforce requirementsālike MFA, compliant devices, or trusted networksāonly on the apps that need them. This lets you match security to the sensitivity of each individual app. āÆ Key Benefits for Admins Tailored Protection for Sensitive Apps Not every app requires strict controls. Conditional Access allows you to tighten security only for apps that handle sensitive or regulated data, without over restricting everything else. Control Access by Device Type Admins can easily block or allow specific device categoriesālike preventing mobile access to a high-risk app or requiring managed devices for apps that contain confidential information. Alignment With Zero Trust Conditional Access enforces identity, device, and session checks in real time, supporting a Zero Trust approach without adding unnecessary friction for legitimate users. Environment-Specific Flexibility You can apply stricter policies in production and lighter ones in development or testing, helping teams build efficiently while keeping sensitive environments locked down. āÆ A Stronger Security Model Conditional Access does not replace existing apps or data permissionsāit complements them. App-level security roles control what users can do inside an app, while Conditional Access governs whether they can get into the app at all. Together, they create a much more robust security posture. āÆ How to enable conditional access for a Canvas App example In this example, I will detail steps to set up conditional access for a Canvas App to ensure tenant guest users are not able to access the app. āÆ Step 1: Create an Authentication Context in Entra ID Go to theāÆMicrosoft Entra Admin Center. Navigate toāÆProtection ā Conditional Access ā Authentication context. ClickāÆ+ New authentication context. Name it (e.g., BlockGuests_PowerAppX) EnableāÆPublish to apps Save and note theāÆAuthentication Context ID āÆ āÆ āÆ Step 2: Create a Conditional Access Policy Go toāÆConditional Access ā Policies ā + New policy. Name the policy (e.g., Block Guests from Power App X). Assignments: Users or workload identities: āÆ Include:āÆGuest or external users Target resources: ChooseāÆAuthentication context Select the one you created earlier Access controls: Grant: SelectāÆBlock access Enable the policy and clickāÆCreate. āÆ āÆ Step 3: Assign the Authentication Context to the Power App Use PowerShell to bind the Authentication Context to the specific Power App: Open PowerShell as Administrator. Connect to Power Apps Add-PowerAppsAccount Run the command to attach the context to your canvas app Set-AdminPowerAppConditionalAccessAuthenticationContextIds -EnvironmentName "<your-environment-name>" ` -AppName "<your-app-id>" ` -AuthenticationContextIds "<your-auth-context-id>" āÆ This binding tells Power Apps: āWhen this app opens, trigger the Conditional Access policy tied to this context.ā āÆ Step 4: Test the Policy Try accessing the app as a guest user. You should see access blocked based on the Conditional Access policy. āÆ āÆ āÆ āÆ Wrap Up A Stronger Security Model Conditional Access does not replace existing apps or data permissionsāit complements them. App-level security roles control what users can do inside an app, while Conditional Access governs whether they can get into the app at all. Together, they create a much more robust security posture. Bottom Line Conditional Access gives admins the flexibility to apply the right security to the right app. Whether you are enforcing MFA, restricting device types, or securing production environments, it helps you protect sensitive data without slowing down the organization. Documentation for further reading: Manage Power Apps - Power Platform | Microsoft Learn Demo from Power CAT: Conditional Access Policies for Canvas Apps - Power CAT Live
