• Cloud, Guide, Microsoft 365, Sicurezza
• 12 Ottobre 2026

Microsoft Defender for Identity è una funzionalità Cloud di Microsoft che vi permette di proteggere e monitorare le identità all’interno della vostra organizzazione.

La funzionalità di MDI (Microsoft Defender for Identity) è completamente integrata in Microsoft Defender XDR e sfrutta i log che provengono dagli utenti di Active Directory locale o Entra ID per Identificare, rilevare e analizzare al meglio le minacce avanzate dirette all’organizzazione.

Distribuire MDI per aiutare i Team di SecOp a offrire una soluzione di Identity Threat Detection in ambienti ibridi tra cui:

• Prevenire le violazioni: usando valutazioni proattive dell’analisi comportamentale dei rispettivi utenti
• Rilevare Minacce: usando l’analisi in tempo reale e l’intelligence dei dati
• Analizzare le attività sospette: usando informazioni degli eventi imprevisti chiare e reattive
• Rispondere agli attacchi: usando la risposta automatica alle identità compromesse

Precedentemente MDI era chiamato Azure Advanced Threat Protection (Azure ATP).

Vorrei darvi evidenza dei quattro punti fondamentali precedentemente descritti per darvi evidenza di come MDI aiuta le organizzazioni a proteggere le identità dell’ambiente Ibrido.

Proteggere le identità degli utenti e riduzione della superfice di attacco

Defender for Identity offre informazioni preziose sulle configurazioni delle identità e sulle procedure consigliate per la sicurezza. Grazie ai report di sicurezza e all’analisi dei profili utente, MDI consente di ridurre notevolmente la superfice di attacco dell’organizzazione, rendendo più difficile compromettere le credenziali utente e far avanzare un attacco.

Valutare in modo proattivo il comportante dell’identità

Defender for Identity offre agli IT Admin una visione chiara, precisa e puntuale del comportante delle identità, consentendo quindi di identificare e risolvere problemi di sicurezza prima che possano essere sfruttati da utente malintenzionati come ad esempio percorsi di Lateral Movement

Rilevazione delle minacce in ambienti moderni

Le infrastrutture al giorno d’oggi sono per la maggior parte Ibride, motivo questo servizio offre una protezione sia delle identità Cloud Based sia delle identità On-prem, difatti è possibile installare il sensore di MDI sia all’interno dei Domain Controller sia all’interno di macchine che eseguono autenticazione come server ADFS (Active Directory Federation Services).

Identificare le attività sospette nella Kill Chain degli attacchi informatici

In genere gli attacchi informatici vengono eseguito verso ogni tipologia di entità.

Gli utenti malintenzionati quindi si spostano rapidamente e lateralmente fino ad ottenere l’accesso ad asset preziosi, come ad esempio utenti / account sensibili come ad esempio di Dominio.

Le minacce che possono essere rilevate da MDI sono le seguenti:

• Reconnaissance
• Compromised Credentials
• Lateral Movements
• Domain Dominance

Analizzare gli avvisi e le attività degli utenti

Defender for Identity è progettato per ridurre al minimo il “rumore” degli avvisi che vengono generati, fornendo un elenco con delle priorità di sicurezza importanti e pertinenti, e soprattutto la semplice e intuitiva integrazione con Microsoft Defender XDR offre un altissimo livello di sicurezza avanzata che correlano dati per una maggior visibilità e accuratezza nella sicurezza della vostra infrastruttura.

Per eventuali approfondimenti sulla soluzione descritta vi rimando al link ufficiale Microsoft What is Microsoft Defender for Identity? – Microsoft Defender for Identity | Microsoft Learn

Figura 1: Schema di come Microsoft Defender for Identity interagisce con diverse fonti per proteggere le identità dell’infrastruttura On-prem e Cloud

Come effettivamente il sensore di MDI aiuta nella protezione?

Il Sensore di Defender for Identity ha le seguenti funzionalità per aiutare le organizzazioni nella protezione delle identità:

• Acquisire e controllare il traffico di rete del controller di dominio
• Ricevere eventi Windows dai Domain Controller
• Ricevere informazioni da Radius
• Recupera dati relativi a utenti di Active Directory

Tutti gli eventi del sensore vengono inviati al portale di Microsoft Defender XDR per analisi tramite la Threat Intelligence Microsoft per la generazione di Alert specifici ed eventuale remediation.

All’interno della community abbiamo già parlato delle potenzialità dello strumento in differenti articoli che per comodità vi riporto:

• Attivare Microsoft Defender for Identity nei Domain Controller attraverso l’agent di Defender for Endpoint – ICT Power
• Defender for Identity: Migrate from Sensor V2 to Sensor V3.0 (Preview) – ICT Power

In questo articolo vorrei parlavi di come poter implementare la soluzione di Microsoft Defender for Identity all’interno dei domain controller senza che essi siano gestiti da Microsoft Defender for Endpoint

Questa, a mio avviso, è una delle nuove funzionalità introdotte da Microsoft, che può aiutare le organizzazioni a estendere la protezione dei propri ambienti Ibridi.

Limitazioni

È importante indicarvi che, questo metodo di Onboarding supporta nuove implementazioni di Defender for Identity v3.x per i Domain Controller idonei che non hanno installato il sensore v2.x.

Il “pacchetto” di Onboarding standalone attiva quindi l’ultima versione di sensore, non distribuisce né concede la licenza di Defender for Endpoint quindi il server richiede comunque la connettività ai servizi Cloud per permettere la visualizzazione della telemetria.

Proprio per questo vi lascio il link ufficiale Microsoft con i prerequisiti Configure network connectivity to Microsoft Defender for Endpoint – Microsoft Defender for Endpoint | Microsoft Learn

Vi fornisco anche il link di tutti i prerequisiti per il sensore v3.x Deploy the Microsoft Defender for Identity sensor v3.x – Microsoft Defender for Identity | Microsoft Learn che è necessario rispettare per il Domain Controller che vorrete onboardare.

Figura 2: Licenze disponibili su tenant di Demo per utilizzare la funzionalità

Figura 3: Sistema operativo del Domain Controller di demo

Figura 4: Server che risulta essere un domain controller

Figura 5: Endpoint Domain Controller di demo che non risulta gestito da Microsoft Defender for Endpoint

Ora procedete ad accedere al portale di Defender XDR

Figura 6: Sezione di Defender for Identity per scaricare il sensore

Figura 7: Fornire un nome al package e generare Onboarding Package

Figura 8: Copiarsi Access Key ed eseguire il Download del package

NB: Il package come indicato dalla documentazione ha una validità di 7 giorni successivamente sarà necessario rieseguire la procedura, la key sarà utilizzata solo durante la procedura di Onboarding.

Figura 9: Portiamo il file zip contenente l’installer all’interno del domain controller in cui lo installeremo

Figura 10: Estraiamo il file zip all’interno del domain controller

Figura 11: Contenuto del file zip

NB: Verificate la presenza della cartella resources che è fondamentale ci sia

Ora dovrete aprire PowerShell come amministratore e posizionatevi all’interno della cartella in cui sono presenti i file scaricati

Figura 12: PowerShell aperto come amministratore e posizionamento nella cartella dove sono presenti i file

NB: il gMSA dovrà essere creato in ogni caso per permettere al sensore di “sfogliare” correttamente Active Directory, per l’implementazione di esso vi rimando alla guida Attivare Microsoft Defender for Identity nei Domain Controller attraverso l’agent di Defender for Endpoint – ICT Power

Figura 13: Esecuzione CMD direttamente dalla cartella in cui abbiamo estratto i programmi

Figura 14: Inserimento della Key nel momento in cui viene richiesta

Figura 15: Attività completata con successo

Figura 16: Server che risulta ora con il sensore Healty nonostante il l’Endpoint non sia gestito da Defender for Endpoint

E se volessi successivamente installare Defender for Endpoint?

Se dopo aver usato questa funzionalità volete eseguire l’onboarding del dispositivo in Defender for Endpoint dovrete procedere con i seguenti Steps:

• Offboarding del Domain Controller da questa funzionalità e rimuovere il sensore Remove the Microsoft Defender for Identity sensor – Microsoft Defender for Identity | Microsoft Learn
• Eseguire Onboarding del domain controller in Defender for Endpoint
• Recarsi nella sezione di Defender for Identity e abilitare il sensore V3.X

Ora vi mostrerà anche questi passaggi, in quanto credo sia fondamentale per la community capire anche come poter abilitare questa configurazione, recatevi all’interno del portale di Microsoft Defender sezione Identity:

Figura 17: Selezioniamo il sensore installato con questa modalità e click su “Delete”

Figura 18: Scegliamo di eseguire il Download dell’Offboarding Script

Figura 19: Copiamo il file di offboarding all’interno del nostro domain controller

Ora è necessario scaricare il Defender Deployment Tools, necessario per eseguire l’offboarding, in quanto viene comunque usato Sense per la componente Identity

Figura 20: Download offboarding package, on preoccupatevi se c’è scritto Onboarding a noi servirà solo l’eseguibile

Figura 21: Generiamo il file, scegliete il tempo necessario, nel mio caso 7 giorni sono più che sufficienti

Figura 22: Nel nostro caso la Key non ci interessa e scegliamo di eseguire il Download in estensione .exe

Figura 23: Copiamo l’eseguibile sul server nello stesso percorso del file di Offboarding

Figura 24: Aprire PowerShell come amministratore e posizionarsi nella cartella in cui sono presenti i due file scaricati in precedenza

Ora sarà necessario eseguire il seguente comando, sostituendo con i nomi ed i path dei due file “.\DefenderDeploymentTool_Offboard.exe -Offboard -File:”C:\Path\WindowsDefenderATP_valid_until_YYYY-MM-DD.offboarding””

Figura 25: Comando configurato secondo i nomi che io ho fornito ai file

Figura 26: Confermare la propria scelta

Figura 27: Offboarding eseguito con successo

Se avevate il sensore V2.X a questo punto bastava eseguire la disinstallazione del sensore dai programmi del server, nel mio caso essendo V3.X recarsi sempre all’interno del portale di Microsoft Defender

Figura 28: Rimuovere il sensore

Ora è possibile eseguire Onboarding in Microsoft Defender, io lo ho fatto tramite script

Figura 29: Onboarding del Domain Controller eseguito in defender for Endpoint

Ora rechiamoci nella sezione Defender for Identity

Figura 30: Attiviamo il sensore di Defender for Identity

Figura 31: Attiviamo il sensore

Figura 32: Processo di Onboarding MDI iniziato

Figura 33: Correttamente presente il domain controller in Defender for Identity

Per eventuali permessi, configurazione di gMsa fate riferimento alla guida Attivare Microsoft Defender for Identity nei Domain Controller attraverso l’agent di Defender for Endpoint – ICT Power che sono necessari per il funzionamento corretto dalla funzionalità, non basta solo eseguire l’onboarding del server.

Con questa procedura quindi eseguiamo offboarding dalla modalità “solo sensore defender for identity” e proteggiamo il server anche per la componente Endpoint Protection e successivamente installiamo anche il sensore, una procedura guidata che ci permette di estendere la protezione dei nostri domain controller.

Conclusioni

Per molte realtà il sensore v3.x era rimasto un’opzione sulla carta. Chi protegge i domain controller con un EDR di terze parti, o chi semplicemente non ha mai voluto portare Defender for Endpoint sui server più critici dell’infrastruttura, si trovava davanti a un vincolo difficile da giustificare. Con questo metodo di onboarding Microsoft toglie di mezzo il problema e rende il passaggio alla v3 una scelta tecnica, non più una scelta di licensing o di strategia EDR.

La procedura in sé è semplice e richiede pochi minuti per ogni DC. Ci sono però alcuni punti da tenere a mente prima di partire. Il metodo vale solo per nuove installazioni, quindi sui domain controller che hanno ancora il sensore v2.x bisogna pianificare prima la rimozione. La connettività verso i servizi cloud di Defender for Endpoint resta obbligatoria, perché il componente Sense si appoggia comunque a quella infrastruttura, e questo va concordato con chi gestisce firewall e proxy.

Il mio consiglio è di partire da un singolo domain controller, aspettare che compaia come Running nel portale (la prima attivazione può richiedere fino a un’ora) e solo dopo estendere il deployment al resto della foresta. È un approccio prudente che costa poco e permette di verificare con calma connettività e telemetria prima di andare in produzione su tutto il perimetro.