• Cloud, Collaborazione, Microsoft 365, Sicurezza, Sistemi Operativi
• 26 Settembre 2021

Sentiamo parlare sempre più spesso di Exchange server e degli annessi servizi che quest’ultimo offre, nello specifico scambiando due chiacchiere con qualche Exchange Server Admin, avrete sentito parlare autodiscover e delle sue magiche doti di alleggerimento dello stress di Admin e utenti di Exchange Server. In questo post vogliamo vedere un po’ più da vicino l’autodiscover e snocciolare più nel dettaglio il suo funzionamento e i flussi che si creano tra client ed Exchange server.

Essere un Admin di Exchange Server è gratificante, ma a volte può risultare frustrante. Una delle fonti principali di questa frustrazione è la gestione delle interazioni tra gli Exchange Servers e il client Outlook. Storicamente, molti problemi derivanti dai client Outlook sono risultati di mismatch di configurazione tra impostazioni del profilo del client Outlook e la configurazione dell’Exchange server. In Exchange server 2007 Microsoft introduce un nuovo servizio chiamato Autodiscover, un componente appartenente al ruolo CAS (Client Access Server o Client Access Service da Exchange 2016 in poi), con lo scopo di permettere ai client (Outlook, Outlook Mobile, Windows Mobile & Co) e agli Exchange Server di trovare automaticamente le configurazioni dell’organizzazione di Exchange e di determinare dunque le proprie impostazioni adatte al proprio profilo.

Autodiscover è più della semplice semplificazione di configurazione dei profili sui client citati precedentemente. Gli altri Exchange presenti in un’organizzazione utilizzano autodiscover per le i configurazioni necessarie per poter comunicare con i loro colleghi Exchange sparsi in giro per l’organizzazione. Feature come “Calendar sharing”, o integrazione con “Lync/Skype for business” necessitano di avere una configurazione corretta dell’autodiscover.

Quali sono i benefici lato client e lato server?

Benefici dei client:

• Supporto a query di record A esterni: Di default, i client possono eseguire query sui DNS esterni su record A dedicato ad autodiscover
• Supporto a query di record SRV esterni: I record SRV vengono supportati per permettere ad organizzazioni che non desiderano pubblicare record A o CNAME.
• Supporto per oggetti SCP (Service Connection Point) in Active Directory: I client joinati a domini che possono contattare i domain controller, possono utilizzare questa feature definita “SCP” per trovare le URL dedicate ad Autodiscover.
• Impostazioni interne dell’Org: I servizi offerti da Exchange Server danno la possibilità di avere sia URL interne che URL esterne.
• Impostazioni esterne dell’Org: Le impostazioni esterne permettono ai servizi di Exchange di essere utilizzati tramite FQDN pubblicati esternamente. In alcuni scenari le organizzazioni preferiscono non pubblicare FQDN dedicati ai servizi accessibili dall’interno del perimetro aziendale.
• Localizzazione del mailbox server contenente la mailbox dell’utente: Nelle versioni precedenti di Exchange Server, il mailbox server era direttamente indicato nell’oggetto user in Active Directory tramite attributo “homeMTA”. Tuttavia, con le modifiche dell’architettura di Exchange iniziate con il 2013, outlook può connettersi a qualsiasi dei mailbox server presenti nell’organizzazione, i quali forniscono i servizi di Client Access Service “CAS” in un sito. La connessione è dunque STATELESS; in altre parole, non è necessaria più l’affinità, o persistenza se volete chiamarla come la chiamerebbe un bilanciatore. Questo cambiamento fa sì che l’Autodiscover diventi ancora più importante. Utilizzando il GUID della mailbox dell’utente più il nome del dominio ricavato dall’SMTP address, Outlook trova un “connection point” al mailbox server.
• Localizzazione dell’Offline Address Book (OAB): Le OAB vengono generate da una di quelle che vengono chiamate Arbitration Mailboxes, conosciuta come Organization mailbox (SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}). Questa arbitration mailbox crea il file che verrà consegnato dai Client Access Services (CAS) ai client outlook tramite protocollo HTTPS. In Exchange server 2010 e precedenti i client Outlook potevano ricevere il file dell’OAB tramite le public folder. La capacità di localizzare l’OAB è fondamentale per un client Outlook, questo perché quest’ultimo lavora in “cached mode” di default e fa affidamento all’OAB per fare le lookup necessarie sull’Address book. In questo scenario l’Autodiscover indica all’Outlook l’URL dell’OAB in modo da scaricare le modifiche del caso della GAL di Exchange. L’url dell’OAB, come anche altre URL degli Exchange Web Services possono potenzialmente essere modificate, dunque per questo motivo il client non contatta Autodiscover solo nella fase di configurazione del profilo, ma in intervalli di 60 minuti se la connessione va a buon fine, e in intervalli di 5 minuti se la connessione non va a buon fine.
• Configurazione Outlook Anywhere e Mapi Over Http: In fase di migrazione a Exchange 2016 i client Outlook possono utilizzare RPC/HTTPS (Outlook anywhere) o Mapi Over HTTP/HTTPS. Considerato che questi protocolli vengono incapsulati nell’HTTP viene da se comprendere che diventa fondamentale per i client avere un servizio come l’Autodiscover che gli fornisce gli url corretti ad ogni retry di query dall’esterno e dall’interno.

Benefici dei server:

• Gli Exchange server appartenenti alla stessa organizzazione e Foresta di Active Directory utilizzano Autodiscover per localizzare svariati servizi per conto dell’utente. Ad esempio, quando un utente effettua il login su OWA (Outlook sul web), il mailbox server responsabile della sessione del browser dell’utente necessità di diversi pezzettini di informazioni fornite dall’Autodiscover. L’utilizzo di Autodiscover riduce il carico sui domain controller e global catalog.
• Autodiscover diventa fondamentale per Exchange server appartenenti a foreste differenti di Active Directory, in questo scenario l’uso di Autodiscover diventa obbligatorio per permetter agli Exchange server di interagire correttamente.
• In scenari con Organizzazioni di Exchange Federate (ad esempio EXCH/EXO), autodiscover diventa fondamentale per permettere di raggiungere i servizi esposti dalle macchine delle organizzazioni federate. Questo oltre alle informazioni di autenticazione permetterà agli utenti il “calendar sharing”, “Free/Busy” etc.

Vediamo nel dettaglio il funzionamento di autodiscover

SCP (Service Connection Point)

Quando installate un nuovo CAS (Client Access Service) server, viene registrato un oggetto definito SCP (Service Connection Point) in Active Directory. L’SCP è un puntatore che associa uno o più endpoint (tramite URL o FQDN) con un particolare servizio e server. Eseguendo una query LDAP su Active directory un determinato software può ottenere una lista di tutti gli endpoint che offrono un ipotetico servizio. La figura sottostante vi illustra alcune delle proprietà associate all’SCP registrate quando l’Exchange è stato installato. L’attributo “ServiceBindingInformation” contiene l’URL o l’FQDN del server installato. Quando un client joinato a dominio riesce a “domandare” ad un Domain controller Global Catalog, si collegherà utilizzando le crenziali fornite dall’utente ed eseguirà la query dell’oggetto SCP.

Figura 1 – Autodiscover SCP Internal Network Flow

Figura 2 – SCP (Service Connection Point)

L’SCP può fare da riferimento per scenari Cross Forest, le URL fornite dagli SCP fungono essenzialmente da puntatori ai CAS ai quali i client possono connettersi per poi essere reindirizzati a qualsiasi Mailbox Server che può fornirgli l’accesso alla cassetta postale.

DNS Lookup

L’SCP viene utilizzato quando un client o server sono joinati in un dominio di Active Directory e possono “domandare” ai domain controller, possono dunque contattarli direttamente. Quando il lookup deve essere effettuato da client esterni o non joinati a dominio, viene utilizzato un altro meccanismo: il DNS Lookup.

Figura 3 – Autodiscover DNS internal flow

Figura 4 – Autodiscover DNS External Lookup flow

Andiamo nel dettaglio dei DNS Lookup effettuati dal servizio di autodiscover in un determinato dominio. In questo esempio utilizzeremo l’utente [email protected]. Il client (o server) prende la porzione del dominio dell’indirizzo (contoso.com) ed eseguire i seguenti lookup in sequenza fino a trovare un match:

1. Lookup di un record A (o CNAME) per contoso.com che punta ad un web server che risponderà con un URL HTTPS https://contoso.com/Autodiscover/Autodiscover.xml.
2. Lookup di un record A (o CNAME) per autodiscover.contoso.com che punta ad un web server che risponderà con un URL HTTPS https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml
3. Lookup di un record A (o CNAME) per contoso.com che punta ad un web server che risponderà con URL HTTP http://autodiscover.contoso.com/Autodiscover/Autodiscover.xml (se avete un reverse proxy o direttamente su Exchange, dovrete fare la configurazione necessaria per implementare l’http to https redirect)
4. Lookup di un record SRV per  autodiscover._tcp.contoso.com (Questo record deve contenere la porta 443 e l’hostname, ad esempio mail.contoso.com, permetendo cosi al client di fare una request in https all’URL https://mail.contoso.com/Autodiscover/Autodiscover.xml)

Esempio Step-by-Step

Lasciamo per un attimo da parte la teoria, vediamo un esempio pratico di una compagnia che possiede contoso.com: un client joinato in Active Directory con a bordo Outlook che tenta di utilizzare Autodiscover dietro al firewall aziendale. Per illustrare questo scenario utilizzeremo una funzionalità di Outlook ben nota a tutti gli Admin di Exchange Server, Outlook Test E-Mail Autoconfiguration. La cosa interessante di questo tool nello scenario delle query ad Autodiscover è l’output, ci vengono fornite infatti tutte le URL che l’Exchange server da in risposta al client Outlook dopo la query Autodiscover. Questo permetterà agli amministratori di verificare eventuali configurazioni errate sulle URL dei suoi Exchange Server.

Figura 5 – Log Email Autoconfiguration

Quando un client utilizza l’autodiscover segue questi step durante il processo:

1. Query LDAP su tutti gli oggetti SCP (Service Connection Point) in Active Directory, se joinato in Active directory e con possibilità di contattare direttamente i domain controller
2. DNS Lookup come precedentemente spiegato, se client esterno alla rete perimetrale aziendale o client non joinato a dominio
3. Una volta ottenuta l’URL corretta dall’attributo “ServiceBindingInformation” dell’oggetto SCP, il client si collega e riceve in risposta da Exchange un file XML (L’XML ricevuto potete vederlo direttamente dal Test E-mail AutoConfiguration di Outlook)

Figura 6 – Query LDAP su SCP object

Figura 7 – DNS Lookup con redirect su CAS Exchange Online

Facciamo alcune considerazioni in merito alle ultime “security research” pubblicate su Autodiscover

Iniziamo le nostre considerazioni direttamente con un caso di studio, l’utente Pippo è in possesso di un client Outlook e di un dominio in suo possesso (fabrikam365.it in questo caso). Questo dominio non è associato a nessuna organizzazione di Exchange e non c’è nessun record DNS interno o esterno che faccia riferimento ad autodiscover o Namespace di Exchange.

Come si comporterà Outlook (2019 in questo caso) nel momento in cui tento tramite “Test Email Autoconfiguration” a farmi dare da qualcuno l’XML (o qualsiasi altra cosa da un web server che ad esempio potrebbe chiedermi la basic auth come farebbe il servizio autodiscover di un Exchange On-premises qualsiasi)?

Figura 8 – Risultati tentativi Autodiscover client

Come vedete dall’immagine soprastante i tentativi effettuati sono i 4 tentativi di DNS Lookup che citavamo precedentemente:

1. DNS Lookup di un Record A che permetta di comporre l’URL https://fabrikam365.it/autodiscover/autodiscover.xml (root domain)
2. DNS Lookup di un Record A che permetta di comporre l’URL https://autodiscover.fabrikam365.it/autodiscover/autodiscover.xml
3. DNS Lookup di un Record A che permetta di comporre l’URL http://autodiscover.fabrikam365.it/autodiscover/autodiscover.xml (HTTP Redirect)
4. Lookup di un record SRV per  autodiscover._tcp.fabrikam365.it
   

Essendo Fabrikam365.it un dominio che non appartiene a nessuna Organizzazione di Exchange e che NON espone nessun record pubblico che faccia riferimento a servizi esposti da Exchange i risultati sono tutti FAILED.

Ma può dunque Outlook fare Lookup cambiando radicalmente il root domain che ricava dall’SMTP address fornito?

Figura 9 – Risultati Autodiscover Outlook

Se io dunque inserisco [email protected] , oltre ai DNS Lookup che avete visto nel paragrafo precedente, potrà mail fare Lookup ad esempio in direzione di https://autodiscover.com/autodiscover/autodiscover.xml ?

Come avrete già ampiamente intuito dalla lettura di questo articolo la risposta è NO, questo perché Outlook è stato disegnato per eseguire sempre e comunque i DNS Lookup che vi ho illustrato fino ad ora, oltre ovviamente alle query LDAP necessarie per individuare oggetti SCP in Active Directory.

Potremmo volendo comprare il dominio “autodiscover.it” (sempre se è libero) e fare in modo che autodiscover, in modo del tutto legittimo, vada a fare DNS Lookup in direzione di https://autodiscover.com/autodiscover/autodiscover.xml, probabilmente non è libero perché qualcuno potrebbe avere già testato questa soluzione.

CONCLUSIONI

Autodiscover da quando è stato introdotto ha sicuramente alleggerito di molto la vita degli amministratori di Exchange e dei loro utenti. Per poter sfruttare al meglio tutte le potenzialità offerte da questo servizio è necessario studiare, testare e conoscere il flusso che c’è tra client e server, solo in questo modo si potrà utilizzare al meglio. Augurandomi di avervi chiarito un po’ di più le idee lascio a voi le considerazioni in merito ai Lookup su “autodiscover.com”, “autodiscover.it” & CO o eventuali processi di “Back-Off” di autodiscover su Client Outlook.

Stay Tuned on ICTPower!!!