Entra PIM Aktivierung: Genehmigung, MFA, Begründung

Entra PIM Aktivierungsfehler: Fehlende Genehmigung, MFA und Begründung Erklärt

Microsoft Entra Privileged Identity Management (PIM) zu aktivieren ist der einfache Teil. Die Entra PIM Aktivierungsfehlkonfiguration bei Genehmigung, MFA und Begründung ist das, was danach passiert: PIM ist eingerichtet, Rollen sind berechtigt statt permanent zugewiesen, aber der Aktivierungsschritt selbst bleibt weit offen — keine Genehmigung erforderlich, keine MFA bei der Aktivierung, keine protokollierte Begründung, und ein Aktivierungsfenster von 8 Stunden oder länger. Das Ergebnis sieht auf einem Dashboard wie Just-in-Time-Zugriff aus, verhält sich in der Praxis aber wie dauerhafter Admin-Zugriff: Jeder, der für eine Rolle berechtigt ist, erhält sie in dem Moment, in dem er auf „Aktivieren" klickt — ohne zweiten Faktor, ohne Nachvollziehbarkeit und mit einem Zeitfenster, das lang genug ist, um die meisten Erkennungszyklen zu überdauern.

Das ist ein eigenständiger Fehlerfall, anders als „PIM ist gar nicht aktiviert". Ein Tenant kann diese erste Prüfung bestehen und trotzdem exponiert sein, weil der Sicherheitswert von PIM fast ausschließlich davon abhängt, wie die Aktivierung konfiguriert ist — nicht davon, dass berechtigte Zuweisungen existieren. Jede der vier Aktivierungskontrollen — Genehmigung, MFA, Begründung und Dauer — ist in Microsoft Entra pro Rolle optional, und keine davon ist standardmäßig erforderlich.

⚠️

⚠️ Warnung: PIM-Rolleneinstellungen gelten pro Rolle und sind unabhängig voneinander. Die Korrektur von Global Administrator behebt nicht automatisch Privileged Role Administrator, Security Administrator oder benutzerdefinierte Verzeichnisrollen — jede Rolle muss einzeln geprüft und konfiguriert werden.

Wie die PIM-Aktivierungskontrollen Funktionieren

Microsoft Entra stellt PIM-Rolleneinstellungen — intern Policies genannt — über das Microsoft Entra Admin Center (ID Governance > Privileged Identity Management > Microsoft Entra roles > Roles > [Rolle] > Role settings) oder über die Microsoft-Graph-Ressource unifiedRoleManagementPolicy bereit. Jede Policy besteht aus unabhängigen Regeln, und vier davon bestimmen, was bei der Aktivierung passiert (Configure Microsoft Entra role settings in PIM, Update rules in PIM by using Microsoft Graph):

Kontrolle	UI-Einstellung	Graph Rule ID	Was sie bewirkt
Genehmigung	Require approval to activate	`Approval_EndUser_Assignment` (`isApprovalRequired`)	Sendet die Aktivierungsanfrage an einen oder mehrere benannte Genehmiger, bevor die Rolle aktiv wird
MFA	On activation, require multifactor authentication	`Enablement_EndUser_Assignment` (`enabledRules: MultiFactorAuthentication`)	Erzwingt eine MFA-Abfrage bei der Aktivierung
Begründung	Require justification on activation	`Enablement_EndUser_Assignment` (`enabledRules: Justification`)	Erzwingt eine Freitext-Geschäftsbegründung, die mit dem Aktivierungsdatensatz gespeichert wird
Dauer	Activation maximum duration	`Expiration_EndUser_Assignment` (`maximumDuration`, ISO 8601, z. B. `PT8H`)	Begrenzt, wie lange die aktivierte Rolle aktiv bleibt, von 1 bis 24 Stunden

Alle vier werden pro Rolle konfiguriert, und keine schließt die andere aus — eine gut gehärtete Rolle hat typischerweise Genehmigung und MFA und Begründung und eine kurze Dauer, nicht nur eine davon.

Warum „PIM Aktiviert" Nicht Dasselbe Ist Wie „Aktivierung Ist Geschützt"

Eine verwandte, grundlegendere Prüfung ist, ob PIM für privilegierte Rollen überhaupt konfiguriert ist — das ist eine separate, schwerwiegendere Lücke, die wir in Azure Privilegierter Zugriff: Zu viele globale Admins behandeln. Dieser Artikel setzt voraus, dass diese Prüfung bereits besteht: PIM ist aktiv, Rollen sind berechtigt, und der Tenant wirkt auf den ersten Blick konform. Die hier behandelte Lücke liegt eine Ebene tiefer — es geht darum, was innerhalb von PIM passiert, sobald jemand aktiviert.

Die vier Standardeinstellungen sind entscheidend, weil keine davon von Haus aus sicher ist:

Genehmigung ist standardmäßig deaktiviert. Jeder berechtigte Benutzer kann sich sofort selbst aktivieren, ohne dass eine zweite Person beteiligt ist.
MFA bei der Aktivierung hat einen dokumentierten blinden Fleck. Microsofts eigene Anleitung stellt fest, dass „Benutzer möglicherweise nicht zur Multi-Faktor-Authentifizierung aufgefordert werden, wenn sie sich mit starken Anmeldeinformationen authentifiziert oder die Multi-Faktor-Authentifizierung bereits früher in der Sitzung durchgeführt haben" — eine Sitzung, die MFA bereits bei der Anmeldung erfüllt hat, kann also eine privilegierte Rolle ohne jede zusätzliche Abfrage aktivieren. Das ist dieselbe Reauthentifizierungslücke, die in Azure Identitätssicherheit: Warum MFA Allein Nicht Reicht behandelt wird.
Begründung ist standardmäßig deaktiviert, sodass Aktivierungen keinen protokollierten Geschäftsgrund tragen — was sowohl die Echtzeitprüfung als auch die nachträgliche Auditierung schwächt.
Die maximale Aktivierungsdauer beträgt standardmäßig 8 Stunden und kann auf bis zu 24 Stunden gesetzt werden — lang genug, damit eine gekaperte Sitzung oder ein gestohlenes Token für einen gesamten Arbeitstag nützlich bleibt.

🚨 Gefahr: Da die Einstellung „MFA bei Aktivierung" keine erneute Authentifizierung erzwingt, wenn MFA bereits innerhalb der Sitzung erfüllt wurde, kann ein Angreifer, der ein gültiges Sitzungstoken gestohlen hat, eine privilegierte Rolle aktivieren, ohne jemals einen zweiten Faktor zu berühren. Microsofts dokumentierte Abhilfe für diese spezifische Lücke ist der Conditional-Access-Authentifizierungskontext in Kombination mit der Anmeldehäufigkeit „Jedes Mal" — nicht die einfache Checkbox „MFA bei Aktivierung".

Erkennung

Was pro Rolle zu prüfen ist

Rufen Sie die aktuelle Aktivierungsrichtlinie für jede Microsoft-Entra-Verzeichnisrolle ab und vergleichen Sie sie mit den vier oben genannten Kontrollen. Manuell bedeutet das, für jede Rolle im Admin Center Role settings zu öffnen. In größerem Maßstab lässt sich das per Graph abfragen:

GET https://graph.microsoft.com/v1.0/policies/roleManagementPolicies?$filter=scopeId eq '/' and scopeType eq 'DirectoryRole'&$expand=rules

Oder mit Microsoft Graph PowerShell:

# Requires RoleManagement.Read.Directory or RoleManagement.ReadWrite.Directory
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
$policies = Get-MgPolicyRoleManagementPolicyAssignment -Filter "scopeId eq '/' and scopeType eq 'DirectoryRole'"
foreach ($p in $policies) {
    Get-MgPolicyRoleManagementPolicyRule -UnifiedRoleManagementPolicyId $p.PolicyId |
        Where-Object { $_.Id -in @('Approval_EndUser_Assignment','Enablement_EndUser_Assignment','Expiration_EndUser_Assignment') }
}

Markieren Sie eine Rolle, wenn: isApprovalRequired auf false steht, enabledRules der Enablement-Regel MultiFactorAuthentication nicht enthält, enabledRules Justification nicht enthält, oder maximumDuration der Expiration-Regel Ihren Richtlinien-Schwellenwert überschreitet (üblicherweise 1–4 Stunden für Tier-0-Rollen). Priorisieren Sie Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator und jede benutzerdefinierte Rolle mit verzeichnisweiten Schreibrechten — das sind die Rollen, bei denen die Lücke den größten Blast Radius hat.

Was im Audit-Log zu beobachten ist

Microsoft Entra speichert die PIM-Richtlinien- und Aktivierungshistorie im Blade Resource audit (ID Governance > Privileged Identity Management > Microsoft Entra roles > Resource audit), standardmäßig 30 Tage lang aufbewahrt (View audit log report for Microsoft Entra roles in PIM) — falls dieses Standardfenster für Ihre Untersuchungszeiträume ein Problem darstellt, siehe Entra ID Protokollierung: Aufbewahrung, Diagnoseeinstellungen, SIEM-Export-Lücken für Wege, sie in einen längerfristigen Speicher zu routen. Zwei Aktivitätstypen sind am wichtigsten:

Aktivität	Warum sie wichtig ist
`Update role setting in PIM`	Jemand hat die Aktivierungsrichtlinie einer Rolle geändert — einschließlich Deaktivierung von Genehmigung, MFA oder Begründung oder Verlängerung des Aktivierungsfensters. Das ist selbst ein hochwertiges Ziel für einen Angreifer, der bereits über gewisse Privilegien verfügt und das Tor vor weiteren Aktivierungen lockern möchte.
Rollenaktivierungsanfragen ohne Begründungs-/Genehmigungsspur	Aktivierungen, die ohne protokollierten Genehmiger und ohne Begründungstext abgeschlossen wurden, sind genau diejenigen, die eine gehärtete Richtlinie blockiert oder verlangsamt hätte.

ℹ️

ℹ️ Hinweis: Ein Update role setting in PIM-Ereignis ist für sich allein kein Beweis für einen Angriff — auch legitime Administratoren konfigurieren PIM-Richtlinien um. Behandeln Sie es als Signal, das dieselbe Überprüfung braucht wie jede andere Änderung an einer privilegierten Rolle: Wer hat sie vorgenommen, an welcher Rolle, und hat sie die Kontrolle geschwächt oder gestärkt?

Behebung

💡

💡 Quick Win: Beginnen Sie mit Global Administrator und Privileged Role Administrator — den beiden Rollen mit dem größten Blast Radius — und arbeiten Sie sich dann zu jeder anderen berechtigten Rolle vor.

Erfassen Sie die aktuelle Richtlinie jeder Rolle mit der oben genannten Graph-Abfrage oder dem PowerShell-Skript, damit Sie eine Vorher-Nachher-Baseline haben und nicht nur eine Schätzung pro Rolle.
Erfordern Sie eine Genehmigung zur Aktivierung für Tier-0-Rollen, mit mindestens zwei explizit konfigurierten, benannten Genehmigern. Lassen Sie die Genehmigerliste nicht leer: Microsofts eigene Anleitung warnt davor, dass ein Tenant ausgesperrt werden kann, wenn jeder Privileged Role Administrator/Global Administrator nur berechtigte (nicht aktive) Zuweisungen hat, eine Genehmigung erforderlich ist und keine Genehmiger konfiguriert sind — richten Sie ordnungsgemäß überwachte Notfallzugangskonten als aktive, permanente Zuweisungen ein, bevor Sie dies aktivieren.
Erfordern Sie MFA bei der Aktivierung, und ergänzen Sie dort, wo die Rolle es rechtfertigt, den Conditional-Access-Authentifizierungskontext mit der Anmeldehäufigkeit „Jedes Mal" — das ist die Einstellung, die bei der Aktivierung tatsächlich eine erneute Authentifizierung erzwingt, statt stillschweigend einen früheren MFA-Nachweis aus der Sitzung zu akzeptieren.
Erfordern Sie eine Begründung bei der Aktivierung (und erwägen Sie, zusätzlich Ticket-Informationen zu verlangen), damit jede Aktivierung einen protokollierten, überprüfbaren Geschäftsgrund trägt.
Reduzieren Sie die maximale Aktivierungsdauer. Sowohl der Standardwert von 8 Stunden als auch die Obergrenze von 24 Stunden existieren aus Bequemlichkeit, nicht aus Sicherheitsgründen — die meisten operativen Aufgaben passen in 1–4 Stunden. Legen Sie sie über maximumDuration der Expiration-Regel im ISO-8601-Format fest (PT2H für zwei Stunden, PT4H für vier).
Wenden Sie dieselbe Richtlinie auf jede gleichwertige Rolle an, nicht nur auf die getestete. Rolleneinstellungen sind unabhängig voneinander, sodass ein Skript, das nur Global Administrator patcht, Privileged Role Administrator, Security Administrator und benutzerdefinierte Verzeichnisrollen unverändert lässt.
Führen Sie die Graph-Abfrage nach der Änderung erneut aus und bestätigen Sie, dass isApprovalRequired: true ist, enabledRules MultiFactorAuthentication und Justification enthält und maximumDuration Ihre neue Obergrenze widerspiegelt — wiederholen Sie diese Prüfung dann regelmäßig, da ein späteres Update role setting in PIM-Ereignis all das stillschweigend zurücksetzen kann.

Wie EtcSec Dies Erkennt

Das Azure-Audit von EtcSec prüft die PIM-Aktivierungsrichtlinie bei jedem Scan, unabhängig davon, ob PIM selbst aktiviert ist.

PA_PIM_NO_APPROVAL_REQUIRED markiert berechtigte Rollenzuweisungen, bei denen die Aktivierung keine Genehmigung erfordert.

PA_PIM_NO_MFA_ON_ACTIVATION markiert Rollen, bei denen die Aktivierungsrichtlinie keine Multi-Faktor-Authentifizierung erfordert.

PA_PIM_NO_JUSTIFICATION markiert Rollen, bei denen die Aktivierung keine Geschäftsbegründung erfordert.

PA_PIM_LONG_ACTIVATION markiert Rollen, deren maximale Aktivierungsdauer lang genug konfiguriert ist, um die Exposition nach einer kompromittierten Aktivierung erheblich zu verlängern.

ℹ️

ℹ️ Hinweis: EtcSec prüft diese Schwachstelle automatisch bei jedem Azure-Audit. Führen Sie ein kostenloses Audit durch, um Ihre Umgebung zu überprüfen.

Entra PIM Aktivierungsfehler: Fehlende Genehmigung, MFA und Begründung