Una delle frasi che più mi è rimasta impressa dell’insediamento di Satya Nadella alla guida di Microsoft è “mobile-first, cloud-first”. A distanza di più di 5 anni da quando ha pronunciato quella frase, devo dire che l’investimento tecnologico che Microsoft ha fatto nelle tecnologie Cloud è stato davvero imponente e anche il nostro modo di lavorare è cambiato tanto in questi anni.
Siamo sempre collegati allo smartphone e lo usiamo tantissimo per lavorare, per essere sempre connessi al nostro business e ai nostri clienti e ormai non ne possiamo più fare a meno.
Lo Smart working, fenomeno che si sta diffondendo nelle aziende intaliane e nella pubblica amministrazione, ci permette di lavorare da casa e di essere flessibii negli orari e negli spazi dove lavorare.
Ma per lavorare abbiamo bisogno di un device, che sia un portatile, un tablet o un PC e abbiamo bisogno di poter controllare gli accessi da questi dispositivi.
In questa guida voglio affrontare la gestione dei dispositivi mobili e dei computer che non sono collegati al dominio aziendale e che pertanto risultano più difficili da gestire. Il BYOD (Bring Your Own Device) da quasi 10 anni permette di portare i propri dispositivi personali nel posto di lavoro e usarli per avere accesso alle informazioni aziendali e alle loro applicazioni.
Affronterò in particolare il caso in cui, in un dominio federato con Office 365, io voglia consentire l’autenticazione e l’accesso alle risorse solo per quei dispositivi che conosco e che ho autorizzato, inseguendo un duplice obiettivo:
- Fare in modo che gli utenti finali siano produttivi sempre e ovunque
- Proteggere gli asset aziendali in qualsiasi momento
E per proteggere le risorse aziendali dobbiamo verificare che gli utenti accedano da dispositivi che soddisfino gli standard per sicurezza e conformità.
Controllo dei dispositivi tramite Azure AD
Per controllare un dispositivo tramite Azure Active Directory, sono disponibili due opzioni:
- Registrazione
- Aggiunta (Join)
La registrazione di un dispositivo in Azure AD (Device Registration) consente di gestire l’identità di un dispositivo. Quando un dispositivo viene registrato, Azure AD Device Registration fornisce al dispositivo un’identità che viene usata per autenticare il dispositivo quando un utente accede ad Azure AD. È possibile usare l’identità creata per abilitare o disabilitare un dispositivo all’accesso ad Azure AD.
![]()
Figura 1: On-Premises Conditional Access utilizzando i registered devices
Prima di poter aggiungere un dispositivo ad Azure AD è necessario verificare di aver abilitato il join dal portale di Azure Active Directory.
Collegatevi al portale di amministrazione di Office 365 e successivamente accedete al’Azure Active Directory Admin Center. Dalla sezione Manage, cliccate su Devices e successivamente su Device Settings. Decidete se abilitare la possibilità di joinare i dispositivi sia valida per tutti gli utenti del tenant o solo per alcuni utenti. Potete scegliere anche quale sarà il numero massimo di dispositivi che ogni utente potrà aggiungere e se sia necessario utilizzare la Multi-Factor Authentication, come mostrato in figura:
![]()
Figura 2: Abilitazione della registrazione dispositivi in Azure Active Directory
Per una panoramica sulla gestione dei dispositivi nel portale di Azure AD, vi rimando alla lettura della guida Gestione dei dispositivi tramite il portale di Azure
Registrare il dispositivo personale in Azure AD
Per registrare il proprio dispositivo in Azure AD e quindi poter avere accesso alle risorse della propria azienda sono necessari pochissimi passaggi. Ovviamente la procedura cambia se volete collegare uno smartphone con Android, con iOS oppure se vi collegate da un pc con Windows.
In questa guida mi occuperò di registrare un dispositivo Windows 10 di proprietà dell’utente e che è in workgroup.
Per registrare il dispositivo personale Windows 10 vi basterà aprire Settings e quindi selezionare Account. Selezionate Access work or school e quindi selezionate Connect. Nella schermata Set up a work or school account digitate l’indirizzo di posta elettronica del vostro account aziendale.
![]()
Figura 3: Connessione del computer Windows 10 ad Azure AD
Il dominio che sto utilizzando (nicolaferrini.com) è un dominio federato (Informazioni sulla gestione delle identità di Office 365 e Azure Active Directory) quindi le credenziali verranno passate direttamente al Federation Server interno della mio dominio locale. Il prompt per la password infatti riporta il nome del server utilizzato (sts.nicolaferrini.com)
![]()
Figura 4: Inserimento delle credenziali da validare tramite Federation Server interno al dominio locale
Completate il resto del processo di registrazione, inclusa l’approvazione della richiesta di verifica dell’identità (se si usa la verifica in due passaggi) e attendete che il dispositivo risulti registrato.
![]()
Figura 5: Completamento del processo di registrazione del dispositivo in Azure AD
Dopo aver registrato il dispositivo personale in Azure AD sarà possibile visualizzare la connessione avvenuta visualizzando che l’account aziendale sia presente nella scheda Access work or school, come mostrato in figura:
![]()
Figura 6: Account aziendale collegato al dispositivo personale
Il vantaggio principale di registrare un dispositivo in Azure AD consiste certamente nel poter fare logon automatico a tutte quelle applicazioni che usano Azure AD per l’autenticazione, come ad esempio Office 365. In questo modo l’utente può entrare senza digitare la password. Se infatti l’utente apre il browser e si collega a https://www.office.com non gli verrà chiesta alcuna autenticazione.
![]()
Figura 7: L’accesso ai software che utilizzano Azure AD per l’autenticazione avviene in maniera automatica
Gli amministratori possono verificare in qualsiasi momento quali sono i dispositivi aggiunti ad Azure AD da ogni singolo utente, utilizzando il portale di amministrazione di Office 365 e successivamente accedendo all’Azure Active Directory Admin Center. Dalla sezione Manage, basta cliccare sul nome dell’utente e successivamente su Devices, come mostrato in figura:
![]()
Figura 8: Dispositivi personali aggiunti dall’utente ad Azure AD
Cliccando sul singolo dispositivo è possibile verificarne l’ID, è possibile disabilitarlo oppure cancellarlo.
![]()
Figura 9: ID del dispositivo aggiunto ad Azure AD
Preparazione della foresta di Active Directory per il supporto al device writeback
Per preparare la foresta Active Directory per supportare i dispositivi è necessario che l’Active Directory forest level sia almeno Windows Server 2012 R2. Potete verificare il livello semplicemente utilizzando la console Active Directory Domains and Trusts e cliccando col tasto destro scegliete Raise Forest Functional Level…, come mostrato in figura:
![]()
Figura 10: Verifica del livello funzionale della foresta di Active Diretory
Sul Federation Server eseguite, solo la prima volta, il comando Powershell Initialize-ADDeviceRegistration. Quando viene richiesto di specificare ServiceAccountName, immettete il nome dell’account di servizio utilizzato da AD FS. Se avete utilizzato un Group Managed Service Account usate il formato dominio\nomeaccount$, se invece avete utilizzato un utente di servizio normale usate il formato dominio\nomeaccount. Nel mio caso ho utilizzato un Group Managed Service Account:
![]()
Figura 11: Preparazione della foresta di Active Directory
È necessario anche preparare il Federation Server del vostro dominio interno a supportare la Device Authentication. Aprite la console di gestione di AD FS e in Authentication Policies selezionate Edit Global Primary Authentication. Cliccate su Enable device authentication e confermate con OK.
![]()
Figura 12: Abilitazione della Device Authentication in AD FS
Per impostazione predefinita, AD FS rimuove periodicamente dall’ Active Directory interno i dispositivi inutilizzati. Disabilitate questa modalità quando si usa il servizio Azure Active Directory Device Registration, in modo che i dispositivi possano essere gestiti in Azure, lanciando sul Federation Server comando PowerShell Set-AdfsDeviceRegistration -MaximumInactiveDays 0
![]()
Figura 13: Disabilitazione della rimozione dei dispositivi inutilizzati in AD FS
Abilitazione del writeback dei dispositivi
Come anticipato all’inizio della guida, l’obiettivo è quello di filtrare gli accessi alle applicazioni gestite dal Federation Server e di consentirli solo se provenienti da dispositivi conosciuti e attendibili. Prima di cominciare assicuratevi di essere nello scenario giusto e di aver implementato Active Directory Federation Services per l’autenticazione ad Office 365. Vi rimando alla lettura della mia guida Configurare AD FS 2016 ed Office 365 con Azure AD Connect per conoscere tutti i passaggi necessari alla realizzazione dello scenario trattato in questo articolo.
Il writeback dei dispositivi, che permette di abilitare l’accesso condizionale alle applicazioni protette tramite AD FS 2012 R2 o versioni successive, serve quindi a registrare nel nostro dominio locale tutti i device che gli utenti hanno aggiunto ad Azure AD.
Lanciate il tool Azure AD Connect (che deve essere versione 1.1.819.0 o successiva) dal server interno su cui lo avete installato e selezionate Configure device options dalla pagina Additional tasks.
![]()
Figura 14: Configure Device Options in Azure AD Connect
Dopo esservi loggati al vostro tenant di Azure AD con le credenziali di un Global Administrator passate alla pagina delle opzioni del dispositivo e selezionate Configure device writeback. L’opzione Disable device writeback non sarà disponibile finché non viene abilitato il writeback dei dispositivi.
![]()
Figura 15: Azure AD Connect dalla versione 1.1.819.0 e successive è capace di configurare l’Hybrid Azure AD Join e il Device Writeback
![]()
Figura 16: Connessione ad Azure AD con le credenziali di un Global Administrator
![]()
Figura 17: Scelta della configurazione del Device Writeback
Selezionate a questo punto la foresta ed il dominio locali dove volete che vengano aggiunti i vostri dispositivi registrati in Azure AD.
![]()
Figura 18: Foresta el dominio locali dove verranno aggiunti i dispositivi registrati in Azure AD
La pagina Device container consente di preparare l’Active Directory locale a ricevere i dispositivi registrati, tramite una delle due opzioni:
- Fornire le credenziali di amministratore di un Enterprise Admin: Azure AD Connect preparerà la foresta automaticamente durante la configurazione del writeback dei dispositivi.
- Scarica lo script di PowerShell: Azure AD Connect genera automaticamente uno script di PowerShell che può preparare Active Directory per il writeback dei dispositivi.
![]()
Figura 19: Inserimento delle credenziali per la creazione dell’oggetto Device Container in Active Directory
![]()
Figura 20: Controllo delle impostaziomni prima della configurazione
![]()
Figura 21: Configurazione del Device Writeback completata
Verifica della creazione dei dispostivi nell’Active Directory locale
Dopo aver completato la configurazione, potrete aprire la console di Active Directory Users and Computer per verificare che sia stato creato un nuovo contenitore chiamato RegisteredDevices, con all’interno gli eventuali dispositivi che erano già stati registrati in Azure AD. Dalla documentazione ufficiale Microsoft risulta che ci potrebbero volere fino a 3 ore per vedere i dispositivi replicati all’interno del dominio locale. Nel mio caso è avvenuto tutto nel giro di pochi minuti. Nella schermata sotto si può vedere la console di Active Directory Users and Computer con evidenziato l’ID del dispositivo aggiunto prima (vedere la figura 9).
![]()
Figura 22: Container RegisteredDevices creato nell’Active Directory locale
Creazione di policy di accesso alle applicazioni
L’obiettivo è quello di creare una regola che consenta solo ai dispositivi registrati di poter accedere all’applicazione che usa AD FS per l’autenticazione. In particolare, noi modificheremo il Relying Party Trust che gestisce l’autenticazione di Office 365.
Dalla console di gestione di Active Directory Federation Services, in AD FS > Trust Relationships > Relying Party Trusts, individuate l’applicazione a cui applicare questa nuova regola di accesso (nel mio caso Microsoft Office 365 Identity Platform). Fate clic con il pulsante destro del mouse sull’applicazione e selezionate Edit Claim Rules.
![]()
Figura 23: Creazione della Application Access policy per Office 365
Selezionate il tab Issuance Authorization Rules e fate clic su Add Rule
![]()
Figura 24: Creazione di una nuova Issuance Authorization Rules
Dal Claim rule template selezionate Permit or Deny Users Based on an Incoming Claim.
![]()
Figura 25: Selezione del Rule Template
Date un nome alla Issuance Authorization Rule, dal menù a tendina di Rule Incoming claim type scegliete Is Registered Usere e nel campo In the Incoming claim value field scrivete true. Lasciate selezionato Permit access to users with this incoming claim
![]()
Figura 26: Creazione della regola con relative configurazioni
Cliccando su Finish verrà creata la nuova Issuance Authorization Rule
![]()
Figura 27: Issuance Authorization Rule creata
Rimuovete eventuali regole più permissive di quella creata. Ad esempio, io ho rimosso la regola predefinita Permit Access to all Users
![]()
Figura 28: Rimozione delle Issuance Authorization Rule più permissive
L’applicazione ora è configurata per consentire l’accesso solo quando l’utente opera da un dispositivo registrato al workplace.
NOTA: è possibile applicare il controllo degli accessi a QUALSIASI applicazione modificando il rispettivo Relying Party Trust. Office 365 è solo un esempio di applicazione che può utilizzare i Federation Services per l’autenticazione
Verifica dell’accesso da dispositivi NON registrati
Se l’utente cerca di autenticarsi da un dispositivo NON registrato, dopo aver fornito le credenziali al Federation Server (si sta collegato da una macchina in workgroup e non in dominio, quindi non può effettuare il Single Sing-on oppure si sta collegando da uno smartphone o da un tablet), riceverà un messaggio di errore e gli verrà impedito l’accesso.
![]()
Figura 29: Connessione al portale di autenticazione di Office 365
![]()
Figura 30: Poiché il dominio utilizzato è federato, la richiesta di autenticazione viene inoltrata al Federation Server del dominio interno
![]()
Figura 31: Inserimento delle credenziali da un dispositivo non registrato
![]()
Figura 32: Messaggio di errore da parte del Federation Server. Il dispositivo NON è registrato e quindi non è permesso l’accesso all’applicazione
Personalizzazione del messaggio di errore di accesso all’applicazione
Ho notato che il messaggio predefinito utilizzato dal Federation Server non avvisa gli utenti della reale problematica relativa all’accesso all’applicazione. Infatti, fa riferimento ad un problema di autorizzazione da parte dell’utente e non del fatto che si stia utilizzando un dispositivo NON registrato.
Potete quindi personalizzare il messaggio di errore. Il messaggio indicherà agli utenti che devono aggiungere il proprio dispositivo al workplace per poter accedere all’applicazione. È possibile usare codice HTML personalizzato e PowerShell per la personalizzazione.
Nel Federation Server lanciate il seguente comando PowerShell:
Set-AdfsRelyingPartyWebContent -Name "Microsoft Office 365 Identity Platform" -ErrorPageAuthorizationErrorMessage "È necessario prima registrare il proprio dispositivo per poter accedere al Portale di Office365, Per maggiori informazioni visitare la pagina <A href='https://docs.microsoft.com/it-it/azure/active-directory/user-help/user-help-register-device-on-network'>Registrare il dispositivo personale nella rete dell'organizzazione</A>"
Ovviamente personalizzate il messaggio di errore a vostro piacimento ![🙂]()
![]()
Figura 33: Messaggio di errore personalizzato per gli utenti che non si connettono da dispositivi registrati nel workplace
Conclusioni
I criteri di accesso condizionale basati su dispositivo permettono di poter aumentare il livello di sicurezza per l’accesso alle applicazioni. Filtrare gli accessi alle applicazioni la cui autenticazione è gestita dal Federation Server (come ad esempio Office 365) e di consentirli solo se provenienti da dispositivi conosciuti e attendibili permette di proteggere gli assett aziendali e permette agli utenti di utilizzare i dispositivi personali senza rinunciare alla sicurezza.
