Archivi categoria: Sicurezza

Pubblicare applicazioni aziendali con Azure Active Directory Application Proxy

Facebooktwittergoogle_plusredditlinkedin

La necessità di rendere utilizzabili al di fuori del perimetro aziendale le applicazioni interne è un’esigenza ormai quotidiana, ma la disponibilità esterna di queste risorse costringe necessariamente chi amministra l’infrastruttura ad “aprire le porte” verso Internet, con tutte le implicazioni dal punto di vista della sicurezza che questo comporta.

Sono state e sono tutt’ora utilizzate una serie di tecniche di mitigazione, ad esempio l’impiego di proxy a reverse con l’utilizzo di sistemi di re-writing degli URL, che consentono una separazione netta delle connessioni in ingresso e forniscono una certa sicurezza sulle risorse esposte.

Questa architettura permette la collocazione in DMZ di sole macchine con il compito di gestire le richieste in ingresso e ridirigerle poi, con alcune regole di controllo all’interno. In questo modo le infrastrutture sensibili non hanno contatto diretto con l’esterno.

Contestualmente a questi accorgimenti l’adozione di sistemi IDS/IPS “garantiscono” un accettabile livello di sicurezza.

In ogni caso questo approccio ha richiesto e richiede che il firewall perimetrale consenta la connessione ed “apra” almeno una porta verso l’interno, richiede anche che i vari apparati posti a controllo del perimetro siano costantemente aggiornati e verificati

Azure Active Directory Application Proxy

In Microsoft Azure è disponibile un servizio che si lega in modo stretto con Azure Active Directory e che in maniera concettualmente del tutto nuova permette in modo semplice la fruizione delle applicazioni ad utenti esterni all’azienda.

Questo servizio è Azure Active Directory Application Proxy, disponibile con la versione BASIC o PEMIUM di Azure Active Directory.

Per poter utilizzare la funzione di Application Proxy, dal portale di Azure è sufficiente, selezionata la Directory di riferimento, attivare la funzionalità in prova valida per 30 giorni e successivamente terminata la fase di test, effettuarne l’acquisto.

Figura 1: Abilitazione servizi AAD Premium

Figura 2: Attivazione di Azure AD Premium P2 Trial

Attivata la funzionalità di Azure AD Premium è necessario installare il componente Application Proxy Connector. La scelta più corretta è quella di dedicare un sistema server a questa funzione, scelta che permette una migliore scalabilità delle risorse e di gestione.

Figura 3 Download componente Connector

Per configurare correttamente regole di uscita dell’Application Proxy è utile la lettura del documento Attività iniziali del proxy di applicazione e installazione del connettore

Mentre per un controllo diretto ed una verifica puntuale della configurazione è disponibile il tool Azure Active Directory Application Proxy Connector Ports Test Tool

È anche possibile permettere che il Connector interno utilizzi per collegarsi ad Azure un Web Proxy , questo qualora non fosse possibile agire direttamente sul Firewall per definire regole puntuali di uscita.

In questo caso è bene considerare che un possibile malfunzionamento del Web Proxy stesso si ripercuoterebbe necessariamente sulla raggiungibilità delle applicazioni.

L’aspetto interessante, relativo alla sicurezza del sistema, è che NON è richiesto che in ingresso venga definita alcuna regola sul Firewall.

L’applicazione che è utilizzata esternamente sarà disponibile tramite il portale Azure e sarà la componente Application Proxy che si occuperà di renderla accessibile e di “dialogare” con il Connector interno, che è la sola componente ad avere contatti con l’applicazione in rete locale.

Per analogia con il sistema tradizionale a Reverse Proxy il Connector è un Reverse Proxy, con la sola ma importante differenza che questo, come detto sopra, non ha contatti con l’esterno ma riceve e reindirizza le richieste dalla componente cloud.

Figura 4: Principio di funzionamento di Azure Active Directory Application Proxy

A questo punto è evidente che l’infrastruttura di sicurezza Aziendale può essere “alleggerita” in quanto come già detto non è richiesto che siano attivate porte in ascolto, questo compito è demandato ad Azure.

Pubblicazione di una applicazione interna tramite Azure AD Application Proxy

Dal portale di Azure selezionare la directory in cui si è abilitata la funzione e successivamente selezionare Configura un’app

Figura 5: Aggiunta dell’applicazione on-premises da esporre

Nella maschera successiva scegliere “Add your own on-premises application”

Verrà così proposta una ulteriore videata con le specifiche proprie dell’applicazione che si intende pubblicare

  • Nome serve ad identificare l’applicazione all’interno del portale di accesso e di configurazione
  • URL interno è l’effettivo URL che il connettore installato on premise contatterà (di norma l’Url dell’applicazione interna)
  • URL Esterno è il riferimento
    pubblico per la raggiungibilità dell’applicazione interna, nel caso si usi un dominio Custom, questo è selezionabile dalla casella
  • Metodo di Autenticazione Preliminare è effettivamente la modalità con cui gli utenti accederanno all’autenticazione dell’applicazione.

Con la modalità Azure AD l’utente verrà effettivamente autenticato con i servizi di Azure e quindi beneficiando anche di quelle che sono le prerogative di questi utenti: gestione Self-Service della password, possibilità di definire criteri di sblocco personalizzati, accesso da dispositivi con determinate caratteristiche etc.

Con la modalità Passtrough invece, all’utente viene proposto direttamente (se previsto) il login dell’applicazione interna.

Nel caso in cui sia impostata la modalità Azure AD e l’applicazione (tipicamente legacy) non sia in grado di utilizzare di questa modalità, verrà richiesta una seconda autenticazione.

A questo punto è possibile accedere all’applicazione, è da notare che di default tutto il traffico è in HTTPS e viene utilizzato un certificato generato per il nome host definito.

Tuttavia, siccome si possono anche gestire URL esposti in Azure con FQDN del proprio dominio pubblico è possibile effettuare l’upload di un certificato aziendale.

Controllo delle funzionalità del Connector Gateway

Questo oggetto non ha particolari opzioni di configurazione, all’atto dell’installazione, viene richiesto un account amministratore globale della directory e con questo il gateway si registra ed autentica sulla directory stessa.

È possibile all’interno del registro eventi rilevare eventuali errori o anomalie archiviate in AadApplicationProxy (fig.6)

Sono anche disponibili, al fine di valutare le performance di questo servizio alcuni Performance Counters (fig.7)

Figura 6: Contatori disponibili per la verifica delle performance del servizio

Figura 7: Aggiunta dei contatori

Considerazioni relative agli aspetti di sicurezza

Controllo tramite NMAP delle informazioni deducibili tramite un port SCAN

Al di là delle considerazioni espresse in precedenza, un piccolo e sicuramente approssimativo test relativo agli aspetti legati alla sicurezza è stato condotto utilizzando NMAP.

Tramite questo tool si è cercato di identificare il sistema operativo sul quale l’applicazione è installata.

Sono stati effettuati due TEST distinti, il primo verso una applicazione esposta in modo tradizionale FWàRev-ProxyàApplicazione

Figura 8: Scansione verso l’esposizione con Reverse Proxy tradizionale

Nmap seppure con una certa approssimazione ha rilevato un host Linux fig. sopra

Ed il secondo sempre verso la stessa applicazione ma esposta tramite AZURE con la struttura descritta sopra

Figura 9 Scansione verso l’esposizione con Azure Application Proxy

Nmap non è riuscito ad identificare il sistema verso il quale ha fatto la scansione.

Conclusioni

Partendo dall’assunto che non esiste LA soluzione perfetta, sicura e garantita e vista anche la velocità di implementazione e il discreto grado di sicurezza by-default dell’infrastruttura, la soluzione di Azure Application Proxy può essere un valido aiuto alle realtà che necessitano di rendere fruibili le proprie applicazioni all’esterno del perimetro aziendale.

Riferimenti:

Azure Application Proxy Connector

Azure Application Proxy Connector – connessione tramite proxy interno

Risoluzione dei problemi relativi alla pubblicazione di applicazioni tramite Azure

Sicurezza

Configurare il disaster recovery delle Azure VM in una regione secondaria di Azure

Facebooktwittergoogle_plusredditlinkedin

Azure Site Recovery è un servizio che permettere di poter replicare in Microsoft Azure le nostre macchine fisiche on-premises e le nostre macchine virtuali Hyper-V oppure VMware, per poterle avviare nel momento in cui si verifica un disastro. Ho già avuto modo di affrontare in diversi articoli come proteggere macchine virtuali VMware e come proteggere e migrare server fisici con Azure Site Recovery. Per chi volesse sapere cosa offre e come funziona Azure Site Recovery consiglio la lettura del documento Informazioni su Site Recovery.

In questo articolo vi voglio parlare di come effettuare il Disaster Recovery (DR) di una macchina virtuale ospitata in Microsoft Azure.

Il servizio, disponibile solo da pochi giorni, permette di replicare una macchina virtuale da una Region di Azure verso un’altra Region, in modo tale che se il sito primario non sia disponibile (per un disastro, per problemi di connettività, ecc..) la macchina virtuale possa essere accesa nel sito secondario e sia già pronta per poter eseguire le applicazioni.

Creazione del Recovery Service Vault

Prima di procedere all’abilitazione della replica della nostra Azure VM è necessario creare un Backup and Site Recovery Vault. Collegatevi al portale di Azure e dopo esservi autenticati create un nuovo Recovery Services Vault, come mostrato in figura. Quando create il Recovery Services Vault considerate sempre due fattori:

  • Il Recovery Services Vault non si deve trovare nella Region di Azure dove si trovano le Azure VM da proteggere
  • Il Resource Group in cui inserite il Recovery Services Vault non deve essere nella Region delle VM da proteggere

Le due condizioni sono necessarie perché, in caso di disastro nella Region dove sono ospitate le VM, non sarebbero disponibili né Resource Group né Recovery Services Vault!


Figura 1: Creazione del Recovery Services Vault in una Region diversa da quella dove sono ospitate le Azure VM da proteggere

Protezione delle Azure VM

Terminata la creazione del Recovery Services Vault siamo pronti per proteggere le nostre Azure VM. Dal portale di Azure vi basterà selezionare la VM da proteggere e cliccare sul collegamento Disaster Recovery. Nel blade che si aprirà configurate la Region di destinazione della replica della vostra VM ed il Resource Group, la VNET, lo Storage Account e tutti gli altri parametri richiesti, come mostrato in figura:

Figura 2: Configurazione della Replica della VM e Replication settings

Attenzione: Per poter abilitare la replica della VM è necessario che nella macchina virtuale sia installato l’Azure VM agent. Nel caso non lo fosse o nel caso non rispondesse alle richieste del portale riceverete un messaggio come quello mostrato in figura:

Figura 3: Messaggio di errore nel caso l’Azure VM agent non sia installato o non funzioni

L’abilitazione della replica dura diversi minuti. Potete controllare lo stato della replica dalle notifiche, come mostrato in figura:

Figura 4: Notifiche sulla creazione degli oggetti necessari alla replica della VM

Selezionando la VM e cliccando su Disaster Recovery sarà possibile visualizzare il Site Recovery Job iniziale di abilitazione della replica, come mostrato in figura:

Figura 5: Informazioni sullo stato di replica della Azure VM

Figura 6: Job di abilitazione della replica

Dal blade del Disaster Recovery sarà sempre possibile tenere sotto controllo lo stato di replica della VM e sarà possibile modificare i parametri. Cliccate sul tasto Settings e modificate i parametri della VM replicata. Potete ad esempio decidere in quale Resource Group accenderla e a quale VNET collegarla, oltre ovviamente alla dimensione che deve avere.

Figura 7: Configurazioni della VM replicata

Test del Failover

È sempre buona norma testare periodicamente il failover e verificare che tutto funzioni nella VM che avete replicato. Per effettuare il test vi basta cliccare su Test Failover e seguire le istruzioni. Vi verrà chiesto il Recovery Point che volete testare e la Azure VNET a cui collegare la VM.

Figura 8: Failover Test della VM

Dopo qualche minuto, nel Resource Group dove avete deciso di avviare la macchina per testare il Failover, apparirà la VM e vi ci potrete collegare per poter verificare che tutto funzioni perfettamente.

Figura 9: Macchina virtuale di test per il Failover

Dopo le opportune verifiche potete cliccare su Cleanup test failover e cancellare la macchina virtuale di test, come mostrato in figura:

Figura 10: Cleanup test failover

Failover della Azure VM

Per poter eseguire il Failover della Azure VM è sufficiente cliccare sul pulsante Failover e dal blade scegliere quale Recovery Point applicare e se spegnere la macchina prima di iniziare il failover. Lo spegnimento della macchina ha senso ovviamente in un Failover programmato e non in caso di vero disastro 🙂

Figura 11: Failover della Azure VM nella seconda Region di Azure

Terminato il Fialover potete decidere anche di cambiare recovery point utilizzando il pulsante Change recovery point oppure confermare la scelta fatta utilizzando il pulsante Commit. Dopo aver effettuato il Commit però non sarà più possibile modificare il Recovery Point.

Figura 12: Commit della macchina virtuale e completamento del Failover

Terminato il disastro è possibile riproteggere la Azure VM utilizzando il pulsante Re-protect. La macchina verrà replicata nuovamente verso la Region di partenza, ma se volete potete cliccare sul pulsante Customize e modificare i parametri, scegliendo il Resource Group, la VNET, lo Storage Account e l’Availability Set della macchina di destinazione.

Figura 13: Re-protect della Azure VM

Conclusioni

Il Disaster Recovery è decisamente importante vista la nostra dipendenza dai sistemi IT. Nonostante tutti gli sforzi profusi, può capitare sempre che accada qualcosa di imprevisto che interrompa la possibilità di usufruire dei servizi. Nonostante il Cloud sia stato concepito per essere affidabile, è buona norma essere sempre preparati al peggio. La replica delle VM di Azure è sicuramente una funzionalità interessante per essere certi di poter gestire un disastro importante e per assicurare alle aziende che hanno anche degli obblighi contrattuali o delle esigenze molto stringenti in ambito di Disaster Recovery di poter usufruire delle VM ospitate in Azure ed essere compliant con le loro specifiche.

Per approfondimenti potete visitare la pagina Set up disaster recovery for Azure VMs to a secondary Azure region

Zip Slip: grave vulnerabilità scoperta in VeeamB&R

Facebooktwittergoogle_plusredditlinkedin

Da qualche giorno è stato scoperto un nuovo rischio per il mondo informatico che questa volta prende il nome di Zip Slip. In cosa consiste? Ecco un estratto della spiegazione:

Zip Slip is an arbitrary file overwrite vulnerability in multiple ZIP decompression algorithm implementations that affects thousands of software products across many ecosystems. The vulnerability is exploited using a specially crafted zip archive that holds path traversal filenames. A path traversal filename is a malicious filename that when chained to the target extraction directory, results in the final path existing outside of the target folder . For instance, if a zip archive were to contain a file called “../../file.exe”, it would break out of the target folder when extracted. We highly recommend patching this vulnerability as soon as possible, as vulnerable code samples are actively being hand crafted and shared in developer communities for all major platforms.

In pratica è possibile iniettare del codice che consente di dirottare l’esportazione dei documenti altrove. La vulnerabilità è stata trovata in diverse piattaforme incluse JavaScript, Ruby, .NET e Go, mentre tra i nomi colpiti troviamo Oracle, Amazon, Spring/Pivotal, Linkedin, Twitter, Alibaba, Jenkinsci, Eclipse, OWASP, SonarCube, OpenTable, Arduino, ElasticSearch, Selenium, Gradle, JetBrains e Google.

Perchè Veeam Backup & Replication? Perchè il processo di Guest File Index usa tecniche simili e quindi è possibile iniettare il codice malevolo ed è per questo che è già disponibile una patch da applicare; il team ha già fatto presente che se non fate utilizzo dei GFI non è necessario applicare la patch.

Se volete saperne di più relativamente a Zip Slip, vi rimandiamo a questo articolo: https://snyk.io/research/zip-slip-vulnerability

Active Directory Password Policies: facciamo un po’ di chiarezza

Facebooktwittergoogle_plusredditlinkedin

Sempre più spesso mi capita, quando sono in azienda o durante i corsi, di riscontrare perplessità o inesattezze sulla corretta applicazione delle password policies da parte degli amministratori di dominio. Per questo motivo oggi voglio scrivere un articolo che faccia chiarezza sulla corretta applicazione delle policy e sull’esatto ordine con cui questa avviene.

Quante password policies posso applicare ad un singolo dominio?

Rispondere a questa domanda è semplice: una ed una sola!

  • Solo le policy applicate a livello di DOMINIO vengono considerate valide e verranno distribuite agli utenti. Le policy applicate a livello di OU (Organizational Unit), inclusa la OU dei Domain Controllers, vengono ignorate.
  • Se a livello di dominio ci sono più policy (ad esempio la Default Domain Policy ed una policy creata da voi) verranno considerati tutti i settaggi delle due policy (viene cioè fatto un merge), ma in caso di conflitto avrà la precedenza il settaggio della policy con la precedenza più alta (cioè la policy che ha un numero inferiore al quello della Default Domain Policy – Link Order più basso).
  • La password policy viene gestita dal domain controller che ha il ruolo FSMO di PDC Emulator.

Quindi, ci può essere solo una password policy per ogni account database e un dominio di Active Directory è considerato un singolo account database, come succede con i computer standalone.

Figura 1: in caso di più policy, vince quella con il LInk Order più basso

Quando viene applicata la password policy?

La password policy è sempre applicata alla macchina e non all’utente. Quindi quando avviene un aggiornamento della policy, questa viene applicata in background ogni 90 minuti di default (Background Refresh of Group Policy), all’avvio del computer oppure utilizzando il comando GPupdate.

Quando gli utenti vengono impattati?

Se cambio la password policy e stabilisco che la lunghezza minima della password sia 8 invece che 6 caratteri, gli utenti non si accorgono della modifica fino a quando la password non scade o gli viene chiesto di cambiarla (perché un amministratore l’ha resettata).

Quindi la modifica non è così “impattante” come si penserebbe e non costringerebbe tutti gli utenti del dominio a cambiare la password lo stesso giorno, per essere compliant con la nuova lunghezza minima imposta.

Quando vengono distribuite le modifiche apportate ad una password policy?

Nel momento in cui modificate la password policy, i seguenti settaggi vengono distribuiti immediatamente:

  • Minimum password length
  • Password must meet complexity requirements
  • Reversible encryption

Mentre gli altri settaggi vengono distribuiti solo dopo un logon, logoff, reboot oppure un GPO refresh

  • Minimum password age
  • Maximum password age
  • Lockout duration
  • Lockout threshold
  • Observation window

Attenzione sempre a distinguere tra distribuzione della policy e applicazione dei nuovi settaggi, che avvengono in momenti distinti a seconda del settaggio stesso, come ho già sottolineato.

Cos’è la Fine-Grained Password Policy?

A partire da Windows Server 2008 (e solo se il livello funzionale del dominio è innalzato a Windows Server 2008) è possibile applicare una password policy direttamente agli utenti o ai gruppi di sicurezza globale (global security groups) di Active Directory. Questa funzionalità, chiamata Fine-Grained Password Policy, permette di definire configurazioni differenti per le password e le account lockout policy per differenti tipi di utenti all’interno del dominio.

Supponiate infatti che la password policy per gli amministratori di dominio o per gli utenti privilegiati richieda un numero minino di caratteri superiore a quelli di un utente limitato. Con la Fine-Grained Password Policy (FGPP) potete applicare la policy direttamente al gruppo di utenti interessato.

Non potete comunque applicare la policy alla singola Organizational Unit (OU). Potreste però creare uno Shadow Group, cioè un gruppo a cui vengono aggiunti tutti gli utenti di una determinata OU con uno script PowerShell automatico ed applicare la FGPP allo Shadow Group. Online trovate decine di esempi di script su come creare uno Shadow Group ed aggiungerci in maniera automatica gli utenti presenti nella OU.

Per creare una FGPP vi rimando alla lettura dell’articolo Step-by-Step: Enabling and Using Fine-Grained Password Policies in AD

Figura 2: Configurazione di una Fine-Grained Password Policy per il gruppo Domain Admins

All’atto pratico, la Fine-Grained Password Policy non modifica nessuna Group Policy, ma modifica un attributo dell’utente chiamato msDS-ResultantPSO. È importante applicare alla FGPP una precedenza, perché nel caso l’utente appartenga a gruppi diversi e a questi gruppi siano state applicate diverse FGPP, la precedenza diventa determinante perché vincerà la FGPP con il valore di precedenza più basso.

Figura 3: Verifica della corretta applicazione della FGPP ad un utente del gruppo a cui è stata applicata la policy

Conclusioni

Spero con questo articolo di aver dipanato alcuni dubbi in merito all’applicazione delle password policy, soprattutto per quanto riguarda le tempistiche di applicazione dopo che avete modificato alcuni parametri, e di avervi indicato il giusto modo per procedere ad una corretta configurazione delle stesse.

Buon lavoro!

Nic

Configurare l’accesso sicuro ad Azure AD utilizzando Privileged Identity Management

Facebooktwittergoogle_plusredditlinkedin

In qualsiasi realtà aziendale è necessario effettuare delle attività di amministrazione informatica che richiedono dei permessi amministrativi elevati ed è una buona pratica che gli utenti abbiano sempre i minori permessi amministrativi possibili, per assicurare un buon livello di sicurezza ed impedire che vengano effettuate delle operazioni senza consenso (volutamente o per sbaglio). È interessante anche limitare nel tempo eventuali permessi amministrativi, giusto il tempo necessario per effettuare l’operazione. Mi è capitato spesso di vedere account privilegiati assegnati ad un consulente esterno che poi non sono stati più rimossi e questo mette a forte rischio la sicurezza aziendale.

Ho avuto modo qualche tempo fa di mostrarvi una nuova funzionalità  introdotta in Windows Server 2016 che si basa sul principio dell’amministrazione Just In Time (JIT) nell’articolo Privileged Access Management e Temporary Group Membership in Windows Server 2016 AD e ho già affrontato il tema della Gestione dell’accesso alle macchine virtuali in Microsoft Azure con la funzionalità JIT (Just-in-Time)

In questo articolo voglio invece parlarvi di come rendere sicuro l’accesso ad Azure AD (e quindi a tutte le risorse che gestisce) utilizzando Privileged Identity Management, che permette di assegnare permessi amministrativi limitati nel tempo e che permette di monitorare e approvare questo tipo di accessi privilegiati.

Privileged Identity Management (PIM) richiede però che abbiate una sottoscrizione Azure AD Premium P2 oppure che abbiate Enterprise Mobility + Security E5. Per chi non conoscesse le differenze tra le diverse edizioni di Azure AD consiglio vivamente la lettura del documento Informazioni su Azure Active Directory, mentre per il pricing vi rimando al link Prezzi di Azure Active Directory

I vantaggi nell’uso di Azure AD Privileged Identity Management sono davvero notevoli e vi permettono di:

  • Vedere a quali utenti vengono assegnati i ruoli con privilegi per gestire le risorse di Azure
  • Abilitare l’accesso come amministratore JIT su richiesta ad Office 365 e alle risorse di Azure (sottoscrizioni, gruppi di risorse e alle singole risorse)
  • Visualizzare una cronologia dell’attivazione dell’amministratore, comprese le modifiche che gli amministratori hanno apportato alle risorse di Azure
  • Essere avvisati delle modifiche apportate nelle assegnazioni del ruolo di amministratore
  • Richiedere l’approvazione per attivare i ruoli di amministratore con privilegi di Azure AD
  • Esaminare l’appartenenza dei ruoli di amministratore e richiedere agli utenti di fornire una giustificazione per l’appartenenza continua ad un determinato ruolo

Abilitare Privileged Identity Management per la directory di Azure

Per cominciare è necessario che accediate al portale di gestione di Azure AD utilizzando i privilegi di un Global Administrator. Decidete di aggiungere una nuova risorsa e scegliete Azure AD Privileged Identity Management. Seguite le indicazioni presenti in console e fate clic su Create.

Figura 1: Aggiunta della risorsa Azure AD Privileged Identity Management

Come accennato prima, per poter aggiungere questa funzionalità è necessario abilitare un piano di Azure AD Premium 2. Potete attivare anche una trial della durata di 30 giorni per testare tutte le funzionalità offerte dal piano.

Figura 2: Attivazione della trial di Azure AD Premium P2

Per poter attivare Privileged Identity Management è necessario che venga verificata l’identità del Global Administrator che la sta attivando. Seguite il wizard ed utilizzate la multi-factor authentication per poter assicurare l’attivazione, come mostrato in figura:

Figura 3: Richiesta della verifica dell’identità prima dell’attivazione di Privileged Identity Management

Figura 4: Completamento della verifica dell’identità con l’utilizzo della multi-factor authentication

Dopo aver effettuato la verifica, confermate l’attivazione facendo clic sul punsante Consent, come mostrato in figura:

Figura 5: Consenso all’attivazione di PIM

La procedura non è ancora terminata e l’ultimo passaggio richiede che effettuiate il Sign Up di Privileged Identity Management ai ruoli di Azure AD directory.

Figura 6: Sign Up di PIM ai ruoli di Azure AD directory

Adesso che avete completato tutti gli step per l’attivazione della funzionalità di Privileged Identity Mangement, potrete visualizzare tutti i ruoli che sono stati assegnati nella vostra directory di Azure AD.


Figura 7: Ruoli assegnati nella directory di Azure AD

Gestione dei ruoli e degli accessi privilegiati

In questa guida utilizzerò il mio tenant di Office 365 e la relativa Azure Directory. Nel tenant è presente un utente, che si chiama Murphy Law, che attualmente è un Exchange Administrator.

Figura 8: Utente con un ruolo permanente di Exchange Administrator

La verifica del ruolo può essere fatta anche dal portale di Azure AD.

Figura 9: Verifica del ruolo dal portale di Azure AD

Sicuramente molti di voi conosceranno la Legge di Murphy e penseranno che probabilmente non sia il caso di affidare la gestione di Exchange Online ad un utente con un nome simile, soprattutto di non farlo in maniera permanente. Io tra l’altro sono molto d’accordo con la Chiosa di O’Toole alla legge di Murphy: Murphy era un ottimista. Per questo motivo ho deciso di convertire il ruolo di Exchange Administrator all’utente Murphy Law da Permanente ad Eleggibile. Murphy potrà richiedere di diventare Exchange Administrator quando ne avrà bisogno, ma per il resto del tempo rimarrà un utente limitato.

Figura 10: Modifica del ruolo di Exchange Administrator da Permament ad Eligible

Figura 11: Verifica della conversione del ruolo

Dal portale amministrativo di Office 365 adesso risulterà che Murphy Law è un semplice utente, senza alcun ruolo amministrativo.

Figura 12: Murphy è diventato un utente senza privilegi amministrativi

Richiesta di appartenenza temporanea ad un ruolo amministrativo

Quando l’utente dovrà effettuare delle operazioni su Exchange Online e avrà bisogno dei privilegi corretti, potrà connettersi al portare di Azure AAD con le proprie credenziali e dal nodo di Privileged Identity Management potrà fare richiesta di attivazione di uno dei ruoli che sono per lui eleggibili, come mostrato in figura:

Figura 13: Richiesta di attivazione di uno dei ruoli per cui l’utente è eleggibile

Figura 14: Richiesta di conferma dell’identità tramite multi-factor authentication

Il ruolo potrà essere attivato per un certo numero di ore, che sono determinate dal “template” del ruolo e che posso essere modificate, e può essere attivato a partire da una certa data e ora invece che immediatamente.

Figura 15: Attivazione temporanea del ruolo con attivazione personalizzata del tempo di inizio

Nel portale amministrativo è possibile verificare l’attivazione del ruolo, la durata e la scadenza dello stesso.

Figura 16: Verifica dell’attivazione del ruolo dal portale di Azure AAD

Da questo momento in poi e per la durata di un’ora l’utente farà parte degli Exchange Administrator.

Gestione del processo di attivazione del ruolo

Come abbiamo visto, l’utente si è auto-attivato il ruolo. È però possibile fare in modo che, prima dell’attivazione, sia necessaria l’approvazione da parte di un utente ancora più privilegiato. Per poter usare l’approvazione è necessario modificare il comportamento del ruolo. Loggatevi in Azure AAD e selezionate Azure AD Privileged Identity Management. Dal nodo Azure Active Directory Roles scegliete Roles e poi selezionate il ruolo che volete modificare. Potete modificarne la durata, potete richiedere che venga mandata una mail agli amministratori ogni volta che il ruolo viene attivato ma soprattutto potete attivare l’approvazione, come mostrato in figura:

Figura 17: Modifica del ruolo di Exchange Administrator ed attivazione dell’approvazione

Terminata la procedura, ogni volta che verrà effettuata una richiesta per avere il ruolo di Exchange Administrator, l’Approver riceverà una mail con la richiesta e potrà decidere se concedere o rifiutare la richiesta.

Figura 18: Mail di richiesta per l’approvazione del ruolo

Figura 19: Approvazione o rifiuto della richiesta dal portare di Azure AD

Conclusioni

Azure AD Privileged Identity Management (PIM) è disponibile con il piano AAD Premium P2 e permette alle aziende di poter controllare meglio quando gli utenti utilizzano gli account privilegiati. Poter limitare nel tempo i privilegi ed utilizzare la Just in Time Administration è sicuramente vantaggioso in termini di sicurezza e permette di poter gestire nel cloud lo stesso principio del Least Administrative Privilege che “dovremmo” avere in azienda. Per approfondimenti sul tema vi rimando alla lettura dell’articolo Iniziare ad usare Azure AD Privileged Identity Management

Buon lavoro!

Nic

Joinare computer Windows 10 ad Azure AD ed effettuare connessioni in RDP

Facebooktwittergoogle_plusredditlinkedin

Dalla versione di Windows 10 Anniversary Update (Professional oppure Enterprise) è possibile aggiungere il sistema operativo client di casa Microsoft ad Azure Active Directory (Azure AD), la directory basata sul cloud multi-tenant usata come servizio di gestione delle identità, che combina i servizi di directory, la gestione dell’accesso delle applicazioni e la protezione delle identità in un’unica soluzione.

Per avere un’idea dei possibili vantaggi e degli scenari di utilizzo di un computer Windows 10 joinato ad Azure AD vi consiglio di leggere prima l’articolo Usage scenarios and deployment considerations for Azure AD Join

In ogni caso potete joinare ad Azure AD solo un computer in Workgroup. Se avete un computer già joinato al dominio locale e volete approfittare delle funzionalità di Single Sign-On, potete invece Connettere un computer in dominio ad Azure AD (Workplace Join). Si tratta quindi di due funzionalità completamente diverse. Per completezza vi inserisco una tabella che riassume le differenze:

Figura 1: tabella riassuntiva delle differenze di funzionalità tra Azure AD Join e Workplace Join

In questo articolo mi occuperò solo di Azure AD Join

Gli utenti possono joinare i propri dispositivi Windows 10 sia durante la first-run experience, il momento in cui si accende il dispositivo per la prima volta ed è necessario inserire le prime informazioni per completare l’installazione, sia dall’app Settings, dove si può decidere se connettere il sistema operativo ad Azure AD oppure joinarlo. Se joinate Windows 10 ad Azure AD potete utilizzare le credenziali di Azure AD per potervi loggare al PC ed utilizzare la funzionalità di Single Sign-On (SSO) quando accedete alle applicazioni SaaS basate sul cloud ed ad Office 365.

È anche possibile impedire agli utenti ed ai gruppi creati in Azure AD la possibilità di joinare i propri dispositivi o limitarne il numero, oltre a forzare l’uso della multi-factor authentication. Dopo che un utente ha joinato il proprio dispositivo in Azure AD è possibile controllarne il comportamento, è possibile cancellarlo, bloccarlo oppure gestirlo con un software di Mobile Device Management (come Microsoft Intune).

Se decidete di joinare Windows 10 durante la first-run experience, i passaggi da seguire cambiano in base alla release di Windows 10 che state utilizzando e sono descritti nell’articolo Aggiungere un nuovo dispositivo Windows 10 con Azure AD in fase di completamento dell’installazione. In sintesi, i passaggi da effettuare sono i seguenti:

  1. Quando si accende il nuovo dispositivo e viene avviato il processo di installazione, viene visualizzato il messaggio Preparazione . Seguite le istruzioni per configurare il dispositivo.
  2. Iniziate personalizzando il paese e la lingua. Quindi accettate le Condizioni di licenza software Microsoft.
  3. Selezionate la rete che desiderate usare per la connessione a Internet.
  4. Fate clic su Questo dispositivo appartiene all’organizzazione.
  5. Immettete le credenziali di Azure AD e quindi fate clic su Accedi.
  6. Il dispositivo individua un tenant in Azure AD. Se si è in un dominio federato, si verrà reindirizzati al server del servizio token di sicurezza locale, ad esempio Active Directory Federation Services (AD FS). Se si è in un dominio non federato, immettete le credenziali direttamente nella pagina ospitata da Azure AD.
  7. Vi viene richiesto di effettuare l’autenticazione a più fattori (non obbligatoria).
  8. Windows registra il dispositivo nella directory dell’organizzazione in Azure AD

Nel mio caso invece, ho deciso di joinare ad Azure AD una macchina virtuale con Windows 10 Professional che ho creato nel Cloud Azure. Non potendo accedere alla schermata della first-run experience, mi sono prima loggato a Windows 10 con le credenziali amministrative in mio possesso e successivamente ho lanciato l’applicazione Settings, che mi permette di gestire gli Accounts. Dalla funzionalità Access Work or School ho cliccato su Connect e poi sul link Join this device to Azure Active Directory, come mostrato in figura:

Figura 2: Schermata iniziale per l’aggiunta di un computer Windows 10 ad Azure AD

Nella schermata successiva ho inserito le credenziali di un utente di Azure AD (non serve che sia un utente privilegiato nel vostro tenant di Azure, può essere un utente qualsiasi).

Figura 3: Inserimento delle credenziali dell’utente a cui associare il dispositivo Windows 10

Figura 4: Inserimento password

Figura 5: L’account che ho usato utilizza la multi-factor authentication (non obbligatoria)

Dopo aver inserito le credenziali, un avviso vi dirà che l’account di Azure AD verrà aggiunto al gruppo Administrators locali della macchina Windows 10 e che alcune policy potrebbero essere applicate alla macchina.

Figura 6: Avviso riguardo l’applicazione di policy sulla macchina Windows 10 dopo il join ad Azure AD

Figura 7: Conferma dell’avvenuto join ad Azure AD

Nella scheda Access work or School adesso appare l’utente che avete utilizzato, a fianco del simbolo di una borsa di lavoro.

Figura 8: Informazioni sull’utente connesso

Se accedete al Pannello di controllo e verificate i membri del gruppo Administrators, vedrete che è stato aggiunto un account con il nome AzureAD\NicolaFerrini, come mostrato in figura.

Figura 9: L’utente di Azure AD è stato aggiunto al gruppo Administrators

Dal portale di Azure è anche possibile verificare in Azure Active Directory che un nuovo dispositivo è stato aggiunto alla directory dove si trova l’utente che avete utilizzato per joinare Windows 10.

Figura 10: Il nuovo dispositivo Windows 10 aggiunto ad Azure AD

Cliccando sul dispositivo sarà possibile ricevere maggiori informazioni, sarà possibile disabilitarlo o anche rimuoverlo.

Figura 11: Proprietà del dispositivo aggiunto ad Azure AD

Connessione in RDP ad un computer joinato ad Azure AD

Per testare la funzionalità di Single Sign-On (SSO) è necessario loggarsi al computer con le credenziali di Azure AD (in genere AzureAD\NomeCognome). Nel mio caso però, poiché la macchina è ospitata su Azure, non ho la possibilità di connettermi in console e devo necessariamente farlo in Desktop Remoto (RDP). Ho quindi fatto logoff con l’utente che stavo utilizzando e ho provato a loggarmi con le credenziali di Azure AD. Infatti l’utente di Azure AD fa parte del gruppo Administrators locali della macchina, che possono accedere di default in RDP. Dopo aver inserito username e password invece ho ottenuto il seguente errore:

Figura 12: Connessione in RDP alla macchina Windows 10 utilizzando le credenziali di Azure AD

Figura 13: Errore di login in RDP usando le credenziali dell’utente di Azure AD

L’accesso in RDP alle macchine Windows 10 è possibile a partire da Windows 10 versione 1607. Entrambi i PC (locale e remoto) devono eseguire Windows 10 versione 1607 o versioni successive. È necessario però che il  Remote Credential Guard, una nuova funzionalità di Windows 10 versione 1607, sia disattivata nel PC client che utilizzate per connettervi al PC remoto.

Ovviamente è un’opzione che NON consiglio, visto che poi esporrebbe il vostro client alla perdita di credenziali per tutte le connessioni RDP e ad attacchi di tipo Pass The Hash.

In alternativa è possibile effettuare queste operazioni:

  • Disabilitare nel computer remoto Windows 10 joinato ad Azure AD la Network Level Authentication
  • Modificare il file .RDP utilizzato per la connessione aggiungendo i valori:
    • enablecredsspsupport:i:0
    • authentication level:i:2

Per disabilitare la Network Level Authentication vi basta andare nel Pannello di controllo e dalle proprietà del Sistema, utilizzate il tab Remote per rimuovere il segno di spunta dalla abilitazione della Network Level Authentication come mostrato in figura:

Figura 14: Disabilitazione della Network Level Authentication

Per modificare il file .RDP vi basta aprirlo con Notepad++ (o con un altro editor di testo a vostra scelta) e aggiungere le due righe sopra indicate, come mostrato in figura:

Figura 15: Modifica del file .RDP

A questo punto, se lanciate la connessione remota utilizzando il file .RDP modificato, il processo di autenticazione sarà diverso. Prima vi apparirà il messaggio di errore del certificato presentato dal client Windows 10 e successivamente vi verrà chiesto di inserire le credenziali di Azure AD

Figura 16: Connessione al computer remoto effettuata

Figura 17: Inserimento delle credenziali di Azure AD

Nonostante l’utente utilizzando abbia la Multi-factor authentication abilitata, per le connessioni RDP non verrà richiesta.

Figura 18: Verifica dell’utente connesso in RDP

Adesso che l’utente è connesso con il suo account di Azure AD potrà approfittare della funzionalità di Single Sign-On (SSO) per loggarsi al portale di Azure o al portale di Office 365, senza che gli vengano chieste le credenziali di autenticazione, utilizzando il browser Edge. Altri browser alternativi, come Google Chrome o Mozilla Firefox non sono compatibili con l’SSO.

Figura 19: L’accesso al portale di Office 365 con l’account di Azure AD e con il browser Edge non richiede l’inserimento delle credenziali di accesso

Conclusioni

Numerosi sono i motivi per cui potrebbe essere utile joinare un computer ad Azure AD. Tra i tanti, è possibile configurare utenti e dipendenti in modo che usino i dispositivi Windows personali (BYOD, Bring Your Own Device) per accedere alle App e alle risorse aziendali (applicazioni SaaS). Gli utenti possono aggiungere i propri account Azure AD (account aziendali o account scolastici) a un dispositivo personale Windows per accedere alle risorse ed alle applicazioni in totale sicurezza e conformità. I dispositivi possono anche essere assoggettati ad alcune policy di sicurezza e possono essere gestiti da remoto con software di Mobile Device Management. Rimane a mio avviso ancora difficile e poco sicuro connettersi in RDP a questi dispositivi e spero che ben presto venga innalzato il livello di sicurezza e non sia necessario effettuare dei workaround.

Buon lavoro!

Nic

RDP Update Windows 10 : Errore di connessione per la “Crittografia Oracle per CredSSP”

Facebooktwittergoogle_plusredditlinkedin

Facilmente molti di voi ultimamente si sono imbattuti nel seguente errore “La Funzione richiesta non è supportata” relativamente alla crittografia Oracle per CredSSP quando si tenta di connettersi in RDP “Desktop Remoto” con Windows 10. L’errore esatto è il seguente:

Connessione Desktop Remoto
Errore di autenticazione.
La funzione richiesta non è supportata.
Computer remoto: nomeserver

La causa potrebbe essere la Correzione crittografia Oracle per CredSSP.
Per altre informazioni, vedi https://go.microsoft.com/fwlink/?linkid=866660

Errore rdp

 

 

 

 

 

 

 

 

Questo errore è causato da un aggiornamento di Windows 10 che ha corretto alcune vulnerabilità del Credential Security Support Provider protocol (CredSSP), nello specifico gli update dell’8 Maggio “incriminati” sono:

KB4103721 -> Build 1803
KB4103727 -> Build 1709
KB4103731 -> Build 1703
KB4103723 -> Build 1609 e Windows Server 2016

Per ovviare al problema, non ricevere l’errore e potersi collegare bisogna che sia il client che il server abbiano ricevuto ed installato l’update (soluzione ideale e più sicura).

Nel caso più frequente in cui il client si sia aggiornato ma che il server non lo fosse ancora bisogna seguire questa procedura (ovviamente per ragioni di sicurezza non consigliata):

Click su start e scrivere ESEGUI (oppure tasto Windows + R) e digitare gpedit.msc

Nella maschera che si apre selezionare CONFIGURAZIONE COMPUTER –> MODELLI AMMINISTRATIVI –> SISTEMA –> DELEGA CREDENZIALI e selezionare nella colonna di destra, con un doppio click, la voce CORREZIONE CRITTOGRAFIA ORACLE

Nella maschera successiva selezionare ATTIVATA e nel menu’ a tendina LIVELLO DI PROTEZIONE selezionare la voce VULNERABILE.

Gpedit

Premere OK e chiudere la finestra princiapale.

A questo punto ci si potrà connettere in desktop remoto al server.

Nel caso non si possa accedere a gpedit (ad es. windows 10 home) occorre modificare o, se non ancora esistente, creare una nuova chiave di registro nel seguente percorso:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\

-> AllowEncryptionOracle = DWORD / valore = 2

Se vuoi fare prima puoi crearti un file .reg e incollarci in seguente contenuto:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters]
“AllowEncryptionOracle”=dword:00000002

Registro

Occorre poi un riavvio.

Per maggiori info: Link 

 

 

Configurare Azure Active Directory Conditional Access per le applicazioni SaaS

Facebooktwittergoogle_plusredditlinkedin

Azure Active Directory (Azure AD) è il servizio di gestione delle identità di Microsoft che combina in un’unica soluzione i servizi di directory, la gestione dell’accesso delle applicazioni e la protezione delle identità. Inoltre permette l’accesso Single Sign-On (SSO) a migliaia di app SaaS basate sul cloud e app locali. Il Single Sign-On permette di accedere alle applicazioni effettuando l’accesso solo una volta con un singolo account utente. Dopo aver effettuato l’accesso, è possibile accedere a tutte le applicazioni necessarie senza dover ripetere una seconda volta l’autenticazione (ad esempio, digitando una password). La configurazione di Single Sign-On basato su password consente agli utenti dell’organizzazione di accedere automaticamente a un’applicazione SaaS di terze parti tramite Azure AD utilizzando le informazioni dell’account utente dall’applicazione SaaS di terze parti. Per maggiori informazioni vi rimando all’articolo Informazioni sull’accesso alle applicazioni e Single Sign-On con Azure Active Directory ed al video Single Sign On to Applications

Figura 1: Il Single Sign-On permette di accedere alle applicazioni effettuando l’accesso solo una volta con un singolo account utente

In un mondo dominato dai dispositivi mobili e basato sul cloud, la sicurezza è una priorità assoluta per le aziende e, poiché gli utenti possono accedere alle risorse aziendali da una serie di dispositivi e ovunque si trovino, è necessario che oltre a stabilire chi possa accedere a determinate risorse diventa fondamentale anche decidere il modo in cui accedere. L’accesso condizionale è una funzionalità di Azure Active Directory che consente di applicare controlli sull’accesso in base a specifiche condizioni.

Figura 2: Schema di funzionamento di Azure Conditional Access

Con i criteri di accesso condizionale è possibile controllare il modo in cui gli utenti autorizzati (che hanno ottenuto l’accesso a un’App cloud) possono accedere alle App cloud in condizioni specifiche. Per poter abilitare questa funzionalità loggatevi al portale Azure e selezionate il nodo Azure Active Directory. Cliccando su Conditional Access avrete la possibilità di definire la policy di accesso alle applicazioni. Per poter utilizzare questa funzionalità è necessario però abilitare il piano Premium P2 di Azure AD. Se non lo avete già fatto potete abilitare una trial gratuita, come mostrato in figura:

Figura 3: Abilitazione della trial di Azure AD Premium

Figura 4: Scelta della versione trial da attivare

Per maggiori informazioni su Azure AD Premium P2, sulle funzionalità che vengono abilitate e sui prezzi potete leggere l’articolo https://azure.microsoft.com/it-it/pricing/details/active-directory/

Una volta terminata l’attivazione avrete la possibilità di creare una nuova policy di accesso condizionale. Cliccate su New Policy per creare un nuovo set di regole.

Figura 5: Policy di accesso condizionale

Voglio creare una policy che obblighi gli utenti ad usare la Azure Multi-Factor Authentication quando si connettono dall’esterno dell’azienda (al di fuori della rete aziendale) e voglio permettere solo alcuni tipi di dispositivi (smartphone Android). La prima impostazione che è possibile fare consiste nel dichiarare a quali utenti o a quali gruppi deve essere associata la policy, come mostrato in figura:

Figura 6: Scelte dei gruppi o degli utenti a cui applicare la policy

La scelta successiva consiste nel selezionare quali App, tra quelle disponibili, saranno soggette alla policy. Potete scegliere tutte le applicazioni oppure selezionarne solo alcune, come mostrato in figura:

Figura 7: Scelta delle applicazioni da filtrare

È possibile dare alla policy un indicazione sul rischio quando si usano le App. Il rischio di accesso è un’indicazione della probabilità (elevata, media o bassa) che un tentativo di accesso non sia stato eseguito dal legittimo proprietario di un account utente. Azure AD calcola il livello di rischio di accesso durante l’accesso di un utente. Nel mio caso ho deciso di assegnare il valore High perché le applicazioni che ho selezionato sono critiche per la mia azienda.

Figura 8: Scelta del valore di rischio

È possibile anche fare in modo che l’applicazione sia lanciata solo da alcune piattaforme, sia Pc che smartphone.

Figura 9: Scelta della piattaforma da cui viene avviata l’applicazione

Poiché la policy serve a filtrare l’accesso e a consentire l’utilizzo dell’App solo tramite Azure Multi-factor Authentication, decido di impostarla per qualsiasi Location ed escludo quelle che sono invece le Trusted Location. Successivamente definirò la Trusted Location (la mia rete aziendale) e quando i dispositivi si trovano in azienda non saranno sottoposti alla policy.

Figura 10: Configurazione della Location dove si devono trovare i dispositivi quando lanciano l’applicazione

Figura 11: Esclusione dalla policy delle Trusted Locations

È possibile anche stabilire quali client verranno utilizzati per connettersi all’App e poterne eventualmente impedire l’accesso

Figura 12: Scelta dei client che potranno essere utilizzati per connettersi all’App

Figura 13: Scelta del Device State

A questo punto stabilisco il controllo dell’accesso e permetto l’accesso solo a chi usa la multi-factor authentication, come mostrato in figura:

Figura 14: Configurazione del controllo dell’accesso e relative impostazioni

Il passaggio finale è l’abilitazione della policy.

Figura 15: Abilitazione della policy

Poiché ho creato l’eccezione nella policy che consente l’utilizzo dell’applicazione senza multi-factor authentication, devo definire quali sono le Trusted Location. Per farlo basta cliccare su Named Locations e poi selezionale New Location, come mostrato in figura. A questo punto potrete definire l’indirizzo IP della vostra rete aziendale o il range degli indirizzi. È anche possibile definire quali sono gli indirizzi IP che vengono considerati sicuri e non soggetti alla multi-factor authentication utilizzando il collegamento Configure MFA trusted IPs

Figura 16: Creazione della Trusted Location

Dopo aver creato la policy è possibile testarla da un dispositivo che non sia nella rete aziendale o che non sia collegato tramite un Trusted IPs. Navigate all’indirizzo https://myapps.microsoft.com e autenticatevi. Dopo l’autenticazione vi apparirà la lista delle applicazioni a cui siete abilitati.

Figura 17: Lista delle applicazioni disponibili per l’utente

Figura 18: Logon all’applicazione automatico (notate la freccia in figura)


Figura 19: Logon all’applicazione da un device Android

Conclusioni

In Azure AD gli utenti possono accedere alle App cloud da una vasta gamma di dispositivi, inclusi i dispositivi mobili (smartphone, tablet) e i dispositivi personali (notebook, Pc). Con l’accesso condizionale possiamo aumentare il livello di sicurezza per l’accesso alle App, facendo in modo che la connessione all’App sia consentita solo da alcune applicazioni (ad esempio il browser), solo da alcuni dispositivi (ad esempio smartphone Android, iPhone, PC o Mac) e solo da alcune reti (solo la rete aziendale). Se volete acquisire familiarità con la configurazione dei criteri di accesso condizionale vi consiglio di leggere anche l’articolo Introduzione all’accesso condizionale in Azure Active Directory.

Buon lavoro!

Nic