Prijava v Outlook po spremembi VPN: kaj Entra v resnici vidi

Outlook po spremembi VPN znova zahteva prijavo, geslo poštnega predala pa se ni spremenilo. Microsoft Entra oceni zahtevo na podlagi omrežnega naslova, ki ga vidi storitev v oblaku, in VPN lahko to opažanje spremeni, ne da bi se dotaknil računa. Zahteva je rezultat pravilnika, ne nujno napaka poverilnic.

Vključeni sta dve seji: seja VPN in žeton poštnega predala. Preverjata se pri različnih sistemih.

Kaj Entra ocenjuje ob prijavi

Ob prijavi Entra oceni zahtevo glede na nastavljene pogoje: omrežno lokacijo, stanje večfaktorskega preverjanja, skladnost naprave in vse morebitne kontrolnike seje. Omrežni pogoj uporabi naslov, ki ga vidi storitev, in ta ni vedno naslov na statusni strani prenosnika. Zato lahko pravilnik, ki zaupa v podjetniško območje, zavrne odjemalca, katerega promet zdaj izhaja drugje. To je pravilna ocena, ne hrošč.

Rezultat berite kot odločitev pravilnika, preden ga berete kot težavo z geslom.

Seja VPN in žeton poštnega predala sta ločena

Da prehod sprejme poverilnice VPN, dokazuje le, da seja omrežja obstaja. Ne pove ničesar o tem, ali je Exchange Online sprejel račun poštnega predala, napravo ali veljavni pravilnik dostopa.

Nova zahteva za žeton lahko naleti na zahtevo Conditional Access in ustvari zakonit dodaten korak preverjanja. Neskončna neuspešna zahteva je drug izid. Ugotovite, katerega imate, preden ponastavite katero koli geslo.

Neprekinjeno ocenjevanje dostopa doda še eno pot: vir lahko zavrne žeton, ki ni potekel, in zahteva ponovno oceno. To ne pomeni, da vsaka omrežna sprememba prisili vsakega odjemalca Outlooka k prijavi.

Kateri naslov oblak v resnici vidi

Ikona povezanega VPN ne potrdi javnega izvora vsake zahteve v oblak. Promet, ki izhaja skozi razdeljen tunel, pot IPv6 ali posredniški strežnik, lahko Entri predstavi drugačen naslov kot Exchange Onlineu. Preverjanje v brskalniku lahko sledi povsem drugi poti.

Primerjajte dejanska opažanja prijave z načrtovano zasnovo omrežja in vključite naslov, ki ga vidi vir, kjer ga uvajanje razkrije.

Prenašalne napake ločite od zavrnitev pravilnika. Blokirana končna točka preverjanja, napaka TLS ali prekinjena posredniška pot so videti kot težava s prijavo in niso odločitev Conditional Access. Ta razlika odloči, ali boste spremenili pravila najemnika ali popravili pot. Ohranite jo, preden karkoli uredite.

Povežite eno zahtevo z enim dogodkom prijave

Zabeležite en poskus naenkrat: čas z njegovim časovnim pasom, različico Outlooka, račun poštnega predala, stanje VPN in točno napako. Če napaka razkrije podrobnosti za odpravljanje težav, obdržite korelacijski identifikator, ne da bi kopirali gesla ali žetone.

Pooblaščeni skrbnik lahko nato v dnevnikih prijave Entra najde ustrezen dogodek in pregleda odjemalca, vir, podrobnosti preverjanja in rezultat pravilnika.

Popravite pravilnik in nato preizkusite pot

Zapis v dnevniku preberite pozorno. Uspešna prijava v brskalniku ni nujno zahteva Outlooka, ki ji sledite, in časovni pas gledalca se lahko razlikuje od vašega. Tudi dejavnost žetonov v ozadju spada k rekonstrukciji.

Ko pravilnik pojasni zahtevo, popravite odobreno identiteto, napravo ali omrežno ureditev skupaj z njenim lastnikom. Zaupanje celotnemu območju ponudnika ali izklop MFA, da bi zahtevo utišali, ni popravilo.

Pogostnost prijave lahko tudi prisili ponovno preverjanje brez napačnega gesla. Po popravku preizkusite pot z novo pooblaščeno sinhronizacijo ali pošiljanjem poštnega predala; branje predpomnjenega sporočila ne dokazuje ničesar. Postopek odpravljanja težav s Conditional Access opisuje korelacijo dnevnikov.