Most large enterprises regularly change their Kerberos passwords. Small- to medium-sized businesses, however, might not have changed them since implementing their domain infrastructure. When an attacker wiggles into a network, they can use the golden ticket attack sequence. Active Directory (AD) uses the KRBTGT in the AD domain for Kerberos tickets. If the KRBTGT account password hash is stolen or broken with an attack, the attackers can then grant themselves full access to your network with the necessary authentication.Changing the Kerberos password is a must-do task if you monitor and maintain an AD infrastructure. If you have had or suspect an intrusion, change that password immediately after the network has been stabilized. Plan on changing it at least twice a year. Performing this action on a regular basis will stop golden ticket attacks. You\u2019ll also want to implement an auditing tool that can detect golden ticket attacks in your environment.KRBTGT authentication sequence in Active DirectoryThe KRBTGT account is used in AD in the following sequence:A user logs on with AD username and password to a domain-joined computer (usually a workstation).The user then requests authentication by sending a timestamp encrypted with the user\u2019s password-based encryption key in the form of a password hash.The user account then requests a Kerberos service ticket with Kerberos AS-REQ.The Kerberos server (KDC) receives the authentication request, validates the data, and replies with a TGT (Kerberos AS-REP). Resetting the Kerberos password with ADUCThere are several ways to reset the password. If you prefer using Active Directory Users and Computers (ADUC):Click on \u201cStart\u201d.In the search box enter \u201cADUC\u201d.Click on \u201cView\u201d and then click on \u201cAdvanced features\u201d.In the console tree, double-click the domain container, and then select \u201cUsers\u201d.In the Details pane, right-click the KRBTGT user account and then select \u201cReset Password\u201d.Enter the new password in \u201cNew password\u201d and retype the password in \u201cConfirm password\u201d and select \u201cOK\u201d.Which password you specify is not significant because the system will generate a strong password automatically independent of the password that you specify. Microsoft recommends resetting the Key Distribution Center Service Account password twice. A ten-hour waiting period is required between resets because that\u2019s the default maximum lifetime for user ticket and maximum lifetime for service ticket policy settings. If you alter the maximum lifetime period, the minimum waiting period between resets should be greater than the configured value. The password history value for the KRBTGT account is \u201c2\u201d, meaning it includes the two most recent passwords. Resetting the password twice clears old passwords from the history, so no other domain controller can replicate with this domain controller by using an old password. Follow this process for regular maintenance.In a breach situation, change the password twice quickly to break AD replication forcing clients to reauthenticate. You\u2019ll need to reboot domain controllers and application servers for Kerberos to properly connect again.Resetting Kerberos password with scriptsIf you prefer to use PowerShell, several scripts ensure that these passwords are changed. GitHub has several scripts to reset the KRBTGT password on read-writable and read-only domain controllers (RWDCs and RODCs) in a controlled manner.One script, by Jorge de Almeida Pinto, provides a single password reset for the KRBTGT account in use by RWDCs in a specific AD domain using either TEST or PROD KRBTGT accounts. It also provides a single password reset for the KRBTGT account in use by an individual RODC in a specific AD domain, using either TEST or PROD KRBTGT accounts. Finally, it resets the password\/keys of the KRBTGT account, which can be done for multiple reasons such as from a security perspective as mentioned in a 2015 blog post, or from an AD recovery perspective as mentioned in this AD Forest Recovery blog post.Microsoft has provided guidance in the form of this PowerShell script that resets the passwords. Before performing these scripts, check what domain functional level you are on. You need to be on a Server 2008 domain or higher to run these scripts. To determine this, from an elevated PowerShell command prompt enter Get-ADDomain | fl Name,DomainMode. If you are still on an older level, it would be wise to investigate why you can\u2019t be on at least a Sever 2008 level.Next, make sure you have domain admin rights and are in the domain where you want to run this script. You cannot be remote to the domain; you can\u2019t target the script to run in a specific domain. Like most PowerShell scripts, you need to change the execution mode to run it. From an elevated PowerShell prompt, enter Set-ExecutionPolicy RemoteSigned.Finally download or copy and paste the PowerShell to the server and run the command to call the script. The script has three modes:This is informational only. It validates that you can run the script in your domain, that the ActiveDirectory PowerShell module is installed, RPCping is present, and repadmin.exe is available. It reports on various name and functions of the domain and on various settings of the KRBTGT account. It checks when the KRBTGT password was last set. Finally, the script checks for RPC connectivity to each writable domain controller. Review for any failures in this mode before going to step 2.The script estimates how long step 3 (resetting the KRBTGT password) will take in your domain without actually resetting the key. It lets you know if you are ready to proceed to step 3.The script performs the actual resetting of the KRBTGT account password and related keys while minimizing the likelihood of Kerberos authentication issues being caused by the operation.If you have never performed this task, now is the time to put it on your must-do list for the health and safety for your network.