SPN e il suo ruolo in Active Directory e nella sicurezza

I Service Principal Names (SPN) sono identificatori unici in Active Directory utilizzati per mappare le istanze di servizio agli account di servizio per l'autenticazione Kerberos. Questo articolo spiega la struttura degli SPN, la registrazione, i requisiti di unicità, gli strumenti (ad esempio, setspn) e le implicazioni di sicurezza. Copre attacchi come il Kerberoasting, le migliori pratiche, i metodi di rilevamento e casi d'uso avanzati in ambienti ibridi, cloud e containerizzati.

Introduzione ai Service Principal Names (SPNs)

Cos'è un SPN? Anche un amministratore Windows con un po' di esperienza con Active Directory potrebbe non essere a conoscenza del ruolo che i Service Principal Names hanno negli ambienti di dominio. Un nome principale di sicurezza (SPN) è un identificatore unico che collega una specifica istanza di servizio all'account che lo esegue, consentendo ai client di autenticarsi e connettersi al servizio giusto all'interno di Active Directory (AD). Questo è particolarmente importante in grandi ambienti aziendali dove molteplici istanze di un servizio possono essere eseguite su server diversi. In questo articolo discuteremo cosa sia lo SPN di active directory, quale sia il suo contributo alla sicurezza e come il suo utilizzo continui ad espandersi nelle reti moderne di oggi.

Ruolo degli SPN nell'autenticazione Kerberos

Proprio come hai bisogno di un biglietto per salire su un aereo o entrare in un cinema, hai anche bisogno di un biglietto per accedere alle risorse all'interno di Active Directory (AD). Quando un client richiede l'accesso a un servizio ospitato da AD, il processo si svolge nel seguente modo:

1. Un cliente che tenta di utilizzare un servizio crea un SPN per quel servizio
2. Il cliente richiede al controller di dominio un ticket utilizzando quello SPN
3. Il controller di dominio cerca nello Active Directory quell'SPN
4. Una volta trovato, il domain controller emette un ticket di servizio
5. Il cliente utilizza questo ticket per autenticarsi al servizio senza la necessità di una password

Analisi dei concetti di base

Componenti di un SPN

SPN è composto da più componenti che, combinati, forniscono un'identità completa per un servizio specifico:

1. Classe di servizio: Questo è il nome dell'istanza del servizio, come “MSSQLSvc” per Microsoft SQL Server o “www” per i servizi web.
2. Hostname: Specifica il server o host dove il servizio è in esecuzione. Questo può essere il nome NetBIOS di una macchina Windows come “FilerServer” o il nome a dominio completo come “fileserver.company.com”
3. Account: The Active Directory account associated with the service. This is not part of the SPN string itself but is the account to which the service principal name is registered.
4. Porta (Opzionale): Se il servizio è in esecuzione su una porta non standard, può essere specificata nell'SPN.

Esempi di SPN comuni in Active Directory

• Servizi Web – HTTP/webserver.netwrix.com
• SQL Server – MSSQLSvc/myhost.redmond.microsoft.com:1433
• Condivisioni di file – CIFS/fileserver.contoso.com
• Servizi Desktop Remoto – TERMSRV/rdserver.abcdomain.com
• Autenticazione LDAP – LDAP/domaincontroller.fabricam.com

SPNs e Active Directory: La Connessione

Come gli SPN si integrano con gli oggetti di Active Directory

Gli SPN sono attributi associati a oggetti AD come account utente, account di servizio o oggetti computer. Funzionano come etichette che indicano quali servizi sono eseguiti sotto quali account. Questa connessione permette ai computer di utilizzare Kerberos per un'autenticazione sicura senza inviare password attraverso la rete. Quando un servizio viene installato o configurato, registra uno SPN che consente a Kerberos di mappare le richieste di autenticazione all'account corretto. Senza uno SPN configurato correttamente, l'autenticazione Kerberos fallirà, potenzialmente causando errori di autenticazione e interruzioni del servizio.

Archiviazione SPN nell'attributo servicePrincipalName

Gli SPN sono memorizzati all'interno di Active Directory come parte dell'attributo servicePrincipalName di un oggetto. Questo attributo esiste negli account computer e negli account servizio. Puoi vedere questo attributo nelle proprietà avanzate di un oggetto utilizzando Active Directory Users and Computers come mostrato nello screenshot qui sotto.

L'attributo contiene un elenco di SPN che sono stati assegnati all'oggetto. Ogni voce SPN segue un formato strutturato che include il tipo di servizio, l'host e il numero di porta opzionale.

Puoi visualizzare gli SPN di un oggetto AD utilizzando il comando: setspn –L hostname. Nell'esempio sottostante, il comando è stato utilizzato per vedere l'elenco degli SPN generati da un controller di dominio per un dominio chiamato ABCDomain.com

Importanza dell'unicità SPN in una foresta AD

Ogni nome di servizio principale deve essere unico in tutta la foresta di Active Directory. Questa unicità garantisce che Kerberos possa indirizzare correttamente le richieste di servizio all'account appropriato. Gli SPN duplicati su account diversi causano conflitti di autenticazione, risultando in comportamenti imprevedibili o fallimenti di autenticazione.

Configurazione degli SPN: Guida passo dopo passo

Strumenti necessari per la configurazione SPN

Lo strumento principale per la configurazione di SPN è setspn.exe, che è integrato nei sistemi operativi Windows Server. Questo strumento da riga di comando permette agli amministratori di leggere, modificare ed eliminare i nomi dei principali servizi per gli account di servizio di Active Directory.

In un esempio precedente, abbiamo usato il comando setspn -L per visualizzare l'SPN di un oggetto computer. È possibile anche utilizzare setspn -S per aggiungere uno SPN. Ad esempio, per aggiungere uno SPN HTTP a un computer chiamato webserver1, il comando sarebbe:

setspn -S HTTP/webserver1.abcdomain.com abcdomain\serviceaccount

Si noti che il comando setspn -S verifica automaticamente l'esistenza di SPN identici esistenti prima di crearne di nuovi per prevenire voci duplicate.

Per rimuovere un SPN, utilizza il comando setspn -D. Puoi anche utilizzare PowerShell in diversi modi per gli SPN. Ad esempio, il seguente cmdlet di PowerShell troverà tutti gli SPN registrati in Active Directory:

Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName | Select-Object Name, servicePrincipalName

Mentre questo rileverà tutti gli SPN duplicati.

$SPNs = Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName |

Select-Object -ExpandProperty servicePrincipalName

Migliori pratiche per la registrazione SPN

• Concedi ai servizi account i permessi minimi necessari per la registrazione SPN
• Utilizza PowerShell per verificare la presenza di duplicati prima di registrare un nuovo SPN:
• Effettua audit periodici degli SPN per identificare e rimuovere voci non necessarie o obsolete
• Utilizza un formato di denominazione SPN standardizzato quando aggiungi SPN

Risoluzione dei problemi comuni degli SPN

Gli SPN duplicati possono causare fallimenti nell'autenticazione e devono essere risolti. Fate attenzione agli utenti che segnalano problemi di accesso intermittenti poiché ciò potrebbe indicare conflitti SPN. Potete utilizzare il comando setspn -x per trovare duplicati all'interno di un singolo dominio come mostrato nello screenshot qui sotto.

Utilizza il comando setspn -F per cercare in tutto il forest. Per risolvere gli SPN duplicati:

1. Identifica gli account che detengono gli SPN duplicati.
2. Determina quale account dovrebbe legittimamente detenere lo SPN.
3. Rimuovi l'SPN dall'account errato utilizzando setspn -D <SPN> <AccountName>8.
4. Aggiungi l'SPN all'account corretto utilizzando setspn -S <SPN> <AccountName>

Oltre ai duplicati, alcune altre comuni configurazioni errate di SPN includono:

• SPN mancanti per i servizi
• SPN registrati su account errati
• SPN obsoleti dopo il cambio del nome del server

(Non c'è bisogno di elencare nuovamente qui gli stessi strumenti che abbiamo già trattato)

Concetti avanzati di SPN

Il ruolo degli SPN negli ambienti multi-servizio e multi-host

Gli account di servizio sono account utente specializzati creati per i servizi in esecuzione su Windows Server. Aiutano a isolare e proteggere gli account di dominio in applicazioni critiche come Internet Information Services (IIS). In ambienti complessi, spesso su una stessa macchina vengono eseguiti più servizi, ognuno dei quali richiede distinti Nomi Principali del Servizio (SPN) per un'autenticazione corretta.

Un esempio comune è un server che ospita un'applicazione web potrebbe eseguire sia SQL Server che IIS. Ogni servizio necessita del proprio SPN per garantire un'autenticazione Kerberos corretta:

• Per IIS: HTTP/servername.domain.com
• Per SQL Server: MSSQLSvc/servername.domain.com:1433

In ambienti multi-host, dove un servizio è eseguito su più server per bilanciamento del carico o failover, la configurazione degli SPN diventa più complessa. Prendiamo in considerazione un'applicazione web ospitata su più server (Web01, Web02, Web03) sotto un unico nome DNS condiviso. In questo scenario, gli SPN devono essere registrati su un unico account di servizio per consentire un'autenticazione senza interruzioni su tutti gli host:

Casi particolari: gli SPN HOST e il loro comportamento unico

Gli SPN HOST sono un tipo speciale di SPN registrato automaticamente sugli oggetti computer in Active Directory. Fungono da identificatore universale per i servizi in esecuzione sotto l'account del sistema locale o del servizio di rete di una macchina. Questo semplifica la gestione per molti servizi standard di Windows e riduce la necessità di configurazione manuale degli SPN.

La seguente tabella riassume quando si dovrebbe utilizzare HOST SPNs rispetto a Custom SPNs:

Suggerimento: Non dovresti mai modificare manualmente gli SPN HOST poiché sono gestiti da AD.

SPN e implicazioni sulla sicurezza

Perché è fondamentale proteggere gli SPN in un ambiente AD

Il motivo per cui la sicurezza è importante per gli SPN è semplice. Gli account di servizio spesso dispongono di privilegi elevati. Hanno anche accesso continuo ai sistemi critici all'interno della rete e spesso vengono dimenticati una volta creati. Tutto ciò li rende obiettivi di alto valore per gli aggressori. Compromettere uno SPN può portare ad accesso non autorizzato a servizi critici e potenzialmente permettere agli aggressori di muoversi lateralmente all'interno della rete ed escalare i loro privilegi

Come possono essere sfruttati gli SPN deboli

Quando gli SPNS sono configurati debolmente, possono essere sfruttati attraverso attacchi come il Kerberoasting. Ecco come un attaccante potrebbe eseguire un tale attacco:

• Un attaccante con privilegi di dominio minimi può richiedere ticket di servizio per qualsiasi SPN Richieste di ticket di servizio per questi SPN
• Il biglietto di servizio, criptato con l'hash della password dell'account di servizio, può essere estratto e portato offline per essere decifrato
• Esegue il cracking offline delle password e se la password è debole, gli aggressori possono potenzialmente scoprirla e ottenere l'accesso all'account di servizio, spesso con privilegi elevati

Una volta che l'attaccante scardina la password di un account di servizio e se quell'account ha elevati privilegi, possono muoversi lateralmente attraverso la rete o aumentare il loro accesso.

Migliori pratiche per la sicurezza degli SPN e degli account di servizio

Di seguito è riportato un elenco di migliori pratiche per mitigare i rischi di sicurezza associati agli SPN:

• Utilizzare password lunghe e complesse per gli account con SPN e ruotarle regolarmente
• Evitare di assegnare SPN agli account ad alto privilegio come gli Domain Admins
• Limitare gli account di servizio solo ai permessi necessari per la loro funzione
• Disabilita l'accesso interattivo per gli account di servizio
• Monitorare l'uso inaspettato di comandi relativi a SPN in PowerShell.
• Poiché qualsiasi utente con autenticazione di dominio può cercare gli SPN, dovresti limitare chi può eseguire queste query modificando i permessi in Active Directory.

Rilevamento e mitigazione dell'abuso di SPN

Monitoraggio e auditing delle attività relative a SPN

Il monitoraggio continuo del tuo ambiente AD e l'audit degli eventi relativi a Kerberos possono rivelarsi molto efficaci per prevenire l'abuso di SPN. Alcune delle cose che dovresti rilevare includono:

• Richieste insolite di enumerazione SPN poiché gli aggressori possono interrogare AD per gli SPN utilizzando strumenti LDAP.
• Richieste frequenti di ticket Kerberos poiché un improvviso aumento delle richieste di ticket di servizio potrebbe indicare un attacco in corso.
• Accessi degli account di servizio da località inaspettate invece delle consuete località designate.
• I tentativi di autenticazione falliti come fallimenti ripetuti suggeriscono attacchi di forza bruta o password spraying tentativi.

Implementazione di strategie di mitigazione contro gli attacchi basati su SPN

Se la tua organizzazione opera all'interno di un ambiente Windows Active Directory, dovresti prendere in considerazione i seguenti controlli di sicurezza preventivi per minimizzare il rischio di abuso di SPN e attacchi di Kerberoasting.

• Utilizzare password lunghe e complesse (minimo assoluto 14 caratteri) per gli account di servizio
• Prevenire il riutilizzo delle password tra diversi account e ruotare regolarmente le password
• Applica il principle of least privilege per limitare i permessi degli account.
• Applica tempi di vita più brevi per i ticket Kerberos per ridurre la finestra di attacco
• Rivedere regolarmente e rimuovere gli SPN obsoleti o non necessari
• Adottare una strategia di difesa multilivello che combina una solida gestione degli account di servizio, un monitoraggio sofisticato e programmi di formazione regolari.

Utilizzando Group Managed Service Accounts e metodi di crittografia avanzati

Implementate Group Managed Service Accounts (gMSAs) per beneficiare della gestione automatica delle password. I Group Managed Service Accounts (gMSAs) sono account di servizio specializzati in Active Directory che offrono funzionalità di sicurezza avanzate rispetto agli account di servizio tradizionali. Sono particolarmente utili per i server collegati al dominio che eseguono servizi come SQL Server, applicazioni web IIS, attività pianificate e altri servizi che necessitano di operare in un contesto di sicurezza con permessi specifici. L'utilizzo di gMSAs eliminerà l'assegnazione manuale delle password e ridurrà il rischio di furto delle credenziali. Per quanto riguarda la crittografia, applicate una forte crittografia Kerberos AES128/AES256 imponendo la disabilitazione dei tipi di crittografia più deboli DES e RC4 in Active Directory.

Applicazioni pratiche e casi d'uso

Come accennato, gli SPN vengono utilizzati nell'autenticazione Kerberos per applicazioni web e database. IIS utilizza SPN nel formato “HTTP/ServerName” che è mappato all'account di dominio che esegue il pool di applicazioni, mentre “MSSQLSvc/host.domain.com:1433” è un esempio di account di servizio SQL. Il ruolo dei Service Principal Names (SPN) sta evolvendo oltre i casi d'uso tradizionali, tuttavia, poiché le imprese adottano sempre più architetture di rete ibride. Oggi vediamo persino gli SPN facilitare l'autenticazione sicura tra risorse on prem e applicazioni native del cloud. Altri esempi includono:

• Gli SPN vengono utilizzati per gestire identità e accessi per applicazioni e servizi containerizzati situati in ambienti containerizzati.
• Gli ambienti Edge utilizzano gli SPN per facilitare la comunicazione sicura tra i dispositivi periferici e le risorse cloud centralizzate.
• Azure AD Connect utilizza SPN per i servizi di sincronizzazione tra AD on-prem e Azure AD.

C'è anche un crescente utilizzo di SPN negli ambienti aziendali oggi. Ad esempio, i team di sicurezza monitorano i log di utilizzo degli SPN per rilevare tentativi di accesso non autorizzati o fallimenti di Kerberos. Altri esempi includono:

• Single Sign-On (SSO): gli SPN abilitano l'SSO basato su Kerberos attraverso molteplici applicazioni e servizi.
• Integrazione delle applicazioni: gli SPN facilitano la comunicazione sicura tra diverse applicazioni e servizi aziendali.
• L'autenticazione delegata: gli SPN consentono ai servizi di autenticarsi per conto degli utenti per applicazioni multi-livello.

Conclusione

I Service Principal Names (SPN) sono stati un pilastro dell'autenticazione Kerberos sin dalla nascita di Active Directory. Sono stati un elemento fondamentale per molti dei servizi classici su cui si affidano gli utenti della rete e gli SPN svolgono un ruolo vitale nel garantire operazioni sicure e senza interruzioni attraverso numerosi servizi di background. Man mano che le organizzazioni continuano ad espandersi ed evolversi, le applicazioni degli SPN si stanno allargando in ambiti come l'integrazione cloud e l'IoT. Con la crescente enfasi sulla sicurezza nelle imprese odierne, è molto probabile che gli SPN giocheranno un ruolo più ampio, adattandosi alle nuove tecnologie e alle sfide di sicurezza nel paesaggio digitale in continua espansione.

Che cos’è SPN?

Un Service Principal Name (SPN) è un identificatore univoco che collega un'istanza di servizio specifica all'account Active Directory che la esegue. Gli SPN devono essere unici in tutto il forest di Active Directory.

Se due account hanno lo stesso SPN, il controller di dominio non può determinare a quale emettere un ticket e l'autenticazione fallisce. Se nessun account possiede lo SPN, la richiesta fallisce completamente e il client di solito ricorre a NTLM, che comporta rischi propri.

Un SPN registrato su un account utente personale invece che su un account di servizio gestito rende possibile quell’attacco. La difesa è l’igiene degli account di servizio. Usa Group Managed Service Accounts. Applica password lunghe e generate casualmente a qualsiasi account che ancora possiede un SPN. Monitora l’Evento ID 4769 per picchi nelle richieste di ticket che rivelano l’attacco.

Ruolo degli SPN nell'autenticazione Kerberos

Sono anche la superficie di attacco per Kerberoasting. Qualsiasi utente autenticato nel dominio può richiedere un ticket di servizio Kerberos per un account con SPN e decifrarlo offline per ottenere la password dell'account, senza attivare una soglia di blocco.

1. Il client costruisce un SPN per il servizio a cui vuole accedere.

Un ambiente Active Directory che esegue SQL Server, IIS, Exchange e applicazioni personalizzate necessita che ogni servizio si autentichi senza richiedere agli utenti le credenziali a ogni richiesta o incorporare password nei file di configurazione. I Service Principal Names rendono tutto ciò possibile.

Quando un client richiede l'accesso a un servizio, il flusso di autenticazione Kerberos segue una sequenza definita:

Gli SPN esistono negli oggetti computer e negli account di servizio come attributo multivalore chiamato servicePrincipalNameExpand. Ogni voce in questo attributo rappresenta un servizio registrato. Un account che esegue più servizi, o un servizio accessibile tramite più nomi host, ha più voci SPN.

1. Il client richiede un ticket di servizio dal controller di dominio usando quell'SPN.
2. Il client presenta il ticket al servizio per l'autenticazione e nessuna password viene trasmessa sulla rete.
3. Il controller di dominio cerca l’SPN in Active Directory.
4. Una volta trovato, il controller di dominio emette un ticket di servizio crittografato con le credenziali dell'account di servizio.

Struttura e componenti di SPN

Questa sequenza spiega perché l’accuratezza dell’SPN è importante. Un SPN mancante, duplicato o configurato in modo errato interrompe la ricerca al passaggio 3, causando il fallimento dell’autenticazione o il ricorso a NTLM.

Componenti di un SPN

Un SPN non è un valore singolo, ma una stringa strutturata composta da diversi componenti. Comprendere questa struttura è essenziale per una corretta registrazione, risoluzione dei problemi e revisione della sicurezza.

Ogni SPN segue un formato definito che identifica il servizio, l’host su cui viene eseguito e, opzionalmente, la porta che utilizza. I componenti sono:

Formati SPN comuni in Active Directory

• Account: l'account di Active Directory associato al servizio. Questo non fa parte della stringa SPN stessa, ma è l'oggetto a cui è registrato lo SPN.
• Porta (opzionale): inclusa quando il servizio è in esecuzione su una porta non standard (ad esempio, MSSQLSvc/host.domain.com:1433Expand).
• Classe di servizio: il nome del tipo di servizio, come MSSQLSvcExpand per Microsoft SQL Server o HTTPExpand per i servizi web.
• Nom d’hôte : le serveur ou l’hôte où le service s’exécute, exprimé soit comme un nom NetBIOS (par ex., FileServerExpand) soit comme un nom de domaine complet (par ex., fileserver.company.comExpand).

Il formato ServiceClass/Hostname: PortExpand produce stringhe prevedibili e riconoscibili tra i tipi di servizio. Esempi comuni includono:

• Servizi web: HTTP/webserver.netwrix.comExpand
• SQL Server: MSSQLSvc/myhost.redmond.microsoft.com:1433Expand
• Condivisioni file: CIFS/fileserver.contoso.comExpand
• Servizi Desktop Remoto: TERMSRV/rdserver.abcdomain.comExpand

Come Active Directory memorizza e risolve gli SPN

• Autenticazione LDAP: LDAP/domaincontroller.fabrikam.comExpand

L'attributo servicePrincipalName

Gli SPN sono attributi associati agli oggetti AD come account utente, account di servizio o oggetti computer. Agiscono come etichette che indicano quali servizi vengono eseguiti sotto quali account. Questa connessione consente ai computer di utilizzare Kerberos per un'autenticazione sicura senza inviare password attraverso la rete.

Quando si installa o configura un servizio, questo registra un SPN che consente a Kerberos di associare le richieste di autenticazione all'account corretto. Senza un SPN configurato correttamente, l'autenticazione Kerberos fallirà, causando potenzialmente errori di autenticazione e interruzioni del servizio.

Quando un client richiede l'accesso a un servizio, costruisce un SPN per quel servizio, lo invia al controller di dominio e il DC cerca quell'SPN nella directory. Se trovato, emette un ticket di servizio Kerberos. Nessuna password viene trasmessa sulla rete.

Come l’unicità di SPN consente la corretta risoluzione del servizio

È possibile visualizzare gli SPN per un oggetto AD utilizzando il comando: setspn –L hostname. Nell'esempio seguente, il comando è stato usato per visualizzare l'elenco degli SPN generati da un controller di dominio per un dominio chiamato ABCDomain.com.

Gli SPN sono memorizzati in Active Directory come parte dell'attributo servicePrincipalName di un oggetto. Questo attributo esiste negli account computer e negli account di servizio e contiene un elenco di tutti gli SPN registrati per quell'oggetto. Puoi visualizzarlo nella scheda delle proprietà di un oggetto in Active Directory Users and Computers, come mostrato nello screenshot qui sotto.

HOST SPN e quando AD li gestisce automaticamente

La tabella seguente riassume quando utilizzare HOST SPNs rispetto a SPNs personalizzati:

Gli HOST SPN sono una categoria speciale di SPN che vengono registrati automaticamente sugli oggetti computer da Active Directory. Agiscono come identificatori universali per i servizi in esecuzione sotto l'account Local System o Network Service su una macchina, coprendo molti servizi standard di Windows senza richiedere voci SPN manuali.

Quando si risolvono problemi di autenticazione, i SPN duplicati dovrebbero essere tra le prime cose da controllare. Usa setspn -XExpand per rilevare duplicati all'interno di un dominio, e setspn -FExpand per cercare in tutta la foresta.

Ogni SPN deve essere univoco in tutto il forest di Active Directory. Questa unicità consente Kerberos authentication di indirizzare le richieste di servizio all'account corretto. Se due account hanno lo stesso SPN, il controller di dominio non può determinare quale usare, causando errori di autenticazione, problemi intermittenti di accesso e connessioni di servizio interrotte.

Non modificare mai manualmente gli HOST SPN. Active Directory li gestisce automaticamente e le modifiche possono interrompere i servizi principali.

Come configurare e gestire gli SPN

Passo 1: Identificare il servizio e l'account di destinazione

Passo 2: Controlla se esistono SPN duplicati o esistenti

La corretta configurazione di SPN è un prerequisito per il funzionamento dell'autenticazione Kerberos. Il processo segue una sequenza coerente indipendentemente dal tipo di servizio, e saltare passaggi è la causa più comune di problemi legati a SPN.

Prima di registrare, conferma che lo SPN non esista già su un altro account. Usa i seguenti comandi per interrogare la directory:

La registrazione di un SPN duplicato può causare errori di autenticazione e risultare difficile da diagnosticare in seguito.

Passo 3: Registra lo SPN con setspn

Prima di registrare un SPN, identifica due cose: la classe e il formato del servizio necessari e l'account di Active Directory che eseguirà il servizio. Per i servizi standard (SQL Server, IIS, Exchange), la classe del servizio è ben documentata. Per l'account, preferisci un Active Directory service account dedicato o, quando possibile, una Group Managed Service Account (gMSA) anziché un account condiviso o personale.

Per SQL Server in esecuzione su una porta non standard:

Usa setspn -SExpand (aggiunta sicura) per registrare lo SPN. Il flag -S controlla automaticamente i duplicati prima di creare la voce, rendendolo più sicuro del vecchio flag -A:

Passo 4: Verifica la registrazione

È inoltre possibile registrare SPN tramite PowerShell utilizzando i cmdlet Set-ADUser o Set-ADComputer, utile per distribuzioni automatizzate o registrazioni in blocco.

Puoi anche verificare usando PowerShell:

Dopo la registrazione, conferma che lo SPN appare sull'account corretto:

L'output deve elencare il nuovo SPN registrato insieme a tutti gli altri già assegnati a quell'account.

Passo 5: Testare l'autenticazione Kerberos

Correzione delle comuni configurazioni errate di SPN

La maggior parte dei problemi SPN rientra in poche categorie. Ognuno richiede una soluzione mirata:

In Windows Event Viewer, una richiesta di ticket di servizio Kerberos riuscita appare come Evento ID 4769. Se l'autenticazione ricade su NTLM, è probabile che l'SPN sia mancante, malformato o registrato sull'account sbagliato.

Con l'SPN registrato, verifica che l'autenticazione Kerberos abbia successo. Connettiti al servizio usando le credenziali di dominio, quindi esegui klistExpand per confermare che il DC abbia emesso un ticket di servizio Kerberos (non un ticket NTLM).

Best practice per la registrazione SPN

• SPN duplicati: Usa setspn -DExpand per rimuovere lo SPN dall’account errato, quindi verifica che rimanga su quello corretto. I duplicati spesso compaiono dopo rinominazioni di server o migrazioni di account.
• SPN obsoleti dopo la rinomina del server: Devono essere rimossi i vecchi SPN che fanno riferimento al nome host precedente e registrati nuovi con il nome attuale.
• SPN mancanti: Se Kerberos fallisce e torna a NTLM, verifica se l'SPN esiste usando setspn -QExpand. Registralo se assente.
• SPN registrati sull'account sbagliato: Rimuovili con setspn -DExpand e registrali nuovamente sull'account di servizio corretto.

Stabilire pratiche coerenti per la gestione degli SPN riduce sia i guasti operativi che i rischi per la sicurezza:

• Esegui audit regolari di PowerShell per identificare SPN registrati su account non appropriati.
• Assegna gli SPN ad account di servizio dedicati, non ad account utente personali o account Domain Admin.
• Usa setspn -SExpand (non -A) durante la registrazione per evitare duplicati accidentali.
• Usa un formato di denominazione standardizzato in tutto l’ambiente per semplificare le verifiche.

Rischi per la sicurezza degli SPN configurati in modo errato

Kerberoasting

• Concedi agli account i permessi minimi necessari. La registrazione SPN richiede l'accesso in scrittura all'attributo servicePrincipalNameExpand, che non dovrebbe essere concesso in modo esteso.

Gli account di servizio associati a SPN sono tra le identità più prese di mira in Active Directory. A differenza degli account utente standard, spesso hanno privilegi elevati, mantengono un accesso persistente ai sistemi critici e vengono raramente revisionati una volta creati. Questa combinazione crea rischi di sicurezza associati a SPN configurati in modo errato.

Attacchi con silver ticket

Un attaccante può richiedere il ticket, estrarlo ed eseguire un cracking offline della password senza attivare blocchi o generare rumore significativo sulla rete.

Kerberoasting è la tecnica di attacco basata su SPN più diffusa. Qualsiasi utente autenticato nel dominio, comprese le account a basso privilegio, può richiedere un ticket di servizio Kerberos per qualsiasi SPN nella directory. Quel ticket è crittografato con l'hash della password dell'account di servizio.

La crittografia RC4 rende questo attacco significativamente più veloce perché i ticket Kerberos crittografati con RC4 sono più facili da decifrare rispetto a quelli moderni protetti da AES, motivo per cui Microsoft sta deprecando attivamente RC4 negli ambienti AD.

Se l'account di servizio utilizza una password debole o riutilizzata, l'attaccante può recuperare le credenziali in chiaro e ottenere l'accesso al servizio, spesso con privilegi elevati.

Movimento laterale tramite account di servizio compromessi

Come difendersi dagli attacchi basati su SPN

Escalatione dei privilegi tramite SPN ad alto privilegio

Gli SPN registrati su account con permessi eccessivi, in particolare account con diritti di Domain Admin o accesso illimitato a sistemi critici, rappresentano le configurazioni a più alto rischio. Un attacco Kerberoasting riuscito contro uno di questi account non compromette solo un servizio; può dare a un attaccante il controllo a livello di dominio.

Rilevamento di Kerberoasting e enumerazione SPN

Un naturale seguito del Kerberoasting è l'attacco con silver ticket. Una volta che un attaccante rompe l'hash della password di un account di servizio, può usarlo per creare ticket di servizio Kerberos completamente offline, senza ulteriore interazione con il controller di dominio. Questi silver ticket concedono accesso persistente al servizio mirato e sono particolarmente difficili da rilevare perché bypassano completamente il DC.

Gli account di servizio solitamente hanno accesso a più sistemi. Quando un attaccante compromette uno, ottiene un punto d'appoggio che consente movimento laterale nell'ambiente. Poiché gli account di servizio sono spesso esclusi dalle regole standard di monitoraggio e rilevamento delle anomalie, questo movimento può passare inosservato per lunghi periodi.

Il monitoraggio continuo del tuo ambiente AD è la prima linea di difesa. Gli indicatori da osservare includono:

La difesa contro gli attacchi basati su SPN opera su tre fronti: rilevare precocemente gli abusi, rispondere efficacemente quando si verificano e rafforzare l'ambiente per ridurre la superficie di attacco prima che si verifichi un incidente.

• Query insolite di enumerazione SPN. Gli aggressori usano comunemente strumenti LDAP per elencare tutti gli SPN in un dominio durante il riconoscimento.
• Accessi di account di servizio da host imprevisti o in orari insoliti.

Limitare chi può interrogare gli SPN modificando i permessi in Active Directory riduce la finestra di ricognizione disponibile agli attaccanti con pochi privilegi.

Contenere e rispondere all'abuso di SPN

• Un improvviso picco nell'ID evento 4769 (richieste di ticket di servizio Kerberos), in particolare quelli che utilizzano la crittografia RC4 (tipo di crittografia 0x17), indica fortemente Kerberoasting, poiché gli aggressori preferiscono i ticket RC4 per una decodifica più veloce.
• Tentativi ripetuti di autenticazione fallita, che possono indicare attacchi di forza bruta o password-spraying contro credenziali compromesse.

Quando viene rilevato un abuso basato su SPN, la priorità è limitare la capacità dell'attaccante di utilizzare le credenziali compromesse:

• Reimpostare immediatamente la password dell'account di servizio interessato con una credenziale lunga generata casualmente.
• Verifica se l'account possiede più privilegi di quelli richiesti dalla sua funzione e riducili.
• Esamina tutti i sistemi a cui l'account di servizio ha accesso e verifica le attività recenti per rilevare segni di movimento laterale.

Rafforzamento degli account di servizio abilitati per SPN

L'indurimento proattivo elimina molte delle condizioni che rendono possibili gli attacchi basati su SPN:

• Usa password lunghe generate casualmente (minimo 25 caratteri) per gli account di servizio e ruotale secondo un programma definito.
• Revoca eventuali ticket Kerberos attivi emessi per l’account reimpostando le chiavi di crittografia Kerberos dell’account (non è necessario un reset di krbtgt per la mitigazione dei silver ticket; reimpostare la password dell’account di servizio invalida i ticket contraffatti).
• Disabilita l'accesso interattivo per gli account di servizio per limitarne l'utilità in caso di compromissione.
• Applica il principio del minimo privilegio. Gli account di servizio dovrebbero avere accesso solo ai sistemi e ai dati necessari per la loro funzione.

Utilizzo di gMSA e crittografia AES per eliminare il rischio permanente

• Migrare a Group Managed Service Accounts ogni volta che è possibile, poiché automatizzano la gestione delle password e rendono il Kerberoasting molto più difficile.

Le Group Managed Service Accounts (gMSA) sono account di servizio specializzati che eliminano completamente la necessità di gestire manualmente le password. Active Directory gestisce automaticamente le password gMSA, ruotandole secondo un programma definito utilizzando credenziali lunghe e generate casualmente che gli amministratori di servizio e di dominio non vedono né gestiscono direttamente.

SPN in ambienti ibridi e moderni

Per impostazione predefinita, Windows ruota le password gMSA ogni 30 giorni e l'intervallo è controllato dall'attributo msDS‑ManagedPasswordInterval (o dal parametro ManagedPasswordIntervalInDays durante la creazione del gMSA), che può essere impostato solo al momento della creazione.

Per i servizi che non supportano gMSA, applica la crittografia Kerberos AES-128 o AES-256 e disabilita esplicitamente i tipi di crittografia più deboli RC4 e DES in Active Directory. La crittografia RC4 è quella predefinita usata negli attacchi Kerberoasting; rimuoverla obbliga a usare AES, che è molto più resistente al cracking offline.

• Non assegnare mai SPN ad account con appartenenza a Domain Admin o ad altri gruppi ad alto privilegio.

SPN e Microsoft Entra Connect

Il ruolo di SPNs si è ampliato oltre il tradizionale Active Directory on-premises, poiché le organizzazioni adottano architetture ibride e carichi di lavoro containerizzati. SPNs rimangono rilevanti ovunque venga utilizzata l'autenticazione Kerberos e, in alcuni contesti più recenti, abilitano schemi di autenticazione che non esistevano nel design originale di AD.

SPN in ambienti containerizzati

Autenticazione delegata in applicazioni multi-livello

Microsoft Entra Connect utilizza SPN per i suoi servizi di sincronizzazione tra Active Directory on-premises e Entra ID (ex Azure AD). L'account del servizio di sincronizzazione richiede SPN configurati correttamente per autenticarsi in entrambi i directory. SPN configurati in modo errato o mancanti possono interrompere silenziosamente la sincronizzazione della directory, causando l'obsolescenza dei dati di identità nell'ambiente ibrido.

Delega Kerberos consente a un servizio di autenticarsi alle risorse a valle per conto di un utente. Questo è comune nelle applicazioni a più livelli dove un front-end web deve trasmettere l'identità dell'utente a un database backend.

I carichi di lavoro containerizzati in esecuzione su Windows Server possono utilizzare gMSA e, per estensione, SPN, per Active Directory security. Le distribuzioni di Kubernetes e Docker su host uniti al dominio possono essere configurate per richiedere credenziali gMSA, consentendo ai servizi containerizzati di autenticarsi alle risorse integrate con AD utilizzando Kerberos senza incorporare credenziali nelle immagini dei container.

Gli SPN sono centrali in questo: la delega è configurata sull'account di servizio che detiene lo SPN, e ogni passaggio nella catena di autenticazione dipende da SPN correttamente registrati.

Gli SPN sono fondamentali e sempre più presi di mira

La delega non vincolata, in cui un servizio può impersonare qualsiasi utente su qualsiasi risorsa, rappresenta una superficie di attacco significativa e dovrebbe essere sostituita con delega vincolata o delega vincolata basata su risorse ove possibile.

I Service Principal Names sono stati una pietra miliare dell'autenticazione Kerberos sin dalla nascita di Active Directory. Consentono un'autenticazione sicura dei servizi senza password negli ambienti aziendali, ma solo se configurati correttamente, regolarmente verificati e strettamente gestiti.

Netwrix offre strumenti appositamente progettati per le due sfide di sicurezza SPN più importanti: rilevare attacchi in corso e mantenere la visibilità delle modifiche in AD che introducono rischi.

Come Netwrix può aiutare

Man mano che le organizzazioni si espandono verso infrastrutture ibride, container e sistemi di identità integrati nel cloud, gli SPN compaiono in più luoghi e sono collegati ad account con accessi più ampi che mai.

Il calcolo delle minacce è cambiato di conseguenza. Il Kerberoasting è diventato una delle tecniche di movimento laterale più comunemente osservate nelle violazioni aziendali, proprio perché gli SPN sono sia ubiqui che poco monitorati. Le configurazioni errate che una volta causavano fallimenti di autenticazione ora fanno parte della superficie di attacco.

Comprendere gli SPN, come sono strutturati, come AD li risolve e come gli attaccanti sfruttano configurazioni deboli è il primo passo per proteggerli. I passaggi operativi trattati in questo articolo forniscono una base. Su questa base, il monitoraggio continuo, le revisioni regolari degli SPN e, quando possibile, la migrazione a gMSA aiutano le organizzazioni a stare un passo avanti alla minaccia.

Netwrix Threat Manager rileva attacchi basati sull’identità, inclusi Kerberoasting, query di enumerazione SPN e richieste sospette di ticket di servizio in Active Directory on-premises e Entra ID.

Si correla con attività anomala a livello di account. Quando un utente con pochi privilegi richiede improvvisamente 50 ticket di assistenza, i team di sicurezza lo vedono come un unico avviso consolidato anziché come voci di log isolate.

Richiedi una demo per vedere come Netwrix può aiutarti a rilevare l'abuso di SPN, controllare le modifiche in AD in tempo reale e ridurre la superficie di attacco prima che gli avversari la sfruttino.

Netwrix Auditor traccia ogni modifica all'attributo servicePrincipalName nel tuo ambiente AD, con valori prima e dopo e l'account responsabile di ogni modifica. Quando un SPN viene registrato su un account ad alto privilegio o rimosso inaspettatamente da un account di servizio, Auditor segnala immediatamente tale modifica.