Archivi categoria: Windows 10

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

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

Impossibile connettersi via RDP a macchine on-premises o alle Azure Virtual Machine: Errore CredSSP Encryption Oracle Remediation

Facebooktwittergoogle_plusredditlinkedin

A partire dall’ 8 Maggio 2018, a seguito del rilascio da parte di Microsoft degli aggiornamenti mensili ed in particolar modo della KB4103727, diversi utenti stanno ricevendo una serie di errori nei collegamenti RDP dovuti alla CredSSP Encryption Oracle Remediation.

Le connessioni Desktop remoto (RDP) sono infatti soggette ad una vulnerabilità di “Remote Code Execution” che è stata descritta nella CVE-2018-0886. Già dal 18 Marzo 2018 Microsoft aveva rilasciato una patch per poter gestire questa vulnerabilità e aveva introdotto una Group Policy per mitigarne i rischi. Se volete conoscere l’evoluzione degli aggiornamenti per questa vulnerabilità potete leggere l’articolo CredSSP updates for CVE-2018-0886

Con le patch contenute nel Cumulative Update di Maggio 2018, la Group Policy è stata modificata ed il valore è passato da Vulnerable Mitigated. Il parametro lo trovate in Computer Configuration -> Administrative Templates -> System -> Credentials Delegation

Questa modifica al parametro della Group Policy obbliga la connessione RDP ad essere instaurata solo se dall’altra parte risponde una macchina che abbia ricevuto l’aggiornamento della KB4103727

Per maggiori informazioni sui diversi valori che il parametro può avere potete fare riferimento all’articolo https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018

Figura 1: Policy utilizzata per la gestione della vulnerabilità di CredSSP Encryption

Per verificare che abbiate installato la KB “incriminata” (KB4103727) potete lanciare un prompt di PowerShell con privilegi elevati ed eseguire il comando Get-Hotfix

Figura 2: Aggiornamenti installati sul sistema operativo client

Problema

Sul mio client Windows 10 ho installato la KB4103727 e quando ho tentato di connettermi ad una macchina dove la patch non era installata ho ricevuto il seguente messaggio di errore:

Figura 3: Impossibile collegarvi via RDP su una macchina non aggiornata

Anche controllando il Registro Eventi l’errore appare chiaro:

Figura 4: Errore nel Registro Eventi relativo al fallimento della negoziazione sicura della connessione

Il comportamento delle macchine può essere riassunto in questo modo:

  • se sia il client che la VM o il PC hanno la patch, la connessione avverrà in maniera sicura
  • se il client ha la patch ma la VM o il PC non ce l’hanno, apparirà un messaggio di errore e non sarà possibile connettersi
  • se il client non ha la patch ma la VM o il PC ce l’hanno, sarà possibile collegarsi via RDP ma la connessione non sarà sicura

Soluzione

Per ovviare al problema è possibile modificare la Policy che vi ho indicato prima (mettendo il valore su Vulnerable) o disinstallare la KB4103727 oppure modificare il registro utilizzando il comando

REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 2

Io sconsiglio queste soluzioni. La cosa migliore da fare è aggiornare tutte le VM ed i PC installando gli aggiornamenti di sicurezza consigliati. Per aggiornare un PC o una VM potete utilizzare Windows Update oppure un server WSUS.

Figura 5: Aggiornamenti di Maggio 2018 su Windows Server 2016

Figura 6: Aggiornamenti di Maggio 2018 su Windows 10

Connessione ad una VM in Microsoft Azure e installazione della patch mancante

Se tentate di connettervi ad una VM in Azure in cui non avete installato la patch KB4103727, allora ricevete l’errore descritto prima e sarà necessario aggiornarla o mitigare la vulnerabilità.

Nel mio caso però la VM non è in dominio e non ho la possibilità di accedervi in console. Per installare la patch mi sono servito della funzionalità di Azure Update Management, una soluzione che vi permette di eseguire gli aggiornamenti per le macchine Windows e per le macchine Linux direttamente dal portale di Azure e tramite un Automation Account.

Figura 7: Abilitazione della soluzione Azure Update Management

Il principio di funzionamento di Azure Update Management è molto semplice e può essere riassunto dal seguente diagramma:

Figura 8: Principio di funzionamento di Azure Update Management

Tipi di client supportati:

La tabella seguente elenca i sistemi operativi supportati:

Sistema operativo Note
Windows Server 2008, Windows Server 2008 R2 RTM Supporta solo le valutazioni degli aggiornamenti
Windows Server 2008 R2 SP1 e versioni successive Sono richiesti .NET Framework 4.5 e WMF 5.0 o versioni successive per Windows Server 2008 R2 SP1
CentOS 6 (x86/x64) e 7 (x64) Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.
Red Hat Enterprise 6 (x86/x64) e 7 (x64) Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.
SUSE Linux Enterprise Server 11 (x86/x64) e 12 (x64) Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.
Ubuntu 12.04 LTS e versioni x86/x64 più recenti Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.

Dopo pochissimi minuti dall’abilitazione della soluzione, la macchina verrà testata e verranno mostrati gli aggiornamenti mancanti. Come è possibile vedere dalla figura, manca il Security Update KB4103723

Figura 9: Aggiornamenti mancanti sulla VM

Fate clic sul pulsante Schedule update deployment che vi appare nel blade del portale di Azure e programmate quando volete effettuare l’aggiornamento. L’aggiornamento non è programmabile prima di 30 minuti e potete scegliere di eliminare alcune patch dall’installazione.

Figura 10: Programmazione dell’aggiornamento della VM

Una volta che avete schedulato l’aggiornamento non vi resta che attendere. La programmazione sarà visibile cliccando su Scheduled update deployment, come mostrato in figura:

Figura 11: Aggiornamenti programmati

Conclusioni

Avere le macchine sempre aggiornate e lavorare con sistemi operativi sicuri è un prerequisito importante per non essere soggetti alle vulnerabilità dei software e dei sistemi operativi e non perdere i propri dati. Prima di aggiornare però assicuratevi di fare dei test sulla vostra infrastruttura e verificate che tutto continui a funzionare prima di distribuire in maniera massiva gli aggiornamenti.

Buon lavoro!

Nic

Windows 10 problemi di connessione RDP dopo l’aggiornamento CredSSP

Facebooktwittergoogle_plusredditlinkedin

Windows 10 problemi di connessione RDP dopo l'aggiornamento CredSSP

windows-10-rdp-connection-fails-01

Un aggiornamento di sicurezza rilasciato recentemente per Windows 10 e documentato nel KB4103727, compromette la funzionalità RDP causando il fallimento della connessione RDP verso la macchina di destinazione visualizzando un errore relativo al CredSSP encryption oracle remediation.

Il protocollo CredSSP (Credential Security Support Provider ) è un provider di authenticazione che processa le richieste di autenticazione per altre applicazioni. Questo errore si verifica quando una macchina Windows 10 aggiornata tenta di connettersi via RDP ad un Server Windows non aggiornato.

 

Problema connessione RDP

L’errore si verifica quando si tenta di effettuare una connessione RDP con un server di destinazione non ancora aggiornato con l’update CredSSP.

windows-10-rdp-connection-fails-02

Dopo aver inserito le credenziali di autenticazione, viene visualizzato il seguente messaggio.

windows-10-rdp-connection-fails-03

Sebbene si dovrebbe effettuare l’aggiornamento sia dei client e sia dei server della propria rete per evitare questa problematica e per motivi di sicurezza, un workaround provvisiorio per permettere le connessioni RDP da un client Windows 10 client è di editare il registro e modificare la chiave AllowEncryptionOracle in questo modo:

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

Accedere al Registry Editor ed individuare la chiave di registro indicata. Effettuare un doppio click sulla REG_DWORD AllowEncryptionOracle e digitare 2 come Value data, quindi cliccare su OK per salvare la configurazione.

windows-10-rdp-connection-fails-04

Dopo aver modificato il registro, il client Windows 10 client è in grado di connettersi correttamente al server di destinazione non aggiornato.

signature

Copyright Nolabnoparty. All Rights Reserved.

Le novità di Horizon 7 e Horizon Cloud

Facebooktwittergoogle_plusredditlinkedin

Courtney Burry, Sr. Director of Product Marketing, EUC

Nonostante l’enorme crescita di SaaS e l’adozione di app mobile, le applicazioni legacy e personalizzate di Windows rappresentano ancora una parte considerevole delle app utilizzate oggi nella maggior parte degli ambienti aziendali. Ma con Windows 10 (e i suoi numerosi aggiornamenti), la gestione di questi tipi di app è diventata ancora più dispendiosa in termini di tempo e denaro.

Non sorprende che molti si siano rivolti alla virtualizzazione per gestire queste app, in particolare nell’ambito di una strategia di digital workspace più ampia, in modo da poter amministrare, garantire e proteggere queste app nello stesso modo in cui è possibile farlo per gli ambienti Web e mobile.

In VMware, continuiamo a guidare l’innovazione nella nostra offerta di virtualizzazione per desktop e applicazioni per aiutarti a gestire in modo semplice ed economico queste app Windows legacy. Inoltre, stiamo integrando strettamente questo portfolio nella nostra piattaforma VMware Workspace ONE, consentendoti di sfruttare la virtualizzazione come parte della tua strategia di digital workspace più ampia. E stiamo rendendo più semplice che mai il deployment di desktop e app virtuali on-premise, nel cloud o in una combinazione dei due. Quindi sono entusiasta di parlare delle novità dei nostri prodotti di punta per la virtualizzazione del desktop e delle applicazioni: VMware Horizon e Horizon Cloud.

Horizon 7 si unisce a VMware Cloud on AWS

VMware Cloud ha consentito alle organizzazioni IT di estendere il SDDC nel cloud con AWS. E ora stiamo seguendo l’esempio con Horizon 7…

Con VMware Horizon 7 su VMware Cloud on AWS, è possibile estendere le implementazioni Horizon 7 on-premise al cloud per gestire un’ampia gamma di casi d’uso, tra cui capacità on demand, disaster recovery e cloud-colocation senza la necessità di un’infrastruttura on-premise addizionale in funzione. Questo permette di ottenere un cloud ibrido perfettamente integrato per desktop e applicazioni virtuali. È possibile creare questo cloud ibrido sfruttando Cloud Pod Architecture (CPA) nella tua infrastruttura locale e AWS. I CPA possono anche essere implementati su più postazioni AWS per supportare ambienti altamente distribuiti. Inoltre, puoi sfruttare la stessa esperienza di gestione amministrativa per VMware vSphere e Horizon 7 su VMware Cloud on AWS per semplificare il coordinamento dell’intero deployment ibrido.

Per ulteriori informazioni su come ottenere l’accesso a questo nuovo servizio, scopri le nostre nuove offerte di abbonamento Horizon e Workspace ONE di seguito.

Horizon Cloud per VDI su Azure accelera il passaggio a Windows 10

Alla fine dello scorso anno, abbiamo annunciato la disponibilità di app e desktop Horizon Cloud basati su RDS con Microsoft Azure. E oggi siamo lieti di estendere questo supporto ai desktop virtuali di Windows 10. Con questi servizi congiunti, sarà possibile connettere la propria istanza di Azure con il piano di controllo Horizon Cloud per impostare e distribuire rapidamente applicazioni Windows virtualizzate e desktop Windows 10 persistenti e non persistenti. È possibile usufruire di una fatturazione oraria a basso costo per la capacità di Azure e sfruttare un footprint globale che si estende su 50 data center. Inoltre, puoi facilmente importare le tue immagini direttamente da Microsoft Azure Marketplace e applicare gli agenti necessari in pochi minuti.

Come parte di questo annuncio, VMware sta lanciando l’Horizon Control Plane anche in Australia, oltre a Stati Uniti e Germania.

In VMware, stiamo assistendo a un grande interesse per questi nuovi servizi – e Ron Neher, Principal Solution Architect di DXC dichiara: “La soluzione Horizon Cloud su Microsoft Azure riunisce due grandi tecnologie. Siamo entusiasti di vedere la soluzione espandersi per supportare desktop e applicazioni virtuali. DXC e VMware offrono un solido portafoglio di servizi e soluzioni cloud ibridi che combinano tecnologie VMware con i servizi, l’esperienza e il supporto DXC, per guidare i clienti comuni nel viaggio verso un’impresa abilitata al cloud ‘as-a-service’, accelerando i risparmi sui costi e riducendo il time-to-market. “

La User Experience diventa più intelligente e audace

In VMware, stiamo rendendo più semplice che mai sfruttare grafiche di alto profilo della workstation, fornendo il supporto per vGPU NVIDIA GRID su tutte le nostre offerte Horizon. Oggi siamo lieti di annunciare la beta per NVIDIA vGPU con app e desktop Horizon Cloud Win10 con IBM SoftLayer. Questa offerta DaaS end-to-end offre supporto per i desktop NVIDIA attraverso 5 diversi profili GPU. VMware lancia inoltre il supporto per le app e i desktop Horizon Cloud RDSH con Microsoft Azure per gli utenti di workstation. Questi due nuovi servizi completano le offerte NVIDIA GRID che oggi si possono già utilizzare con Horizon 7 e garantiscono agli utenti finali una user experience audace e ricca con Horizon sia on-premise che nel cloud.

Nuove licenze di abbonamento per Workspace ONE e Horizon

A grande richiesta, il mese scorso abbiamo annunciato una nuova offerta di abbonamento Workspace ONE Enterprise che consente di utilizzare le app e i desktop Horizon 7 tramite un’offerta di abbonamento come parte di Workspace ONE. Oggi siamo lieti di lanciare una nuova licenza di abbonamento universale Horizon che consente di distribuire Horizon Cloud o Horizon 7 a un prezzo conveniente.

Horizon 7.5 introduce JMP in una veste completamente nuova

Nel corso del VMworld dello scorso agosto, vi abbiamo mostrato un’anteprima tecnica di come stiamo portando JMP (la nostra piattaforma desktop just-in-time) a un livello superiore, rendendo la creazione di desktop veloce e senza interruzioni. Per quelli di voi che sono nuovi a JMP questa è la collezione di tecnologia Instant Clones per il provisioning rapido di immagini, VMware App Volumes per la consegna delle app just in time e User Environment Manager per la personalizzazione degli utenti, la gestione dei profili e le policy. Quando unisci queste capacità insieme, ottieni la possibilità di creare desktop personalizzati e stateless in pochi secondi.

In Horizon 7.5 (che siamo lieti di annunciare oggi) – stiamo mettendo insieme questa raccolta di tecnologie JMP e integrandole in un unico flusso di lavoro comune. Gli amministratori IT possono facilmente creare spazi di lavoro VDI costituiti da un sistema operativo desktop, applicazioni e impostazioni, in modo integrato e incentrato sulle esigenze degli utenti. Il motore del flusso di lavoro JMP crea automaticamente le autorizzazioni per fornire questo workspace, rende incredibilmente facile apportare modifiche e semplifica il test e la distribuzione di Windows 10 e degli aggiornamenti delle applicazioni.

NUOVO Extended Service Branch per Horizon 7

Per soddisfare al meglio le esigenze di coloro che stanno cercando di rimanere sulla versione attuale di Horizon e ricevere ancora correzioni di bug e aggiornamenti di sicurezza, offriremo anche un nuovo Extended Service Branch (ESB) per i deployment di VMware Horizon 7 Enterprise, che includerà la piattaforma principale Horizon 7, VMware App Volumes e VMware User Environment Manager. Scopri di più qui.

Workspace ONE Intelligence lancia la preview tecnologica per Horizon e Horizon Apps

Proprio il mese scorso abbiamo introdotto Workspace ONE Intelligence, che ti consentirà di trarre vantaggio da insight approfonditi, abilitare la pianificazione intelligente della gestione degli endpoint unificata e offrire una potente automazione per il digital workspace. Oggi, siamo lieti di annunciare un’anteprima tecnologica di Workspace ONE Intelligence per Horizon e Horizon Apps. Con questa preview tecnologica, puoi sfruttare un unico pannello di controllo per ottenere informazioni sugli endpoint fisici e virtuali per una visibilità completa su tutti i tuoi dipendenti, app (incluse le app virtuali) e sistemi operativi Win10. È anche possibile utilizzare il monitoraggio dello stato del sistema e dell’ambiente dell’utente, sfruttare le regole e gli avvisi per semplificare le attività di amministrazione e monitorare le app virtuali attraverso dashboard personalizzabili per migliorare la sicurezza, la conformità e la user experience. Questo servizio SaaS non sarà incluso nei pacchetti permanenti Horizon esistenti.

In conclusione

Le app legacy di Windows stanno scomparendo in azienda? Assolutamente no. Ma non preoccuparti…perché stiamo rendendo molto più semplice per te gestire, garantire e proteggere queste app in autonomia per affrontare una serie di casi d’uso  e come parte di una più ampia strategia di digital workspace.