Account KRBTGT e best practices di sicurezza

L’account KRBTGT, come indicato in Active Directory Accounts, è un account di Active Directory predefinito utilizzato dal servizio Key Distribution Center (KDC). Tale account non può essere eliminato, non può essere rinominato e non può essere abilitato.

Inoltre KRBTGT è anche il security principal name usato dal KDC per un dominio Windows Server, come specificato nella RFC 4120 – The Kerberos Network Authentication Service.

L’account KRBTGT è l’entità per il KRBTGT security principal e viene creato automaticamente durante la creazione di un nuovo dominio Active Directory.

L’utente KRBTGT permette al KDC di far funzionare l’autenticazione in quanto quest’ultima avviene grazie ad uno speciale Kerberos ticket-granting ticket (TGT) crittografato con una chiave simmetrica rilasciato al client Kerberos dal KDC. Tale chiave simmetrica è derivata deriva dalla password del server o del servizio a cui è richiesto l’accesso. Per richiedere un ticket di sessione, il TGT deve essere presentato al KDC. La password TGT dell’account KRBTGT è nota solo al servizio Kerberos.

Come indicato in Active Directory Accounts
all’account KRBTGT e ai trust accounts viene assegnata automaticamente una password robusta, ma occorre pianificare la modifica schedulata di tali password. La password dell’account KDC viene utilizzata per derivare una chiave segreta per la crittografare e decrittografare le richieste di TGT. La password per un domain trust account è usata per derivare una inter-realm key per crittografare dei ticket.

La reimpostazione della password richiede di essere membro del gruppo Domain Admins o essere stati delegati con l’autorità appropriata, inoltre è necessario essere un membro del gruppo Administrators locale oppure o essere stati delegati con l’autorità appropriata. Dopo aver reimpostato la password dell’account KRBTGT verificare che l’evento con ID evento 9 con ‘origine eventi (Kerberos) Key-Distribution-Center venga registrato nel log eventi di sistema.

Nel caso si sia verificata la compromissione di controller di dominio è consigliabile reimpostare la password dell’account KRBTGT per garantire che un controller di dominio appena ripristinato non si replichi con un controller di dominio compromesso. In uno scenario del genere è importate tenere presente quanto riportato in Active Directory Accounts:

In this case, in a large forest recovery that is spread across multiple locations, you cannot guarantee that all domain controllers are shut down, and if they are shut down, they cannot be rebooted again before all of the appropriate recovery steps have been undertaken. After you reset the KRBTGT account, another domain controller cannot replicate this account password by using an old password.

Inoltre si tenga presente che nel caso in si sospetti la compromissione dell’account KRBTGT l’impatto per ripristinare la proprietà dell’account è a livello di dominio ed è un’attività ad elevato impatto come riportato in Active Directory Accounts:

An organization suspecting domain compromise of the KRBTGT account should consider the use of professional incident response services. The impact to restore the ownership of the account is domain-wide and labor intensive an should be undertaken as part of a larger recovery effort.

The KRBTGT password is the key from which all trust in Kerberos chains up to. Resetting the KRBTGT password is similar to renewing the root CA certificate with a new key and immediately not trusting the old key, resulting in almost all subsequent Kerberos operations will be affected.

For all account types (users, computers, and services)

• All the TGTs that are already issued and distributed will be invalid because the DCs will reject them. These tickets are encrypted with the KRBTGT so any DC can validate them. When the password changes, the tickets become invalid.
  
• All currently authenticated sessions that logged on users have established (based on their service tickets) to a resource (such as a file share, SharePoint site, or Exchange server) are good until the service ticket is required to re-authenticate.
  
• NTLM authenticated connections are not affected
  

Because it is impossible to predict the specific errors that will occur for any given user in a production operating environment, you must assume all computers and users will be affected.

In caso di problemi dopo il cambio della password dell’account KRBTGT provare a riavviare il sistema come indicato in Active Directory Accounts:

Rebooting a computer is the only reliable way to recover functionality as this will cause both the computer account and user accounts to log back in again. Logging in again will request new TGTs that are valid with the new KRBTGT, correcting any KRBTGT related operational issues on that computer.

Per avere informazioni sull’account KRBTGT come ad esempio la data di impostazione della password è possibile utilizzare il seguente comando PowerShell:

Get-AdUser krbtgt -property created, passwordlastset, enabled, sid, distinguishedname

La procedura di reset della password dell’account è illustrata nel seguente AD Forest Recovery – Resetting the krbtgt password:

Sempre in AD Forest Recovery – Resetting the krbtgt password viene riportato di eseguire la procedura due volte per svuotare la history delle password dell’account:

You should perform this operation twice. The password history of the krbtgt account is two, meaning it includes the two most recent passwords. By resetting the password twice you effectively clear any old passwords from the history, so there is no way another DC will replicate with this DC by using an old password.

Per il cambio della password JaredPoeppelman, un dipendente Microsoft, ha reso disponibile lo script New-KrbtgtKeys.ps1 che non è supportato in Windows 2000/2003, inoltre si vedano attentamente i KNOWN ISSUES/BUGS dello script prima di utilizzarlo.

Nel documento Mitigating Pass-the-Hash and Other Credential Theft, version 2 sono inoltre riportate ulteriori considerazioni inerenti alla sicurezza dell’account KRBTGT:

If a domain controller has been compromised, it is possible that the KRBTGT password hash has been stolen and is now being used by an attacker to obtain access. In this case, it may be required to plan and execute a reset of the key stored in the password hash for the KRBTGT account. This action requires planning because it can disrupt all authentication.

The KRBTGT account stores a secret that is used by the Kerberos service to issue and validate ticket granting tickets (TGTs) in a domain. In a compromised domain, an attacker may use publicly available tools to steal this secret stored in the KRBTGT account and generate arbitrary valid TGTs. This technique allows an attacker to obtain long-term access to the infrastructure as any user, including domain administrators, if organizations do not reset the KRBTGT account after compromise. Initiating a password reset for the KRBTGT account will instruct the system to generate a new random key for this value. This action will invalidate the currently issued Kerberos TGTs but can also cause authentication errors throughout the domain and forest, so a planned approach is advised.