APPROFONDIMENTI E NEWS

Sfrutta i benefici delle licenze Windows Azure Hybrid

di Francesco Pandiscia | Aggiornato il 24/03/2026

Pochi sanno che è possibile risparmiare su Azure non solo utilizzando il sizing e la soluzione più idonea per quel particolare workload, ma anche sfruttando i benefici della modalità di acquisto delle licenze in abbonamento con la cosiddetta Software Assuranca.

Azure Hybrid Benefit denominato HUB (acronimo che sta Hybrid User Benefit) è invece un programma che aiuta gli utenti di Microsoft Azure ad ottenere uno sconto in modo da ottenere più valore dalle loro licenze Microsoft Server risparmiando anche fino al 40% sul normale costo di esecuzione delle proprie macchine virtuali.
L'effettivo risparmio dipenderà poi da alcuni fattori come l’utilizzo dei servizi di Azure da parte dei clienti, la loro area geografica e il tipo di istanze di macchine virtuali in esecuzione.
Per esempio gli utenti di Windows Server potranno pagare la propria velocità di calcolo in base alle proprie macchine virtuali convertendo le licenze in modo da eseguire le VM in Azure.

Chi è idoneo per Azure HUB?
Tutti quegli utenti Windows Server le cui licenze sono coperte dal programma di manutenzione Software Assurance di Microsoft. Questo vale sia che utilizzino Datacenter e sia l’edizione standard di Windows Server.
Anche i clienti che acquistano Azure tramite partner Microsoft che rivendono l’infrastruttura di Azure, possono beneficiare di Hybrid User Benefit.

Quali sono i prodotti idonei a Azure Hybrid Benefit

Vediamo che Microsoft specifica i prodotti che possono usufruire dei servizi di Azure Hybrid Benefit:

Windows Server Standard Edition con Software Assurance;
Windows Server Datacenter Edition con Software Assurance;
SQL Server Enterprise Core con Software Assurance;
SQL Server Enterprise Core con Software Assurance;
Database SQL di Azure.

Come posso utilizzare Azure Hybrid Benefit

Precisamente cosa è possibile fare e quanto è possibile risparmiare con Azure Hybrid Benefit? Lo vediamo insieme:

Azure Hybrid permette di migrare su cloud avendo un forte risparmio. Fino al 49% sulle macchine virtuali Windows Server pagando una velocità di calcolo ridotta. Per risparmiare fino all’80% sarà possibile combinare le istanze riservate di Azure;
Distribuire una nuova macchina virtuale utilizzando Azure Marketplace;
Caricare una VM personalizzata;
Attuare una migrazione con Azure Site Recovery;
Utilizzare le immagini del Marketplace di Azure

Come creare una nuova Virtual Machine

Molto semplicemente per creare una nuova VM bisogna attivare Azure Hybrid Benefits come mostrato qui sotto nello screenshot

Attivazione

I clienti Azure hanno 3 opzioni per l’attivazione del proprio HUB.

La prima opzione è quella di distribuire VM di Windows Server che sono già state configurate con HUB quando le ottengono da Azure Marketplace;
In secondo luogo gli utenti di Azure possono migrare i propri carichi di lavoro esistenti con Azure Site Recovery, gratuito per i primi 31 giorni;
La terza opzione per l’attivazione di HUB è quella di caricare una VM personalizzata. Gli utenti di Windows Server che non dispongono ancora di Azure dovranno pensare a come migrare ad Azure in modo da ridurre al minimo l’interruzione dell’attività. Successivamente per attivare HUB bisognerà distribuire nuove macchine virtuali da una piattaforma che supporti l’immagine di Windows Server

Limiti per le VM

Gli utenti potranno ricevere al massimo due macchine virtuali con un massimo di 8 core ciascuna per ogni licenza Windows Server a due processori in loro possesso; come abbiamo già detto, questo a patto che le licenze siano coperte da Software Assurance.
Potranno anche ricevere una VM con 16 core per ogni licenza Windows Server a 16. Core il loro possesso.
Impilando le proprie licenze gli utenti potranno eseguire macchine virtuali con più di 16 core per esempio un utente con due licenze a due processori o due licenze a 16 core può eseguire una VM con al massimo 32 core.

Cos’è la regola dei 90 giorni

Secondo la regola di riassegnazione delle licenze di 90 giorni, un cliente non sarà in grado di riassegnare le licenze da un server ad un altro all’interno di una server farm in un limite di tempo di 90 giorni. Quindi quando una licenza viene assegnata ad un hardware, poi prima di poterla spostare bisognerà attendere 90 giorni.

Il risparmio sui costi è uno step fondamentale per ogni azienda che punti a crescere. Per questo motivo Nexsys offre consulenza sull'ottimizzazione dei costi con Azure in modo che possiate trarne dei vantaggi immediati sia in termini di prestazioni e sia per quanto riguarda le spese.
Se sei interessato a passare ad Azure o vuoi saperne di più su quel servizio o su cosa offriamo, contattaci o visita il nostro sito.

Prerequisiti tecnici prima del rollout

Prima di abilitare FIDO2 con Cloud Kerberos Trust in produzione, conviene trattare il progetto come un intervento di architettura identita ibrida, non come una semplice opzione di portale. I prerequisiti principali riguardano client, tenant, dominio Active Directory, sicurezza Kerberos, sincronizzazione directory e gestione del dispositivo.

Area	Verifica richiesta
Client Windows	Windows 10 versione 2004 o successiva, oppure Windows 11. Preferibile standardizzare su build aggiornate e gestite.
Join del dispositivo	Dispositivi Microsoft Entra joined o hybrid joined, con registrazione corretta e utente sincronizzato.
Active Directory	Domain Controller Windows Server 2016 o successivi, patching aggiornato, replica sana, DNS e time sync corretti.
Kerberos	Verificare supporto AES e dismissione algoritmi deboli. Per l’approfondimento operativo vedere disabilitare RC4 in Kerberos.
Sincronizzazione identita	Entra Connect o Cloud Sync correttamente configurato, con attributi necessari e utenti sincronizzati verso Entra ID.
Ruoli amministrativi	Privilegi separati tra dominio e cloud; usare account dedicati e tracciare le operazioni eseguite.
Gestione dispositivi	Policy Intune o GPO coerenti. Nei tenant moderni il canale preferenziale e Endpoint Management e UEM con Microsoft Intune.
Sicurezza tenant	Verificare metodi di autenticazione, Conditional Access, breakglass e account privilegiati tramite Microsoft 365 Security Assessment.

Progettazione consigliata Nexsys

L’errore tipico e abilitare FIDO2 a tutti gli utenti senza segmentazione, senza pilota e senza processo di recovery. Un progetto passwordless deve invece partire da un disegno operativo: chi usa FIDO2 fisico, chi usa Windows Hello for Business, quali gruppi vengono abilitati, quali account sono esclusi, come si gestisce lo smarrimento della chiave, quali controlli vengono applicati da Conditional Access e quali risorse on-premises sono coinvolte.

Assessment iniziale su tenant e dominio, collegando la verifica cloud al Microsoft 365 Security Assessment e la verifica AD all’Assessment & Hardening Active Directory.
Definizione dei gruppi pilota: IT, amministratori selezionati, utenti high-value, poi progressione per reparti.
Scelta del metodo: FIDO2 hardware per ruoli critici, Windows Hello for Business per utenti con PC gestiti, eventuali passkey solo dove il modello di rischio lo consente.
Configurazione Microsoft Entra Kerberos nel dominio Active Directory interessato.
Distribuzione policy client tramite Intune o GPO, con controlli su TPM, PIN, biometria, hardware security device e cloud trust.
Test controllati su file share, applicazioni IIS, stampanti, mappature di rete, VPN, accessi remoti e scenari di recovery.
Rollout progressivo con reportistica, troubleshooting e revisione periodica dei metodi di autenticazione registrati.

Configurazione Microsoft Entra Kerberos

Il cuore tecnico del modello e la creazione dell’oggetto AzureADKerberos nel dominio Active Directory. L’oggetto si comporta in modo simile a un oggetto RODC logico usato da Microsoft Entra ID per l’emissione dei ticket Kerberos necessari. Non e un Domain Controller fisico e non sostituisce il controllo locale delle autorizzazioni.

La configurazione va eseguita con account amministrativi separati per il piano cloud e per il dominio. Nel modello operativo Nexsys e preferibile usare sessioni tracciate, MFA phishing-resistant sugli amministratori e un processo di change documentato. Gli account di emergenza devono essere gia definiti; la guida interna correlata e Breakglass in Entra ID.

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

$domain = $env:USERDNSDOMAIN

$cloudCred = Get-Credential # Hybrid Identity Administrator o ruolo equivalente

$domainCred = Get-Credential # Domain Admin per il dominio interessato

Set-AzureADKerberosServer -Domain $domain `

-CloudCredential $cloudCred `

-DomainCredential $domainCred

Dopo la configurazione, il dominio deve essere verificato lato replica AD, lato portale Entra e lato client. In ambienti multi-dominio o multi-foresta non va dato per scontato che un solo intervento copra tutto il perimetro: ogni dominio interessato va valutato in base a utenti, risorse e trust esistenti.

Abilitazione FIDO2 e metodi passwordless in Entra ID

Il metodo FIDO2 va abilitato in Authentication Methods di Microsoft Entra ID con targeting per gruppi. La configurazione deve essere esplicita: gruppi abilitati, eventuale attestation, restrizioni sui modelli di chiave supportati, criteri di registrazione e processo di revoca. Per account privilegiati e ruoli critici, la governance deve rientrare in un disegno piu ampio di Identity Security.

Creare gruppi pilota dedicati per FIDO2 e per Windows Hello for Business.
Abilitare FIDO2 solo ai gruppi selezionati nella prima fase.
Documentare modelli di security key ammessi, PIN policy e processo di consegna.
Prevedere almeno un metodo di recupero forte e controllato, evitando ritorni incontrollati a fattori deboli.
Eseguire audit periodico dei metodi registrati dagli utenti e degli account senza metodo forte.

Policy client: Intune o GPO

Una volta pronto il piano identita, il client deve ricevere policy coerenti. Negli ambienti cloud-managed, Intune e il canale piu naturale per standardizzare Windows Hello for Business, requisiti TPM, PIN, biometria, uso di cloud trust e configurazioni di sicurezza endpoint. Negli ambienti ancora fortemente on-premises, le GPO restano utilizzabili, ma devono essere mantenute coerenti con la strategia Entra ID.

Canale	Configurazioni da presidiare
Microsoft Intune / Endpoint Management	Abilitare Windows Hello for Business, Cloud Trust for on-premises authentication, requisiti TPM/security device, profili account protection, compliance e Conditional Access.
Group Policy	Abilitare Windows Hello for Business, usare Cloud Kerberos Trust per autenticazione on-premises, definire policy PIN/biometria e hardware security device dove richiesto.
Conditional Access	Rendere coerenti i controlli con device compliance, ruoli amministrativi, rischio accesso e metodi di autenticazione resistenti al phishing.

Test di validazione prima della produzione

Il test non deve limitarsi al fatto che l’utente riesca ad accedere a Windows. Il vero obiettivo e verificare che l’utente acceda senza password e continui a usare le risorse on-premises senza prompt aggiuntivi, senza fallback manuale alla password e senza perdita di autorizzazioni.

Login Windows con security key FIDO2 o Windows Hello for Business.
Verifica PRT e stato registrazione dispositivo.
Accesso a file share SMB con permessi basati su gruppi AD.
Accesso ad applicazioni interne con Integrated Windows Authentication.
Mappatura stampanti o drive di rete dove ancora presenti.
Test da rete aziendale, VPN e scenario remoto previsto dall’organizzazione.
Verifica ticket con klist e analisi event log Kerberos lato client e Domain Controller.
Test di smarrimento chiave, reset metodo e revoca accesso.
Test sugli account esclusi o privilegiati, senza modificare impropriamente la Password Replication Policy.

Comandi utili per troubleshooting

In fase di troubleshooting conviene partire da evidenze semplici: stato dispositivo, PRT, ticket Kerberos, connettivita verso Domain Controller, DNS, time sync, gruppi utente e policy applicate. La presenza di un login passwordless riuscito non garantisce automaticamente che il ticket Kerberos sia utilizzabile verso ogni risorsa locale.

dsregcmd /status

klist

klist purge

whoami /groups

nltest /dsgetdc:contoso.local

Test-NetConnection dc01.contoso.local -Port 88

Test-NetConnection dc01.contoso.local -Port 445

Se il problema riguarda solo alcune risorse, analizzare ACL, SPN, DNS, trust, deleghe e configurazione Kerberos del servizio. Se il problema riguarda tutti gli accessi on-premises dopo login passwordless, la causa e piu probabilmente nella configurazione Entra Kerberos, nella policy client, nella sincronizzazione utente o nella connettivita verso i Domain Controller.

Limiti e scenari da non forzare

FIDO2 con Cloud Kerberos Trust e potente, ma non deve essere interpretato come una soluzione universale per qualsiasi scenario Windows. Alcuni casi richiedono ancora smart card, certificati, PAM, jump server o architetture diverse.

Non usare FIDO2 come unica risposta per accessi RDP, VDI o login diretto sui server se lo scenario non e supportato.
Non estendere indiscriminatamente CKT agli account privilegiati senza valutare gruppi built-in, policy di replica password e modello Tier 0.
Non lasciare password legacy attive senza controllo: il passwordless perde valore se la password resta il fallback principale e attaccabile.
Non trascurare DNS, time sync e salute dei Domain Controller: Kerberos resta sensibile alla qualita dell’infrastruttura AD.
Non trattare la sicurezza cloud separatamente da AD. In ambienti ibridi, Identity Security e Assessment & Hardening Active Directory devono essere coordinati.

Account privilegiati, breakglass e recovery

Gli account amministrativi richiedono una progettazione distinta. FIDO2 e un metodo eccellente per account critici, ma non deve eliminare la capacita di recovery. Un tenant deve mantenere account breakglass documentati, monitorati e protetti con criteri coerenti. Allo stesso tempo, gli amministratori non devono usare account privilegiati per attivita quotidiane o per test di rollout utente.

Per questo la configurazione passwordless va collegata a un modello di ruoli, privilegi e account amministrativi. La pagina Nexsys su Microsoft Entra ID Tiering puo essere usata come approfondimento sul piano identita; la guida Breakglass in Entra ID resta invece il riferimento per continuita di accesso amministrativo in scenari critici.

Roadmap di implementazione consigliata

Fase	Obiettivo	Output
1. Assessment	Verificare tenant, Entra ID, metodi MFA, Conditional Access, AD, Kerberos, client e gruppi pilota. Collegare a Microsoft 365 Security Assessment e Assessment AD.	Gap list tecnica, prerequisiti, rischi, utenti pilota.
2. Design	Definire chiavi FIDO2, WHfB, criteri Intune/GPO, gruppi, recovery, breakglass, rollout e rollback.	Documento di architettura e piano operativo.
3. Configurazione	Creare oggetto AzureADKerberos, abilitare metodi Entra, configurare policy client e Conditional Access.	Tenant e dominio pronti per pilota controllato.
4. Pilot	Validare login passwordless, accesso file share, applicazioni Kerberos, VPN, recovery e supporto helpdesk.	Esiti test, anomalie, correzioni e decisione go/no-go.
5. Rollout	Distribuire per gruppi progressivi, monitorando registrazioni, ticket, incidenti e fallback.	Rollout controllato e misurabile.
6. Governance	Audit periodico metodi di autenticazione, chiavi, account privilegiati, ticket Kerberos e compliance dispositivi.	Controllo continuativo e miglioramento della postura.

Come Nexsys supporta il progetto

Nexsys supporta aziende e reparti IT nella progettazione e implementazione di accessi passwordless in ambienti Microsoft 365, Entra ID e Active Directory. L’intervento puo partire da un assessment puntuale o inserirsi in un percorso piu ampio di modernizzazione della sicurezza, con focus su identita, dispositivi, Conditional Access, hardening AD e formazione tecnica del personale IT.

Analisi della postura cloud con Microsoft 365 Security Assessment.
Verifica del dominio, dei Domain Controller e dei controlli Kerberos con Assessment & Hardening Active Directory.
Progettazione dei metodi passwordless nel quadro di Identity Security.
Distribuzione policy client tramite Endpoint Management e UEM e Microsoft Intune.
Affiancamento tecnico e remediation tramite Consulenza Cybersecurity.
Trasferimento competenze al team IT con Corso Microsoft 365 Administration o Corso Microsoft Cloud Security.

L’obiettivo non e abilitare una singola opzione, ma rendere operativo un modello di accesso passwordless che riduca il rischio di furto credenziali e mantenga la compatibilita con le risorse aziendali ancora basate su Active Directory.

Per valutare l’adozione di FIDO2 e Cloud Kerberos Trust nel tuo ambiente Microsoft, richiedi una consulenza tecnica Nexsys con analisi del tenant, del dominio Active Directory e dei dispositivi coinvolti.

FAQ

Cloud Kerberos Trust sostituisce Active Directory?

No. Cloud Kerberos Trust non sostituisce Active Directory e non elimina i Domain Controller. Permette a Microsoft Entra ID di partecipare al rilascio dei ticket necessari per l’accesso passwordless, ma autorizzazioni, ACL, gruppi e service ticket restano governati dall’infrastruttura AD on-premises.

FIDO2 permette di accedere ai file server aziendali senza password?

Si, se l’ambiente e configurato correttamente con Microsoft Entra Kerberos e Cloud Kerberos Trust. L’utente puo accedere a Windows con security key FIDO2 o metodo passwordless e ottenere SSO verso risorse Kerberos come file share SMB e applicazioni interne.

Serve ancora Entra Connect?

Nella maggior parte degli scenari ibridi si, perche gli utenti devono essere sincronizzati tra Active Directory e Microsoft Entra ID. La configurazione va verificata soprattutto se il tenant usa regole di sincronizzazione personalizzate o domini multipli.

FIDO2 funziona anche con RDP o VDI?

Non va dato per scontato. Gli scenari RDP, VDI, login diretto sui server ed “Esegui come” hanno limitazioni specifiche. In questi casi possono essere piu adatti certificati smart card, PAM, jump server o altri modelli di accesso privilegiato.

E meglio usare FIDO2 o Windows Hello for Business?

Dipende dallo scenario. FIDO2 hardware e indicato per account critici e utenti high-value. Windows Hello for Business e spesso piu adatto per utenti con PC aziendali gestiti. In molti progetti i due metodi convivono, con regole diverse per gruppi e ruoli.

Quali controlli vanno fatti prima del rollout?

Vanno verificati tenant Entra ID, metodi di autenticazione, Conditional Access, dispositivi gestiti, salute Active Directory, Domain Controller, DNS, time sync, supporto Kerberos AES, sincronizzazione identita e processo di recovery.