Entra ID Microsoft 365 bezpieczenstwo Conditional Access administracja

11 maja 2026

Konta break glass w Entra ID: jak nie stracić dostępu do tenantu na zawsze

Błędna polityka Conditional Access może zablokować wszystkich adminów z tenantu jednocześnie — a odblokowanie przez Microsoft Support trwa 3–7 dni. Dowiedz się jak prawidłowo skonfigurować konta break glass z FIDO2, wykluczeniami CA i alertami Azure Monitor.

TL;DR: Błędna polityka Conditional Access może zablokować WSZYSTKICH administratorów z tenantu jednocześnie — odblokowanie przez Microsoft Support trwa 3–7 dni roboczych. Konta break glass to jedyne skuteczne zabezpieczenie przed tą katastrofą, ale tylko gdy są prawidłowo skonfigurowane z FIDO2, wykluczone z CA, regularnie testowane i monitorowane. Ten artykuł wyjaśnia jak to zrobić bez pomijania krytycznych szczegółów.

Problem

W 2025 roku na forum Microsoft Q&A pojawił się kolejny wpis zatytułowany “URGENT: Global Administrator locked out after enabling Conditional Access”. Administrator wdrożył politykę CA wymagającą zgodności urządzeń dla wszystkich adminów — problem w tym, że żadne z urządzeń nie było jeszcze zarejestrowane w Intune. Efekt: całkowita blokada tenantu. Ticket trafił do kolejki “Data Protection / Tenant Recovery” i czekał 72 godziny zanim inżynier Microsoft w ogóle na niego spojrzał.

To nie jest rzadkość — to wzorzec. Na forach r/sysadmin i Microsoft Community Hub można znaleźć dziesiątki takich historii. Ale w marcu 2025 roku Microsoft sam spowodował masowy lockout: błędne wdrożenie funkcji MACE Credential Revocation — narzędzia do wykrywania wyciekłych poświadczeń — wygenerowało fałszywe alerty i automatycznie zablokowało konta w tysiącach organizacji. Jeden dostawca MDR odnotował ponad 20 000 alertów od różnych klientów w ciągu jednej nocy. Konta z unikalnymi hasłami i aktywnym MFA były blokowane bez żadnych dowodów kompromitacji.

Organizacje które miały prawidłowo skonfigurowane konta break glass przetrwały ten incydent bez większego bólu. Reszta czekała w kolejce do Microsoft Support.

Jako administrator M365 możesz napotkać lockout z kilku powodów: błędna polityka Conditional Access (najczęstszy przypadek), awaria federacji AD FS lub zewnętrznego IdP (Okta, Ping), niedostępność wszystkich metod MFA, sytuacja kiedy ostatni Global Admin opuścił firmę bez przekazania dostępów, lub właśnie taki incydent po stronie Microsoft. W każdym scenariuszu jedynym ratunkiem jest konto break glass — ale tylko jeśli zostało skonfigurowane zanim potrzebujesz.

Dlaczego tak się dzieje

Microsoft Entra ID ma wbudowaną ochronę przed przypadkowym lockoutem — nie możesz usunąć ostatniego Global Admina w tenantcie. Ale ta ochrona nie pomaga gdy:

Conditional Access blokuje wszystkich adminów jednocześnie. CA sprawdza każde logowanie, w tym logowania adminów. Nie ma trybu “admin override” — jeśli polityka wymaga urządzenia zgodnego z Intune, a żadne z urządzeń adminów tego warunku nie spełnia, wszyscy są zablokowani naraz. Entra ID nie wie że “logicznie” powinno dać ci dostęp żebyś naprawił błąd — po prostu egzekwuje politykę.

Federacja pada. Konta zsynchronizowane z on-premises Active Directory uwierzytelniają się przez serwer federacji (AD FS) lub zewnętrzny IdP. Gdy ta infrastruktura przestaje działać — kont federacyjnych nie da się użyć. Konta cloud-only z domeną .onmicrosoft.com uwierzytelniają się bezpośrednio w Entra ID i są odporne na awarie on-premises.

MFA staje się niedostępne. Jeśli wszyscy admini używają wyłącznie Microsoft Authenticator i ten serwis ma incydent, lub wszystkie telefony adminów są niedostępne, nikt nie może aktywować ról w PIM ani zalogować się do portalu administracyjnego.

Role w PIM są eligible, nie active. Jeśli masz tylko eligible przypisanie roli Global Administrator, musisz przejść przez aktywację PIM — co wymaga MFA. Jeśli MFA nie działa, rola jest nieosiągalna. Pełny deadlock.

Kluczowa informacja: lockout tenantu nie można naprawić z wewnątrz gdy wszyscy admini są zablokowani. Musisz złożyć ticket do Microsoft Support przez ścieżkę „Data Protection / Tenant Recovery" — co zajmuje 3–7 dni roboczych. Przez ten czas twój tenant jest praktycznie nieadministrowalny.

Rozwiązanie krok po kroku

Krok 1: Utwórz dwa konta break glass

Dwa konta, nie jedno — bo klucz FIDO2 może się uszkodzić, jedno konto może zostać przypadkowo zablokowane, może zdarzyć się incydent bezpieczeństwa wymagający izolacji pierwszego konta.

Wymagania dla obu kont:

Domena .onmicrosoft.com — nie domena firmowa, nie konto zsynchronizowane z AD
Rola Global Administrator — permanently active (nie eligible w PIM)
Bez licencji M365 — do logowania licencja nie jest potrzebna
Nie powiązane z konkretną osobą — konto należy do organizacji, nie do “Marka z IT”

Przykładowe nazwy które nie zdradzają celu konta (ważne ze względu na ataki password spray):

svc-infra-01@contoso.onmicrosoft.com
svc-cloud-mgmt@contoso.onmicrosoft.com

Unikaj: breakglass@, emergency@, admin-backup@ — to pierwsze cele ataków password spray i credential stuffing.

Przez PowerShell (Microsoft Graph):

Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.ReadWrite.All","RoleManagement.ReadWrite.Directory"

# Generuj silne hasło (80+ znaków jako backup dla FIDO2)
$password = "$(New-Guid)-$(New-Guid)-$(New-Guid)"

$passwordProfile = @{
    Password = $password
    ForceChangePasswordNextSignIn = $false
}

$user1 = New-MgUser `
    -DisplayName "Infra Service Account 01" `
    -UserPrincipalName "svc-infra-01@contoso.onmicrosoft.com" `
    -AccountEnabled $true `
    -PasswordProfile $passwordProfile `
    -PasswordPolicies "DisablePasswordExpiration,DisableStrongPassword"

Write-Host "Konto 1 ID: $($user1.Id)" -ForegroundColor Green
Write-Host "ZAPISZ TO HASLO W SEJFIE: $password" -ForegroundColor Yellow

# Przypisz rolę Global Administrator (permanently active — nie przez PIM)
$gaRole = Get-MgDirectoryRole | Where-Object {$_.DisplayName -eq "Global Administrator"}
New-MgDirectoryRoleMember -DirectoryRoleId $gaRole.Id `
    -BodyParameter @{"@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$($user1.Id)"}

Write-Host "Rola Global Administrator przypisana." -ForegroundColor Green

Powtórz dla drugiego konta. Zanotuj ObjectId obu kont — będzie potrzebny do konfiguracji alertów.

Krok 2: Skonfiguruj FIDO2 jako metodę uwierzytelniania

Konta break glass nie powinny używać Microsoft Authenticator (zależność od telefonu), SMS/głosu (ryzyko SIM swap, awaria sieci komórkowej), ani kodów TOTP (zależność od zarejestrowanego urządzenia). Jedyna właściwa opcja: klucz sprzętowy FIDO2.

Dlaczego FIDO2 jest prawidłowym wyborem:

Sprzętowy — działa gdy telefon, email i sieć komórkowa są niedostępne
Odporny na phishing — klucze kryptograficzne są powiązane z domeną
Nie wygasa — brak dat ważności jak w przypadku certyfikatów
Spełnia wymagania Mandatory MFA obowiązujące od maja 2024 dla Global Adminów

Zakup kluczy: Kup dwa klucze od różnych producentów — np. YubiKey 5 NFC dla konta 1 i Nitrokey 3 lub Token2 dla konta 2. Jeśli jeden producent miałby problem z firmware, drugi nadal działa.

Aby zarejestrować klucz FIDO2: zaloguj się na konto break glass (przeglądarka InPrivate), przejdź do myprofile.microsoft.com → Security info → Add sign-in method → Security key i postępuj zgodnie z instrukcjami.

Ważne: Zarejestruj klucze FIDO2 zanim dodasz konta do wykluczeń w CA. Kolejność ma znaczenie.

Krok 3: Wyklucz konta z polityk Conditional Access

Sprawdzona strategia wykluczeń:

Konto 1: wykluczone ze wszystkich polityk CA. Klucz FIDO2 w sejfie w serwerowni.
Konto 2: objęte jedną dedykowaną polityką CA wymagającą klucza FIDO2 (authentication strength). Klucz w innej lokalizacji fizycznej.

Po skonfigurowaniu wykluczeń obowiązkowo użyj narzędzia What-If w Conditional Access:

Entra admin center → Protection → Conditional Access → What If
Ustaw: User = svc-infra-01, Apps = All cloud apps, warunki domyślne
Wynik powinien pokazać zero polityk lub wyłącznie politykę break-glass FIDO2
Jeśli jakakolwiek inna polityka się pojawi — napraw wykluczenia zanim przejdziesz dalej

Ten krok weryfikacyjny nie jest opcjonalny. Jedno pominięte wykluczenie wystarczy żeby zniweczyć całą konfigurację.

Krok 4: Skonfiguruj monitoring w Azure Monitor

80% administratorów pomija tę część — co oznacza że nie wiedzą gdy ktoś loguje się na konto awaryjne, czy to w sytuacji awaryjnej, przypadkowo, czy jako intruz.

Najpierw skonfiguruj diagnostic settings w Entra: Entra admin center → Monitoring → Diagnostic settings → Add setting → zaznacz SignInLogs i AuditLogs → wyślij do Log Analytics Workspace.

Następnie utwórz alert rule z poniższym zapytaniem KQL:

// Alert na każdą próbę logowania na konto break glass (sukces lub porażka)
SigninLogs
| where TimeGenerated > ago(5m)
| where UserPrincipalName in (
    "svc-infra-01@contoso.onmicrosoft.com",
    "svc-cloud-mgmt@contoso.onmicrosoft.com"
)
| project
    TimeGenerated,
    UserPrincipalName,
    IPAddress,
    Location,
    AppDisplayName,
    ResultType,
    ResultDescription,
    DeviceDetail,
    ConditionalAccessStatus
| order by TimeGenerated desc

Ustawienia reguły alertowej:

Threshold value: 0 — wyzwól przy pierwszym trafieniu
Evaluation frequency: 1 minuta
Lookback period: 5 minut
Severity: Critical (Sev 0)
Action Group: email + SMS do wszystkich Global Adminów + ticket w systemie ITSM

Krok 5: Fizyczne przechowywanie poświadczeń

Konto break glass jest bezużyteczne jeśli w sytuacji kryzysowej nie wiesz gdzie są klucze FIDO2 i PIN.

Konto 1 (wykluczone ze wszystkich CA):

Klucz FIDO2 + PIN zapisany na papierze: zapieczętowana koperta w sejfie w serwerowni
Hasło (backup): zapieczętowana koperta u dyrektora IT lub CTO
Procedura użycia: IT Glue / Confluence — tylko gdzie szukać, BEZ haseł

Konto 2 (z polityką FIDO2):

Klucz FIDO2 + PIN: inna lokalizacja fizyczna (druga siedziba, skrytka bankowa)
Hasło (backup): inna upoważniona osoba

Nigdy nie przechowuj obu kluczy w tym samym miejscu. Pożar lub kradzież sejfu nie może wyeliminować obu kont jednocześnie.

Krok 6: Regularne testowanie — co 90 dni

Zaplanuj w kalendarzu kwartalne ćwiczenie:

Pobierz klucz FIDO2 z sejfu
Zaloguj się na konto break glass (przeglądarka InPrivate — żeby nie korzystać z cached credentials)
Potwierdź dostęp do Entra admin center i Azure Portal
Sprawdź że alert w Azure Monitor odpalił się w ciągu 1–2 minut
Sprawdź że wszyscy Global Admini dostali powiadomienie
Zanotuj wynik: data, osoba testująca, wynik
Odłóż klucz z powrotem

Bez regularnych testów nie wiesz czy FIDO2 nadal działa, czy PIN nie wygasł, czy konto nie zostało przypadkowo zablokowane przez skrypt porządkujący, czy monitoring jest aktywny.

Typowe pułapki i edge cases

Pułapka 1: Rola eligible w PIM zamiast permanently active

Jeśli Global Administrator jest eligible na koncie break glass, w sytuacji awaryjnej nadal musisz przejść przez aktywację PIM — co wymaga MFA. To niweluje całą ideę konta awaryjnego. Sprawdź że przypisanie roli jest Active, Permanent bez daty wygaśnięcia.

# Weryfikacja — czy konta break glass mają permanently active GA role
$gaRoleDefinitionId = "62e90394-69f5-4237-9190-012177145e10"  # stały ID roli Global Administrator

$activeAssignments = Get-MgRoleManagementDirectoryRoleAssignment `
    -Filter "roleDefinitionId eq '$gaRoleDefinitionId'"

Write-Host "Permanently active Global Admin assignments:"
$activeAssignments | ForEach-Object {
    $user = Get-MgUser -UserId $_.PrincipalId -Property DisplayName,UserPrincipalName -ErrorAction SilentlyContinue
    Write-Host "  $($user.UserPrincipalName) - $($user.DisplayName)"
}
# Jeśli twoje konta break glass tu nie widać — mają tylko eligible. Napraw to natychmiast.

Pułapka 2: Mandatory MFA blokuje konta z samym hasłem

Od maja 2024 Microsoft wymusza Mandatory MFA dla Global Adminów przy logowaniu do portali administracyjnych (Azure Portal, Intune, Entra admin center). To dotyczy RÓWNIEŻ kont break glass. Samo hasło nie wystarczy do zalogowania do portalu.

Jeśli masz stare konta break glass z 2022–2023 roku skonfigurowane tylko z hasłem — od maja 2024 są bezużyteczne do administracji tenantu. Zarejestruj klucze FIDO2 jak najszybciej.

Pułapka 3: Wykluczenie przez grupę — cicha pułapka

Typowy wzorzec: konta break glass dodane do grupy zabezpieczeń, a ta grupa wykluczona z polityk CA. Problem: admin robiący “porządki” w Entra ID może usunąć konto z grupy nie rozumiejąc konsekwencji. Konto znika z wykluczeń bez żadnego alarmu i staje się objęte tymi samymi politykami CA co reszta użytkowników.

Bezpieczniejsze podejście: wykluczaj konta bezpośrednio przez UPN w każdej polityce CA, nie przez grupę. Jeśli używasz grupy — chroń ją przez Restricted Management Administrative Unit (RMAU) tak aby tylko specjalnie upoważnieni admini mogli modyfikować jej członkostwo.

Pułapka 4: Brak monitorowania — konto używane jako zwykłe konto robocze

Prawdziwy przypadek: podczas przeglądu bezpieczeństwa admin znalazł logi logowania na konto break glass sprzed 4 miesięcy. Okazało się że inny admin użył go bo zapomniał hasła do swojego konta i nikomu nie powiedział. Przez 4 miesiące nikt nie wiedział że konto jest potencjalnie skompromitowane.

Każde logowanie na konto break glass wymaga natychmiastowej odpowiedzi: sprawdzenie powodu, audyt działań wykonanych na koncie, potencjalna rotacja poświadczeń. Bez alertu w Azure Monitor ten proces jest niemożliwy.

Pułapka 5: Hasło wygasłe z powodu braku polityki DisablePasswordExpiration

Domyślna polityka haseł w Entra ID ustawia wygaśnięcie co 90 dni. Jeśli konto break glass nie ma flagi DisablePasswordExpiration, hasło wygaśnie i konto stanie się niedostępne dokładnie wtedy gdy go potrzebujesz. Sprawdź i napraw:

# Weryfikacja i naprawa polityki haseł kont break glass
$breakGlassAccounts = @(
    "svc-infra-01@contoso.onmicrosoft.com",
    "svc-cloud-mgmt@contoso.onmicrosoft.com"
)

foreach ($upn in $breakGlassAccounts) {
    $user = Get-MgUser -UserId $upn -Property "UserPrincipalName,PasswordPolicies"
    $policies = $user.PasswordPolicies

    if ($policies -notlike "*DisablePasswordExpiration*") {
        Write-Host "UWAGA: $upn - haslo moze wygasnac! ($policies)" -ForegroundColor Red
        Update-MgUser -UserId $upn -PasswordPolicies "DisablePasswordExpiration"
        Write-Host "  Naprawiono: DisablePasswordExpiration ustawione." -ForegroundColor Green
    } else {
        Write-Host "OK: $upn - DisablePasswordExpiration ustawione." -ForegroundColor Green
    }
}

Podsumowanie

Dwa konta, domena .onmicrosoft.com, cloud-only — żadnych zależności od on-premises AD ani zewnętrznych IdP
FIDO2 od dwóch różnych producentów — spełnia Mandatory MFA od maja 2024, odporne na phishing, bez zależności od telefonów
Rola permanently active — nie eligible, nie time-limited, bez wymaganej aktywacji PIM
What-If po każdej zmianie CA — jedno konto poza wszystkimi politykami, drugie z jedną polityką FIDO2
Alert Azure Monitor przy każdym logowaniu — Severity 0, powiadomienie do wszystkich Global Adminów
Fizyczna separacja kluczy FIDO2 — dwie różne lokalizacje, dwóch różnych producentów
Test co 90 dni — zaloguj się, sprawdź alert, zanotuj wynik w dokumentacji
DisablePasswordExpiration obowiązkowo — hasło break glass nie może wygasnąć po 90 dniach