Alertă de securitate Outlook – Numele de pe certificatul de securitate nu este valid sau nu se potrivește cu numele site-ului (Administrarea sistemului, Ssl, Schimb, Outlook, Certificat)

Mike66350216 a intrebat.

SBS 2008 care rulează Exchange 2007 și IIS6.0

CompaniaA are alte două companii care operează sub același acoperiș. Pentru a găzdui e-mailul, avem 3 conturi Exchange pentru fiecare utilizator pentru a gestiona acest lucru. Toți utilizatorii își folosesc contul CompanyA pentru a se conecta la domeniu.

E-mailul funcționează bine pe plan intern și prin OWA. Problema există atunci când se configurează Outlook pentru utilizatorii de la distanță care au nevoie de acces la e-mailurile companieiB și companieiC, Outlook afișează o eroare de certificat.

Certificatul SSL SAN are următoarele nume DNS:

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

Utilizatorii care accesează de la distanță adresa de e-mail a companieiC mi-au spus că acest lucru nu se întâmpla niciodată înainte. Acest lucru a început odată cu schimbarea de către CEO a furnizorilor de DNS pe cont propriu și în acest proces s-au pierdut setările DNS originale. El a menționat ceva despre crearea unei înregistrări SRV care a corectat această problemă, dar cam atât.

Caut îndrumări cu privire la modul în care să rezolvăm în mod corespunzător acest lucru.

2 răspunsuri
Cosmic Ossifrage

Această problemă este cel mai probabil cauzată de Outlook’s Autodiscover care face parte din serviciul Outlook Anywhere de la Outlook Anywhere. Autodiscover furnizează diverse informații clientului Outlook al utilizatorului final cu privire la diversele servicii oferite de Exchange și unde pot fi localizate acestea; aceste informații sunt utilizate în diverse scopuri:

  • Autoconfigurarea profilurilor Outlook la prima rulare a Outlook, care poate configura un cont Exchange utilizând doar adresa de e-mail și parola utilizatorului, deoarece celelalte informații sunt localizate și recuperate automat.

  • Localizarea dinamică a serviciilor bazate pe web accesate de clientul Outlook, inclusiv a asistentului de out-of-office, a funcționalității de mesagerie unificată, a localizării panoului de control Exchange (ECP) și așa mai departe.

Aceasta este o implementare proprietară a Microsoft a RFC 6186. Din nefericire, aceștia nu au urmat cu adevărat recomandările acelui RFC în proiectarea Outlook Anywhere, dar acest lucru este poate de așteptat, deoarece Exchange și funcționalitatea RPC over HTTPS nu reprezintă un server IMAP/SMTP tradițional.


Cum funcționează Autodiscover (pentru utilizatorii externi*)?

Autodiscover comunică cu un serviciu web de pe un server de acces client (în acest caz, toate rolurile sunt pe serverul SBS) la calea /Autodiscover/Autodiscover.xml, , înrădăcinată de pe site-ul său web implicit. Pentru a localiza FQDN-ul serverului cu care trebuie să comunice, elimină partea de utilizator din adresa de e-mail, lăsând domeniul (de exemplu, @companyB.com). Încearcă să comunice cu Autodiscover folosind fiecare dintre următoarele URL-uri, pe rând:

  • https://companyB.com/Autodiscover/Autodiscover.xml
  • https://autodiscover.companyB.com/Autodiscover/Autodiscover.xml

Dacă acestea eșuează, va încerca o conexiune nesecurizată, dezactivând SSL și încercând să comunice pe portul 80 (HTTP), de obicei după ce solicită utilizatorului să confirme că aceasta este o acțiune acceptabilă (o opțiune greșită, în opinia mea, deoarece utilizatorii neștiutori vor aproba de obicei acest lucru și vor risca să trimită acreditările prin text simplu – iar administratorii de sistem neștiutori care nu cer o comunicare securizată a acreditărilor și a datelor sensibile pentru afaceri reprezintă un risc pentru continuitatea activității).

În cele din urmă, se face o verificare ulterioară cu ajutorul unei înregistrări de servicii (SRV) în DNS, care există într-o locație bine cunoscută în afara rețelei companyB.com spațiul de nume și poate redirecționa Outlook către URL-ul corespunzător unde serverul este ascultat.


Ce poate merge prost?

În acest proces poate apărea una dintre mai multe probleme:

Nu există înregistrări DNS

În mod obișnuit, rădăcina domeniului (companyB.com) s-ar putea să nu se rezolve la o înregistrare gazdă în DNS. O configurație DNS necorespunzătoare (sau o decizie conștientă de a nu expune serviciul Outlook Anywhere) ar putea însemna că autodiscover.companyB.com să nu existe nici înregistrarea

În aceste cazuri, nu există o problemă majoră; Outlook continuă pur și simplu să comunice cu Exchange utilizând ultima configurație cunoscută și poate fi degradat în ceea ce privește anumite funcții bazate pe web pentru care trebuie să recupereze URL-uri prin intermediul Autodiscover (cum ar fi asistentul de ieșire din birou). O soluție de rezolvare este utilizarea Outlook Web Access pentru a accesa astfel de funcții.

Configurarea automată a conturilor Exchange în noile profiluri Outlook nu este, de asemenea, automatizată și necesită configurarea manuală a setărilor RPC over HTTPS. Cu toate acestea, acest lucru nu va cauza problema pe care o descrieți.

Certificate SSL defecte

Este foarte posibil ca URL-ul pe care Outlook îl utilizează pentru a încerca să contacteze serverul Exchange să se rezolve la o gazdă, care poate fi sau nu un server de acces client. În cazul în care Outlook poate comunica cu acel server pe portul 443, se vor schimba, bineînțeles, certificate pentru a stabili un canal securizat între Outlook și serverul la distanță. În cazul în care URL-ul cu care Outlook crede că vorbește nu este listat pe acel certificat – fie că este vorba de numele comun sau de un nume alternativ al subiectului (SAN) – acest lucru va determina Outlook să prezinte dialogul pe care îl descrieți în mesajul inițial.

Acest lucru se poate întâmpla din mai multe motive, toate acestea depinzând de modul în care este configurat DNS și de modul în care URL-urile pe care le-am descris mai sus sunt verificate de Outlook:

  • În cazul în care https://companyB.com/… URL-ul se rezolvă la o înregistrare gazdă, și serverul web de la acea adresă ascultă pe portul 443, și are un certificat SSL care face nu enumeră companyB.com în numele comun sau în Subject Alternative Name, atunci va apărea problema. Nu contează dacă gazda este un server Exchange sau nu; poate fi vorba de un server web care găzduiește un site web al companiei și care nu este configurat corespunzător. Corrige fie:

    • Dezactivați înregistrarea gazdă la rădăcina serverului companyB.com zonă (solicitând vizitatorilor site-ului web sau altui serviciu să introducă www.companyB.com, , sau echivalent; fie
    • Dezactivați accesul la mașina de la companyB.com pe portul 443, ceea ce face ca Outlook să respingă companyB.com URL înainte de schimbul de certificate și să treacă mai departe; sau
    • Remediați certificatul la companyB.com pentru a vă asigura că companyB.com este listat pe acel certificat și că încercările de a vizita https://companyB.com într-un browser standard nu eșuează.

    Cele de mai sus se aplică indiferent dacă companyB.com se rezolvă la Exchange Server; dacă Outlook poate comunica cu acesta, va descoperi ulterior că certificatul /Autodiscover/Autodiscover.xml calea produce o eroare HTTP 404 (nu există) și va trece mai departe.

  • În cazul în care https://autodiscover.companyB.com/… URL-ul se rezolvă la Exchange Server (sau la orice alt server), dar, din nou, autodiscover.companyB.com nu este listată ca nume comun sau ca nume alternativ al subiectului, veți observa acest comportament. Acesta poate fi rezolvat ca mai sus prin repararea certificatului, sau așa cum ați indicat în mod corect, puteți utiliza un înregistrare SRV pentru a redirecționa Outlook către un URL care este listată pe certificat și pe care Outlook poate să comunice cu acesta.

Rezolvarea probabilă a acestei probleme

În acest caz, soluția tipică este de a face cea din urmă; creați înregistrări SRV în noul furnizor DNS pentru a vă asigura că Outlook este redirecționat către autodiscover.companyA.com, , care (lăsând la o parte orice alte probleme) va funcționa cu succes, deoarece este listat în certificat ca SAN. Pentru ca acest lucru să funcționeze, trebuie să:

  • Configurați un _autodiscover._tcp.companyB.com înregistrare SRV în conformitate cu documentația.
  • Să ștergeți înregistrarea autodiscover.companyB.com host record, dacă există, pentru a împiedica Outlook să rezolve această înregistrare și să încerce să ajungă la Autodiscover în acest mod.
  • Rezolvați, de asemenea, orice problemă cu accesul HTTPS la https://companyB.com ca mai sus, deoarece Outlook va enumera URL-urile derivate din adresa de e-mail a utilizatorului înainte de de a trece la abordarea înregistrării SRV.

*Cum funcționează Autodiscover (pentru clienții interni, conectați la un domeniu)?

Adaug acest lucru doar pentru a fi complet, deoarece este un alt motiv comun pentru care apar aceste solicitări de certificate.

La un client conectat la un domeniu, atunci când acesta este local la mediul Exchange (adică în LAN-ul intern), tehnicile de mai sus nu sunt utilizate. În schimb, Outlook comunică direct cu un Service Connection Point din Active Directory (listat în setările de acces la clientul Exchange), care enumeră URL-ul unde Outlook poate localiza serviciul Autodiscover.

Este obișnuit ca în aceste circumstanțe să apară avertismente de certificat, deoarece:

  • URL-ul implicit configurat în acest scop se referă la intern URL al Exchange, care este adesea diferit de URL-ul public.
  • Este posibil ca certificatele SSL să nu menționeze pe ele URL-ul intern. În prezent, al dvs. o face, dar acest lucru poate deveni o problemă în viitor pentru domeniile Active Directory care utilizează .local și sufixe de nume de domenii gTLD non-globale similare, deoarece o decizie a ICANN interzice emiterea de certificate SSL pentru astfel de domenii după 2016.
  • Este posibil ca adresa internă să nu se rezolve la serverul corespunzător.

În acest caz, problema se rezolvă prin corectarea URL-ului înregistrat pentru a se referi la adresa externă corectă, externă (listată în certificat), prin rularea comenzii Set-ClientAccessServer cmdlet cu opțiunea -AutodiscoverServiceInternalUri switch. Părțile care fac acest lucru configurează de obicei și split-horizon DNS, , fie pentru că sunt obligate să facă acest lucru de configurația rețelei lor și/sau pentru continuitatea rezoluției în cazul unei întreruperi a rezolvării/conexiunii în amonte.

Comentarii

  • Excelent articol! Deși cred că în ultima secțiune ar trebui să fie „Service Connection Point (SCP)” și nu „Service Locator Point (SLP)”. –  > Por BlueCompute.
  • @BlueCompute într-adevăr, ai dreptate, am stat prea mult timp cu capul în țara System Center în ultima vreme! (SLP-urile existau în SCCM 2007 și aveau un scop legat de la distanță de SCP). Fixat în cele de mai sus –  > Por Cosmic Ossifrage.
  • Vă mulțumim pentru scrierea amănunțită! Tocmai am observat că autodiscover.companyA.com este o înregistrare A și nu o înregistrare CNAME. Va avea acest lucru vreun impact asupra funcționării corecte a înregistrării SRV pentru companiaB.com? –  > Por Mike66350216.
  • Suportul public pentru înregistrările SRV este încă puțin deficitar, chiar și în rândul furnizorilor de DNS. Totuși, se pare că ați rezolvat problema! –  > Por Cosmic Ossifrage.
  • Vreau doar să subliniez că minunata ta scriere + următorul link mi-a rezolvat problema. superuser.com/questions/770308/…. Am vrut doar să las această notă aici pentru oricine care a fost în aceeași barcă ca și mine. –  > Por James Watt.
joeqwerty

Trebuie să creați o înregistrare SRV în domeniile B și C care să se potrivească cu unul dintre numele din cert (autodiscover.companyA.com). Acest lucru îi spune lui Outlook că acel nume se ocupă de autodescoperire pentru Domeniile B și C.

Citiți aici secțiunea privind înregistrările SRV în DNS:

https://jaapwesselius.com/2011/08/28/autodiscover-redirect-srv-record/

Comentarii

  • Linkul este rupt… –  > Por Eu zic să o reintroducem pe Monica.
  • @Twisty A reparat linkul. –  > Por Alexander Gonchiy.