Prijava u Outlook nakon promjene VPN-a: šta Entra zapravo vidi

Outlook ponovo traži prijavu nakon promjene VPN-a, a lozinka poštanskog sandučeta nije promijenjena. Microsoft Entra procjenjuje zahtjev koristeći mrežnu adresu koju cloud usluga vidi, a VPN može promijeniti to opažanje bez diranja u račun. Upit je rezultat pravila, a ne nužno neuspjeh akreditacija.

Uključene su dvije sesije: VPN sesija i token poštanskog sandučeta. One se autentifikuju na različitim sistemima.

Šta Entra procjenjuje pri prijavi

Pri prijavi Entra procjenjuje zahtjev prema podešenim uslovima: mrežna lokacija, stanje višefaktorske autentifikacije, usklađenost uređaja i sve kontrole sesije. Mrežni uslov koristi adresu koju usluga vidi, a to nije uvijek adresa na statusnoj stranici laptopa. Zato pravilo koje vjeruje korporativnom rasponu može odbiti klijenta čiji saobraćaj sada izlazi negdje drugdje. To je ispravna procjena, a ne greška.

Pročitajte rezultat kao odluku pravila prije nego što ga pročitate kao problem s lozinkom.

VPN sesija i token poštanskog sandučeta su odvojeni

To što gateway prihvata VPN akreditacije dokazuje samo da mrežna sesija postoji. To ne govori ništa o tome da li je Exchange Online prihvatio račun poštanskog sandučeta, uređaj ili trenutno pravilo pristupa.

Novi zahtjev za token može naići na uslov Conditional Access i proizvesti legitiman dodatni korak autentifikacije. Beskonačni neuspjeli upit je drugačiji ishod. Utvrdite koji od njih imate prije nego što resetujete bilo koju lozinku.

Kontinuirana procjena pristupa dodaje još jedan put: resurs može odbiti token koji nije istekao i zatražiti ponovnu procjenu. To ne znači da svaka promjena mreže tjera svakog Outlook klijenta na prijavu.

Koju adresu cloud zapravo vidi

Ikona povezanog VPN-a ne dokazuje javni izvor svakog cloud zahtjeva. Saobraćaj koji izlazi kroz split tunel, IPv6 put ili proxy može predstaviti Entri drugačiju adresu nego Exchange Onlineu. Provjera u pregledniku može slijediti sasvim drugu rutu.

Uporedite stvarna opažanja prijave sa predviđenim dizajnom mreže i uključite adresu koju resurs vidi tamo gdje je implementacija izlaže.

Držite transportne kvarove odvojeno od odbijanja pravila. Blokirana autentifikacijska krajnja tačka, kvar TLS-a ili pokvaren proxy put izgledaju kao problem prijave i nisu odluka Conditional Accessa. Ta razlika odlučuje hoćete li promijeniti pravila tenanta ili popraviti put. Sačuvajte je prije nego što bilo šta uredite.

Povežite jedan upit s jednim događajem prijave

Bilježite jedan pokušaj odjednom: vrijeme s vremenskom zonom, verziju Outlooka, račun poštanskog sandučeta, stanje VPN-a i tačnu grešku. Ako greška otkriva detalje za rješavanje problema, zadržite identifikator korelacije bez kopiranja lozinki ili tokena.

Ovlašteni administrator zatim može pronaći odgovarajući događaj u Entra zapisima prijave i pregledati klijenta, resurs, detalje autentifikacije i rezultat pravila.

Ispravite pravilo, pa provjerite put

Pažljivo pročitajte zapis u dnevniku. Uspješna prijava u pregledniku nije nužno Outlook zahtjev koji tražite, a vremenska zona pregledača može se razlikovati od vaše. Pozadinska aktivnost tokena takođe pripada rekonstrukciji.

Kada pravilo objašnjava upit, ispravite odobreni identitet, uređaj ili mrežni raspored zajedno s njegovim vlasnikom. Vjerovanje cijelom rasponu provajdera ili isključivanje MFA-e da bi upit utihnuo nije popravka.

Učestalost prijave takođe može prisiliti ponovnu autentifikaciju bez pogrešne lozinke. Nakon ispravke provjerite put svježom ovlaštenom sinhronizacijom ili slanjem pošte; čitanje keširane poruke ništa ne dokazuje. Procedura za rješavanje problema s Conditional Accessom opisuje korelaciju zapisa.