Přihlášení do Outlooku po změně VPN: co Entra skutečně vidí

Outlook po změně VPN znovu žádá přihlášení, a heslo poštovní schránky se nezměnilo. Microsoft Entra vyhodnocuje požadavek podle síťové adresy, kterou cloudová služba vidí, a VPN může toto pozorování změnit, aniž by se účtu dotkla. Výzva je výsledkem zásady, ne nutně selháním přihlašovacích údajů.

Jde o dvě relace: relaci VPN a token poštovní schránky. Ověřují se proti různým systémům.

Co Entra při přihlášení vyhodnocuje

Při přihlášení Entra vyhodnocuje požadavek podle nakonfigurovaných podmínek: umístění v síti, stav vícefaktorového ověření, shoda zařízení a jakékoli ovládání relace. Síťová podmínka používá adresu, kterou služba vidí, a ta nemusí vždy odpovídat adrese na stavové stránce notebooku. Zásada, která důvěřuje firemnímu rozsahu, proto může odmítnout klienta, jehož provoz nyní vychází jinam. To je správné vyhodnocení, ne chyba.

Čtěte výsledek jako rozhodnutí zásady, než ho začnete číst jako problém s heslem.

Relace VPN a token poštovní schránky jsou oddělené

To, že brána přijme přihlašovací údaje VPN, dokazuje jen existenci síťové relace. Nic to neříká o tom, zda Exchange Online přijal účet poštovní schránky, zařízení nebo aktuální zásadu přístupu.

Nový požadavek na token může narazit na požadavek Conditional Access a vytvořit oprávněný krok ověření navíc. Nekonečná neúspěšná výzva je jiný výsledek. Zjistěte, který z nich máte, než resetujete kterékoli heslo.

Průběžné vyhodnocování přístupu přidává další cestu: prostředek může odmítnout token, kterému nevypršela platnost, a požádat o nové vyhodnocení. To neznamená, že každá změna sítě vyvolá výzvu u každého klienta Outlooku.

Kterou adresu cloud skutečně vidí

Ikona připojené VPN neurčuje veřejný zdroj každého cloudového požadavku. Provoz, který vychází rozděleným tunelem, cestou IPv6 nebo přes proxy, může Entře představit jinou adresu než Exchange Online. Kontrola v prohlížeči může sledovat zcela jinou trasu.

Porovnejte skutečná pozorování přihlášení se zamýšleným návrhem sítě a zahrňte adresu, kterou prostředek vidí, pokud ji nasazení zveřejňuje.

Držte transportní selhání odděleně od odmítnutí zásadou. Zablokovaný koncový bod ověřování, selhání TLS nebo rozbitá cesta přes proxy vypadají jako problém s přihlášením a nejsou rozhodnutím Conditional Access. Toto rozlišení rozhoduje o tom, zda změníte pravidla tenanta, nebo opravíte cestu. Zachovejte ho, než cokoli upravíte.

Spojte jednu výzvu s jednou událostí přihlášení

Zaznamenávejte jeden pokus po druhém: čas s jeho časovým pásmem, sestavení Outlooku, účet poštovní schránky, stav VPN a přesnou chybu. Pokud chyba odhaluje podrobnosti pro řešení potíží, uchovejte korelační identifikátor, aniž byste kopírovali hesla nebo tokeny.

Oprávněný správce pak může v protokolech přihlášení Entra najít odpovídající událost a prohlédnout klienta, prostředek, podrobnosti ověření a výsledek zásady.

Opravte zásadu a potom ověřte cestu

Čtěte záznam v protokolu pozorně. Úspěšné přihlášení v prohlížeči nemusí být požadavek Outlooku, který sledujete, a časové pásmo prohlížeče se může lišit od vašeho. Aktivity tokenů na pozadí patří do rekonstrukce.

Když výzvu vysvětluje zásada, opravte schválenou identitu, zařízení nebo síťové uspořádání společně s jeho vlastníkem. Důvěřovat celému rozsahu poskytovatele nebo vypnout MFA, aby výzva utichla, není oprava.

Frekvence přihlašování může také vynutit opětovné ověření bez špatného hesla. Po opravě ověřte cestu novou oprávněnou synchronizací nebo odesláním poštovní schránky; čtení uložené zprávy nic nedokazuje. Postup řešení potíží s Conditional Access popisuje korelaci protokolů.