Exchange Server – Configurazione Hybrid Modern Authentication (HMA)

Modern Authentication è un metodo di gestione delle identità che porta con se meccanismi di autenticazione e autorizzazione molto più sicuri e adatti a quello che è ora il nuovo perimetro della strategia di sicurezza informatica dell’azienda, l’identità utente. E’ possibile abilitare Modern Authentication per S4B ed Exchange Server in scenari ibridi con Microsoft 365.

Modern Authentication è un termine coniato con l’obiettivo di definire un’insieme di metodi di autenticazione e autorizzazione, tra client (ad esempio il vostro laptop, o il vostro dispositivo mobile) e server. Oltre ai metodi di autenticazione e autorizzazione Modern Authentication contiene una serie di misure di sicurezza basate su Access Policies, con le quali potreste già avere avuto a che fare.

In questo post di blog verranno utilizzate le seguenti abbreviazioni:

• HMA = Hybrid Modern Authentication
• EXCH = Exchange On-Premises
• EXO = Exchange Online
• S4B = Skype For Business On-Premises
• evoSTS = Security Token Service utilizzato da Azure Active Directory

Modern Authentication include:

• Metodi di Autenticazione: Multi-Factor authentication (MFA); smart card authentication; client certificate-based authentication
• Metodi di Autorizzazione: Implementazione di Microsoft del protocollo OAuth (Open Authorization)
• Policies di Conditional Access : Mobile Application Management (MAM) ed Azure Active Directory (Azure AD) Conditional Access

Gli amministratori di Sistema tramite la Modern Authentication avranno differenti tool a disposizione per la gestione delle identità e delle modalità di accesso alle risorse, in scenari On-Premises e ibridi per S4B ed Exchange Server.

Cosa cambierà nel flusso di autenticazione?

Quando si utilizza la Modern Authentication con S4B o EXCH, la prima fase di Autenticazione degli utenti verrà ancora effettuata utilizzando l’infrastruttura On-Premises, ciò che cambierà è la fase di Autorizzazione all’accesso alle risorse (es. file, email). Se ad esempio un client di S4B dovesse avere la necessità di accedere alle informazioni del calendario di una mailbox presente su EXCH per conto di un utente, il client di S4B utilizzerà Active Directory Authentication Library (ADAL). ADAL ha il compito di mettere al sicuro le risorse della directory tramite i token oAuth. In questo processo vengono verificati i claim(attributi) passati nel processo di autenticazione dall’utente, avviene lo scambio dei token (o password) che permetteranno infine all’utente di accedere alla risorsa richiesta. In passato, l’autorità in una transazione come questa poteva essere ad esempio Active Directory Federation Services. Modern Authentication centralizzerà questa “autorità” su Azure Active Directory.

Viene da se comprendere che sarà strettamente necessario che le macchine che ospiteranno S4B o EXCH dovranno avere la capacità di stabilire e mantenere una sessione in outbound con Azure Active Directory.

Questa centralizzazione dell’autorità su Azure Active Directory, come ben immaginate porterà enormi benefici alla vostra strategia di gestione dell’identità come nuovo perimetro di sicurezza, portando tutti i metodi di autenticazione “strong” presenti in cloud anche sui Workload che ospitate in casa.

Prerequisiti Exchange Server

Come detto precedentemente, la Modern Authentication cambia il server responsabile dell’autorizzazione utilizzato con OAuth, per questo motivo la prima cosa che dovrete fare è verificare la configurazione a livello di Organizzazione dell’OAuth, per farlo potete eseguire la seguente CMDLET:

Get-OrganizationConfig | ft OAuth*

Se il valore del parametro “OAuth2ClientProfileEnabled” sarà uguale a “False” allora vorrà dire che non avete abilitato Modern Authentication nella vostra Organizzazione.

• • Prerequisiti EXCH:
    • E’ necessario avere a disposizione Exchange server 2013 CU19 in su, Exchange server 2016 CU8 in su o Exchange server 2019 CU1 in su.
    • NON devono essere presenti Exchange 2010 nell’Organizzazione
    • NON è supportato l’SSL Offloading. È supportato terminare l’SSL su reverse proxy per poi consegnare i pacchetti dopo averli crittografati nuovamente.

• Prerequisiti EXCH in hybrid environment:
  • • In caso di EXCH 2013 è consigliato avere almeno una macchina con ruolo CAS e Mailbox installati
    • In caso di EXCH 2016 o 2019, almeno un server deve avere il mailbox role installato
    • NON devono esserci Exchange Server 2007 o 2010 presenti nell’Organizzazione ibridata con EXO
    • TUTTE le macchine con a bordo Exchange Server dovranno avere le ultime CU installate, fate un check nella lista di Cumulative Updates per EXCH e perché no, date un’occhiata anche all’Assistant Online, quest’ultimo eliminerà i tanti dubbi che avrete sul processo decisionale in fase di installazione delle Cumulative Updates.

• Prerequisiti EXCH clients e protocolli:

La possibilità di utilizzare HMA dipenderà e sarà determinata anche dalla combinazione di versioning del client, protocollo utilizzato e configurazione. Nel caso in cui HMA non sia supportata dal client, protocollo e/o dalla configurazione, l’utente continuerà ad utilizzare auntenticazione legacy.

I seguenti client e protocolli supportano HMA:

Clients	Protocollo	Note
Outlook 2013 e successivi	MAPI/http	Mapi over HTTP deve essere abilitato nell’organizzazione di EXCH. Per maggiori informazioni su MAPI/http vi rimando all’articolo scritto precedentemente su Technical 365 qui.
Outlook 2016 e successivi	EXCH Web Services
Outlook per IOS e ANDROID	Microsoft Sync Technology	E’ fortemente consigliato utilizzare Outlook per IOS o ANDROID per usufruire al massimo delle funzionalità offerte dai Workload ospitati su Microsoft 365.
EXCH ActiveSync clients (IOS11 MAIL, SAMSUNG MAIL etc)	Exchange ActiveSync	Nel caso in cui stiate utilizzando uno dei client delle case madri del vostro mobile, dovrete ricreare il profilo in modo da poter switchare dalla Basic Auth ad HMA

I client e/o protocolli che non trovate nella tabella soprastante (es. POP3) non supportano HMA con workload On-Premises, continuano dunque ad utilizzare protocolli legacy anche se HMA è abilitata a livello di Organizzazione.

• Prerequisiti Infrastrutturali:
  • Scenari con Foreste di Risorse e Account separate, avranno necessità di eseguire una trust bidirezionale tra le foreste, questo per permettere che vengano effettuati i lookup del caso dei SID durante le richieste di HMA.
  • Se utilizzate AD FS, dovrete utilizzare ADFS 3.0 in su, quindi Windows 2012R2 in su
  • La tipologia di autenticazione in ambiente ibrido può essere una delle seguenti:
    • Password Hash sync
    • Pass-through authentication
    • On-Premises STS (Federazione con ADFS)
  • Le identità devono essere sincronizzate tramite Azure AD Connect
  • L’organizzazione di EXCH deve essere ibridata in modalità CLASSIC HYBRID TOPOLOGY con EXO, HMA non supporta la Modern Hybrid Topology

Step abilitazione HMA su EXCH:

• Prima di cominciare assicuratevi di aver soddisfatto tutti i prerequisiti descritti precedentemente
• Sarà necessario aggiungere le URL configurate sulle virtual directory di EXCH come Service Principal Names (SPNs) su Azure Active Directory.
• Sarà necessario assicurarsi che le virtual directory di EXCH siano abilitate per HMA
• Dovremo fare il check dell’oggetto evoSTS Auth Server su EXCH
• Procederemo infine con l’abilitazione di HMA su Exchange Server

Check OAuth Organizzazione

Get-OrganizationConfig | ft OAuth*

Per fare il check di tutte le URL utilizzate sulle virtual directory di EXCH potete sfruttare la lista di CMDLET sottostante, queste URL verranno aggiunte come SPN (Service Principal Name) su Azure AD. Infine, gli SPN saranno utilizzati nel processo di autenticazione e autorizzazione da utenti e client. Dunque, tutte le URL (internal ed external) che possono potenzialmente essere utilizzate sulle virtual directory di EXCH devono essere registrate come SPN su Azure AD.

Get-MapiVirtualDirectory | FL server,*url*

Get-WebServicesVirtualDirectory | FL server,*url*

Get-ClientAccessService | FL Name, AutodiscoverServiceInternalUri

Get-OABVirtualDirectory | FL server,*url*

Get-AutodiscoverVirtualDirectory | FL server,*url*

Get-OutlookAnywhere | FL server,*hostname*

Figure 1 – Esempio Configurazione virtual directories Default Website Exchange

Assicuriamoci ora che tutte le URL che sono state date in output dalle precedenti CMDLET siano presenti come SPN su Azure AD.

1. 1. Per fare ciò dovrete prima collegarvi in powershell a Microsoft 365, tramite il modulo “MSOnline” che andrà scaricato dalla PowershellGallery e installato se già non lo avete fatto in passato, utilizzando i seguenti CMDLET:

Install-Module MSOnline

Connect-MsolService

1. Per fare il check degli SPN che interessano a EXO ed EXCH eseguite il seguente comando:

Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames

Figure 2 – Esempio Output SPN

Come vedete nell’immagine soprastante nel mio caso è presente solo il namespace principale dell’organizzazione, manca evidentemente l’FQDN dedicato all’autodiscover (cname record pubblicato sia internamente che esternamente). Vediamo come aggiungere l’SPN dedicato ad Autodiscover.

1. Su EXCH potete potenzialmente utilizzare hostname differenti per mapi, owa etc.. Se uno di questi URL manca tra gli SPN che avete visto nell’output del comando precendente, potrete aggiungerlo, sempre tramite powershell e modulo “MSOnline”, utilizzando i seguenti comandi:

$x= Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000

$x.ServicePrincipalnames.Add("https://mail.corp.contoso.com/")

$x.ServicePrincipalnames.Add("https://owa.contoso.com/")

Set-MSOLServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 -ServicePrincipalNames $x.ServicePrincipalNames

Figure 3 – Aggiunta SPN Autodiscover

Dopo avere aggiunto l’SPN che ci mancava, “autodiscover.contoso.com”, procediamo con la verifica dell’abilitazione dell’OAuth su tutte le vDir:

Get-MapiVirtualDirectory | FL server,*url*,*auth*

Get-WebServicesVirtualDirectory | FL server,*url*,*oauth*

Get-OABVirtualDirectory | FL server,*url*,*oauth*

Get-AutoDiscoverVirtualDirectory | FL server,*oauth*

Figure 4 – Esempio configurazione OAuth sulle virtual directory interessate

Verifichiamo che l’oggetto evoSTS (Security Token Service) sia presente nella nostra Organizzazione On-Premises:

Get-AuthServer | where {$_.Name -like "EvoSts*"} | ft name,enabled

Figure 5 – evoSTS check utilizzando EMS On-Premises

NB: Nel caso in cui siate in uno scenario “singola Organizzazione On-Premises” ibridata con più Tenant di M365, troverete in output tanti oggetti evoSTS quanti i tenant con cui avete ibridato la vostra Organizzazione On-Premises , ciascuno con GUID differente. Se invece siete in uno scenario con EXCH 2010, l’evoSTS Authentication Provider non verrà creato e non riceverete nulla in output.

Abilitazione di HMA tramite EMS di EXCH

Set-AuthServer -Identity "EvoSTS - <GUID>" -IsDefaultAuthorizationEndpoint $true

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Figure 6 – Esempio abilitazione HMA e verifica evoSTS auth server

Verifica configurazione HMA da Connection Status Outlook (Pre e Post abilitazione)

Figure 7 – Connection Status Outlook Pre abilitazione HMA

Come vedete nell’immagine soprastante, il tipo di autenticazione utilizzato è “Negotiate”, modalità che sceglie automaticamente NTLM o Kerberos Auth. Se Kerberos auth è abilitato e disponibile viene utilizzato, in alternativa il client usufruirà dell’NTLM.

Figure 8 – Connection Status Outlook Post abilitazione HMA

Dopo l’abilitazione dell’HMA outlook utilizzerà la modern authentication, come vedete ora nella colonna “Authn” trovate “Bearer*”.

La Bearer Auth (autenticazione del portatore, chiamata anche autenticazione del token) è uno schema di autenticazione HTTP che coinvolge token di sicurezza chiamati “Bearer”. Il nome “Autenticazione del portatore” può essere inteso come “concedere l’accesso al portatore di questo token”. Il token Bearer può essere una stringa criptata o un JWT (JSON Web based Token), generalmente generata dal server in risposta a una richiesta di accesso. Il client deve inviare questo token nell’intestazione di Authorization quando effettua richieste a risorse protette. Notate bene che JWT è semplicemente un formato per il trasferimento di dati, è importante capire che sebbene quasi tutti gli Authorization Server usino il formato JWT come rappresentazione dei loro Bearer Token, questo NON implica affatto che io possa usare i token di uno per accedere alle risorse protette dall’altro.

CONCLUSIONI

L’autenticazione moderna ibrida (HMA) è un metodo di gestione delle identità che offre un’autenticazione e un’autorizzazione utente più sicura, sfruttando i potenti strumenti che ci vengono offerti da Microsoft 365 per passare oltre al vecchio e debole concetto di “utente e password”, ed è disponibile per le distribuzioni ibride di Exchange Server.

Stay Tuned on Technical365!!