Outlook-logon efter en VPN-ændring: hvad Entra faktisk ser

Outlook begynder at spørge om logon igen efter en VPN-ændring, og postkassens adgangskode er ikke ændret. Microsoft Entra vurderer anmodningen ud fra den netværksadresse, cloudtjenesten ser, og en VPN kan ændre den observation uden at røre ved kontoen. Anmodningen er et politikresultat, ikke nødvendigvis en fejl i adgangsoplysningerne.

Der er to sessioner involveret: VPN-sessionen og postkassens token. De godkender mod forskellige systemer.

Hvad Entra vurderer ved logon

Ved logon vurderer Entra anmodningen mod de konfigurerede betingelser: netværksplacering, multifaktortilstand, enhedsoverensstemmelse og eventuelle sessionskontroller. Netværksbetingelsen bruger den adresse, tjenesten ser, og den er ikke altid adressen på bærbarens statusside. En politik, der stoler på et virksomhedsområde, kan derfor afvise en klient, hvis trafik nu går ud et andet sted. Det er en korrekt vurdering, ikke en fejl.

Læs resultatet som en politikbeslutning, før du læser det som et adgangskodeproblem.

VPN-sessionen og postkassens token er adskilte

At en gateway accepterer VPN-adgangsoplysningerne beviser kun, at netværkssessionen findes. Det siger intet om, hvorvidt Exchange Online har accepteret postkassekontoen, enheden eller den aktuelle adgangspolitik.

En ny tokenanmodning kan ramme et Conditional Access-krav og give et legitimt ekstra godkendelsestrin. En endeløs mislykket anmodning er et andet udfald. Fastslå, hvilket af dem du har, før du nulstiller en adgangskode.

Løbende adgangsevaluering tilføjer endnu en vej: en ressource kan afvise et token, der ikke er udløbet, og bede om en ny vurdering. Det betyder ikke, at enhver netværksændring får hver Outlook-klient til at spørge.

Hvilken adresse ser skyen faktisk

Et tilsluttet VPN-ikon fastslår ikke den offentlige kilde for hver cloudanmodning. Trafik, der forlader gennem en split tunnel, en IPv6-rute eller en proxy, kan vise Entra en anden adresse end Exchange Online. En browserkontrol kan følge en helt anden rute.

Sammenlign de faktiske logon-observationer med det tilsigtede netværksdesign, og medtag den adresse, ressourcen ser, hvor udrulningen viser den.

Hold transportfejl adskilt fra politikafvisninger. Et blokeret godkendelsesendepunkt, en TLS-fejl eller en brudt proxyvej ligner et logonproblem og er ikke en Conditional Access-beslutning. Forskellen afgør, om du ændrer tenantens regler eller reparerer ruten. Bevar den, før du redigerer noget.

Korrelér én anmodning med én logonhændelse

Registrér ét forsøg ad gangen: tidspunktet med tidszone, Outlook-build, postkassekontoen, VPN-tilstanden og den præcise fejl. Hvis fejlen viser fejlfindingsoplysninger, skal du beholde korrelationsidentifikatoren uden at kopiere adgangskoder eller tokens.

En autoriseret administrator kan derefter finde den matchende hændelse i Entra-logonloggene og undersøge klienten, ressourcen, godkendelsesoplysningerne og politikresultatet.

Ret politikken, og prøv derefter ruten

Læs logposten omhyggeligt. Et vellykket browser-logon er ikke nødvendigvis den Outlook-anmodning, du jagter, og visningens tidszone kan afvige fra din. Baggrundstokenaktivitet hører også med i rekonstruktionen.

Når en politik forklarer anmodningen, skal du rette den godkendte identitet, enhed eller netværksordning sammen med dens ejer. At stole på et helt udbyderområde eller slå MFA fra for at dæmpe anmodningen er ikke en reparation.

Logonfrekvens kan også tvinge ny godkendelse uden en forkert adgangskode. Efter rettelsen prøver du ruten med en ny autoriseret postkassesynkronisering eller -afsendelse; at læse en cachelagret meddelelse beviser intet. Fejlfindingsproceduren for Conditional Access beskriver logkorrelationen.