Extending Microsoft Entra: Logic Apps, Power Apps, and the Art of Tinkering with Entra ID

Most Conditional Access gaps aren’t exotic. They come from reading policies the wrong way: as firewall rules with an “allow”, as a list of platforms that seems complete, as an MFA exception for the office that made sense years ago. Brandon Colley has reviewed well over a thousand Conditional Access policies in customer assessments, and the same handful of mistakes come up in tenant after tenant. Once those are fixed, the risk moves. Passkeys, privileged access and Conditional Access put more locks on the front door, the user sign-in. An app that was consented to years ago, holds a client secret and still has a stale redirect URI is a back door that none of those locks cover. Brandon is a Senior Security Consultant at TrustedSec and a Microsoft Security MVP. He came from systems administration, learned Active Directory security at Trimarc, and now spends his days on cloud and on-premises assessments and the remediation that follows. These are the gaps he checks first, and the app and consent settings he has moved on to. Security defaults can cover more admins than your policies The free tier can be stricter than the paid one. Security defaults require MFA for 16 administrator roles. The Microsoft-managed policy “Multifactor authentication for admins accessing Microsoft Admin Portals”, and the “Require MFA for admins” template it mirrors, cover 14. The two extra roles in security defaults are Authentication Policy Administrator and Identity Governance Administrator. If a small tenant is on security defaults, think hard before switching it off: the moment you do, you lose protections that you then have to rebuild in Conditional Access yourself. Sponsored by: ENow Software Introduces New Entra ID App Onboarding Experience As user requests for SaaS and AI applications increase, Entra ID and M365 teams face a growing volume of security reviews, added hours of manual research, and bottlenecks. New! ENow App Governance Accelerator 4.0 introduces App Onboarding, helping teams: * Accelerate app approvals with configurable, multistage workflows. * Evaluate security risks more efficiently with integrated Microsoft Defender for Cloud Apps risk scores. * Reduce manual work with centralized requests, reviews, and approvals. * Improve transparency with a self-service portal for requesters to track status and decisions. * Control app sprawl with an Internal App Catalog of approved applications. Go beyond Microsoft’s consent and approval capabilities with customizable, structured application governance, from the initial request through ongoing oversight. Faster Approvals. Less Admin Work. Better Security Posture. Learn More About ENow App Governance Accelerator 4.0 See It In Action: Request a Demo Decide which roles are privileged yourself “We require MFA on privileged roles” is easy to say in an audit. An assessment asks a harder question: privileged by whose definition? Brandon’s own list is about 36 roles, grouped into tier 0 and tier 1, the same tiering model Active Directory admins used 20 years ago. Don’t lean on Microsoft’s mandatory MFA either. It covers the Azure portal, the Microsoft Entra admin center, the Intune admin center and the Microsoft 365 admin center, plus create, update and delete operations from Azure CLI, Azure PowerShell, the Azure mobile app and IaC tools. Microsoft Graph APIs are generally not in scope, so in some cases a single-factor sign-in can still reach Graph. Your Conditional Access still has to cover every app and every role you consider privileged. Every platform is not all platforms Conditions inside one policy combine with AND. A policy that requires MFA when the user is risky, the sign-in is risky and the location is outside the United States only fires when all three are true at once, so it almost never fires. Put conditions that should act on their own into separate policies. The device platforms condition has the same trap. Ticking Android, iOS, Windows, macOS and Linux is not the same as “any device”.

Most tenants have the same problem: hundreds of app registrations and service principals, client secrets that were set to expire in a hundred years, permission grants nobody remembers approving, and test tenants that were never cleaned up. It’s tempting to start fixing the scariest app on the list. Jeff Sakowicz argues for a different order: stop the problem from growing first, then remove the debt that gives you the most risk reduction for the least disruption. Jeff isn’t describing someone else’s product. He has spent most of his 14 years at Microsoft as a product leader on the Entra application platform, shaping the application and service principal model and the OAuth permissions and consent model that every Entra tenant runs on today. Publisher verification and risk-based step-up consent came out of that work, and he now leads part of the team building the platform behind Microsoft Entra Agent ID. Inside Microsoft, he’s the person teams call when an app incident needs untangling. This is his playbook for securing non-human identities, from client secret burndown and unused apps to consent phishing and the protections Microsoft runs in every tenant by default.

A phished and stolen refresh token is one of the most useful things an attacker can take from your tenant. It is a long-term artifact, which is why so many phishing attempts go after it. Alex Pavlovsky’s answer to that attack is a feature every Entra ID P1 tenant already owns. Compliant network is part of Global Secure Access, and, like source IP restoration, it comes with Entra ID P1. Put the GSA client on your devices, add one Conditional Access policy that blocks access from anywhere outside the All Compliant Network locations named location, and a stolen refresh token or PRT cookie no longer works from the attacker’s own machine. As Alex puts it, the token itself does not become bound, but your use of it is gated by being on your organization’s compliant network. Merill is joined by two former colleagues who are Microsoft Entra PMs: Alexander (Alex) Pavlovsky from the Global Secure Access feature team, and Marilee Turscak, who works on helping customers adopt AI safely. They explain why Microsoft built networking into identity, walk through the compliant network policy and a BYOD sign-in with no client installed, and demo a network policy that stops an agent from deleting a file its user is allowed to delete. Why a stolen token stops working For phishing itself, Alex is clear that the main line of defence is still stronger credentials that do not involve passwords. Compliant network helps with what comes after: the newer attack patterns where refresh tokens are stolen and replayed. If your tenant-wide policy says you can only authenticate from a compliant network, you can also only replay refresh tokens from a compliant network. PRTs become unusable unless they are used from a device that has GSA, which means your organization’s device. Alex says the same applies to ROADtools-style attacks with PRT cookies: none of that works with compliant network in place. The signal is also tenant-specific. A GSA device in tenant B satisfies compliant network in tenant B and nowhere else. In the demo, Alex builds the policy in a few clicks: all users, all resources (so the primary refresh token, Entra ID itself and Microsoft Graph are covered), any network except compliant network locations, then block. Start it in report-only mode, watch who is not coming through compliant network, pilot with a smaller group and expand. You do not need the advanced GSA licences for this, but you do need the GSA client on your devices or a remote network sending the traffic. And exclude your break glass accounts. Alex has taken many panicked customer calls from admins who forgot, and Marilee locked herself out of a test tenant this way recently. One engine for identity and network When Merill joined Microsoft, he couldn’t see why networking belonged to the identity team. Alex explains the reasoning. When identity picks up a signal that a user, session or token is at risk, the network has to hear about it quickly, and passing those signals between separate systems through traditional APIs is too slow at this scale. So Microsoft made the identity engine and the network engine one engine. That design shows up in source IP restoration. Behind a typical proxy or security service edge, every user looks like they signed in from the provider’s shared IP range. GSA sends the user’s original source IP to Entra securely, so sign-in logs are accurate, Conditional Access can evaluate the user’s own IP, and Identity Protection’s location and impossible travel detections work again. It is also why compliant network works at all: the GSA edge shares a security engine with Entra ID, so it can tell Entra that this is a legitimate GSA device from a specific tenant, and Entra can trust that signal. The network can tell agents from users “Agents are super deterministic. They are very resourceful. They do not give up.” Alex also argues that saying no to agents means falling behind your competitors, so the question becomes how to protect their use. GSA can detect when network

Ask a coding agent to build something that talks to another service and watch what it does. It creates a client secret. Then another one. As Arturo Lucatero puts it, next thing you know you have ten secrets that were created without you knowing about it. At the speed AI is moving, he thinks we could be cleaning up a few million new secrets within six months. That would undo a lot of hard work. Under Microsoft’s Secure Future Initiative, Microsoft spent years removing secrets from its own estate and helping customers do the same with managed identities and workload identity federation. The agent era is the window to make secretless the default before the habit sets in. Arturo is a Principal Product Manager on Microsoft Entra Agent ID, and he helped launch Managed Service Identity, the feature we now call Managed Identities for Azure resources. In this episode he and Merill trace the whole path: why secrets break, how managed identity takes them away inside Azure, how workload identity federation extends that to AWS, GCP, Azure Arc and now AI vendors like Anthropic, and what that means for agents. Secrets work until they don’t A service principal with a client secret works. It works right up to the moment it gets leaked, expires in the middle of an important job, or turns out to have no clear owner, no rotation plan and no one who knows where it is stored. Managed identity moves that whole burden to the platform. The secret still exists, but the developer never sees it. The admin’s job shrinks to control-plane questions: which resource, which identity, and what it can access. Arturo also hints at what comes next: binding managed identity tokens to the resource so a leaked token is useless anywhere else. Beyond Azure Not every workload or data source lives in Azure. Workload identity federation lets a workload present a token from an identity provider you already trust, such as AWS, Google Cloud, GitHub or Kubernetes, and exchange it for an Entra token with no secret involved. Azure Arc brings managed identity to servers outside Azure, including the one under your desk, which raised a hard design question for the team: what happens to the secret when the machine is in someone’s basement? Coding agents default to secrets Coding agents learned from years of examples full of client secrets and Key Vault plumbing, so that is what they produce. Merill has to push his own agents back towards workload identity federation every time. Arturo hit the same problem from the inside: when he asked a coding agent to build with Agent ID, it created a plain service principal and named it “blueprint”. The fix was rewriting documentation and shipping agent skills that teach coding agents the right pattern. Why agent identities still allow client secrets Merill asks the obvious question. If secrets are this bad, why can an agent identity have one? Arturo’s answer is compatibility. Agent identities already authenticate through a federated identity credential flow under the hood, but many places that call agents cannot obtain an OIDC token yet. Without secrets or certificates as a fallback, people would simply keep using app registrations. Open standards are the way out Agents now cross identity providers and clouds every day. Entra is leaning on open standards so they can do that without secrets or interrupting users: SPIFFE identities that can be exchanged for Entra tokens, and ID-JAG, which lets admins pre-consent so an agent can reach a service like GitHub or Slack without prompting the user. Arturo’s advice for anyone building today is simple: whatever you can do to avoid having a secret, do it.

Active Directory is not dead. It is nearly thirty years old, Microsoft is still shipping new capabilities and new telemetry for it, and most of the forests running today will outlive the people currently administering them. What has changed is that you can now test it the same way you test your cloud tenant. Maester, the open-source PowerShell testing framework, added Active Directory coverage: 269 opt-in checks across 19 areas, from users, groups, computers and service principal names through GPO state, DACLs, DNS, trusts, replication and schema. They run against your domain, not your tenant, and they are off unless you explicitly connect to Active Directory. Mike Soule, who wrote and validated that test suite, and Sam Erde, Microsoft MVP and author of DLLPickle, join Merill at HIP Conf in Nashville to go through what the tests cover, how to run them safely, and where the project is heading. Sponsored by: Is Each App in Entra ID Still Worth Governing? App registrations and enterprise applications accumulate. Owners change. Projects and pilots end. Credentials linger. And stale or unused apps and their permissions can continue adding risk and governance overhead long after their purpose is gone. ENow App Governance Accelerator helps you understand what’s in your Entra ID application estate, who owns it, which apps, permissions, and credentials need attention, and what can safely be cleaned up to reduce your attack surface on a continuous basis as your tenant grows and changes. Get the visibility and automated workflows you need to investigate application lifecycles at scale, clear out stale apps, and stop wasting time governing applications that shouldn’t still be there in the first place. Operational health is not the same as a security finding The design decision that makes these tests usable is the split between operational patterns and security controls. Six groups nested in a row is not a vulnerability. Nesting is an intentional, functional capability. It is also nearly impossible to reason about when you are trying to work out where a permission actually comes from, and that is how incidents happen. So not every test is pass/fail. Some exist to be investigated and monitored, and Maester’s tagging lets you baseline them and watch whether an anti-pattern is spreading or receding over time. The underlying guidance is a blend: years of health checks across dozens of forests, community research from teams like Semperis and SpecterOps, and Microsoft’s own documentation — which, for a product people keep declaring dead, is currently some of the best documentation and logging Microsoft ships. The new NTLM auditing in Windows Server is the example: the who, the why and the where of every NTLM authentication, instead of replaying events and correlating them yourself. Maester is not trying to replace the likes of PingCastle, Purple Knight or Locksmith. Those tools offer real value, and the conversation now is about bringing those perspectives into one central platform. The permissions you actually need Everything the AD tests do is read-only. A plain domain user gets a surprising amount, because a directory is built to be readable — you will simply get a subset of the tests. The full set needs tier-zero read access, because some tests reach objects in the configuration container. In a tiered environment, that means running as a tier-zero admin from a privileged admin workstation. Interactively, there is nothing to set up beyond line of sight to a domain controller, the ActiveDirectory module and PowerShell. The AD tests are excluded by default and have to be requested by tag. For automation, run a local runner, or give a container runtime a path back to a domain controller. Today the tests run as the logged-in user’s domain credentials; alternate credentials and group managed service accounts are on the road map. Tiering, ESAE and the enterprise access model There are no explicit tiering tests yet, but they are coming now that Mic