Peringatan keamanan Outlook - Nama pada sertifikat keamanan tidak valid atau tidak cocok dengan nama situs


14

SBS 2008 menjalankan Exchange 2007 dan IIS6.0

CompanyA memiliki dua perusahaan lain yang beroperasi di bawah satu atap. Untuk mengakomodasi email, kami memiliki 3 akun Exchange per pengguna untuk mengelola ini. Semua pengguna menggunakan akun CompanyA mereka untuk masuk ke domain.

  • CORP \ user user@companyA.com
  • CORP \ user-companyb user@companyB.com <- hanya digunakan untuk email
  • CORP \ user-companyc user@companyC.com <- hanya digunakan untuk email

Email berfungsi dengan baik secara internal dan melalui OWA. Masalahnya ada ketika mengatur Outlook untuk pengguna jarak jauh yang membutuhkan akses ke email companyB dan companyC, Outlook muncul kesalahan sertifikat.

SSL sert SAN memiliki nama DNS berikut:

  • webmail.companyA.com
  • www.webmail.companyA.com
  • CORP-SBS
  • CORP-SBS.lokal
  • autdiscover.companyA.com

Saya diberitahu oleh pengguna yang mengakses alamat email companyC dari jarak jauh bahwa ini tidak pernah terjadi sebelumnya. Ini dimulai dengan CEO mengubah penyedia DNS sendiri dan dalam proses pengaturan DNS asli hilang. Dia menyebutkan sesuatu tentang catatan SRV yang dibuat yang memperbaiki masalah ini, tetapi hanya itu.

Mencari panduan tentang cara mengatasi hal ini dengan benar.

Jawaban:


25

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.comnamespace 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.comcatatan 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.comdalam 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.comzona (mengharuskan pengunjung ke situs web atau layanan lain untuk masuk www.companyB.com, atau setara; atau
    • Nonaktifkan akses ke mesin di companyB.compada port 443, menyebabkan Outlook menolak companyB.comURL sebelum sertifikat dipertukarkan dan melanjutkan; atau
    • Perbaiki sertifikat pada companyB.comuntuk memastikan companyB.comterdaftar pada sertifikat itu, dan bahwa upaya untuk mengunjungi https://companyB.comdi browser standar tidak gagal.

    Di atas berlaku terlepas dari apakah companyB.commemutuskan untuk Exchange Server; Jika Outlook dapat berkomunikasi dengannya, nanti akan menemukan bahwa /Autodiscover/Autodiscover.xmljalur 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.comtidak 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.comcatatan SRV sesuai dengan dokumentasi .
  • Hapus autodiscover.companyB.comcatatan 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.comseperti 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 .localdan 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-ClientAccessServercmdlet dengan -AutodiscoverServiceInternalUrisakelar. 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.


2
Tulisan yang bagus! Meskipun saya percaya bahwa pada bagian terakhir itu harus menjadi Service Connection Point (SCP) daripada Service Locator Point (SLP).
BlueCompute

@BlueCompute memang, Anda benar, saya sudah terlalu lama berada di System Center! (SLP dulu ada di SCCM 2007 dan melayani tujuan yang terkait jarak jauh dengan SCP). Diperbaiki di atas
Cosmic Ossifrage

Terima kasih atas penulisan lengkapnya! Saya baru saja memperhatikan bahwa autodiscover.companyA.com adalah catatan A dan bukan catatan CNAME. Apakah ini akan berdampak pada catatan SRV yang berfungsi dengan baik untuk companyB.com?
Mike66350216

1
Dukungan publik untuk catatan SRV masih agak kurang, bahkan di antara penyedia DNS. Kedengarannya seperti Anda sudah beres!
Cosmic Ossifrage

3
Saya hanya ingin menunjukkan bahwa tulisan Anda yang bagus + tautan berikut ini menyelesaikan masalah saya. superuser.com/questions/770308/… . Hanya ingin meninggalkan catatan ini di sini untuk siapa saja yang berada di kapal yang sama dengan saya.
James Watt

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.