Login Outlook setelah perubahan VPN: apa yang sebenarnya dilihat Entra

Outlook mulai meminta login lagi setelah perubahan VPN, dan kata sandi kotak surat tidak berubah. Microsoft Entra mengevaluasi permintaan menggunakan alamat jaringan yang dilihat layanan cloud, dan VPN dapat mengubah pengamatan itu tanpa menyentuh akun. Permintaan ini adalah hasil kebijakan, bukan berarti kegagalan kredensial.

Ada dua sesi yang terlibat: sesi VPN dan token kotak surat. Keduanya mengautentikasi ke sistem yang berbeda.

Apa yang dievaluasi Entra saat login

Saat login, Entra mengevaluasi permintaan terhadap kondisi yang dikonfigurasi: lokasi jaringan, status multifaktor, kepatuhan perangkat, dan kontrol sesi apa pun. Kondisi jaringan memakai alamat yang dilihat layanan, yang tidak selalu alamat pada halaman status laptop. Karena itu, kebijakan yang memercayai rentang korporat dapat menolak klien yang trafiknya kini keluar di tempat lain. Itu evaluasi yang benar, bukan bug.

Baca hasilnya sebagai keputusan kebijakan sebelum membacanya sebagai masalah kata sandi.

Sesi VPN dan token kotak surat terpisah

Gerbang yang menerima kredensial VPN hanya membuktikan bahwa sesi jaringan ada. Itu tidak mengatakan apa pun tentang apakah Exchange Online menerima akun kotak surat, perangkat, atau kebijakan akses saat ini.

Permintaan token baru dapat berbenturan dengan persyaratan Conditional Access dan menghasilkan langkah autentikasi tambahan yang sah. Permintaan gagal tanpa henti adalah hasil yang berbeda. Tentukan mana yang Anda hadapi sebelum menyetel ulang kata sandi mana pun.

Evaluasi akses berkelanjutan menambah jalur lain: sumber daya dapat menolak token yang belum kedaluwarsa dan meminta evaluasi ulang. Itu tidak berarti setiap perubahan jaringan membuat setiap klien Outlook meminta login.

Alamat mana yang sebenarnya dilihat cloud

Ikon VPN tersambung tidak membuktikan sumber publik setiap permintaan cloud. Trafik yang keluar melalui terowongan terpisah, jalur IPv6, atau proksi dapat menyajikan alamat berbeda kepada Entra daripada kepada Exchange Online. Pemeriksaan browser dapat mengikuti rute yang sama sekali lain.

Bandingkan pengamatan login yang sebenarnya dengan desain jaringan yang dimaksud, dan sertakan alamat yang dilihat sumber daya jika penerapan mengungkapkannya.

Pisahkan kegagalan transport dari penolakan kebijakan. Endpoint autentikasi yang diblokir, kegagalan TLS, atau jalur proksi yang rusak tampak seperti masalah login dan bukan keputusan Conditional Access. Perbedaan itu menentukan apakah Anda mengubah aturan tenant atau memperbaiki jalur. Pertahankan sebelum mengedit apa pun.

Korelasikan satu permintaan dengan satu peristiwa login

Catat satu percobaan setiap kali: waktu beserta zona waktunya, versi Outlook, akun kotak surat, status VPN, dan kesalahan persisnya. Jika kesalahan menampilkan detail pemecahan masalah, simpan pengenal korelasi tanpa menyalin kata sandi atau token.

Administrator yang berwenang kemudian dapat menemukan peristiwa yang cocok di log login Entra dan memeriksa klien, sumber daya, detail autentikasi, dan hasil kebijakan.

Perbaiki kebijakan, lalu uji jalurnya

Baca entri log dengan cermat. Login browser yang berhasil belum tentu permintaan Outlook yang Anda lacak, dan zona waktu penampil mungkin berbeda dari zona waktu Anda. Aktivitas token di latar belakang juga termasuk dalam rekonstruksi.

Ketika kebijakan menjelaskan permintaan itu, perbaiki identitas, perangkat, atau tata letak jaringan yang disetujui bersama pemiliknya. Memercayai seluruh rentang penyedia atau mematikan MFA untuk membungkam permintaan bukan perbaikan.

Frekuensi login juga dapat memaksa autentikasi ulang tanpa kata sandi yang salah. Setelah koreksi, uji jalur dengan sinkronisasi atau pengiriman kotak surat baru yang sah; membaca pesan yang di-cache tidak membuktikan apa pun. Prosedur pemecahan masalah Conditional Access menjelaskan korelasi log.