Molto probabilmente questo problema è causato dal servizio di individuazione automatica di Outlook , parte della funzionalità Outlook via Internet . La funzione di individuazione automatica fornisce varie informazioni al client Outlook dell'utente finale sui vari servizi offerti da Exchange e su dove possono trovarsi; questo viene utilizzato per vari scopi:
Configurazione automatica dei profili di Outlook alla prima esecuzione di Outlook, che può configurare un account Exchange utilizzando solo l'indirizzo e-mail e la password dell'utente, poiché le altre informazioni vengono automaticamente individuate e recuperate.
Posizione dinamica dei servizi basati sul Web a cui accede il client Outlook, incluso l'assistente fuori sede, la funzionalità di messaggistica unificata, la posizione del Pannello di controllo di Exchange (ECP) e così via.
Questa è l'implementazione proprietaria di Microsoft di RFC 6186 . Sfortunatamente, in realtà non hanno seguito le raccomandazioni di tale RFC nella progettazione di Outlook via Internet, ma forse è prevedibile poiché la funzionalità Exchange e RPC su HTTPS non è un server IMAP / SMTP tradizionale.
Come funziona l'individuazione automatica (per utenti esterni *)?
L'individuazione automatica comunica con un servizio Web su un server Accesso client (in questo caso, tutti i ruoli si trovano sul server SBS) nel percorso /Autodiscover/Autodiscover.xml, sradicato dal sito Web predefinito. Per individuare il nome FQDN del server con cui comunicare, rimuove la parte dell'utente dell'indirizzo e-mail, lasciando il dominio (es. @ CompanyB.com). Tenta di comunicare con l'individuazione automatica utilizzando ciascuno dei seguenti URL, a sua volta:
https://companyB.com/Autodiscover/Autodiscover.xmlhttps://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
Se questi falliscono, tenterà una connessione non sicura disabilitando SSL e tentando di comunicare sulla porta 80 (HTTP), in genere dopo aver chiesto all'utente di confermare che si tratta di un'azione accettabile (un'opzione difettosa a mio avviso, poiché gli utenti che non sanno nulla in genere lo approvano e rischiano di inviare credenziali tramite testo normale e gli amministratori di sistema che non necessitano di comunicazione sicura di credenziali e dati sensibili per il business rappresentano un rischio per la continuità aziendale).
Infine, viene eseguito un controllo successivo utilizzando un record di servizio (SRV) nel DNS, che esiste in una posizione ben nota fuori dallo companyB.comspazio dei nomi e può reindirizzare Outlook all'URL corretto in cui il server è in ascolto.
Cosa può andare storto?
In questo processo possono sorgere una serie di problemi:
Nessuna voce DNS
In genere, la radice del dominio ( companyB.com) potrebbe non risolversi in un record host nel DNS. Una configurazione DNS errata (o una decisione consapevole di non esporre il servizio Outlook via Internet) potrebbe significare che il autodiscover.companyB.comrecord non esiste.
In questi casi, non vi è alcun problema rilevante; Outlook continua semplicemente a comunicare con Exchange utilizzando l'ultima configurazione nota e potrebbe essere degradato rispetto ad alcune funzioni basate sul Web per le quali è necessario recuperare gli URL tramite l'individuazione automatica (come l'assistente fuori sede). Una soluzione alternativa consiste nell'utilizzare Outlook Web Access per accedere a tali funzioni.
Anche la configurazione automatica degli account Exchange nei nuovi profili di Outlook non è automatizzata e richiede la configurazione manuale delle impostazioni RPC su HTTPS. Tuttavia, ciò non causerà il problema descritto.
Certificati SSL difettosi
È del tutto possibile che l'URL di Outlook utilizzato per tentare di contattare Exchange Server si risolva in un host, che può essere o meno un server Accesso client. Se Outlook è in grado di comunicare con quel server sulla porta 443, i certificati verranno ovviamente scambiati per impostare un canale sicuro tra Outlook e il server remoto. Se l'URL di Outlook ritiene che stia parlando non è elencato in quel certificato - sia esso il nome comune o un nome alternativo soggetto (SAN) - questo solleciterà Outlook a presentare la finestra di dialogo che descrivi nel tuo post iniziale.
Questo può accadere per diversi motivi, tutti in base alla configurazione del DNS e al modo in cui gli URL sopra descritti vengono controllati da Outlook:
Se l' https://companyB.com/URL ... si risolve in un record host e il server Web a quell'indirizzo è in ascolto sulla porta 443 e dispone di un certificato SSL che non è elencato companyB.comnel nome comune o nel Nome alternativo soggetto, il problema si verificherà. Non importa se l'host è un Exchange Server oppure no; potrebbe essere un server Web che ospita un sito Web aziendale che non è configurato correttamente. Corrige o:
- Disabilitare il record dell'host nella radice della
companyB.comzona (richiedendo l'accesso ai visitatori del sito Web o di altro servizio www.companyB.como equivalente; oppure
- Disabilitare l'accesso alla macchina
companyB.comsulla porta 443, facendo sì che Outlook rifiuti l' companyB.comURL prima che vengano scambiati e proseguiti i certificati; o
- Correggere il certificato
companyB.comper assicurarsi che companyB.comsia elencato su quel certificato e che i tentativi di visita https://companyB.comin un browser standard non falliscano.
Quanto sopra si applica indipendentemente dal fatto che si companyB.comrisolva in Exchange Server; se Outlook può comunicare con esso, in seguito scoprirà che il /Autodiscover/Autodiscover.xmlpercorso genera un errore HTTP 404 (non esiste) e proseguirà.
Se l' https://autodiscover.companyB.com/URL ... si risolve in Exchange Server (o in qualsiasi altro server) ma, di nuovo, autodiscover.companyB.comnon è elencato come nome comune o nome alternativo soggetto, si osserverà questo comportamento. Può essere fissato come sopra fissando il certificato, o come ha giustamente indica, è possibile utilizzare un record SRV per reindirizzare Outlook a un URL, che è quotata al certificato e che Outlook può comunicare.
La tua probabile soluzione a questo problema
In questo caso, la soluzione tipica è quella di eseguire quest'ultima; creare record SRV nel nuovo provider DNS per garantire il reindirizzamento di Outlook autodiscover.companyA.com, che (a parte eventuali altri problemi) funzionerà correttamente poiché è elencato nel certificato come SAN. Perché questo funzioni, è necessario:
- Configurare un
_autodiscover._tcp.companyB.comrecord SRV in conformità con la documentazione .
- Eliminare il
autodiscover.companyB.comrecord host, se esiste, per impedire a Outlook di risolvere questo problema e tentare di raggiungere l'individuazione automatica in quel modo.
- Risolvi anche eventuali problemi con l'accesso HTTPS
https://companyB.comcome sopra, poiché Outlook enumera gli URL derivati dall'indirizzo e-mail dell'utente prima di passare all'approccio record SRV.
* Come funziona l'individuazione automatica (per client interni, aggiunti al dominio)?
Lo aggiungo solo per completezza, poiché è un altro motivo comune per cui si verificano queste richieste di certificato.
Su un client aggiunto al dominio, quando è locale all'ambiente Exchange (ovvero sulla LAN interna), le tecniche sopra descritte non vengono utilizzate. Invece, Outlook comunica direttamente con un punto di connessione del servizio in Active Directory (elencato nelle impostazioni di Accesso client di Exchange), che elenca l'URL in cui Outlook può individuare il servizio di individuazione automatica.
È comune che si verifichino avvisi di certificato in queste circostanze, perché:
- L'URL predefinito configurato a questo scopo si riferisce all'URL interno di Exchange, che è spesso diverso dall'URL pubblico.
- I certificati SSL potrebbero non elencare l'URL interno su di essi. Al momento, il tuo sì, ma questo potrebbe diventare un problema in futuro per i domini Active Directory che utilizzano
.locale suffissi di nomi di dominio gTLD non globali simili, dal momento che una decisione dell'ICANN proibisce l'emissione di certificati SSL per tali domini dopo il 2016.
- L'indirizzo interno potrebbe non essere risolto nel server corretto.
In questo caso, la questione viene risolta correggendo l'URL registrato per fare riferimento all'indirizzo esterno appropriato (elencato nel certificato), eseguendo il Set-ClientAccessServercmdlet con lo -AutodiscoverServiceInternalUriswitch. Le parti che eseguono questa operazione in genere configurano anche DNS split-horizon , sia perché sono tenuti a farlo dalla loro configurazione di rete e / o per la continuità della risoluzione in caso di interruzione del risolutore / connessione a monte.