R: Il protocollo di autenticazione Kerberos utilizza ticket di sessione crittografati con una chiave simmetrica derivata dalla password del server o del servizio a cui un utente Windows richiede l’accesso. Per richiedere un ticket di sessione, l’utente deve presentare un ticket speciale, denominato ticket-Granting Ticket (TGT) al servizio Kerberos Key Distribution Center (KDC) su un controller di dominio (DC). Tutti gli utenti Windows ricevono un TGT dal KDC all’inizio della sessione di accesso di Windows dopo che si sono autenticati correttamente al KDC utilizzando la loro password.
Il KDC crittografa il TGT di un utente con una chiave che deriva dalla password dell’account krbtgt AD domain. L’account krbtgt e la relativa password sono condivisi tra i servizi KDC di tutti i DCS in un dominio. L’account krbtgt viene creato automaticamente come parte del processo di installazione di dcpromo AD sul primo DC in un dominio. Viene visualizzato nel contenitore Utenti dello snap-in Utenti e computer di Microsoft Management Console (MMC) Active Directory ed è disabilitato per impostazione predefinita. A differenza di altri account utente AD, l’account krbtgt non può essere utilizzato per accedere in modo interattivo al dominio. Poiché è un account integrato, anche krbtgt non può essere rinominato.
Un controller di dominio di sola lettura (RODC) è un nuovo tipo di DC che Microsoft ha introdotto in Windows Server 2008. Un RODC ospita partizioni di sola lettura del database AD. Non memorizza gli hash delle password di tutti gli account utente in un dominio Windows; invece, un RODC memorizza solo gli hash delle password degli account definiti nel criterio di replica delle password (PRP) di RODC. Questo metodo significa che il compromesso di un RODC rappresenta molto meno rischio rispetto al compromesso di un classico DC di lettura/scrittura (RWDC) che contiene copie degli hash delle password di tutti gli account utente in un dominio. Ecco perché un RODC può essere distribuito in un modo che potrebbe essere considerato meno sicuro. Le organizzazioni in genere li distribuiscono nelle filiali o nelle loro zone demilitarizzate (DMZ).
Un RODC funge da Kerberos KDC per una filiale o DMZ, e come tale richiede anche un account krbtgt. Per garantire che il krbtgt di un RODC compromesso non possa essere sfruttato per richiedere biglietti ad altri RODC o RWDC, ogni RODC ha uno speciale account krbtgt locale. Questo account ha il formato krbtgt123, dove ” 123 ” è una stringa di numeri casuali. Questa stringa casuale identifica in modo univoco il RODC e viene generata quando viene installato un RODC.
I diversi account krbtgt locali dei RODC in un dominio sono memorizzati in AD e vengono visualizzati negli utenti e nei computer di Active Directory sotto il contenitore Utenti. Tutti i RWDC nel dominio conservano anche una copia degli hash delle password degli account krbtgt dei RODC nel dominio. Pertanto, un TGT emesso da un RODC è valido per la richiesta di ticket di sessione contro lo stesso RODC e anche contro qualsiasi altro RWDC nel dominio.
Se un RODC riceve una richiesta di ticket di sessione basata su un TGT non valido, il che significa che il TGT non è stato emesso dal RODC stesso, restituisce un errore Kerberos che chiede al computer client di richiedere una nuova richiesta TGT contro il RODC stesso. Se il RODC non ha una copia dell’hash della password dell’utente, il RODC inoltra la richiesta TGT a un RWDC. In questo caso, il RODC funge da proxy, per cui inoltra la risposta dal RWDC direttamente al computer client. Allo stesso tempo, il RODC attiva il processo di memorizzazione nella cache dell’hash della password utente in modo che il RODC sarà in grado di creare un TGT per quel particolare utente in futuro. La memorizzazione nella cache ha esito positivo se il PRP del RODC consente di memorizzare nella cache l’hash della password dell’account utente sul RODC.
Correlati: Come posso installare e configurare un controller di dominio di sola lettura (RODC)?
