Configurazione del Protocollo di Autenticazione Kerberos

Prende il nome dal cane a tre teste che, secondo la mitologia greca antica, custodiva le porte degli Inferi, il protocollo Kerberos fornisce un servizio di autenticazione sicura per le reti informatiche. Esso effettua un’autenticazione reciproca tra l’utente e il server con l’aiuto di un Key Distribution Center (KDC) di terze parti fidato che fornisce un servizio di autenticazione e di rilascio dei ticket. Tutti i principali sistemi operativi, inclusi Microsoft Windows, Linux, Apple OS X e FreeBSD, supportano il protocollo Kerberos.

I messaggi del protocollo Kerberos sono protetti contro attacchi di replay e intercettazioni grazie alla crittografia a chiave condivisa. L’obiettivo principale di Kerberos è evitare la trasmissione di password criptate attraverso la rete. Ciò elimina la minaccia dei packet sniffers e aumenta la sicurezza complessiva della rete.

Perché l’Autenticazione Kerberos è Importante

L’autenticazione Kerberos è un protocollo fondamentale per la verifica centralizzata e sicura degli utenti nelle reti aziendali. Essa permette una fiducia reciproca tra utenti e servizi senza inviare le password attraverso la rete, riducendo l’esposizione al furto di credenziali e agli attacchi man-in-the-middle.

Oggi, Kerberos è ampiamente utilizzato nei domini Active Directory, nei sistemi aziendali di single sign-on e negli ambienti cloud sicuri. Il suo modello basato sui ticket garantisce un’autenticazione scalabile ed efficiente, soprattutto in infrastrutture complesse e a più livelli.

Strumenti come DataSunrise supportano l’autenticazione Kerberos agendo come proxy sicuro, applicando le politiche di Active Directory e gestendo l’accesso alle risorse dati critiche, sia in sede che nel cloud.

Nonostante il fornitore di supporto di sicurezza Kerberos affronti efficacemente gravi minacce di sicurezza, la sua implementazione può essere complessa a causa di varie limitazioni:

• Se il server Kerberos è inattivo, gli utenti non possono effettuare il login. Il problema può essere risolto utilizzando meccanismi di autenticazione di riserva e più server Kerberos.
• Gli orologi degli host coinvolti devono essere sincronizzati. Altrimenti, l’autenticazione fallirà, poiché i ticket Kerberos hanno un determinato periodo di validità.
• Kerberos non può essere utilizzato quando gli utenti desiderano connettersi a servizi da sistemi non fidati.
• Nel caso venga usata la crittografia simmetrica, il compromesso dell’infrastruttura di autenticazione permetterà a un attaccante di impersonare qualsiasi utente.
• Ogni servizio di rete che richiede un hostname diverso avrà bisogno del proprio set di chiavi Kerberos.

Come Funziona l’Autenticazione Kerberos

Un Key Distribution Center è composto da un Authentication Server (AS) e un Ticket Granting Server (TGS). TGT sta per Ticket Granting Ticket.

1. L’utente inserisce il login e la password. L’ID utente in chiaro viene inviato all’Authentication Server (AS) con una richiesta di servizi per conto dell’utente.
2. AS verifica se il login utente è presente nel database. Se esistono informazioni su quell’utente, AS può generare una chiave segreta del client in base all’ID e alla password dell’utente. AS invia all’utente:
   • La chiave di sessione client/TSG (crittografata con la chiave segreta del client);
   • Il TGT che include l’ID utente, l’indirizzo di rete e il periodo di validità del ticket + la chiave di sessione Client/TGS (crittografata con la chiave segreta del TGS).
3. L’utente decodifica il primo messaggio, ma non riesce a decodificare il secondo, perché non possiede la chiave segreta del TSG. Il client invia un messaggio al TGS:
   • Il TGT ricevuto da AS + ID del server + chiave segreta TGS/Client (crittografata con la chiave segreta del TGS);
   • L’autenticatore che include l’ID del client e il timestamp (crittografato con la chiave di sessione Client/TSG).
4. Il TGS decrittografa il primo messaggio, ottiene il TGT + la chiave di sessione TGS/Client, con la quale decrittografa il secondo messaggio. Il TGS verifica se l’ID utente del primo messaggio corrisponde all’ID del secondo messaggio e se il timestamp non supera il periodo di validità del ticket. Se tutto è corretto, il TSG invia all’utente:
   • L’ID utilizzato, l’indirizzo di rete, il periodo di validità del ticket + la chiave di sessione Client/Server (crittografata con la chiave segreta del Server);
   • La chiave di sessione client/server (crittografata con la chiave segreta Client/TGS).
5. Il client invia quanto segue al Server a cui tenta di accedere:
   • L’ID utilizzato, l’indirizzo di rete, il periodo di validità del ticket + la chiave di sessione Client/Server (crittografata con la chiave segreta del Server);
   • L’autenticatore che include l’ID e il timestamp (crittografato con la chiave di sessione Client/Server).
6. Il server di destinazione decrittografa i messaggi dell’utente, verifica se l’ID utente in entrambi i messaggi ha lo stesso valore e se il periodo di validità non è scaduto, quindi invia al client il seguente parametro per confermare la propria identità:
   • Timestamp + 1 (crittografato con la chiave di sessione Client/Server).

Il client controlla se il valore del timestamp corrisponde a timestamp + 1, il che conferma la vera identità del server. Se ciò avviene, il client può fidarsi del server e iniziare a lavorare con esso.

Applicazioni Moderne di Kerberos

Kerberos rimane fondamentale negli ambienti aziendali odierni. I provider cloud integrano Kerberos con i loro servizi di identità. L’autenticazione a più fattori rafforza la postura di sicurezza di Kerberos. Le soluzioni single sign-on sfruttano Kerberos per un accesso senza interruzioni. Molte applicazioni containerizzate supportano l’autenticazione Kerberos. Le pipeline DevOps utilizzano Kerberos per flussi di lavoro CI/CD sicuri. I sistemi di gestione dei dispositivi mobili incorporano i principi di Kerberos. Le architetture Zero Trust si basano spesso sui fondamenti di Kerberos. Le soluzioni di identità federata estendono Kerberos oltre i confini organizzativi. La gestione automatizzata dei certificati semplifica la manutenzione di Kerberos. Le implementazioni moderne affrontano molte delle tradizionali limitazioni di Kerberos.

Configurazione del Protocollo di Autenticazione Kerberos

Per configurare il protocollo Kerberos, è necessario eseguire le seguenti operazioni:

1. Creare un utente Active Directory (è possibile utilizzare uno esistente al suo posto).
   • Accedere al server del domain controller, fare clic su Start → Strumenti Amministrativi e avviare Utenti e Computer di Active Directory.
   • Se non è già selezionato, fare clic sul nodo relativo al proprio dominio (domain.com).
   • Fare clic con il pulsante destro su Utenti, puntare su Nuovo e quindi fare clic su Utente.
   • Nella finestra di dialogo Nuovo Oggetto → Utente specificare i parametri del nuovo utente. Potrebbe trattarsi di un utente normale, non è necessario fornire privilegi aggiuntivi. L’account utente deve essere attivo (la casella di controllo L’account è disabilitato non deve essere selezionata) e la password dell’account deve essere perpetua (la casella di controllo La password non scade mai deve essere selezionata).
2. Assegnare i nomi principali con le chiavi crittografate sulla macchina del domain controller. Per le macchine Linux, creare un file keytab contenente le coppie di principal Kerberos e chiavi crittografate. Un file keytab viene utilizzato per autenticarsi a vari sistemi remoti usando Kerberos senza dover inserire una password.
   • Creare un keytab con la prima voce utilizzando lo strumento ktpass: ktpass /princ [email protected] /mapuser user1_backend /pass /crypto all /ptype KRB5_NT_PRINCIPAL /out C:\Users\user1\Desktop \datasunrise.keytab -setupn
     

     /princ	Il nome principale del servizio (SPN) nel seguente formato: @
     /mapuser	Mappa il nome del principal Kerberos, specificato dal parametro princ, all’account di dominio indicato.
     /pass	Specifica la password per il nome principale dell’utente.
     /ptype	Specifica il tipo di principal. Utilizzare KRB5_NT_PRINCIPAL.
     /crypto	Specifica le chiavi che vengono generate nel file keytab.
     /out	Assegna una directory e un nome per il file di output *.keytab.
     -setupn	Non imposta il nome principale utente insieme al nome principale del servizio.

   • Creare una seconda voce nel file keytab per la connessione al database utilizzando l’utente AD. L’esempio mostra la creazione di voci keytab per la connessione al database Vertica utilizzando l’utente AD. Per altri database o per l’autenticazione tramite GUI, eseguire lo stesso comando con il nome del servizio corrispondente nel parametro /princ. ktpass /out ./datasunrise.keytab /princ vertica/[email protected] /mapuser user1 /mapop set /pass /ptype KRB5_NT_PRINCIPAL /crypto RC4-HMAC-NT
   • Sarà necessario trasferire il file keytab sulla macchina Linux.
3. Configurare la delega in Active Directory.
   • Sulla macchina del domain controller, aprire Utenti e Computer di Active Directory e individuare l’account della macchina per la quale si desidera configurare Kerberos.
   • Nella sezione Proprietà, andare alla scheda Delegazione e selezionare Considera questo computer attendibile per la delega solo ai servizi specificati e fare clic su Aggiungi.
   • Nella finestra Utenti e Computer specificare l’account utente che è stato usato per avviare il database o il nome del server su cui è installato l’RDBMS.
   • Facoltativamente, è possibile utilizzare Verifica nomi per controllare se l’utente o il computer specificato esiste e fare clic su OK, quindi selezionare il servizio richiesto e fare clic su OK.
4. Installare e configurare il client Kerberos sulla propria macchina. sudo apt-get install krb5-user libpam-krb5 libpam-ccreds auth-client-config

   Editare il file /etc/krb5.conf per aggiungere il nome completo del dominio, il nome del domain controller e il parametro realm

   Importante: Non lasciare commenti identificati dal segno “#” nel file di configurazione.

   [libdefaults]
       default_realm       =           DOMAIN.COM    # parametro specifico del dominio (nome completo del dominio)
       clockskew           =           300
       ticket_lifetime     =           1d
       forwardable         =           true
       proxiable           =           true
       dns_lookup_realm    =           true
       dns_lookup_kdc      =           true
      
    
      [realms]
           DOMAIN.COM = {
           kdc            =       hostname.domain.com   # parametro specifico del dominio (nome del domain controller)
           admin_server   =       hostname.domain.com   # parametro specifico del dominio (nome del domain controller)
           default_domain =       DOMAIN.COM         # parametro specifico del dominio (nome completo del dominio)
           }
    
   [domain_realm]
           .domain.com = DOMAIN.COM  # parametro specifico del dominio (nome del dominio per i nomi DNS)
           domain.com = DOMAIN.COM   # parametro specifico del dominio (nome del dominio per i nomi DNS)
    
   [appdefaults]
           pam = {
           ticket_lifetime         = 1d
           renew_lifetime          = 1d
           forwardable             = true
           proxiable               = false
           retain_after_close      = false
           minimum_uid             = 0
           debug                   = false
           }

Per le macchine con sistema operativo Windows, non è necessario installare e configurare il protocollo Kerberos, ma la macchina deve far parte del dominio Active Directory. Inoltre, per impostare i nomi principali del servizio viene utilizzato il comando setspn. Di seguito è riportato un esempio di configurazione di una macchina Windows per la connessione al database MS SQL Server utilizzando le credenziali dell’utente AD.

L’indirizzo proxy deve corrispondere all’SPN registrato del servizio MSSQLSvc. Utilizzare lo strumento SetSPN per registrare i due SPN richiesti per l’account del computer per il quale è stata autorizzata la delega:

setspn -A MSSQLSvc/proxy-host:proxy-port proxy-host setspn -A MSSQLSvc/full-fqdn-proxy-host:proxy-port proxy-host

L’elenco di tutti gli SPN registrati può essere ottenuto con il seguente comando:

setspn -L proxy-host

Per eliminare l’SPN proxy, eseguire quanto segue:

setspn -D MSSQLSvc/proxy-host:proxy-port proxy-host

Per testare lo schema di autorizzazione, eseguire il seguente comando dopo essersi connessi al server:

select auth_scheme from sys.dm_exec_connections where session_id=@@spid

Il risultato corrisponderà allo schema di autenticazione utilizzato dal server: SQL, NTLM o KERBEROS.

In caso di errore “Cannot generate SSPI context”, fare riferimento alle istruzioni di supporto Microsoft su come risolvere il problema relativo all’interfaccia di supporto della sicurezza.

DataSunrise può funzionare come proxy di autenticazione per database cloud e on-premises per minimizzare i rischi di accessi non autorizzati mantenendo le politiche di autenticazione di Microsoft Active Directory e del protocollo Kerberos.

Il tuo database o l’archiviazione basata su cloud contiene informazioni sensibili che necessitano di protezione? Hai bisogno di conformarti alle normative GDPR, SOX o HIPAA? Scopri le soluzioni innovative di DataSunrise per la auditing dei database, la sicurezza e il data masking. Prova il nostro software gratuitamente o prenota una demo online oggi.