Sdílet prostřednictvím

Další informace o podrobnostech aktivit protokolu přihlašování

  • Článek

Microsoft Entra protokoluje všechna přihlášení do tenanta Azure pro účely dodržování předpisů. Jako správce IT potřebujete vědět, co znamenají hodnoty v protokolech přihlašování, abyste mohli hodnoty protokolu správně interpretovat.

Tento článek vysvětluje hodnoty nalezené v protokolech přihlašování. Tyto hodnoty poskytují cenné informace pro řešení potíží s chybami přihlášení.

Komponenty aktivit přihlašování

V MICROSOFT Entra ID se přihlašovací aktivita skládá ze tří hlavních komponent:

  • Kdo: Identita (uživatel) provádějící přihlášení
  • Postupy: Klient (aplikace) používaný pro přístup
  • Co: Cíl (prostředek) přístupný identitou

Při zkoumání přihlášení se zaměřte na tyto tři komponenty, abyste hledání zúžili, takže se nedíváte na všechny podrobnosti. V každé z těchto tří součástí jsou související identifikátory, které můžou poskytovat další informace. Každé přihlášení obsahuje také jedinečné identifikátory, které korelují pokus o přihlášení k přidruženým aktivitám.

Kdo

K uživateli jsou přidruženy následující podrobnosti:

  • Uživatelská
  • Username
  • ID uživatele
  • Identifikátor přihlášení
  • Typ uživatele

Jak

Způsob identifikace uživatele pomocí následujících podrobností:

  • Požadavek na ověření
  • Klientská aplikace
  • Typ přihlašovacích údajů klienta
  • Nepřetržité vyhodnocování přístupu

Co

Prostředek, ke který se uživatel pokouší získat přístup, můžete identifikovat pomocí následujících podrobností:

  • Aplikace
  • ID aplikace
  • Prostředek
  • ID zdroje
  • ID tenanta prostředku
  • ID instančního objektu prostředku

Jedinečné identifikátory

Protokoly přihlášení také obsahují několik jedinečných identifikátorů, které poskytují další přehled o pokusu o přihlášení.

  • ID korelace: Přihlášení skupin ID korelace ze stejné přihlašovací relace. Hodnota je založená na parametrech předaných klientem, takže ID Microsoft Entra nemůže zaručit jeho přesnost.
  • ID požadavku: Identifikátor odpovídající vydanému tokenu. Pokud hledáte přihlášení s konkrétním tokenem, musíte nejprve extrahovat ID požadavku z tokenu.
  • Jedinečný identifikátor tokenu: Jedinečný identifikátor tokenu předaného během přihlášení. Tento identifikátor slouží ke korelaci přihlášení s požadavkem tokenu.

Podrobnosti o aktivitě přihlášení

Každý pokus o přihlášení obsahuje podrobnosti přidružené k těmto třem hlavním komponentám. Podrobnosti jsou uspořádané do několika karet podle typu přihlášení.

Základní informace

Karta Základní informace obsahuje hromadnou část podrobností přidružených k pokusu o přihlášení. Poznamenejte si jedinečné identifikátory, protože můžou být potřeba k řešení potíží s přihlášením. Můžete sledovat , kdo, jak, jaký vzor pomocí podrobností na kartě Základní informace.

Diagnostiku přihlašování můžete spustit také na kartě Základní informace. Další informace naleznete v tématu Použití diagnostiky přihlašování.

Kód chyb přihlášení

Pokud přihlášení selhalo, můžete získat další informace o důvodu na kartě Základní informace související položky protokolu. V podrobnostech se zobrazí kód chyby a přidružený důvod selhání. Další informace najdete v tématu Řešení potíží s chybami přihlášení.

Snímek obrazovky s kódem chyby přihlášení na kartě Základy

Umístění a zařízení

Na kartách Informace o poloze a zařízení se zobrazují obecné informace o umístění a IP adrese uživatele. Karta Informace o zařízení obsahuje podrobnosti o prohlížeči a operačním systému použitém k přihlášení. Tato karta také obsahuje podrobnosti o tom, jestli zařízení dodržuje předpisy, spravuje se nebo jestli je hybridní připojení Microsoft Entra.

Podrobnosti o ověřování

Karta Podrobnosti ověřování v podrobnostech protokolu přihlášení obsahuje následující informace pro každý pokus o ověření:

  • Seznam použitých zásad ověřování, jako je podmíněný přístup nebo výchozí nastavení zabezpečení.
  • Posloupnost metod ověřování používaných k přihlášení.
  • Pokud byl pokus o ověření úspěšný a důvod proč.

Tyto informace vám umožní řešit potíže s jednotlivými kroky přihlášení uživatele. Pomocí těchto podrobností můžete sledovat:

  • Objem přihlášení chráněných vícefaktorovým ověřováním
  • Míra využití a úspěšnosti pro každou metodu ověřování
  • Použití metod ověřování bez hesla, jako je přihlášení k telefonu bez hesla a FIDO2
  • Jak často jsou požadavky na ověřování splněné deklaracemi identity tokenů, například když uživatelé nejsou interaktivně vyzváni k zadání hesla nebo zadání hesla SMS jednorázovým heslem.

Snímek obrazovky s kartou Podrobnosti ověřování

Podmíněný přístup

Pokud se zásady podmíněného přístupu (CA) používají ve vašem tenantovi, můžete zjistit, jestli se tyto zásady použily pro pokus o přihlášení. Zobrazí se všechny zásady, které se dají použít pro přihlášení. Zobrazí se konečný výsledek zásady, abyste mohli rychle zjistit, jestli zásada ovlivnila pokus o přihlášení.

  • Úspěch: Zásada podmíněného přístupu se úspěšně použila na pokus o přihlášení.
  • Selhání: Zásady podmíněného přístupu se použily na pokus o přihlášení, ale pokus o přihlášení selhal.
  • Nepoužito: Přihlášení neodpovídá kritériím pro zásadu, která se má použít.
    • Existují konkrétní scénáře, které kvůli své povaze musí být vyloučené z vyhodnocení podmíněného přístupu, aby se zabránilo cyklický závislost (scénář kuřecího a vejce), který by nebylo možné dokončit. Jedná se o scénáře bootstrap a můžou zahrnovat přihlášení přidružená k registraci zařízení, dodržování předpisů zařízením nebo konektorům serveru Network Policy Server.
    • Windows Hello pro firmy přihlášení se zobrazují jako Nepoužité, protože zásady podmíněného přístupu chrání pokusy o přihlášení ke cloudovým prostředkům, ne proces přihlášení k Windows.
  • Zakázáno: Zásada byla v době pokusu o přihlášení zakázaná.

Pouze sestavy

Vzhledem k tomu, že zásady podmíněného přístupu můžou změnit přihlašovací prostředí pro vaše uživatele a potenciálně narušit jejich procesy, je vhodné se ujistit, že jsou vaše zásady správně nakonfigurované. V režimu pouze sestav můžete nakonfigurovat zásadu a vyhodnotit její potenciální účinek před povolením zásady.

Tato karta protokolů přihlašování zobrazuje výsledky pokusů o přihlášení, které byly v oboru zásad. Další informace najdete v článku Co je režim sestavy jen pro podmíněný přístup?

Podrobnosti o přihlášení a důležité informace

Při kontrole protokolů přihlašování je důležité zvážit následující scénáře.

  • IP adresa a umístění: Neexistuje žádné konečné připojení mezi IP adresou a místem, kde se počítač s danou adresou fyzicky nachází. Poskytovatelé mobilních zařízení a sítě VPN vydávají IP adresy z centrálních fondů, které jsou často daleko od místa, kde se klientské zařízení používá. V současné době je převod IP adresy na fyzické umístění založený na trasování, datech registru, zpětných vyhledáváních a dalších informacích.

  • Datum a čas: Datum a čas pokusu o přihlášení je lokalizováno do časového pásma osoby přihlášené do Centra pro správu Microsoft Entra, nikoli do uživatele, který se pokusil přihlásit.

  • Podmíněný přístup:

    • Not applied: Během přihlašování se na uživatele a aplikaci nepoužijí žádné zásady. Windows Hello pro firmy se zobrazí jako Nepoužité, protože zásady podmíněného přístupu chrání pokusy o přihlášení ke cloudovým prostředkům, ne proces přihlášení k Windows. Ostatní přihlášení se můžou přerušit, aby se zásady nepoužíly.
    • Success: Jedna nebo více zásad podmíněného přístupu se použilo pro uživatele a aplikaci (ale nemusí nutně platit pro jiné podmínky) během přihlašování. I když zásady podmíněného přístupu nemusí platit, pokud byly vyhodnoceny, stav podmíněného přístupu zobrazuje úspěch.
    • Failure: Přihlášení splnilo podmínku uživatele a aplikace alespoň jedné zásady podmíněného přístupu a udělování ovládacích prvků buď nejsou splněné, nebo jsou nastavené tak, aby blokovaly přístup.
    • Podmíněný přístup se nevztahuje na přihlášení k Windows, například Windows Hello pro firmy. Podmíněný přístup chrání pokusy o přihlášení ke cloudovým prostředkům, ne proces přihlašování zařízení.

  • Průběžné vyhodnocování přístupu: Ukazuje, jestli se u události přihlášení použilo průběžné vyhodnocování přístupu (CAE).

  • Typ přístupu mezi tenanty: Popisuje typ přístupu mezi tenanty, který objekt actor používá pro přístup k prostředku. Možné hodnoty jsou:

    • none – Přihlašovací událost, která nepřekračovala hranice tenanta Microsoft Entra.
    • b2bCollaboration– Přihlášení mezi tenanty prováděné uživatelem typu host pomocí spolupráce B2B.
    • b2bDirectConnect – Přihlášení mezi tenanty prováděné B2B.
    • microsoftSupport– Přihlášení mezi tenanty prováděné agentem podpory Microsoftu v externím tenantovi Microsoftu.
    • serviceProvider – Přihlášení mezi tenanty prováděné poskytovatelem cloudových služeb (CSP) nebo podobným správcem jménem zákazníka tohoto poskytovatele CSP v tenantovi.
    • unknownFutureValue – Hodnota sentinelu používaná MS Graphem k tomu, aby klienti mohli zpracovávat změny v seznamech výčtů. Další informace najdete v tématu Osvědčené postupy pro práci s Microsoft Graphem.

  • Tenant: Protokol přihlašování sleduje dva identifikátory tenanta, které jsou relevantní ve scénářích mezi tenanty:

    • Domácí tenant – tenant, který vlastní identitu uživatele. ID Microsoft Entra sleduje ID a název.
    • Tenant prostředků – tenant, který vlastní (cílový) prostředek.
    • Vzhledem k závazku k ochraně osobních údajů nezaplní ID Microsoft Entra název domovského tenanta během scénářů mezi tenanty.
    • Pokud chcete zjistit, jak uživatelé mimo vašeho tenanta přistupují k vašim prostředkům, vyberte všechny položky, ve kterých se domovský tenant neshoduje s tenantem prostředku.

  • Vícefaktorové ověřování: Když se uživatel přihlásí pomocí vícefaktorového ověřování, skutečně probíhá několik samostatných událostí vícefaktorového ověřování. Pokud například uživatel zadá nesprávný ověřovací kód nebo neodpoví včas, odešle se více událostí vícefaktorového ověřování, aby odrážely nejnovější stav pokusu o přihlášení. Tyto události přihlášení se v protokolech přihlašování Microsoft Entra zobrazují jako jedna řádek. Stejná přihlašovací událost ve službě Azure Monitor se ale zobrazuje jako více řádkových položek. Všechny tyto události mají stejné correlationId.

  • Požadavek na ověření: Zobrazuje nejvyšší úroveň ověřování potřebnou prostřednictvím všech kroků pro přihlášení, aby přihlášení bylo úspěšné.

    • Rozhraní Graph API podporuje $filter (eq a startsWith pouze operátory).

  • Typy událostí přihlášení: Označuje kategorii přihlášení, která událost představuje.

    • Kategorie přihlášení uživatele může být interactiveUser nebo nonInteractiveUser odpovídá hodnotě vlastnosti isInteractive u prostředku přihlášení.
    • Kategorie spravované identity je managedIdentity.
    • Kategorie instančního objektu je servicePrincipal.
    • Rozhraní Microsoft Graph API podporuje: $filter (eq pouze operátor).
    • Azure Portal tuto hodnotu nezobrazuje, ale přihlašovací událost se umístí na kartu, která odpovídá typu události přihlášení. Možné hodnoty:
      • interactiveUser
      • nonInteractiveUser
      • servicePrincipal
      • managedIdentity
      • unknownFutureValue

  • Typ uživatele: Příklady zahrnují member, guest, nebo external.

  • Podrobnosti o ověřování:

    • Ověřovací kód OATH se protokoluje jako metoda ověřování pro hardwarové i softwarové tokeny OATH (jako je aplikace Microsoft Authenticator).
    • Karta Podrobnosti o ověřování může zpočátku zobrazovat neúplná nebo nepřesná data, dokud nebudou plně agregované informace protokolu. Mezi známé příklady patří:
      • Při počátečním zaprotokolování událostí přihlášení se nesprávně zobrazí žádost o deklaraci identity ve zprávě tokenu .
      • Primární řádek ověřování není původně protokolován.
    • Pokud si nejste jisti podrobnostmi v protokolech, shromážděte ID požadavku a ID korelace, které se mají použít k další analýze nebo řešení potíží.
    • Pokud se použijí zásady podmíněného přístupu pro ověřování nebo životnost relace, jsou uvedené nad pokusy o přihlášení. Pokud některou z těchto možností nevidíte, tyto zásady se aktuálně nepoužívají. Další informace naleznete v tématu Řízení relací podmíněného přístupu.