Zjistit více o aktivitách v protokolu přihlašování

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živatel
  • Uživatelské jméno
  • ID uživatele
  • Identifikátor přihlášení
  • Typ uživatele

Jak

Jakým způsobem se uživatel přihlašuje, lze zjistit 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 principálu služby zdroje

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: ID korelace seskupuje přihlášení 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 chcete najít 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 záložek 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 vzor kdo, jak, co pomocí podrobností na kartě Základní informace.

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

Kód chyb přihlášení

Pokud přihlášení selhalo, můžete na kartě Základní informace v související položce protokolu získat více informací o příčině. 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í vyhovuje požadavkům, je spravované, nebo jestli je připojeno jako hybridní zařízení 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í k účtu.
  • 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 naplněny požadavky na ověřování tvrzeními tokenu, například když uživatelé nejsou interaktivně vyzváni k zadání hesla nebo jednorázového hesla zaslaného SMS.

Snímek obrazovky záložky Podrobnosti ověřování

Podmíněný přístup

Pokud se ve vašem tenantovi používají zásady podmíněného přístupu, 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ásady podmíněného přístupu se úspěšně použily k pokusu 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é je z důvodu jejich povahy potřeba vyloučit z hodnocení podmíněného přístupu, aby se zabránilo cyklické závislosti (scénář kukačky vejce-kuře), který by nebylo možné dokončit. Tyto scénáře se považují za 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 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, nikoli proces přihlášení do Windows.
  • Zakázáno: Zásada byla v době pokusu o přihlášení zakázaná.

Pouze sestavy

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. Doporučujeme nakonfigurovat zásady podmíněného přístupu v režimu jen pro sestavy po určitou dobu, abyste měli jistotu, že jsou zásady správně nakonfigurované. V režimu pouze pro sestavy můžete nakonfigurovat politiku a vyhodnotit, jaký by měla potenciální účinek, před jejím aktivováním.

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

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í nejlepší možný pokus prováděný pomocí trasování, údajů z registrů, zpětných vyhledávání a dalších informací.

  • 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. Jiná přihlášení mohou být přerušena, takže zásady nejsou aplikovány.
    • Success: Jedna nebo více zásad podmíněného přístupu se použily nebo byly vyhodnoceny 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ínky uživatele a aplikace alespoň jedné zásady podmíněného přístupu, a podmínky udělení přístupu buď nejsou splněny, nebo jsou nastaveny 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ý uživatel 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 provedené hostujícím uživatelem za využití spolupráce B2B.
    • b2bDirectConnect – Přihlášení mezi různými tenanty prováděné subjektem B2B.
    • microsoftSupport– Přihlášení mezi tenanty prováděné agentem podpory Microsoftu v externím tenantovi Microsoftu.
    • serviceProvider – Přihlášení napříč tenanty, které provádí poskytovatel cloudových služeb (CSP) nebo podobný správce jménem svého zákazníka v rámci tenantového prostředí tohoto poskytovatele CSP.
    • passthrough – Přihlášení mezi tenanty, kde se ověřování předává zprostředkovateli domovské identity uživatele bez nutnosti opětovného zadání přihlašovacích údajů.
    • unknownFutureValue – Hodnota používaná MS Graphem, která pomáhá klientům při zpracování změn v seznamu 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í nájemce – nájemce, který vlastní identitu uživatele. Microsoft Entra ID sleduje identifikátor a název.
    • Nájemce prostředků – nájemce, který vlastní (cílový) prostředek.
    • Kvůli závazkům na ochranu osobních údajů nedochází k vyplnění názvu domovského tenanta v ID Microsoft Entra při scénářích mezi různými 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 přihlašovacích protokolech Microsoft Entra zobrazují jako jeden řá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í: Běžně se zobrazuje požadavek na ověření požadovaný poskytovatelem prostředků, aby přihlášení proběhlo úspěšně. Tato hodnota obvykle odráží fázi ověřování dosaženou během přihlášení, ale existují některé zvláštní případy, například:

    • Následný pokus o přihlášení po selhání, kdy je primární ověřování úspěšné a vyžaduje se vícefaktorové ověřování, je hodnota multiFactorAuthentication.
    • V některých okrajových případech toto pole neodráží ověření, které bylo dosaženo při přihlášení. Pokud je například požadavek splněn již z předchozí deklarace vícefaktorového ověřování, poskytovatel prostředků ho sám nevynucuje.
    • U pokusů o přihlášení, u kterých se vyžaduje vícefaktorové ověřování, ale primární ověřování selhalo, je singleFactorAuthentication hodnota, protože pokus nebyl vyhodnocen podmíněným přístupem, aby vyžadoval vícefaktorové ověřování.
    • Rozhraní Graph API podporuje $filter (pouze operátory eq a startsWith).

  • 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 služby je servicePrincipal.
    • Rozhraní Microsoft Graph API podporuje: $filter (pouze operátor eq).
    • 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 zaznamenání událostí přihlášení se nesprávně zobrazuje zpráva "splněno prostřednictvím tvrzení v tokenu".
      • Řádek primárního ověřování není zpočátku zaznamená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 uplatní zásady podmíněného přístupu pro ověřování nebo životnost relace, jsou uvedeny 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í pro podmíněný přístup.

  • ČasGenerování a DatumČasVytvoření:

    • Pokud odesíláte protokoly přihlašování do pracovního prostoru služby Log Analytics, můžete si všimnout dvou různých časových razítek pro stejnou událost přihlášení.
    • Pole TimeGenerated je čas, kdy se záznam události přihlášení ingestoval a uložil v Log Analytics. Odráží, kdy se protokol zpracoval a zpřístupnil v pracovním prostoru.
    • Toto pole CreatedDateTime je časové razítko, kdy došlo k události ověřování a kdy bylo přihlášení zpracováno službou Microsoft Entra ID. Nejedná se o časové razítko samotné události přihlášení.
    • Rozdíl mezi dvěma časovými razítky je způsoben časem potřebným ke zpracování a odeslání přihlašovací události do Log Analytics.
  • Last updated on