Autenticazione Kerberos alcune note

Kerberos V5 rappresenta il protocollo di protezione principale per l’autenticazione in un dominio. Tramite questo protocollo viene verificata l’identità dell”utente che richiede l’autenticazione e del server che fornisce l’autenticazione richiesta. Questa duplice verifica viene definita anche autenticazione reciproca.

l meccanismo di autenticazione Kerberos V5 è basato sul rilascio di ticket per l’accesso ai servizi di rete. Questi ticket contengono dati crittografati, compresa una password crittografata, che conferma l’identità dell’utente al servizio richiesto. Ad eccezione dell’immissione di credenziali quali la password o la smart card, l’intero processo di autenticazione risulta invisibile all’utente.

 

image

I servizi Kerberos V5 vengono installati in ciascun controller di dominio e il client Kerberos viene installato in ogni workstation e server (in Windows 2000 e successivo è supportato in modo nativo e automaticamente installato, ma disponibile solo per logon verso domini Active Directory o altri Realm Kerberos).

Un servizio importante offerto dal protocollo Kerberos V5 è il Centro distribuzione chiave (KDC, Key Distribution Center). Il KDC viene eseguito in ciascun controller di dominio come parte del servizio directory Active Directory.

Un client utilizza una ricerca DNS (Domain Name Service) per individuare il controller di dominio più vicino. Tale controller di dominio funziona quindi come KDC preferito per tale utente durante la sessione di accesso. Se il KDC preferito non è più disponibile, il sistema individuerà un altro KDC per fornire l’autenticazione.

 Il KDC consiste di due componenti:

  • Authentication Service (AS)
    • Riceve: AS_REQuest
    • Invia: AS_REPly
  • Ticket Granting Server (TGS)
    • Riceve: TGS_REQuest
    • Invia: TGS_REPly

Il processo di autenticazione Kerberos V5 funziona come segue:

  1. L’utente che si trova in un sistema client ottiene l’autenticazione al KDC utilizzando una password o una smart card.
  2. Il servizio KDC rilascia al client un ticket di concessione ticket (TGT, Ticket-Granting Ticket).
  3. Tramite il TGT il sistema client accede al servizio di concessione ticket (TGS, Ticket-Granting Service).Il servizio TGS rilascia quindi al client un ticket di servizio (ST).
  4. Il client presenta il ST al servizio di rete richiesto. Con il ST viene verificata l’identità dell’utente al servizio e l’identità del servizio all’utente.

 

image

In sintesi:

  • il TGT identifica l’utente presso il KDC durante le richieste di Service Ticket ed evita il mantenimento dei dati di logon
  • il ST è valido solamente tra User e Servizio e consente la mutua autenticazione accelerando la velocità di connessione perché rende non necessaria l’autenticazione da parte del servizio

 

Un ruolo importante nell’autenticazione kerberos è rivestito dalla sincronizzazione temporale tra client e server, a tal proposito si veda il seguente How the Kerberos Version 5 Authentication Protocol Works:

The authenticator’s timestamp

The timestamp is perhaps the most important piece of data in the authenticator. A domain’s Kerberos policy and policies established by applications typically require that the timestamp be within minutes of the time on the target server. Otherwise, the authenticator and the ticket will be rejected. This helps prevent message replay.

Although no authenticator is included in the initial authentication service request message, the message does include the client’s timestamp in the pre-authentication field.”

Infatti come si può vedere dalle Kerberos Policy uno scostamento dei riferimenti temporali tra client e server di 5 minuti causa il fallimento dell’autenticazione:

  • Maximum lifetime for service ticket.
    A service ticket is a session ticket. Settings are in minutes. The setting must be greater than ten minutes and less than the setting for Maximum user ticket lifetime . The default is ten hours.
  • Maximum lifetime for user ticket
    A user ticket is a TGT. Settings are in hours. The default setting is ten hours.
  • Maximum lifetime for user ticket renewal
    Settings are in days. The default setting is seven days.
  • Maximum tolerance for computer clock synchronization
    Settings are in minutes. The default is five minutes.

Lo scostamento temporale va però considerato tenendo presente le note del seguente Kerberos tickets are issued even though the time difference between the client clock and the domain controller clock is greater than the “Maximum tolerance for computer clock synchronization” value:

“If a client computer sends a time stamp whose value differs from that of the server’s time stamp by more than the value that you configured in the Maximum tolerance for computer clock synchronization setting, the domain controller returns a “KRB_AP_ERR_SKEW” error code in its response packet. In this packet, the domain controller also includes a time stamp of its own clock. When the client computer receives this packet, it uses the time stamp of the domain controller together with the value of the Maximum tolerance for computer clock synchronization setting to calculate the valid time. Then, the client computer uses the valid time to retry the request. On this second try, the Kerberos ticket is issued to the client computer.
This behavior is documented in Request for Comments (RFC) 4430, “Kerberized Internet Negotiation of Keys (KINK).”

If the clock of the client computer is faster than the clock time of the domain controller plus the lifetime of Kerberos ticket, the Kerberos ticket is invalid. In this scenario, the logon fails.

Per analizzare i ticket kerberos rilasciati al client è possibile utilizzare i seguenti tool: