Configurazione del Protocollo di Autenticazione Kerberos

Chiamato come il cane a tre teste che custodiva le porte degli inferi nei miti dell’antica Grecia, il protocollo Kerberos fornisce un servizio di autenticazione sicuro per le reti informatiche. Effettua l’autenticazione reciproca tra l’utente e il server con l’aiuto di un Centro di Distribuzione delle Chiavi (KDC) di terze parti fidata, che fornisce servizi di autenticazione e rilascio di 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 gli attacchi di ripetizione e intercettazione mediante crittografia segreta condivisa. Lo scopo principale di Kerberos è evitare la trasmissione di password crittografate sulla rete. Elimina la minaccia degli sniffers di pacchetti e migliora la sicurezza complessiva della rete.

Nonostante il provider di supporto alla sicurezza Kerberos gestisca efficacemente gravi minacce alla sicurezza, può essere difficile da implementare a causa di diverse limitazioni:

• Se il server Kerberos è inattivo, gli utenti non possono accedere. Il problema può essere risolto utilizzando meccanismi di autenticazione di fallback e più server Kerberos.
• Gli orologi degli host coinvolti devono essere sincronizzati. Altrimenti, l’autenticazione fallirà poiché i ticket Kerberos hanno un certo periodo di validità.
• Kerberos non può essere utilizzato quando gli utenti desiderano connettersi a servizi da sistemi non attendibili.
• Nel caso in cui venga utilizzata 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 Centro di Distribuzione delle Chiavi è costituito da un Server di Autenticazione (AS) e da un Server di Rilascio Ticket (TGS). Il TGT è un Ticket di Rilascio Ticket.

1. L’utente inserisce il login e la password. L’ID utente in chiaro va al Server di Autenticazione (AS) con una richiesta di servizi a nome dell’utente.
2. AS verifica se il login utente è nel database. Se c’è informazione su quell’utente, AS può generare una chiave segreta 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 client);
   • TGT che include l’ID utente, l’indirizzo di rete e il periodo di validità del ticket + Chiave di sessione client/TGS (crittografata con la chiave segreta TGS).
3. L’utente decodifica il primo messaggio ma non può decodificare il secondo, perché l’utente non ha la chiave segreta TSG. Il client invia un messaggio al TGS:
   • Il TGT ricevuto da AS + ID Server + chiave segreta TGS/Client (crittografata con la chiave segreta TGS);
   • L’autenticatore che include l’ID client e il timestamp (crittografato con la chiave di sessione client/TSG).
4. Il TGS decodifica il primo messaggio, ottiene il TGT + la chiave di sessione TGS/Client, con cui decodifica 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. In caso tutto sia corretto, il TSG invia all’utente:
   • L’ID utente usato, l’indirizzo di rete, il periodo di validità del ticket + 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 usato, l’indirizzo di rete, il periodo di validità del ticket + 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 decodifica i messaggi dell’utente, verifica se l’ID utente dei due messaggi ha lo stesso valore e se il periodo di validità non è scaduto, quindi invia al client il seguente parametro per confermare la sua identità:
   • Timestamp + 1 (crittografato con la chiave di sessione client/Server).

Il client verifica se il valore del timestamp è timestamp + 1, il che dimostra la vera identità del server. Se è così, il client può fidarsi del server e iniziare a lavorare con esso.

Configurazione del Protocollo di Autenticazione Kerberos

Per configurare il protocollo Kerberos, è necessario fare quanto segue:

1. Creare un utente di Active Directory (è possibile usarne uno esistente).
   • Accedere al server del controller di dominio, fare clic su Start → Strumenti di Amministrazione e avviare Utenti e Computer di Active Directory.
   • Se non è già selezionato, fare clic sul nodo per il proprio dominio (domain.com).
   • Fare clic con il pulsante destro del mouse su Users, puntare su New e quindi fare clic su User.
   • Nella finestra di dialogo Nuovo Oggetto → Utente specificare i parametri del nuovo utente. Potrebbe essere un utente regolare, non è necessario fornire all’utente privilegi aggiuntivi. L’account utente deve essere attivo (la casella di controllo Account è disattivato deselezionata) e la password per l’account deve essere perpetua (la casella di controllo La password non scade mai selezionata).
2. Assegnare i nomi principali con le chiavi crittografate sulla macchina del controller di dominio. Per le macchine su Linux, creare un file keytab contenente coppie di principali Kerberos e chiavi crittografate. Un file keytab viene utilizzato per autenticarsi a vari sistemi remoti utilizzando Kerberos senza 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 principale Kerberos, specificato dal parametro princ, all’account di dominio specificato.
     /pass	Specifica la password per il nome dell’utente principale.
     /ptype	Specifica il tipo principale. Utilizzare KRB5_NT_PRINCIPAL.
     /crypto	Specifica le chiavi che vengono generate nel file keytab.
     /out	Assegna una directory e un nome per il file *.keytab di output.
     -setupn	Non imposta il nome principale dell’utente insieme al nome principale del servizio.

   • Creare una seconda voce nel file keytab per connettersi al database utilizzando l’utente AD. L’esempio è dato per la creazione di voci keytab per connettersi al database Vertica utilizzando l’utente AD. Per altri database o per l’autenticazione 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 di Active Directory.
   • Sulla macchina del controller di dominio, andare su Utenti e Computer di Active Directory, individuare l’account della macchina che si desidera configurare per Kerberos.
   • Nella sezione Proprietà, andare alla scheda Delega e selezionare Fida questo computer solo per la delega ai servizi specificati e fare clic su Aggiungi.
   • Nella finestra Utenti e Computer, specificare l’account utente che è stato utilizzato per avviare il database o il nome del server in cui è installato l’RDBMS.
   • Facoltativamente, si può usare Controlla nomi per verificare se un utente o 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

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

   Importante: Non lasciare commenti contrassegnati con il 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 controller di dominio)
           admin_server   =       hostname.domain.com   # parametro specifico del dominio (nome del controller di dominio)
           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 sul sistema operativo Windows, non è necessario installare e configurare il protocollo Kerberos ma deve essere nel dominio di Active Directory. Inoltre, per impostare i nomi principali dei servizi si utilizza il comando setspn. Qui sotto è riportato un esempio di configurazione di una macchina Windows per connettersi al database MS SQL Server utilizzando le credenziali utente AD.

L’indirizzo del 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 cui è stata consentita 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 il proxy SPN, 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 con l’interfaccia di supporto della sicurezza.

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

Il suo database o l’archiviazione cloud contiene informazioni sensibili che richiedono protezione? Ha bisogno di conformità con le normative GDPR, SOX o HIPAA? Scopra le soluzioni all’avanguardia di DataSunrise per l’auditing, la sicurezza e il mascheramento dei dati. Provi il nostro software gratuitamente o pianifichi una demo online oggi stesso.