Outlook prisijungimas po VPN pakeitimo: ką Entra iš tikrųjų mato

Outlook vėl pradeda prašyti prisijungimo po VPN pakeitimo, o pašto dėžutės slaptažodis nepasikeitė. Microsoft Entra vertina užklausą pagal tinklo adresą, kurį mato debesijos paslauga, o VPN gali pakeisti tą stebėjimą neliesdamas paskyros. Užklausa yra politikos rezultatas, o ne būtinai prisijungimo duomenų klaida.

Dalyvauja dvi sesijos: VPN sesija ir pašto dėžutės prieigos raktas. Jos autentifikuojasi skirtingose sistemose.

Ką Entra vertina prisijungiant

Prisijungiant Entra vertina užklausą pagal sukonfigūruotas sąlygas: tinklo vietą, daugiaveiksnę būseną, įrenginio atitiktį ir bet kokią sesijos kontrolę. Tinklo sąlyga naudoja adresą, kurį mato paslauga, ir jis ne visada sutampa su adresu nešiojamojo kompiuterio būsenos puslapyje. Todėl politika, pasitikinti įmonės diapazonu, gali atmesti klientą, kurio srautas dabar išeina kitur. Tai teisingas vertinimas, o ne klaida.

Skaitykite rezultatą kaip politikos sprendimą, prieš skaitydami jį kaip slaptažodžio problemą.

VPN sesija ir pašto dėžutės prieigos raktas yra atskiri

Tai, kad šliuzas priima VPN prisijungimo duomenis, įrodo tik tinklo sesijos egzistavimą. Tai nieko nesako apie tai, ar Exchange Online priėmė pašto dėžutės paskyrą, įrenginį ar dabartinę prieigos politiką.

Nauja prieigos rakto užklausa gali susidurti su Conditional Access reikalavimu ir sukurti teisėtą papildomą autentifikavimo žingsnį. Begalinė nepavykusi užklausa yra kitas rezultatas. Nustatykite, kuris iš jų yra pas jus, prieš atstatydami bet kurį slaptažodį.

Nuolatinis prieigos vertinimas prideda dar vieną kelią: išteklius gali atmesti dar nepasibaigusį prieigos raktą ir paprašyti pervertinimo. Tai nereiškia, kad kiekvienas tinklo pakeitimas verčia kiekvieną Outlook klientą prašyti prisijungimo.

Kokį adresą debesis iš tikrųjų mato

Prijungto VPN piktograma neįrodo kiekvienos debesijos užklausos viešosios kilmės. Srautas, išeinantis per padalintą tunelį, IPv6 maršrutą ar tarpinį serverį, gali pateikti Entra kitą adresą nei Exchange Online. Naršyklės patikra gali sekti visiškai kitu maršrutu.

Palyginkite tikruosius prisijungimo stebėjimus su numatytu tinklo projektu ir įtraukite ištekliaus matomą adresą ten, kur diegimas jį atskleidžia.

Laikykite transporto gedimus atskirai nuo politikos atmetimų. Užblokuotas autentifikavimo galinis taškas, TLS gedimas ar sugadintas tarpinio serverio kelias atrodo kaip prisijungimo problema, o ne Conditional Access sprendimas. Šis skirtumas nusprendžia, ar keisite nuomininko taisykles, ar taisysite kelią. Išsaugokite jį prieš ką nors redaguodami.

Susiekite vieną užklausą su vienu prisijungimo įvykiu

Fiksuokite po vieną bandymą: laiką su laiko juosta, Outlook versiją, pašto dėžutės paskyrą, VPN būseną ir tikslią klaidą. Jei klaida atskleidžia trikčių šalinimo informaciją, išsaugokite koreliacijos identifikatorių nenukopijuodami slaptažodžių ar raktų.

Įgaliotas administratorius tada gali rasti atitinkamą įvykį Entra prisijungimo žurnaluose ir ištirti klientą, išteklių, autentifikavimo informaciją ir politikos rezultatą.

Ištaisykite politiką, tada išbandykite kelią

Atidžiai perskaitykite žurnalo įrašą. Sėkmingas prisijungimas naršyklėje nebūtinai yra ta Outlook užklausa, kurios ieškote, o peržiūros laiko juosta gali skirtis nuo jūsų. Foninė raktų veikla taip pat priklauso rekonstrukcijai.

Kai politika paaiškina užklausą, ištaisykite patvirtintą tapatybę, įrenginį ar tinklo išdėstymą kartu su jo savininku. Pasitikėjimas visu teikėjo diapazonu arba MFA išjungimas, kad užklausa nutiltų, nėra taisymas.

Prisijungimo dažnumas taip pat gali priversti pakartotinį autentifikavimą be neteisingo slaptažodžio. Po pataisymo išbandykite kelią nauju įgaliotu pašto dėžutės sinchronizavimu arba siuntimu; talpykloje esančio pranešimo skaitymas nieko neįrodo. Conditional Access trikčių šalinimo procedūra aprašo žurnalų koreliaciją.