Masalah ini kemungkinan besar disebabkan oleh layanan Autodiscover Outlook , bagian dari fungsionalitas Outlook Anywhere . Autodiscover menyediakan berbagai informasi kepada klien Outlook pengguna akhir tentang berbagai layanan yang ditawarkan oleh Exchange dan di mana ini dapat ditemukan; ini digunakan untuk berbagai keperluan:
Konfigurasi otomatis profil Outlook saat Outlook dijalankan pertama kali, yang dapat mengonfigurasi akun Exchange hanya menggunakan alamat email dan kata sandi pengguna, karena informasi lain secara otomatis ditemukan dan diambil.
Lokasi dinamis layanan berbasis web diakses oleh klien Outlook, termasuk asisten di luar kantor, fungsionalitas Perpesanan Bersatu, lokasi Exchange Control Panel (ECP) dan sebagainya.
Ini adalah implementasi RFC 6186 milik Microsoft . Sayangnya, mereka tidak benar-benar mengikuti rekomendasi RFC dalam desain Outlook Anywhere, tetapi itu mungkin diharapkan karena Exchange dan RPC melalui fungsi HTTPS bukan server IMAP / SMTP tradisional.
Bagaimana cara kerja Autodiscover (untuk pengguna * eksternal)?
Autodiscover berkomunikasi dengan layanan web di Client Access Server (dalam hal ini, semua peran ada di server SBS) di jalur /Autodiscover/Autodiscover.xml
, di-root dari situs web standarnya. Untuk mencari FQDN dari server untuk berkomunikasi, itu menghapus bagian pengguna dari alamat email, meninggalkan domain (yaitu @ companyB.com). Ia mencoba untuk berkomunikasi dengan Autodiscover menggunakan masing-masing URL berikut, pada gilirannya:
https://companyB.com/Autodiscover/Autodiscover.xml
https://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
Jika gagal, itu akan mencoba koneksi yang tidak aman dengan menonaktifkan SSL dan mencoba untuk berkomunikasi pada port 80 (HTTP), biasanya setelah meminta pengguna untuk mengkonfirmasi ini adalah tindakan yang dapat diterima (pilihan yang cacat menurut saya, karena pengguna yang tidak mengerti akan biasanya menyetujui ini dan berisiko mengirimkan kredensial atas teks biasa - dan sysadmin yang tidak mengerti yang tidak memerlukan komunikasi aman dari kredensial dan data sensitif bisnis adalah risiko bagi kelangsungan bisnis).
Akhirnya, pemeriksaan lanjutan dibuat menggunakan catatan layanan (SRV) dalam DNS, yang ada di lokasi yang terkenal dari companyB.com
namespace dan dapat mengarahkan Outlook ke URL yang tepat di mana server mendengarkan.
Apa yang salah?
Salah satu dari beberapa masalah dapat muncul dalam proses ini:
Tidak ada entri DNS
Biasanya, root dari domain ( companyB.com
) mungkin tidak menyelesaikan ke catatan host di DNS. Konfigurasi DNS yang tidak benar (atau keputusan sadar untuk tidak mengekspos layanan Outlook Anywhere) mungkin berarti autodiscover.companyB.com
catatan juga tidak ada.
Dalam kasus ini, tidak ada masalah besar; Outlook terus berkomunikasi dengan Exchange menggunakan konfigurasi yang terakhir diketahui, dan mungkin terdegradasi sehubungan dengan fungsi berbasis web tertentu yang diperlukan untuk mengambil URL melalui Autodiscover (seperti asisten di luar kantor). Solusinya adalah menggunakan Outlook Web Access untuk mengakses fungsi-fungsi tersebut.
Konfigurasi otomatis akun Exchange di profil Outlook baru juga tidak otomatis, dan memerlukan konfigurasi manual pengaturan RPC melalui HTTPS. Namun, ini tidak akan menyebabkan masalah yang Anda gambarkan.
Sertifikat SSL salah
Sangat mungkin bahwa URL Outlook digunakan untuk mencoba menghubungi server Exchange yang diselesaikan ke host, yang mungkin atau mungkin bukan Server Akses Klien. Jika Outlook dapat berkomunikasi dengan server itu pada port 443, tentu saja sertifikat akan ditukar untuk mengatur saluran aman antara Outlook dan server jarak jauh. Jika URL Outlook meyakini bahwa yang dibicarakannya tidak terdaftar pada sertifikat itu - baik itu sebagai nama umum atau nama alternatif subjek (SAN) - ini akan mendatangkan Outlook untuk menyajikan dialog yang Anda jelaskan di posting awal Anda.
Ini bisa terjadi karena beberapa alasan, semuanya ke bagaimana DNS dikonfigurasi dan bagaimana URL yang saya jelaskan di atas diperiksa oleh Outlook:
Jika https://companyB.com/
... URL dipecahkan menjadi catatan host, dan server web di alamat itu mendengarkan pada port 443, dan memiliki sertifikat SSL yang tidak tercantum companyB.com
dalam nama umum atau Nama Alternatif Subjek, maka masalah akan muncul. Tidak masalah apakah tuan rumah adalah Exchange Server atau tidak; mungkin server web hosting situs web perusahaan yang tidak dikonfigurasi dengan benar. Corrige :
- Nonaktifkan catatan host di root
companyB.com
zona (mengharuskan pengunjung ke situs web atau layanan lain untuk masuk www.companyB.com
, atau setara; atau
- Nonaktifkan akses ke mesin di
companyB.com
pada port 443, menyebabkan Outlook menolak companyB.com
URL sebelum sertifikat dipertukarkan dan melanjutkan; atau
- Perbaiki sertifikat pada
companyB.com
untuk memastikan companyB.com
terdaftar pada sertifikat itu, dan bahwa upaya untuk mengunjungi https://companyB.com
di browser standar tidak gagal.
Di atas berlaku terlepas dari apakah companyB.com
memutuskan untuk Exchange Server; Jika Outlook dapat berkomunikasi dengannya, nanti akan menemukan bahwa /Autodiscover/Autodiscover.xml
jalur menghasilkan kesalahan HTTP 404 (tidak ada) dan melanjutkan.
Jika https://autodiscover.companyB.com/
... URL diselesaikan ke Exchange Server (atau server lain) tetapi, sekali lagi, autodiscover.companyB.com
tidak terdaftar sebagai nama umum atau nama alternatif subjek, Anda akan mengamati perilaku ini. Hal ini dapat diperbaiki seperti di atas dengan memperbaiki sertifikat, atau seperti yang Anda benar menunjukkan, Anda dapat menggunakan data SRV untuk mengarahkan Outlook ke URL yang adalah terdaftar pada sertifikat dan yang Outlook dapat berkomunikasi dengan.
Kemungkinan perbaikan Anda untuk masalah ini
Dalam hal ini, perbaikan tipikal adalah melakukan yang terakhir; membuat catatan SRV di penyedia DNS baru untuk memastikan Outlook dialihkan ke autodiscover.companyA.com
, yang (selain masalah lainnya) akan berhasil karena terdaftar di sertifikat sebagai SAN. Agar ini berfungsi, Anda perlu:
- Konfigurasikan
_autodiscover._tcp.companyB.com
catatan SRV sesuai dengan dokumentasi .
- Hapus
autodiscover.companyB.com
catatan host, jika ada, untuk mencegah Outlook menyelesaikan ini dan berusaha mencapai Autodiscover dengan cara itu.
- Juga atasi masalah apa pun dengan akses HTTPS
https://companyB.com
seperti di atas, karena Outlook akan menghitung URL yang berasal dari alamat email pengguna sebelum jatuh ke pendekatan catatan SRV.
* Bagaimana cara kerja Autodiscover (untuk klien internal yang bergabung dengan domain)?
Saya menambahkan ini hanya untuk kelengkapan, karena ini adalah alasan umum lainnya untuk munculnya sertifikat ini.
Pada klien yang bergabung dengan domain, saat lokal ke lingkungan Exchange (yaitu pada LAN internal), teknik di atas tidak digunakan. Sebagai gantinya, Outlook berkomunikasi secara langsung dengan Titik Sambungan Layanan di Direktori Aktif (terdaftar dalam pengaturan Akses Klien Exchange), yang mencantumkan URL tempat Outlook dapat menemukan layanan Autodiscover.
Biasanya peringatan sertifikat terjadi dalam keadaan ini, karena:
- URL default yang dikonfigurasi untuk tujuan ini merujuk ke URL internal Exchange, yang sering berbeda dari URL publik.
- Sertifikat SSL mungkin tidak mencantumkan URL internal di dalamnya. Saat ini, Anda memilikinya, tetapi ini dapat menjadi masalah di masa depan untuk domain Direktori Aktif yang menggunakan
.local
dan akhiran nama domain gTLD non-global yang serupa, karena keputusan oleh ICANN melarang sertifikat SSL untuk domain tersebut yang dikeluarkan pasca-2016.
- Alamat internal mungkin tidak menyelesaikan ke server yang tepat.
Dalam hal ini, masalah diselesaikan dengan mengoreksi URL yang direkam untuk merujuk ke alamat eksternal yang tepat (tercantum dalam sertifikat), dengan menjalankan Set-ClientAccessServer
cmdlet dengan -AutodiscoverServiceInternalUri
sakelar. Pihak yang melakukan ini biasanya juga mengkonfigurasi DNS split-horizon , baik karena mereka diharuskan untuk melakukannya dengan konfigurasi jaringan mereka dan / atau untuk kesinambungan resolusi dalam hal pemadaman hulu penyelesai / koneksi terputus.