Outlook-ensaluto post VPN-ŝanĝo: kion Entra efektive vidas

Outlook denove petas ensaluton post VPN-ŝanĝo, kaj la poŝtkesta pasvorto ne ŝanĝiĝis. Microsoft Entra taksas la peton per la reta adreso, kiun la nuba servo vidas, kaj VPN povas ŝanĝi tiun observon sen tuŝi la konton. La peto estas politika rezulto, ne nepre malsukceso de akreditaĵoj.

Du sesioj estas implikitaj: la VPN-sesio kaj la poŝtkesta ĵetono. Ili aŭtentikigas kontraŭ malsamaj sistemoj.

Kion Entra taksas ĉe ensaluto

Ĉe ensaluto, Entra taksas la peton laŭ la agorditaj kondiĉoj: reta loko, plurfaktora stato, aparata konformeco kaj ajnaj sesiaj regiloj. La reta kondiĉo uzas la adreson, kiun la servo vidas, kaj tiu ne ĉiam estas la adreso sur la statpaĝo de la tekkomputilo. Politiko, kiu fidas al kompania gamo, povas do malakcepti klienton, kies trafiko nun eliras aliloke. Tio estas ĝusta taksado, ne cimo.

Legu la rezulton kiel politikan decidon antaŭ ol legi ĝin kiel pasvortan problemon.

La VPN-sesio kaj la poŝtkesta ĵetono estas apartaj

Tio, ke enirejo akceptas la VPN-akreditaĵojn, pruvas nur, ke la reta sesio ekzistas. Ĝi diras nenion pri tio, ĉu Exchange Online akceptis la poŝtkestan konton, la aparaton aŭ la nunan alirpolitikon.

Nova ĵetonpeta povas trafi postulon de Conditional Access kaj produkti laŭleĝan plian aŭtentikigan paŝon. Senfina malsukcesa peto estas alia rezulto. Determinu, kiun vi havas, antaŭ ol restarigi ajnan pasvorton.

Daŭra alirtaksado aldonas alian vojon: rimedo povas malakcepti ĵetonon, kiu ne eksvalidiĝis, kaj peti retaksadon. Tio ne signifas, ke ĉiu reta ŝanĝo igas ĉiun Outlook-klienton peti ensaluton.

Kiun adreson la nubo efektive vidas

Konektita VPN-piktogramo ne establas la publikan fonton de ĉiu nuba peto. Trafiko, kiu eliras tra dividita tunelo, IPv6-vojo aŭ prokuro, povas prezenti al Entra alian adreson ol al Exchange Online. Retumila kontrolo povas sekvi tute alian itineron.

Komparu la faktajn ensalutajn observojn kun la intencita reta dezajno, kaj inkluzivu la adreson vidatan de la rimedo, kie la disigado malkaŝas ĝin.

Tenu transportajn fiaskojn aparte de politikaj malakceptoj. Blokita aŭtentikiga finpunkto, TLS-fiasko aŭ rompita prokura vojo aspektas kiel ensaluta problemo kaj ne estas decido de Conditional Access. Tiu distingo decidas, ĉu vi ŝanĝas la regulojn de la luanto aŭ ripari la vojon. Konservu ĝin antaŭ ol redakti ion ajn.

Korelaciu unu peton kun unu ensaluta evento

Registru unu provon samtempe: la horon kun sia horzono, la Outlook-version, la poŝtkestan konton, la VPN-staton kaj la ĝustan eraron. Se la eraro malkaŝas detalojn pri problemtraktado, konservu la korelacian identigilon sen kopii pasvortojn aŭ ĵetonojn.

Rajtigita administranto povas poste trovi la respondan eventon en la Entra-ensalutaj protokoloj kaj ekzameni la klienton, la rimedon, la aŭtentikigajn detalojn kaj la politikan rezulton.

Korektu la politikon, poste provu la vojon

Legu la protokolan enskribon atente. Sukcesa retumila ensaluto ne nepre estas la Outlook-peto, kiun vi postkuras, kaj la horzono de la vidanto povas malsami de la via. Fona ĵetona agado ankaŭ apartenas al la rekonstruo.

Kiam politiko klarigas la peton, korektu la aprobitan identecon, aparaton aŭ retan aranĝon kune kun ĝia posedanto. Fidi tutan provizantan gamon aŭ malŝalti MFA por silentigi la peton ne estas riparo.

Ensaluta ofteco ankaŭ povas devigi reaŭtentikigon sen malĝusta pasvorto. Post la korekto, provu la vojon per nova rajtigita poŝtkesta sinkronigo aŭ siendo; legi kaŝmemorigitan mesaĝon pruvas nenion. La procedo por problemtraktado de Conditional Access priskribas la protokolan korelacion.