Cos'è SPN e qual è 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.