Đăng nhập Outlook sau khi thay đổi VPN: Entra thực sự thấy gì

Outlook bắt đầu yêu cầu đăng nhập lại sau khi thay đổi VPN, và mật khẩu hộp thư không thay đổi. Microsoft Entra đánh giá yêu cầu bằng địa chỉ mạng mà dịch vụ đám mây quan sát, và VPN có thể thay đổi quan sát đó mà không chạm vào tài khoản. Yêu cầu này là kết quả của chính sách, không nhất thiết là lỗi thông tin xác thực.

Có hai phiên liên quan: phiên VPN và mã thông báo hộp thư. Chúng xác thực với các hệ thống khác nhau.

Entra đánh giá gì khi đăng nhập

Khi đăng nhập, Entra đánh giá yêu cầu theo các điều kiện đã cấu hình: vị trí mạng, trạng thái đa yếu tố, tuân thủ thiết bị và mọi kiểm soát phiên. Điều kiện mạng dùng địa chỉ mà dịch vụ thấy, không phải lúc nào cũng là địa chỉ trên trang trạng thái của máy tính xách tay. Vì vậy, chính sách tin cậy một dải mạng doanh nghiệp có thể từ chối một máy khách mà lưu lượng nay đi ra ở nơi khác. Đó là đánh giá đúng, không phải lỗi.

Hãy đọc kết quả như một quyết định chính sách trước khi đọc nó như một vấn đề mật khẩu.

Phiên VPN và mã thông báo hộp thư là riêng biệt

Việc cổng chấp nhận thông tin xác thực VPN chỉ chứng minh phiên mạng tồn tại. Nó không nói gì về việc Exchange Online có chấp nhận tài khoản hộp thư, thiết bị hay chính sách truy cập hiện tại hay không.

Yêu cầu mã thông báo mới có thể gặp yêu cầu Conditional Access và tạo ra một bước xác thực bổ sung hợp lệ. Yêu cầu thất bại không dứt là kết quả khác. Xác định bạn đang gặp trường hợp nào trước khi đặt lại bất kỳ mật khẩu nào.

Đánh giá truy cập liên tục thêm một con đường khác: tài nguyên có thể từ chối mã thông báo chưa hết hạn và yêu cầu đánh giá lại. Điều đó không có nghĩa là mọi thay đổi mạng khiến mọi máy khách Outlook yêu cầu đăng nhập.

Đám mây thực sự thấy địa chỉ nào

Biểu tượng VPN đã kết nối không chứng minh nguồn công khai của mọi yêu cầu đám mây. Lưu lượng đi ra qua đường hầm chia tách, tuyến IPv6 hoặc proxy có thể trình cho Entra một địa chỉ khác với địa chỉ trình cho Exchange Online. Kiểm tra trên trình duyệt có thể đi theo một tuyến hoàn toàn khác.

So sánh các quan sát đăng nhập thực tế với thiết kế mạng dự kiến, và bao gồm địa chỉ mà tài nguyên thấy khi việc triển khai tiết lộ nó.

Giữ các lỗi truyền tải tách khỏi các từ chối chính sách. Điểm cuối xác thực bị chặn, lỗi TLS hoặc đường dẫn proxy hỏng trông giống sự cố đăng nhập và không phải quyết định Conditional Access. Sự phân biệt này quyết định bạn thay đổi quy tắc của đối tượng thuê hay sửa đường dẫn. Hãy giữ nó trước khi chỉnh sửa bất cứ điều gì.

Tương quan một yêu cầu với một sự kiện đăng nhập

Ghi một lần thử mỗi lần: thời điểm kèm múi giờ, bản dựng Outlook, tài khoản hộp thư, trạng thái VPN và lỗi chính xác. Nếu lỗi hiển thị chi tiết khắc phục sự cố, hãy giữ mã định danh tương quan mà không sao chép mật khẩu hoặc mã thông báo.

Quản trị viên được ủy quyền sau đó có thể tìm sự kiện khớp trong nhật ký đăng nhập Entra và kiểm tra máy khách, tài nguyên, chi tiết xác thực và kết quả chính sách.

Sửa chính sách, sau đó thử nghiệm đường dẫn

Đọc mục nhật ký một cách cẩn thận. Đăng nhập thành công trên trình duyệt không nhất thiết là yêu cầu Outlook bạn đang theo đuổi, và múi giờ của người xem có thể khác của bạn. Hoạt động mã thông báo nền cũng thuộc phần tái dựng.

Khi một chính sách giải thích yêu cầu, hãy sửa danh tính, thiết bị hoặc cách bố trí mạng đã được phê duyệt cùng với chủ sở hữu của nó. Tin cậy toàn bộ dải nhà cung cấp hoặc tắt MFA để làm im yêu cầu không phải là sửa chữa.

Tần suất đăng nhập cũng có thể buộc xác thực lại mà không có mật khẩu sai. Sau khi sửa, hãy thử nghiệm đường dẫn bằng một lần đồng bộ hoặc gửi hộp thư mới được ủy quyền; đọc một tin nhắn đã lưu trong bộ nhớ đệm không chứng minh được gì. Quy trình khắc phục sự cố Conditional Access mô tả tương quan nhật ký.