Vấn đề này rất có thể do dịch vụ Tự động phát hiện của Outlook , một phần của chức năng Outlook Anywhere . Tự động phát hiện cung cấp nhiều thông tin khác nhau cho máy khách Outlook của người dùng cuối trên các dịch vụ khác nhau do Exchange cung cấp và nơi có thể đặt các dịch vụ này; cái này được sử dụng cho nhiều mục đích khác nhau:
Tự động cấu hình các cấu hình Outlook trong lần chạy Outlook đầu tiên, có thể định cấu hình tài khoản Exchange chỉ sử dụng địa chỉ email và mật khẩu của người dùng, vì các thông tin khác được tự động định vị và truy xuất.
Vị trí động của các dịch vụ dựa trên web được khách hàng Outlook truy cập, bao gồm trợ lý ngoài văn phòng, chức năng Nhắn tin hợp nhất, vị trí của Bảng điều khiển Exchange (ECP), v.v.
Đây là triển khai RFC 6186 độc quyền của Microsoft . Thật không may, họ không thực sự làm theo các khuyến nghị của RFC trong thiết kế của Outlook Anywhere, nhưng điều đó có lẽ được mong đợi vì chức năng Exchange và RPC qua HTTPS không phải là máy chủ IMAP / SMTP truyền thống.
Autodiscover hoạt động như thế nào (đối với người dùng * bên ngoài)?
Tự động phát hiện giao tiếp với một dịch vụ web trên Máy chủ Truy cập Máy khách (trong trường hợp này, tất cả các vai trò đều nằm trên máy chủ SBS) tại đường dẫn /Autodiscover/Autodiscover.xml, thoát khỏi trang web mặc định của nó. Để xác định vị trí FQDN của máy chủ để liên lạc, nó sẽ loại bỏ phần người dùng của địa chỉ email, để lại tên miền (ví dụ: @ companyB.com). Lần lượt, nó cố gắng liên lạc với Tự động phát hiện bằng cách sử dụng từng URL sau:
https://companyB.com/Autodiscover/Autodiscover.xmlhttps://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
Nếu thất bại, nó sẽ thử kết nối không an toàn bằng cách vô hiệu hóa SSL và cố gắng giao tiếp trên cổng 80 (HTTP), thông thường sau khi nhắc người dùng xác nhận đây là một hành động có thể chấp nhận (theo ý kiến của tôi, người dùng không biết gì thường chấp thuận điều này và có nguy cơ gửi thông tin đăng nhập qua văn bản thuần túy - và các hệ thống không có thông tin không yêu cầu liên lạc bảo mật thông tin xác thực và dữ liệu nhạy cảm với doanh nghiệp là rủi ro đối với hoạt động kinh doanh liên tục).
Cuối cùng, kiểm tra tiếp theo được thực hiện bằng bản ghi dịch vụ (SRV) trong DNS, tồn tại ở một vị trí nổi tiếng ngoài companyB.comkhông gian tên và có thể chuyển hướng Outlook đến URL thích hợp nơi máy chủ đang nghe.
Cái mà có thể sai lầm?
Một trong một số vấn đề có thể phát sinh trong quá trình này:
Không có mục DNS
Thông thường, thư mục gốc của tên miền ( companyB.com) có thể không phân giải thành bản ghi máy chủ trong DNS. Cấu hình DNS không đúng (hoặc quyết định có ý thức không để lộ dịch vụ Outlook Anywhere) có thể có nghĩa là autodiscover.companyB.combản ghi cũng không tồn tại.
Trong những trường hợp này, không có vấn đề lớn; Outlook chỉ cần tiếp tục liên lạc với Exchange bằng cách sử dụng cấu hình đã biết cuối cùng và có thể bị xuống cấp đối với các chức năng dựa trên web nhất định mà nó cần để truy xuất URL thông qua Tự động phát hiện (chẳng hạn như trợ lý ngoài văn phòng). Cách giải quyết là sử dụng Outlook Web Access để truy cập các chức năng đó.
Cấu hình tự động của tài khoản Exchange trong cấu hình Outlook mới cũng không được tự động và yêu cầu cấu hình thủ công của RPC qua cài đặt HTTPS. Tuy nhiên, điều này sẽ không gây ra vấn đề bạn mô tả.
Chứng chỉ SSL bị lỗi
Hoàn toàn có thể là URL Outlook sử dụng để cố gắng liên hệ với Máy chủ Exchange phân giải đến máy chủ lưu trữ, có thể hoặc không phải là Máy chủ Truy cập Máy khách. Nếu Outlook có thể giao tiếp với máy chủ đó trên cổng 443, tất nhiên các chứng chỉ sẽ được trao đổi để thiết lập kênh an toàn giữa Outlook và máy chủ từ xa. Nếu URL Outlook tin rằng nó đang được nói đến không được liệt kê trên chứng chỉ đó - có thể là tên chung hoặc tên thay thế chủ đề (SAN) - điều này sẽ gợi ra Outlook để trình bày hộp thoại bạn mô tả trong bài đăng đầu tiên của bạn.
Điều này có thể xảy ra vì nhiều lý do, tất cả đều thuộc về cách DNS được định cấu hình và cách các URL tôi mô tả ở trên được Outlook kiểm tra:
Nếu https://companyB.com/... URL giải quyết thành một bản ghi máy chủ và máy chủ web tại địa chỉ đó lắng nghe trên cổng 443 và nó có chứng chỉ SSL không liệt kê companyB.comtrong tên chung hoặc Tên thay thế chủ đề, thì vấn đề sẽ xảy ra. Vấn đề không phải là máy chủ có phải là Máy chủ Exchange hay không; nó có thể là một máy chủ web lưu trữ một trang web công ty không được cấu hình đúng. Chính xác :
- Vô hiệu hóa bản ghi máy chủ ở gốc của
companyB.comkhu vực (yêu cầu khách truy cập vào trang web hoặc dịch vụ khác để nhập www.companyB.comhoặc tương đương; hoặc
- Vô hiệu hóa quyền truy cập vào máy tại
companyB.comcổng 443, khiến Outlook từ chối companyB.comURL trước khi chứng chỉ được trao đổi và tiếp tục; hoặc là
- Khắc phục chứng chỉ tại
companyB.comđể đảm bảo companyB.comđược liệt kê trên chứng chỉ đó và các lần thử truy cập https://companyB.comtrong trình duyệt chuẩn không bị lỗi.
Những điều trên áp dụng cho dù có companyB.comgiải quyết được với Máy chủ Exchange hay không; nếu Outlook có thể giao tiếp với nó, sau đó nó sẽ phát hiện ra rằng /Autodiscover/Autodiscover.xmlđường dẫn dẫn đến lỗi HTTP 404 (không tồn tại) và tiếp tục.
Nếu https://autodiscover.companyB.com/... URL phân giải thành Máy chủ Exchange (hoặc bất kỳ máy chủ nào khác) nhưng, một lần nữa, autodiscover.companyB.comkhông được liệt kê dưới dạng tên chung hoặc tên thay thế chủ đề, bạn sẽ quan sát hành vi này. Nó có thể được sửa như trên bằng cách sửa chứng chỉ hoặc như bạn chỉ ra một cách chính xác, bạn có thể sử dụng bản ghi SRV để chuyển hướng Outlook đến một URL được liệt kê trên chứng chỉ và Outlook có thể giao tiếp với.
Khắc phục có thể xảy ra của bạn cho vấn đề này
Trong trường hợp này, sửa chữa điển hình là làm sau; tạo bản ghi SRV trong nhà cung cấp DNS mới để đảm bảo Outlook được chuyển hướng đến autodiscover.companyA.com, điều này (bất kỳ vấn đề nào khác sang một bên) sẽ hoạt động thành công vì nó được liệt kê trên chứng chỉ dưới dạng SAN. Để làm việc này, bạn cần phải:
- Cấu hình một
_autodiscover._tcp.companyB.combản ghi SRV theo tài liệu .
- Xóa
autodiscover.companyB.combản ghi máy chủ, nếu nó tồn tại, để ngăn Outlook giải quyết vấn đề này và cố gắng tiếp cận Tự động phát hiện theo cách đó.
- Đồng thời giải quyết mọi vấn đề với quyền truy cập HTTPS
https://companyB.comnhư trên, vì Outlook sẽ liệt kê các URL xuất phát từ địa chỉ email của người dùng trước khi chuyển sang cách tiếp cận bản ghi SRV.
* Autodiscover hoạt động như thế nào (đối với các máy khách nội bộ, đã tham gia tên miền)?
Tôi thêm điều này chỉ để hoàn thiện, vì đó là một lý do phổ biến khác cho những lời nhắc chứng chỉ này xảy ra.
Trên máy khách tham gia miền, khi nó cục bộ trong môi trường Exchange (tức là trên mạng LAN nội bộ), các kỹ thuật trên không được sử dụng. Thay vào đó, Outlook liên lạc trực tiếp với Điểm kết nối dịch vụ trong Active Directory (được liệt kê trong cài đặt Exchange Client Access), liệt kê URL nơi Outlook có thể định vị dịch vụ Tự động phát hiện.
Thông thường các cảnh báo chứng chỉ xảy ra trong những trường hợp này, bởi vì:
- URL mặc định được định cấu hình cho mục đích này đề cập đến URL nội bộ của Exchange, thường không giống với URL công khai.
- Chứng chỉ SSL có thể không liệt kê URL nội bộ trên chúng. Hiện tại, bạn cũng vậy, nhưng điều này có thể trở thành vấn đề trong tương lai đối với các tên miền Active Directory sử dụng
.localvà hậu tố tên miền gTLD không toàn cầu tương tự, do ICANN quyết định cấm chứng chỉ SSL cho các tên miền đó được cấp sau năm 2016.
- Địa chỉ nội bộ có thể không giải quyết đến máy chủ thích hợp.
Trong trường hợp này, vấn đề được giải quyết bằng cách sửa URL đã ghi để tham khảo địa chỉ bên ngoài, thích hợp (được liệt kê trong chứng chỉ), bằng cách chạy Set-ClientAccessServerlệnh ghép ngắn với công -AutodiscoverServiceInternalUritắc. Các bên thực hiện việc này cũng thường định cấu hình DNS đường chân trời , bởi vì họ được yêu cầu thực hiện bởi cấu hình mạng của họ và / hoặc để liên tục giải quyết trong trường hợp mất kết nối / giải quyết ngược dòng.