Outlook mula meminta log masuk semula selepas perubahan VPN, dan kata laluan peti mel tidak berubah. Microsoft Entra menilai permintaan menggunakan alamat rangkaian yang dilihat oleh perkhidmatan awan, dan VPN boleh mengubah pemerhatian itu tanpa menyentuh akaun. Permintaan ini ialah hasil dasar, bukan semestinya kegagalan kelayakan.

Dua sesi terlibat: sesi VPN dan token peti mel. Kedua-duanya mengesahkan diri dengan sistem yang berbeza.

Apa yang Entra nilai semasa log masuk

Semasa log masuk, Entra menilai permintaan terhadap syarat yang dikonfigurasikan: lokasi rangkaian, keadaan berbilang faktor, pematuhan peranti dan sebarang kawalan sesi. Syarat rangkaian menggunakan alamat yang dilihat oleh perkhidmatan, yang tidak selalunya alamat pada halaman status komputer riba. Oleh itu, dasar yang mempercayai julat korporat boleh menolak klien yang trafiknya kini keluar di tempat lain. Itu penilaian yang betul, bukan pepijat.

Baca hasilnya sebagai keputusan dasar sebelum membacanya sebagai masalah kata laluan.

Sesi VPN dan token peti mel adalah berasingan

Gerbang yang menerima kelayakan VPN hanya membuktikan sesi rangkaian wujud. Ia tidak menyatakan apa-apa tentang sama ada Exchange Online menerima akaun peti mel, peranti atau dasar akses semasa.

Permintaan token baharu boleh bertembung dengan keperluan Conditional Access dan menghasilkan langkah pengesahan tambahan yang sah. Permintaan gagal tanpa henti ialah hasil yang berbeza. Tentukan yang mana satu anda ada sebelum menetapkan semula mana-mana kata laluan.

Penilaian akses berterusan menambah laluan lain: sumber boleh menolak token yang belum tamat tempoh dan meminta penilaian semula. Itu tidak bermakna setiap perubahan rangkaian menyebabkan setiap klien Outlook meminta log masuk.

Alamat mana yang sebenarnya dilihat oleh awan

Ikon VPN yang bersambung tidak membuktikan sumber awam setiap permintaan awan. Trafik yang keluar melalui terowong berpecah, laluan IPv6 atau proksi boleh menunjukkan alamat berbeza kepada Entra berbanding Exchange Online. Semakan pelayar boleh mengikut laluan yang sama sekali berbeza.

Bandingkan pemerhatian log masuk sebenar dengan reka bentuk rangkaian yang dimaksudkan, dan sertakan alamat yang dilihat sumber di tempat penggunaan mendedahkannya.

Asingkan kegagalan pengangkutan daripada penolakan dasar. Titik akhir pengesahan yang disekat, kegagalan TLS atau laluan proksi yang rosak kelihatan seperti masalah log masuk dan bukan keputusan Conditional Access. Perbezaan ini menentukan sama ada anda menukar peraturan penyewa atau membaiki laluan. Kekalkannya sebelum mengedit apa-apa.

Kaitkan satu permintaan dengan satu peristiwa log masuk

Rekod satu percubaan pada satu masa: masa dengan zon masanya, binaan Outlook, akaun peti mel, keadaan VPN dan ralat yang tepat. Jika ralat mendedahkan butiran penyelesaian masalah, simpan pengecam korelasi tanpa menyalin kata laluan atau token.

Pentadbir yang dibenarkan kemudian boleh mencari peristiwa yang sepadan dalam log log masuk Entra dan memeriksa klien, sumber, butiran pengesahan dan hasil dasar.

Betulkan dasar, kemudian uji laluan

Baca entri log dengan teliti. Log masuk pelayar yang berjaya bukan semestinya permintaan Outlook yang anda jejaki, dan zon masa penonton mungkin berbeza daripada anda. Aktiviti token di latar belakang juga termasuk dalam pembinaan semula.

Apabila sesuatu dasar menjelaskan permintaan itu, betulkan identiti, peranti atau susunan rangkaian yang diluluskan bersama pemiliknya. Mempercayai seluruh julat penyedia atau mematikan MFA untuk mendiamkan permintaan bukan pembaikan.

Kekerapan log masuk juga boleh memaksa pengesahan semula tanpa kata laluan yang salah. Selepas pembetulan, uji laluan dengan penyegerakan atau penghantaran peti mel baharu yang dibenarkan; membaca mesej yang di-cache tidak membuktikan apa-apa. Prosedur penyelesaian masalah Conditional Access menerangkan korelasi log.

Artikel berkaitan