Konto awaryjne: dostęp, gdy logowanie przez katalog przestaje działać

Nowa zasada dostępu warunkowego miała wymagać zgodnego urządzenia od wszystkich użytkowników. Po jej włączeniu nikt, łącznie z administratorami, nie może zalogować się do portalu, w którym da się ją wyłączyć. Inny scenariusz: po awarii macierzy kontrolery domeny nie startują, a hasło lokalnego administratora hostów wirtualizacji jest w LAPS, czyli w katalogu, który właśnie nie działa.

Konto awaryjne, nazywane też kontem break-glass, jest planem na dokładnie te sytuacje. Działa tylko wtedy, gdy nie zależy od mechanizmu, którego awarię ma obejść, i gdy ktoś sprawdził je wcześniej niż w dniu awarii.

Zasady ogólne

Konto awaryjne nie jest używane do codziennej pracy. Jego hasło lub klucz jest przechowywany tak, żeby dało się go użyć w kryzysie, ale nie dało się go użyć niezauważenie. Każde użycie wywołuje alert i kończy się wymianą poświadczeń. Konto, którego nikt nie testował, traktuje się jak konto, które nie działa.

Gdzie potrzebne są konta awaryjne

System	Konto awaryjne	Poświadczenie	Przechowanie
Entra ID i Microsoft 365	dwa konta tylko-chmurowe z rolą Global Administrator	po dwa klucze FIDO2 na konto	sejf A i sejf B
Active Directory	jedno konto domenowe w Domain Admins	hasło 32 znaki w dwóch częściach	części u dwóch osób, w dwóch sejfach
Kontrolery domeny	hasło trybu przywracania usług katalogowych	hasło, kopia przez LAPS	koperta w sejfie A
Hosty wirtualizacji	konto lokalne spoza LAPS	hasło	koperta w sejfie A
Narzędzia logujące przez katalog	lokalny administrator narzędzia	losowe hasło	koperta albo menedżer haseł z niezależnym dostępem
Urządzenia sieciowe	konto lokalne z dostępem do konsoli	hasło	koperta w sejfie A

Konta tylko-chmurowe w Entra ID

Konta awaryjne w chmurze mają działać niezależnie od lokalnego katalogu, synchronizacji i federacji. Dlatego:

• są tworzone bezpośrednio w Entra ID, w domenie onmicrosoft.com, na przykład bg-admin-01@example.onmicrosoft.com, a nie synchronizowane z Active Directory,
• mają rolę Global Administrator przypisaną na stałe, a nie przez aktywację w Privileged Identity Management, która sama może wymagać zatwierdzenia lub drugiego składnika,
• logują się kluczem FIDO2: dwa klucze na konto, każdy w innym sejfie, z kodem PIN zapisanym w tej samej kopercie co klucz,
• nie mają metod zależnych od jednej osoby, takich jak SMS czy aplikacja na prywatnym telefonie,
• są wykluczone ze wszystkich zasad dostępu warunkowego, wprost albo przez grupę o stałym członkostwie, nigdy przez grupę dynamiczną.

Wykluczenie z zasad dostępu warunkowego nie oznacza logowania samym hasłem. Microsoft wymusza uwierzytelnianie wieloskładnikowe przy logowaniu do portali administracyjnych niezależnie od tych zasad, więc konto bez silnej metody i tak by się tam nie zalogowało. Klucz FIDO2 spełnia ten wymóg i jest odporny na phishing.

Konto w katalogu i konta lokalne

Konto awaryjne w Active Directory przydaje się, gdy katalog działa, ale konta administratorów nie: zostały zablokowane, wyłączone po podejrzeniu kompromitacji albo nie mogą uzyskać biletu Kerberos. Należy do Domain Admins bezpośrednio i zostaje poza grupą Protected Users.

Hasło ma 32 znaki i jest podzielone na dwie części po 16 znaków. Każdą część zna tylko jedna osoba i każda leży w innym sejfie, więc użycie konta wymaga obecności dwóch osób. Przy wymianie hasła obie osoby wpisują kolejno swoje części w tym samym polu.

# Polecenie pyta o nowe hasło i jego potwierdzenie
Set-ADAccountPassword -Identity bg-ad-01 -Reset

Przechowanie

Sprawdzone podejście: poświadczenia w zaplombowanych kopertach, osobno dla każdego systemu, z listą osób uprawnionych do otwarcia. Dwa sejfy w różnych lokalizacjach, na wypadek gdy jeden jest niedostępny. Numer plomby zapisany w rejestrze, a zerwana plomba oznacza obowiązkową wymianę poświadczeń.

Alert przy każdym logowaniu

W Entra ID logi logowania trafiają przez ustawienia diagnostyczne do obszaru roboczego Log Analytics, a reguła alertu sprawdza je co 5 minut. Alert wysyła grupa akcji, do co najmniej dwóch osób, pocztą i SMS-em. Reguła obejmuje także nieudane próby, bo próba logowania na konto awaryjne jest równie ważnym sygnałem.

SigninLogs
| where UserPrincipalName in~ ("bg-admin-01@example.onmicrosoft.com", "bg-admin-02@example.onmicrosoft.com")
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType

W Active Directory uwierzytelnienie konta domenowego zostawia na kontrolerach domeny zdarzenie 4768 (bilet Kerberos) albo 4776 (weryfikacja NTLM). Reguła w systemie zbierania logów reaguje na każde z nich z nazwą konta awaryjnego, a także na zdarzenia 4724 (reset hasła) i 4738 (zmiana konta).

Test co kwartał

Raz na kwartał dla każdego systemu z tabeli:

1. Zgłoszenie testu w systemie zgłoszeń, z datą i nazwiskami osób.
2. Otwarcie kopert przez osoby z listy uprawnionych.
3. Logowanie i sprawdzenie, że konto ma oczekiwane uprawnienia.
4. Potwierdzenie, że alert dotarł, z zapisem czasu od logowania do powiadomienia.
5. Wymiana hasła albo kodu PIN klucza, nowe koperty i nowe plomby.
6. Wpis w rejestrze: system, konto, miejsce przechowania, data testu, kto testował, czas dotarcia alertu.

Test sprawdza jednocześnie trzy rzeczy: czy konto działa, czy alert przychodzi i czy procedura dostępu do sejfu jest wykonalna w praktyce.

Sprawdź u siebie

Stan konta awaryjnego w Active Directory. LastLogonDate powinien odpowiadać dacie ostatniego testu, z dokładnością do 14 dni, bo atrybut, z którego pochodzi, jest replikowany z opóźnieniem. PasswordLastSet musi być późniejszy niż ostatni test. Logowanie nowsze niż ostatni test bez zgłoszenia awarii wymaga wyjaśnienia.

Get-ADUser -Identity bg-ad-01 -Properties LastLogonDate, PasswordLastSet |
    Select-Object SamAccountName, Enabled, LastLogonDate, PasswordLastSet

Dokładna data ostatniego logowania na każdym kontrolerze domeny. Atrybut lastLogon nie jest replikowany, więc trzeba zapytać każdy kontroler osobno. Rok 1601 w wyniku oznacza, że na tym kontrolerze konto nigdy się nie logowało.

foreach ($dc in Get-ADDomainController -Filter *) {
    $user = Get-ADUser -Identity bg-ad-01 -Server $dc.HostName -Properties lastLogon
    [pscustomobject]@{ DC = $dc.HostName; LastLogon = [datetime]::FromFileTime($user.lastLogon) }
}

Konta w Entra ID: data ostatniego logowania i zasady dostępu warunkowego, które ich nie wykluczają. Dobry wynik drugiego zapytania jest pusty. Jeśli wykluczenie jest zrobione przez grupę, sprawdź pole Conditions.Users.ExcludeGroups.

Connect-MgGraph -Scopes 'User.Read.All', 'AuditLog.Read.All', 'Policy.Read.All'
$user = Get-MgUser -UserId 'bg-admin-01@example.onmicrosoft.com' -Property Id, UserPrincipalName, SignInActivity
# Data ostatniego logowania
$user.SignInActivity.LastSignInDateTime
# Włączone zasady, które nie wykluczają konta
Get-MgIdentityConditionalAccessPolicy -All |
    Where-Object { $_.State -eq 'enabled' -and $_.Conditions.Users.ExcludeUsers -notcontains $user.Id } |
    Select-Object DisplayName