<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Azure-Rbac on Trust Anchor</title><link>https://trustanchor.pro/tags/azure-rbac/</link><description>Recent content in Azure-Rbac on Trust Anchor</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 George Vaculik</copyright><lastBuildDate>Sat, 06 Jun 2026 10:00:00 +0200</lastBuildDate><atom:link href="https://trustanchor.pro/tags/azure-rbac/index.xml" rel="self" type="application/rss+xml"/><item><title>PIM at scale: roles, groups, and Azure resources as one system</title><link>https://trustanchor.pro/posts/pim-at-scale-three-domains/</link><pubDate>Sat, 06 Jun 2026 10:00:00 +0200</pubDate><guid>https://trustanchor.pro/posts/pim-at-scale-three-domains/</guid><description>PIM is one service in Microsoft Entra admin center, with three management areas — Entra roles, Azure resources, Groups — and no default-policy mechanism in any of them. The integrated view, with consistent tiered policies bound by authentication context, has to be reconstructed in code. This post walks the design and the API patterns that make it work, including the non-inheritance gotcha, the role-assignable-group Member-vs-Owner setup clash, and the service-principal exemption that has to be governed instead of forgotten. The MSSP section at the end shows how the whole pattern lands in a pipeline with drift detection.</description></item></channel></rss>