Microsoft Teams è l’hub per la collaborazione di Microsoft 365, che integra persone, contenuti e strumenti per rendere i nostri team di lavoro sempre più coinvolti ed efficaci, questo è reso possibile grazie a svariati prodotti Microsoft (Exchange, Sharepoint, Onedrive, Azure Active Directory) che assieme vanno a comporre quello che è ora Microsoft Teams. La crescita di Teams nel primo quadrimestre del 2020 è stata esponenziale, questo ovviamente a causa della situazione difficile che ha colpito l’intero pianeta. Tra i molti scenari di implementazione della soluzione, quello più diffuso e a mio parere più consono alle esigenze di sicurezza del dato è l’ibridazione dell’Organizzazione On-Premises con quella Online.
Molti clienti hanno la necessità di poter usufruire della suite di Office 365 ma continuando a tenere le proprie mailbox su Exchange On-Premises. Uno dei servizi più richiesti in questo momento è sicuremente Microsoft Teams, questa soluzione offre diverse feature molto apprezzate dagli utenti, tra queste c’è indubbiamente l’integrazione del calendario direttamente sull’interfaccia della web app e dell’app per desktop. Questa integrazione permette di schedulare meeting, meeting istantanei ed eventi live.
Hybrid Configuration Wizard Exchange Server
Perché ibridare Exchange On-Premises con quello Online se voglio tenermi le mailbox in casa?
Per comprendere a fondo ciò di cui stiamo parlando è prima necessario precisare che il “calendario” nell’architettura di Exchange Server non è altro che una “cartella” all’interno di una ipotetica mailbox utente/shared/public folder. Quando quindi andiamo ad aggiungere un’appuntamento sul calendario su Teams utilizzando un’identità sincronizzata con mailbox On-Premises non facciamo altro che andare a scrivere sulla cartella calendario della mailbox dell’utente interessato. Microsoft Teams è un servizio Cloud Only, basato quindi esclusivamente su Exchange Online, ciò sta a significare che andiamo a sfruttare Exchange Online per andare a scrivere sulle folder delle mailbox interessate su Exchange On-Premises. Per poter fare questo è necessario dare i permessi necessari alle due Organizzazioni di poter leggere e scrivere informazioni una verso l’altra e viceversa.
L’Hybrid Configuration Wizard è il tool che ci permette di poter fare questo tramite una semplice interfaccia grafica che andiamo ad eseguire su uno dei nostri CAS On-Premises, per maggiori informazioni sull’Hybrid Configuration Wizard leggete qui.
Di seguito riportiamo un esempio di esecuzione dell’Hybrid Configuration Wizard, la procedura di configurazione dell’ambiente ibrido va a buon fine ma come vedete presenta un warning facente riferimento alla porzione dell’autenticazione tramite protocollo OAuth dell’Intra-Organization Connector.
Che cos’è il protocollo OAuth?
OAuth, abbreviazione di “Open Authorization“, è un protocollo standard aperto che consente una autorizzazione API sicura. Il termine tecnico di programmazione API (abbreviazione di “Application Programming Interface“) si riferisce in questo contesto ad una interfaccia che funge da trasmettitore di dati tra diverse applicazioni, interfacce utente o pagine web. L’autorizzazione dei trasferimenti di dati effettuati per mezzo delle API è necessaria in quanto altrimenti sussiste il rischio che terzi non autorizzati possano intercettare i dati e utilizzarli illegittimamente per scopi personali.
Questo significa, ad esempio, che se un’applicazione deve pubblicare per conto di un utente un post su Facebook (e quindi accedere all’API di Facebook), l’utente deve fornirle l’autorizzazione necessaria. Allo stesso modo, un’applicazione ha bisogno del permesso dell’utente per estrapolare informazioni sul suo profilo da un altro servizio. Tramite il protocollo OAuth, l’utente può concedere tale delega (autorizzazione) senza dover fornire all’applicazione autorizzata username e password, mantenendo quindi il pieno controllo sui propri dati.
Viceversa, fornitori come Google, Twitter e Facebook utilizzano OAuth per rendere i loro prodotti e servizi piùflessibili e allo stesso tempo piùsicuri, ad esempio attraverso soluzioni Single sign-on. Anche Amazon e Microsoft figurano tra le grandi aziende che utilizzano OAuth come standard di delega di accesso per i loro servizi.
In che modo viene utilizzato il protocollo OAuth nello scenario ibrido di Exchange On-Premises ed Exchange Online?
Il protocollo OAuth nel caso dell’ambiente ibrido viene utilizzato per permettere alle organizzazioni “trustate” di poter usufruire di determinati servizi che in mancaza di questo protocollo possono essere sfruttati solo all’interno della stessa organizzazione. Di seguito una lista di questi servizi:
- Gestione Record di Messagistica di Exchange (MRM).
- Ricerca sul posto di Exchange.
- Archiviazione sul posto di Exchange.
- Calendari di Microsoft Teams.
Nel nostro caso quello che va a toccare più da vicino i nostri utenti in questo periodo è il quarto punto della lista sopracitata, i calendari di Microsoft Teams.
È possibile rendere disponibili queste funzionalità nel nostro ambiente ibrido?
La risposta è si, l’HCW può configurare l’autenticazione di Azure Active Directory per OAuth, può creare IntraOrganizationConnectors, ma non può esportare e importare il certificato (self-signed) sul server Exchange On-Premises, né può (o lo fa) creare gli oggetti del server di autorizzazione in Active directory. Per questo dobbiamo procedere con una lista di operazioni manuali su Exchange On-Premises e su Exchange Online per terminare con successo la configurazione, qui trovate il riferimento ufficiale Microsoft della procedura.
Andiamo a vedere passo passo ciò che dobbiamo fare manualmente per concludere con successo la configurazione.
Nota. Funziona solo con Exchange 2013 e versioni successive, io ci ho lavorato su un ambienti ibridi che comprendevano Exchange 2016 ed Exchange 2019.
Creare oggetti del server di autorizzazione su Exchange server On-Premises
Per creare gli oggetti del server di autorizzazione nell’ambiente On-Premises, immettere i seguenti comandi in Exchange Management Shell.
New-AuthServer -Name "WindowsAzureACS" -AuthMetadataUrl "https://accounts.accesscontrol.windows.net/contoso.com/metadata/json/1"
New-AuthServer -Name "evoSTS" -Type AzureAD -AuthMetadataUrl https://login.windows.net/contoso.com/federationmetadata/2007-06/federationmetadata.xml
Abilitare l’applicazione partner per l’uso con Exchange Online
L’applicazione partner è stata creata nel passaggio precedente (il primo comando) e questo dovrebbe essere abilitato. A tale scopo, utilizza il seguente comando in Exchange Management Shell (locale):
Get-PartnerApplication | ?{$_.ApplicationIdentifier -eq "00000002-0000-0ff1-ce00-000000000000" -and $_.Realm -eq ""} | Set-PartnerApplication -Enabled $true
Nota. L’application identifier facente riferimento ad Exchange Online ovviamente su tutti gli Exchange On-premises è sempre lo stesso, “00000002-0000-0ff1-ce00-000000000000”.
Esportare il certificato di autorizzazione dell’Exchange On-Premises
L’autenticazione tra Organizzazioni usa i certificati, quindi il certificato dell’Exchange On-Premises deve essere esportato e in seguito importato su Azure Active Directory. Nel caso vi steste chiedendo da dove provenisse il certificato “CN = Microsoft Exchange Server Auth Certificate” potete scoprirlo utilizzando il comando Get-ExchangeCertificate in Exchange Management Shell On-Premises e vedrete la lista di tutti i certificati presenti nel “Personal Store” della vostra macchina.
Utilizzare i seguenti comandi di PowerShell e archiviarli in uno script di PowerShell che potete chiamare ExportAuthCert.ps1 ed eseguirlo. Questo andrà ad esportare il certificato OAuth in un file chiamato OAuthCert.cer.
$ThumbPrint = (Get-AuthConfig).CurrentCertificateThumbprint
If((Test-Path $ENV:SYSTEMDRIVE\OAuthConfig) -eq $false)
{
md $ENV:SYSTEMDRIVE\OAuthConfig
}
CD $ENV:SYSTEMDRIVE\OAuthConfig
$oAuthCert = (dir Cert:\LocalMachine\My) | ?{$_.ThumbPrint -Match $ThumbPrint}
$CertType = [System.Security.Cryptography.X509Certificates.X509ContentType]::Cert
$CertBytes = $oAuthCert.Export($CertType)
$CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
[System.IO.File]::WriteAllBytes($CertFile, $CertBytes)
Nota. Il cmdlet Export-ExchangeCertificate che potreste pensare di utilizzare invece dello script che abbiamo definito precedentemente non funziona considerato che si tratta di un certificato self-signed.
Importare il certificato di autorizzazione dell’Exchange On-Premises su Azure Active Directory
Il passaggio successivo consiste nell’importare il certificato OAuthCert.cer in Azure AD. Per fare ciò dovete connettervi al servizio Microsoft Online (Connect-MSOLService, se non lo avete installato potete utilizzare il comando MSOnline Install-Module su powershell 5.0 e superiori) e ed eseguire lo script powershell con all’interno i seguenti comandi:
$Cred = Get-Credential Connect-MSOLService -Credential $Cred $CertFile = "$ENV:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer" $objFSO = New-Object -ComObject Scripting.FileSystemObject $CertFile = $objFSO.GetAbsolutePathName($CertFile) $CER = New-Object System.Security.Cryptography.X509Certificates.X509Certificate $CER.Import($CertFile) $binCert = $cer.GetRawCertData() $CredValue = [System.Convert]::ToBase64String($binCert) $ServiceName = "00000002-0000-0ff1-ce00-000000000000" $P = Get-MsolServicePrincipal -ServicePrincipalName $ServiceName New-MsolServicePrincipalCredential -AppPrincipalId $P.AppPrincipalId -Type asymmetric -Usage Verify -Value $credValue
Registriamo gli endpoint della nostra Infrastruttura On-Premises su Azure Active Directory
L’ultimo passaggio consiste nel registrare gli endpoint dell’ambiente di Exchange On-Premises in Azure Active Directory. È possibile utilizzare i seguenti comandi per registrare gli endpoint:
$ServiceName = "00000002-0000-0ff1-ce00-000000000000";
$x = Get-MsolServicePrincipal -AppPrincipalId $ServiceName;
$x.ServicePrincipalnames.Add("https://webmail.exchangeserver.com/");
$x.ServicePrincipalnames.Add("https://autodiscover.exchangeserver.com/");
Set-MSOLServicePrincipal -AppPrincipalId $ServiceName -ServicePrincipalNames $x.ServicePrincipalNames;
Invece di webmail.exchangeserver.com e Autodiscover.exchangeserver.com è necessario utilizzare i propri FQDN del server Exchange On-Premises (mostrato di seguito nella schermata di verifica).
È possibile utilizzare il comando seguente per verificare se questo è stato configurato correttamente.
Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames
Verifichiamo la configurazione dell’autenticazione tra le organizzazioni tramite protocollo OAuth
Per verificare la configurazione di OAuth è possibile utilizzare il comando Test-OAuthConnectivity. È necessario eseguire ciò sul server di Exchange On-Premises e in Exchange Online.
Sul server Exchange On-Premises utilizzare l’Uri di Exchange Online e una cassetta postale locale:
Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox onprem-user@exchangeserver.com -Verbose | Format-List
In Exchange Online, utilizzare l’Uri dell’Exchange On-Premises con una cassetta postale in Exchange Online:
Test-OAuthConnectivity -Service EWS -TargetUri https://webmail.exchangeserver.com/metadata/json/1 -Mailbox Online-User@exchangeserver.com -Verbose | Format-List
L’output è un elenco esteso, ma alla fine se la procedura è andata a buon fine vedrete “ResultType: Success e IsValid: True” sulla vostra sessione di powershell:
CONCLUSIONI
Microsoft Teams è l’HUB di collaborazione più completo attualmente nel panorama mondiale, ovviamente per usufruire più facilmente e con configurazioni che richiedono poco dispendio di energie per gli amministratori, la cosa migliore sarebbe quella di eseguire la migrazione delle proprie mailbox su Exchange Online. Deve essere però chiaro che ciò che viene utilizzato su 365 è ciò che ci viene proposto anche per la parte On-Premises, dunque non è un limite non superabile per i clienti che preferiscono tenere i propri dati in casa, come avete visto basta eseguire dei piccoli step per permettere alle Organizzazioni di poter accedere alle risorse necessarie tramite protocollo OAuth.
Stay Tuned on Technical365!!