so prüfst du die Lücke...
Seit ein paar Tagen steht auf der Übersichtsseite des bedingten Zugriffs ein gelber Hinweis: "Some Conditional Access policies are protecting more users than your current licensing entitlements". Der Reflex vieler Admins ist eine Bestellung beim Reseller. Der ist meistens falsch, weil der Hinweis keine Durchsetzung ist, sondern eine Auswertung.
Microsoft schaltet keine Richtlinie ab und stellt nichts nach. Der Banner sagt nur: die Zahl der Benutzer, für die im Messzeitraum eine Conditional-Access-Richtlinie ausgewertet wurde, liegt über der Zahl der Benutzer, denen du eine passende Lizenz zugewiesen hast.
Der Unterschied ist wichtig, weil beide Zahlen aus unterschiedlichen Quellen stammen. Die Nutzung kommt aus den Anmeldeprotokollen, die Berechtigung aus der Lizenzzuweisung pro Benutzer. Solange du beide nicht nebeneinander legst, rätst du. Diese Anleitung legt sie nebeneinander.
Der übliche Weg läuft über drei Stufen: erst Sichtbarkeit im Portal, dann der Hinweis an den Admin, dann die Konsequenz, sei es als Meldung an den Reseller oder als gesperrte Bearbeitung betroffener Richtlinien. Ich rechne damit, dass Microsoft diese Zahlen in absehbarer Zeit aktiv verwendet.
Zieh die Zuordnung von Konto zu Lizenz deshalb jetzt sauber, solange sie dich nur Admin-Zeit kostet, und nicht erst in dem Quartal, in dem aus dem Hinweis eine Aufforderung wird. Das ist meine Lesart der Entwicklung, keine Ankündigung von Microsoft.
Schritt 1: Den Banner im richtigen Blade nachvollziehen
Melde dich im Entra Admin Center an und gehe zu Entra ID, Bedingter Zugriff, Übersicht. Dort steht der Hinweis mit einem Link auf die Dokumentation zu den License Usage Insights. Der Link führt nicht zu deinen Daten, sondern zur Erklärung. Deine Daten liegen an anderer Stelle.
QUELLE
Schritt 2: Lizenznutzung öffnen und die beiden Zahlen trennen
Wechsle zu Abrechnung, Lizenzen, Lizenznutzung. Alternativ nutzt du den Direkteinstieg über den folgenden LINK . Die Seite zeigt zwei Blöcke: die Berechtigungen (Entitlements) und die Feature-Nutzung.
Die Berechtigungszahl ist eine Summe über alle Produkte, die eine Entra-Stufe als Service Plan enthalten. Microsoft 365 E3 bringt Entra ID P1 mit, Microsoft 365 E5 bringt P1 und P2 mit. Fünfzehn E5-Lizenzen erzeugen deshalb fünfzehn P1- und fünfzehn P2-Berechtigungen, obwohl du nur ein Produkt gekauft hast.
Die Nutzungszahl unter P1 heißt "Conditional Access users" und zählt die eindeutigen Benutzer, für die im Messzeitraum mindestens eine Conditional-Access-Richtlinie ausgewertet wurde. Unter P2 steht "Risk-based Conditional Access users" und zählt dasselbe für risikobasierte Richtlinien. Ausgewertet bedeutet nicht blockiert und nicht erfolgreich: eine Richtlinie, die nur greift und "notApplied" liefert, kann den Benutzer schon in die Zählung ziehen.
Schritt 3: Die Nutzer hinter der Zahl per Graph ermitteln
Das Portal nennt dir eine Zahl, keine Namen. Die Namen holst du aus den Anmeldeprotokollen, weil genau die die Datenbasis der Kachel sind. Verbinde dich mit den Leserechten, die für Anmeldeprotokolle nötig sind, und filtere serverseitig, damit du nicht Millionen Einträge über die Leitung ziehst.
Connect-MgGraph -Scopes 'AuditLog.Read.All','Directory.Read.All'
$Start = (Get-Date).AddDays(-29).ToString('yyyy-MM-ddTHH:mm:ssZ')
$Filter = "createdDateTime ge $Start and conditionalAccessStatus eq 'success'"
[array]$SignIns = Get-MgAuditLogSignIn -Filter $Filter -All
Write-Host ("{0} Anmeldungen mit ausgewertetem Conditional Access gefunden" -f $SignIns.Count)
Der Filterwert success ist kleingeschrieben, weil conditionalAccessStatus ein Graph-Enum ist und die Werte success, failure, notApplied und unknownFutureValue lauten. Willst du die Kachel im Portal möglichst genau nachbauen, ersetzt du die Bedingung durch conditionalAccessStatus ne 'notApplied', weil dann auch fehlgeschlagene Auswertungen mitzählen.
Beachte die Aufbewahrung: mit P1 oder P2 liegen die Anmeldeprotokolle 30 Tage im Portal, ohne Premium-Lizenz nur 7 Tage. Der Messzeitraum der Kachel ist der Vormonat. Du kannst also einen abgeschlossenen Monat nur dann sauber nachrechnen, wenn du die Logs per Diagnoseeinstellung in einen Log Analytics Workspace oder ein Storage Account exportierst.
Schritt 4: Gastkonten herausrechnen
Gäste lösen Conditional Access aus, kosten dich aber keine P1-Zuweisung. Externe Identitäten werden über das MAU-Modell abgerechnet, dessen Freikontingent bei 50.000 monatlich aktiven Benutzern liegt. In den meisten Tenants bleibt dieser Anteil damit kostenfrei, verzerrt aber jede Handzählung. Trenne ihn deshalb sofort.
$TenantId = (Get-MgOrganization).Id
$Unique = $SignIns | Where-Object { $_.UserPrincipalName } |
Sort-Object UserPrincipalName -Unique
$Guests = $Unique | Where-Object {
$_.UserPrincipalName -like '*#EXT#*' -or
($_.HomeTenantId -and $_.HomeTenantId -ne $TenantId)
}
$Members = $Unique | Where-Object { $_ -notin $Guests }
Write-Host ("{0} eindeutige Benutzer: {1} Mitglieder, {2} Gäste" -f `
$Unique.Count, $Members.Count, $Guests.Count)
Die doppelte Bedingung ist Absicht. Der #EXT#-Anteil im UPN erkennt klassische B2B-Gäste, deren Konto in deinem Tenant liegt. Die Prüfung auf HomeTenantId fängt die Fälle ab, in denen ein Benutzer aus einem fremden Tenant per Cross-Tenant-Zugriff auf deine Ressourcen kommt und deshalb keinen #EXT#-UPN trägt.
Schritt 5: Lizenzzuweisung der verbliebenen Mitglieder prüfen
Jetzt kommt der Punkt, an dem die meisten Tenants ihre Lücke finden. Die Berechtigung zählt gekaufte Service Plans, die Nutzung zählt Benutzer. Wenn ein Konto mit Office 365 E3 arbeitet, verbraucht es Conditional Access, bringt aber keinen einzigen P1-Service-Plan mit, weil Office 365 E3 kein Entra Premium enthält. Fünfzehn freie P1-Berechtigungen aus E5-Lizenzen helfen dir nicht, solange sie auf anderen Köpfen sitzen.
$Premium = 'AAD_PREMIUM','AAD_PREMIUM_P2'
foreach ($User in $Members) {
$Plans = (Get-MgUserLicenseDetail -UserId $User.UserPrincipalName).ServicePlans |
Where-Object { $_.ServicePlanName -in $Premium -and
$_.ProvisioningStatus -eq 'Success' }
[PSCustomObject]@{
Benutzer = $User.UserPrincipalName
Premium = if ($Plans) { ($Plans.ServicePlanName -join ', ') } else { 'KEINE' }
}
}Alles, was in der Spalte Premium auf KEINE steht, ist deine echte Lücke. Den Bestand auf der Kaufseite holst du dir mit Get-MgSubscribedSku und vergleichst ConsumedUnits gegen PrepaidUnits.Enabled. Sind freie Einheiten vorhanden, ist der Fall eine Umverteilung per Set-MgUserLicense, keine Bestellung.
Schritt 6: Große Tenants tageweise abfragen
Ein einziger Graph-Call über 30 Tage läuft in mittleren und großen Tenants in Timeouts oder bricht mit einem HTTP-Fehler ab, weil die Paginierung über Hunderttausende Einträge zu lange dauert. Zerlege den Zeitraum in Tagesscheiben und setze die Ergebnisse zusammen.
$All = [System.Collections.Generic.List[object]]::new()
for ($Day = 29; $Day -ge 0; $Day--) {
$From = (Get-Date).Date.AddDays(-$Day).ToString('yyyy-MM-ddTHH:mm:ssZ')
$To = (Get-Date).Date.AddDays(-$Day + 1).ToString('yyyy-MM-ddTHH:mm:ssZ')
$F = "createdDateTime ge $From and createdDateTime lt $To and " +
"conditionalAccessStatus eq 'success'"
try { $All.AddRange((Get-MgAuditLogSignIn -Filter $F -All)) }
catch { Write-Warning ("Tag {0} fehlgeschlagen: {1}" -f $From, $_.Exception.Message) }
}Der try-Block ist kein Schmuck. Bricht ein einzelner Tag wegen Throttling ab, verlierst du sonst den gesamten Lauf und startest von vorn.
Stolperfallen
Report-only-Richtlinien zählen mit, weil sie ausgewertet werden. Wer eine Policy im Testmodus auf "Alle Benutzer" laufen lässt, zieht jeden angemeldeten Kopf in die Nutzungszahl, ohne dass die Richtlinie je etwas erzwungen hätte.
Microsoft-verwaltete Richtlinien laufen ebenfalls in deinem Tenant und werden dort ausgewertet. Sie erscheinen automatisch im Report-only-Zustand und werden nach 30 Tagen von Microsoft scharf geschaltet, sofern du nicht widersprichst. Das erklärt Nutzungssprünge in Tenants, in denen niemand eine neue Richtlinie angelegt hat.
Break-Glass-Konten schließt du üblicherweise aus allen Richtlinien aus. Genau deshalb tauchen sie in der Nutzungszählung nicht auf, was gut ist, dich aber bei der Kopfzahl-Rechnung durcheinanderbringen kann, wenn du sie als lizenzierte Benutzer mitrechnest.
Security Defaults sind kein Ersatz und kein Ausweg. Sie sind lizenzfrei, aber sie schließen sich mit Conditional Access gegenseitig aus. Wer sie einschaltet, um die Warnung loszuwerden, verliert jede granulare Steuerung.
Fazit
Der Hinweis im Entra Admin Center ist eine Informationsmeldung, keine Rechnung und keine Sperre. Microsoft vergleicht dabei nicht Nutzung gegen den Gesamtpool an P1- und P2-Berechtigungen, sondern wertet aus, welche einzelnen Konten Conditional Access verbraucht haben und ob genau diese Konten eine passende Lizenz tragen. Das ist technisch nachvollziehbar und lizenzrechtlich korrekt, führt aber zu Warnungen in Tenants, die längst genug Lizenzen im Schrank liegen haben. Der Fehler liegt dann in der Zuweisung, nicht im Einkauf.
Für den Betrieb heißt das: Die Auswertung aus Schritt 3 bis 5 gehört einmal pro Quartal in deine Routine, weil sich der Lizenzmix mit jedem Onboarding verschiebt. Ein Konto, das heute nur Mail nutzt und morgen über eine neue Richtlinie läuft, verändert die Zahl ohne jede Aktion in der Lizenzverwaltung.
Für Sicherheitsverantwortliche ist die Meldung ein Warnsignal mit doppeltem Boden. Microsoft treibt die MFA-Pflicht für Admin-Portale und Anmeldungen konsequent voran, und der empfohlene Weg dorthin ist Conditional Access. Wer wegen einer Lizenzwarnung Richtlinien entschärft oder ihren Geltungsbereich verkleinert, senkt sein Schutzniveau, um eine Kachel im Portal zu beruhigen. Das ist der falsche Tausch. Sinnvoller ist die Dokumentation: halte fest, welche Konten Conditional Access auslösen, welche davon Dienstkonten, Adminkonten oder Gäste sind, und welche Lizenz jeweils dahintersteht. Diese Aufstellung brauchst du ohnehin, sobald Microsoft von der Information zur Durchsetzung übergeht, und sie ist gleichzeitig ein sauberer Nachweis für ein ISO-27001-Audit oder eine NIS2-Bestandsaufnahme.
Für Entscheider bleibt die nüchterne Rechnung: Der Sprung von Office 365 E3 auf Microsoft 365 E3 kostet Geld, ein Umschichten vorhandener E5-Lizenzen kostet eine Stunde Admin-Zeit. Prüfe die zweite Option, bevor du über die erste redest.
Sei der Erste und starte die Diskussion mit einem hilfreichen Beitrag.
Kommentar hinterlassen
Dein Beitrag wird vor der Veröffentlichung kurz geprüft — fachlich, respektvoll und auf den Punkt ist hier genau richtig.