Ten problem jest najprawdopodobniej spowodowany przez usługę Autodiscover programu Outlook, będącą częścią funkcji Outlook Anywhere . Autodiscover dostarcza różne informacje do klienta Outlook użytkownika końcowego na temat różnych usług oferowanych przez Exchange i gdzie można je zlokalizować; jest to wykorzystywane do różnych celów:
Automatyczna konfiguracja profili programu Outlook przy pierwszym uruchomieniu programu Outlook, który może skonfigurować konto Exchange przy użyciu tylko adresu e-mail i hasła użytkownika, ponieważ pozostałe informacje są automatycznie lokalizowane i pobierane.
Dynamiczna lokalizacja usług internetowych, do których ma dostęp klient Outlook, w tym asystent poza biurem, funkcja Unified Messaging, lokalizacja panelu sterowania Exchange (ECP) i tak dalej.
To zastrzeżona implementacja RFC 6186 firmy Microsoft . Niestety tak naprawdę nie zastosowali się do zaleceń tego dokumentu RFC w projekcie Outlook Anywhere, ale być może należy się tego spodziewać, ponieważ funkcje Exchange i RPC over HTTPS nie są tradycyjnym serwerem IMAP / SMTP.
Jak działa funkcja automatycznego wykrywania (dla zewnętrznych * użytkowników)?
Autodiscover komunikuje się z usługą internetową na serwerze dostępu klienta (w tym przypadku wszystkie role są na serwerze SBS) na ścieżce /Autodiscover/Autodiscover.xml , zrootowanej z domyślnej strony internetowej. Aby zlokalizować nazwę FQDN serwera do komunikacji, usuwa część adresu e-mail użytkownika i opuszcza domenę (tj. @ CompanyB.com). Próbuje komunikować się z Autodiscover przy użyciu każdego z następujących adresów URL:
https://companyB.com/Autodiscover/Autodiscover.xmlhttps://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
Jeśli się to nie powiedzie, spróbuje nawiązać niezabezpieczone połączenie, wyłączając protokół SSL i próbując komunikować się na porcie 80 (HTTP), zwykle po wyświetleniu monitu o potwierdzenie, że jest to akceptowalne działanie (moim zdaniem wadliwa opcja, ponieważ użytkownicy nieświadomi zazwyczaj zatwierdza to i ryzykuje wysyłanie poświadczeń w postaci zwykłego tekstu - a nieświadomi sysadmini, którzy nie wymagają bezpiecznej komunikacji poświadczeń i poufnych danych biznesowych, stanowią ryzyko dla ciągłości biznesowej).
Wreszcie, sprawdzanie jest wykonywane przy użyciu rekordu usługi (SRV) w DNS, który istnieje w znanej lokalizacji poza obszarem companyB.comnazw i może przekierować Outlooka na właściwy adres URL, na którym serwer nasłuchuje.
Co może pójść źle?
W tym procesie może pojawić się jedna z kilku kwestii:
Brak wpisów DNS
Zazwyczaj katalog główny domeny ( companyB.com) może nie zostać rozpoznany jako rekord hosta w DNS. Nieprawidłowa konfiguracja DNS (lub świadoma decyzja o nieujawnianiu usługi Outlook Anywhere) może oznaczaćautodiscover.companyB.com rekord również nie istnieje.
W takich przypadkach nie ma większego problemu; Program Outlook po prostu kontynuuje komunikację z Exchange przy użyciu ostatniej znanej konfiguracji i może zostać zdegradowany w odniesieniu do niektórych funkcji internetowych, dla których musi pobierać adresy URL za pomocą funkcji automatycznego wykrywania (np. Asystent poza biurem). Obejściem tego problemu jest korzystanie z programu Outlook Web Access w celu uzyskania dostępu do takich funkcji.
Automatyczna konfiguracja kont Exchange w nowych profilach Outlook również nie jest zautomatyzowana i wymaga ręcznej konfiguracji RPC przez ustawienia HTTPS. Nie spowoduje to jednak opisanego problemu.
Wadliwe certyfikaty SSL
Jest całkowicie możliwe, że adres URL używany przez program Outlook do próby nawiązania połączenia z serwerem Exchange jest rozwiązywany na hoście, który może, ale nie musi, być serwerem dostępu klienta. Jeśli program Outlook może komunikować się z tym serwerem na porcie 443, certyfikaty zostaną oczywiście wymienione w celu skonfigurowania bezpiecznego kanału między programem Outlook a serwerem zdalnym. Jeśli adres URL programu Outlook, który uważa, że mówi, nie jest wymieniony na tym certyfikacie - czy to jako nazwa zwyczajowa, czy alternatywna nazwa podmiotu (SAN) - spowoduje to wyświetlenie przez Outlooka okna dialogowego opisanego w początkowym poście.
Może się to zdarzyć z kilku powodów, w tym konfiguracji DNS i sprawdzania adresów URL opisanych powyżej przez Outlook:
Jeśli https://companyB.com/... URL rozwiązuje się w rekordzie hosta, a serwer WWW pod tym adresem nasłuchuje na porcie 443 i ma certyfikat SSL, który nie znajduje się companyB.comw nazwie pospolitej lub alternatywnej nazwie podmiotu, problem wystąpi. Nie ma znaczenia, czy host jest serwerem Exchange, czy nie; może to być serwer sieciowy obsługujący witrynę firmy, która nie jest odpowiednio skonfigurowana. Spełnij albo:
- Wyłącz rekord hosta w katalogu głównym
companyB.comstrefy (wymagając od odwiedzających stronę internetową lub inną usługę wejścia www.companyB.comlub równoważnego; lub
- Wyłącz dostęp do komputera
companyB.comna porcie 443, powodując, że program Outlook odrzuci companyB.comadres URL przed wymianą certyfikatów i przejściem; lub
- Napraw certyfikat w,
companyB.comaby upewnić companyB.comsię, że jest wymieniony na tym certyfikacie i że próby odwiedzenia https://companyB.comw standardowej przeglądarce nie zakończą się niepowodzeniem.
Powyższe dotyczy niezależnie od tego, czy companyB.comrozwiązuje to na serwerze Exchange; jeśli Outlook może się z nim komunikować, później odkryje, że /Autodiscover/Autodiscover.xmlścieżka powoduje błąd HTTP 404 (nie istnieje) i przechodzi dalej.
Jeśli https://autodiscover.companyB.com/... URL rozwiązuje się z serwerem Exchange (lub innym serwerem), ale ponownie autodiscover.companyB.comnie jest wymieniony jako nazwa pospolita lub nazwa alternatywna podmiotu, zaobserwujesz to zachowanie. Może on być ustalony powyżej ustalając certyfikatu, lub jak słusznie wskazują, można użyć rekord SRV przekierować Outlook do adresu URL, który jest podany na świadectwie i Outlook, które mogą komunikować z.
Prawdopodobna poprawka tego problemu
W takim przypadku typową poprawką jest zrobienie tego drugiego; utwórz rekordy SRV w nowym dostawcy DNS, aby upewnić się, że program Outlook jest przekierowywany, do autodiscover.companyA.comktórego (oprócz innych problemów) będzie działało pomyślnie, ponieważ jest wymieniony w certyfikacie jako SAN. Aby to zadziałało, musisz:
- Skonfiguruj
_autodiscover._tcp.companyB.comrekord SRV zgodnie z dokumentacją .
- Usuń
autodiscover.companyB.comrekord hosta, jeśli istnieje, aby zapobiec rozwiązaniu problemu przez program Outlook i próbie osiągnięcia w ten sposób funkcji automatycznego wykrywania.
- Rozwiąż również wszelkie problemy z dostępem HTTPS do
https://companyB.compowyższego, ponieważ program Outlook wyliczy adresy URL pochodzące z adresu e-mail użytkownika, zanim przejdzie do metody rejestrowania SRV.
* Jak działa funkcja automatycznego wykrywania (dla wewnętrznych klientów przyłączonych do domeny)?
Dodaję to tylko dla kompletności, ponieważ jest to kolejny częsty powód wyświetlania monitów o certyfikat.
W kliencie przyłączonym do domeny, gdy jest on lokalny dla środowiska Exchange (tj. W wewnętrznej sieci LAN), powyższe techniki nie są używane. Zamiast tego program Outlook komunikuje się bezpośrednio z punktem połączenia usługi w usłudze Active Directory (wymienionym w ustawieniach dostępu klienta Exchange), który podaje adres URL, pod którym program Outlook może zlokalizować usługę automatycznego wykrywania.
W takich okolicznościach ostrzeżenia o certyfikatach występują często, ponieważ:
- Domyślny adres URL skonfigurowany w tym celu odnosi się do wewnętrznego adresu URL Exchange, który często różni się od publicznego adresu URL.
- Certyfikaty SSL mogą nie zawierać na nich wewnętrznego adresu URL. Obecnie Twoja, ale może to stać się problemem w przyszłości dla domen Active Directory, które używają
.locali podobnych nieglobalnych sufiksów domen gTLD, ponieważ decyzja ICANN zabrania wydawania certyfikatów SSL dla takich domen po 2016 roku.
- Adres wewnętrzny może nie zostać rozpoznany na odpowiednim serwerze.
W takim przypadku problem zostaje rozwiązany przez poprawienie zarejestrowanego adresu URL, tak aby odwoływał się do właściwego adresu zewnętrznego (wymienionego w certyfikacie), poprzez uruchomienie polecenia Set-ClientAccessServercmdlet z -AutodiscoverServiceInternalUriprzełącznikiem. Strony, które to robią, zwykle konfigurują również DNS z podziałem horyzontu , albo dlatego, że jest to wymagane przez ich konfigurację sieci i / lub ciągłość rozdzielczości w przypadku awarii usługi rozpoznawania / połączenia w górę.