• Cloud, Guide, Microsoft 365, Sicurezza
• 27 Maggio 2026

All’interno della community ho già trattato l’argomento del sensore di Defender for Identity V3.0, raccontando i benefici, ma anche le limitazioni attuali che ha lo strumento, vi riporto per comodità l’articolo della community Microsoft Defender for Identity: Active Logging from Defender Portal – ICT Power. All’interno dell’articolo trovate anche una descrizione approfondita di come lavora nel dettaglio questa funzionalità di Microsoft.

L’identità è il primo punto di accesso alle organizzazioni proprio per questo in ottica Zero Trust è necessario proteggerla per evitare spiacevoli sorprese.

Microsoft Defender for Identity consente alle organizzazioni di rilevare, analizzare e rispondere agli attacchi basati sulle identità in ambienti on-prem, cloud e Ibridi.

Gli utenti malintenzionati hanno spesso come destinazione identità come utenti, applicazioni e account di servizio per ottenere l’accesso, avere privilegi e persistere all’interno dell’ambiente dell’organizzazione “attaccata”.

Questo strumento di casa Redmond monitora i segnali delle identità provenienti da Active Directory locale e Microsoft Entra ID, altre soluzioni IAM come ad esempio Okta, analizzati questi segnali usando l’analisi comportamentale, la componente di Threat Intelligence e modelli di attacchi noti per rilevare attività sospette durante l’intero ciclo di vita degli attacchi. Questi avvisi includono il contento di indagine nel portale di Microsoft Defender XDR, consentendo difatto ai team di Sicurezza di comprendere cosa sia successo, aiutandoli in modo considerevole nel loro quotidiano.

Avendo Microsoft rilasciato la versione V3.0 dello strumento, è necessario capire come poter migrare a questa ultima versione dalla precedente, anche se in Preview ho voluto contribuire con questa guida per aiutare le organizzazioni a eseguire questa migrazione e rispettare i più alti standard di sicurezza disponibili sul mercato.

Quindi come possiamo procedere alla migrazione dalla versione V2 alla versione V3.0?

La casa di Redmond ha rilasciato in Preview una procedura per procedere proprio alla migrazione di versione, procedura che vi spiegherò nel dettaglio all’interno di questa guida.

È possibile eseguire la migrazione dei sensori di Microsoft Defender for Identity dalla versione V2.X alla versione V3.X direttamente dal portale di Microsoft Defender XDR. La migrazione completa automaticamente il passaggio e mantiene le configurazioni del server e del monitoraggio della sicurezza, senza tempi di inattività o duplicazione dei dati.

Prerequisiti

Per poter procedere con questa nuova funzionalità, ogni server deve:

• Essere un Domain Controller, senza ruoli di gestione delle identità aggiuntivi in esecuzione
• Avere in esecuzione un sensore di Defender for Identity V2.X
• Avere un sistema operativo Windows Server 2019 o versioni successive
• Includere aggiornamento cumulativo di Marzo 2026 o versione successiva March 10, 2026—KB5078766 (OS Build 20348.4893) – Microsoft Support
• Deve avere Microsoft Defender for Endpoint installato a gestito

Per i prerequisiti completi della versione V3.0 vi rimando al link uffiiale Microsoft Microsoft Defender for Identity sensor v3.x prerequisites – Microsoft Defender for Identity | Microsoft Learn

Figura 1: Serve su cui è installato il sensore V2.X che è un Windows Server 2025 e quindi rispetta i prerequisiti

Figura 2: Server che ha il ruolo di Domain Controller

Figura 3: Sensore V2.X installato sul server di demo

Ora accediamo al portale di Microsoft Defender XDR

Figura 4: Accediamo alle impostazioni del portale di Microsoft Defender XDR

Figura 5: Accediamo alla sezione specifica di Defender for Identity

Figura 6: Device di demo che risulta “Not Ready for Migration”

Ho volutamente non installato uno dei prerequisiti visti in precedenza, questo per darvi evidenza che lo strumento non permette l’aggiornamento senza che prima tutti i prerequisiti non siano rispettati, questo è un vantaggio a mio avviso molto importante per evitare di incorrere in problemi post aggiornamento, nel mio caso specifico il prerequisito mancante è che il server non è stato “onbordato” in Microsoft Defender for Endpoint, operazione che eseguo per darvi evidenza di come funziona lo strumento.

A titolo informativo vi fornisco anche la tabella con tutti gli stati disponibili per “Migration State”:

Figura 7: Server SRVDCICTPOWER non presente in Microsoft Defender for Endpoint e quindi uno dei prerequisiti non è stato rispettato

Ora ho eseguito il deploy di Mirosoft Defender for Endpoint sull’Endpoint oggetto di questa demo

Figura 8: Eseguito onboarding di Defender for Endpoint sul server oggetto della demo

Ora vediamo se il sensore di Microsoft Defender for Identity risulta pronto per la migrazione

Figura 9: Sensore di Defender for Identity che risulta “Ready for Migration” dopo aver rispettato tutti i requisiti imposti da Microsoft

Ora siamo pronti, ad eseguire la procedura di migrazione del sensore di Microsoft Defender for Identity

Figura 10: Selezioniamo il server con installato il sensore V2.X e clicchiamo su Migrate

È importante dichiarare, come da documentazione ufficiale Microsoft, che la migrazione del sensore richiede circa 20 minuti, durante questo periodo il sensore V2.X continua ad essere operativo fino a quanto il sensore V3.X non è pronto, in questo modo tutto rimane monitorato senza interruzioni.

Figura 11: Richiesta di conferma se voler procedere con l’attività di migrazione del sensore di Defender for Identity

Figura 12: Vediamo come lo status passa a “Migrating” questo significa che il processo di migrazione è “partito” con successo

Figura 13: Dopo circa una mezz’ora nel mio caso il sensore risulta migrato correttamente alla versione 3.X

Ora ci sono alcune ottimizzazioni da eseguire per ottenere al meglio le prestazioni della nuova versione del sensore V3.X:

• Configurare il controllo RPC.
• Configurare il controllo automatico degli eventi di Windows. Le configurazioni di controllo esistenti dal sensore v2.x vengono mantenute e convertite per v3.x, ma è consigliabile abilitare il controllo automatico degli eventi di Windows (Preview) per la convalida ottimale della configurazione.
• Passare da gMSA al sistema locale. Il sensore v3.x usa l’identità del sistema locale. Se è stato configurato un gMSA per il sensore v2.x, rimuovere la configurazione gMSA.

Per quanto riguarda il mio ambiente il punto numero 3, legato all’account gMSA è già predisposto

Figura 14: Account gMSA utilizzato per il sensore di Defender for Identity per il dominio “ictpower.lab”

Ora vediamo come configurare il controllo RPC

Figura 15: Come primo passaggio creiamo una Regola di Asset rule Management

Dovrete creare un TAG che includa gli Endpoint che hanno il sensore di Defender for Identity V3.X, scegliendo i filtri appropriati, nel mio caso li selezionerò tramite il nome macchina essendo solo due

Figura 16: Scegliere nome regola e descrizione parlante

Figura 17: Filtro, nel mio caso per Device Name, e proseguo con la configurazione

Figura 18: Inserire la tag da appore agli Endpoint e proseguo con la configurazione

Figura 19: Creazione della Regola di assegnazione della tag

Figura 20: Regola creata correttamente

A questo punto avrete abilitato la funzionalità.

Ora possiamo procedere con il secondo passaggio “Configure Defender for Identity to collect Windows events automatically” specifico che questa funzionalità è ancora in Preview, ma è corretto darvene evidenza

Figura 21: Sezione portale di Defender relativo alla protezione delle identità

Figura 22: Abilitazione della funzionalità

Per il terzo punto, quello relativo alla creazione dell’account gMSA vi rimando all’articolo scritto per la community che spiega in modo dettagliato come crearlo Microsoft Defender for Identity: Active Logging from Defender Portal – ICT Power

Come posso eseguire un test sugli alert?

Giusto per darvi evidenza che tutto funziona nel modo corretto simuliamo un alert di tipo “Network mapping reconnaissance (DNS)” tramite questi comandi, da eseguire in Comand Prompt eseguito come amministratore

Che nel mio caso diventa

Figura 22: Comando nslookup

Figura 23: Configuriamo il server su cui eseguire la query, che risulta essere il dominio locale

Figura 24: Esecuzione comando per simulare alert

Oppure potete simulare un attacco “User and group membership reconnaissance (SAMR)” con I seguenti comandi

Figura 25: Comandi riusciti correttamente

Figura 26: Alert arrivato dopo l’esecuzione dei comandi

Conclusioni

La migrazione al sensore Microsoft Defender for Identity V3.x rappresenta un’evoluzione naturale per le organizzazioni che desiderano rafforzare la sicurezza delle identità senza introdurre complessità operative. La nuova architettura, più moderna e integrata con Microsoft Defender XDR, consente una gestione più efficiente e una maggiore visibilità sugli eventi di sicurezza, mantenendo al tempo stesso la continuità del monitoraggio durante l’aggiornamento. Uno degli aspetti più interessanti è la possibilità di effettuare la migrazione direttamente dal portale, preservando le configurazioni esistenti e senza duplicazioni dei dati, semplificando così l’intero processo. Questo approccio riduce i rischi operativi e permette di adottare rapidamente le nuove funzionalità. Adottare il sensore V3.x significa quindi migliorare prestazioni, sicurezza e capacità di rilevamento, allineando la protezione delle identità ai principi Zero Trust e agli standard di sicurezza moderni. Un aggiornamento consigliato per tutte le organizzazioni che vogliono mantenere un’infrastruttura sicura, efficiente e pronta ad affrontare le minacce attuali.