Outlook pieteikšanās pēc VPN maiņas: ko Entra patiešām redz

Outlook pēc VPN maiņas atkal sāk prasīt pieteikšanos, un pastkastes parole nav mainījusies. Microsoft Entra izvērtē pieprasījumu pēc tīkla adreses, ko redz mākoņpakalpojums, un VPN var mainīt šo novērojumu, nepieskaroties kontam. Pieprasījums ir politikas rezultāts, nevis obligāti akreditācijas datu kļūda.

Iesaistītas divas sesijas: VPN sesija un pastkastes pilnvara. Tās autentificējas dažādās sistēmās.

Ko Entra vērtē pieteikšanās laikā

Pieteikšanās laikā Entra izvērtē pieprasījumu pret konfigurētajiem nosacījumiem: tīkla atrašanās vietu, daudzfaktoru stāvokli, ierīces atbilstību un jebkādu sesijas kontroli. Tīkla nosacījums izmanto adresi, ko redz pakalpojums, un tā ne vienmēr ir adrese klēpjdatora statusa lapā. Tāpēc politika, kas uzticas uzņēmuma diapazonam, var noraidīt klientu, kura trafiks tagad iziet citur. Tas ir pareizs novērtējums, nevis kļūda.

Lasiet rezultātu kā politikas lēmumu, pirms lasāt to kā paroles problēmu.

VPN sesija un pastkastes pilnvara ir atsevišķas

Tas, ka vārteja pieņem VPN akreditācijas datus, pierāda tikai tīkla sesijas esamību. Tas neko nepasaka par to, vai Exchange Online pieņēma pastkastes kontu, ierīci vai pašreizējo piekļuves politiku.

Jauns pilnvaras pieprasījums var saskarties ar Conditional Access prasību un radīt likumīgu papildu autentifikācijas soli. Bezgalīgs neveiksmīgs pieprasījums ir cits rezultāts. Nosakiet, kurš no tiem jums ir, pirms atiestatāt jebkuru paroli.

Nepārtraukts piekļuves novērtējums pievieno vēl vienu ceļu: resurs var noraidīt vēl neizbeigtu pilnvaru un lūgt atkārtotu novērtējumu. Tas nenozīmē, ka katra tīkla maiņa liek katram Outlook klientam prasīt pieteikšanos.

Kuru adresi mākonis patiešām redz

Pievienota VPN ikona nepierāda katras mākoņa pieprasījuma publisko izcelsmi. Trafiks, kas iziet caur sadalītu tuneli, IPv6 ceļu vai starpniekserveri, var uzrādīt Entra citu adresi nekā Exchange Online. Pārlūkprogrammas pārbaude var sekot pavisam citam maršrutam.

Salīdziniet faktiskos pieteikšanās novērojumus ar paredzēto tīkla dizainu un iekļaujiet resursa redzēto adresi, kur izvietošana to atklāj.

Turiet transporta kļūmes atsevišķi no politikas atteikumiem. Bloķēts autentifikācijas galapunkts, TLS kļūme vai bojāts starpniekservera ceļš izskatās kā pieteikšanās problēma un nav Conditional Access lēmums. Šī atšķirība izlemj, vai mainīsiet nomnieka noteikumus vai labosiet ceļu. Saglabājiet to pirms kaut kā rediģēšanas.

Korelējiet vienu pieprasījumu ar vienu pieteikšanās notikumu

Ierakstiet vienu mēģinājumu vienlaikus: laiku ar laika joslu, Outlook versiju, pastkastes kontu, VPN stāvokli un precīzu kļūdu. Ja kļūda atklāj problēmu novēršanas informāciju, saglabājiet korelācijas identifikatoru, nekopējot paroles vai pilnvaras.

Pilnvarots administrators pēc tam var atrast atbilstošo notikumu Entra pieteikšanās žurnālos un pārbaudīt klientu, resursu, autentifikācijas informāciju un politikas rezultātu.

Izlabojiet politiku, pēc tam pārbaudiet ceļu

Uzmanīgi izlasiet žurnāla ierakstu. Veiksmīga pieteikšanās pārlūkprogrammā ne vienmēr ir tas Outlook pieprasījums, kuru meklējat, un skatītāja laika josla var atšķirties no jūsējās. Fona pilnvaru darbība arī ietilpst rekonstrukcijā.

Kad politika izskaidro pieprasījumu, izlabojiet apstiprināto identitāti, ierīci vai tīkla izkārtojumu kopā ar tā īpašnieku. Uzticēšanās visam pakalpojumu sniedzēja diapazonam vai MFA izslēgšana, lai pieprasījums apklustu, nav labojums.

Pieteikšanās biežums var arī piespiest atkārtotu autentifikāciju bez nepareizas paroles. Pēc labojuma pārbaudiet ceļu ar jaunu pilnvarotu pastkastes sinhronizāciju vai sūtīšanu; kešatmiņā saglabātas ziņas lasīšana neko nepierāda. Conditional Access problēmu novēršanas procedūra apraksta žurnālu korelāciju.