Hello Everyone, my name is Zoheb Shaikh and I’m a Solution Engineer working with Microsoft Mission Critical team (SfMC). Today I’ll share with you some FAQs on KRBTGT reset.
Recently I had couple of customers asking many questions on KRBTGT account password reset and Microsoft’s recommendations for this, in this article I will list these questions and provide my responses which will address many queries you may have.
Before we deep dive into details let’s have a brief on what’s KRBTGT and its use briefly.
KRBTGT: KRB stands for Kerberos and TGT is Ticket Granting Ticket. In simple words during Kerberos Authentication process TGTs are issued to users, services or accounts requesting access to resources, these TGT’s are encrypted by cryptographic key which is derived from the password of the Key Distribution Center’s (KDC) account (KRBTGT), this key is known only by the Kerberos service. Since this is the account which encrypts TGTs it becomes extremely important to secure and monitor (More details on How Kerberos works are here).
The KRBTGT account is a domain default account that acts as a service account for the Key Distribution Center (KDC) service. This account cannot be deleted, account name cannot be changed, and it cannot be enabled in Active Directory.
For information about name forms and addressing conventions, see RFC 4120 .
Coming back to customer queries, our customer wanted to know what Microsoft’s recommendation on resetting KRBTGT is regularly and had various queries on whether this can create an impact.
Why do organizations reset KRBTGT password?
Typically, KRBTGT resets might be performed during compromise recovery scenarios of Active Directory on recommendations from Microsoft DART team/Microsoft Compromise Recovery Team, following a set procedure after ensuring all back doors are closed.
Some organizations might reset KRBTGT password based on recommendations from 3rd party Auditors also.
It is important to remember that resetting the KRBTGT is only one part of a recovery strategy and alone will likely not prevent a previously successful attacker from obtaining unauthorized access to a compromised environment in the future. We strongly advise that customers create a comprehensive recovery plan using guidance found in the white paper of Mitigating Pass the Hash Attacks and Other Credential Theft.
What are Microsoft Recommendations on KRBTGT Reset?
There is no specific recommendation regarding password reset for the KRBTGT account.
Although you can reset it periodically even without any indicators of compromise, you should plan the interval of resets for your organization taking into considerations your backup schedules, operational procedures, security requirements, etc.
However, that is a separate discussion to have, and we are more over going to discuss what exactly happens during a KRBTGT reset and few other queries which came up when discussed this with one of our Mission Critical customers.
FAQs on KRBTGT Reset
Note: Terms KRB1, KRB2 and KRBOLD used below is only for explanation purposes.
- Why does KRBTGT need to be reset twice?
KRBTGT keeps a password history of 2, hence we reset it twice to invalidate all tickets issued from old KRBTGT password.
- What happens when you reset KRBTGT account password once?
- After 1st reset the new KRBTGT password replicates to all the DC’s in the Domain.
- All new Tickets will use the new password (KRB1).
- Old tickets issued by old KRBTGT password (KRBOLD) should continue to work as password history is 2.
- Post old tickets expiry they should renew tickets with new KRBTGT password (KRB1).
- Present KRBTGT passwords will be KRB1 & KRBOLD.
- What happens when you reset KRBTGT account password twice?
- After second reset new KRBTGT password replicates to all the DCs in domain.
- All new tickets will use the new password (KRB2).
- Old tickets issued by old KRBTGT password (KRB1) should continue to work as password history is 2.
- Present KRBTGT passwords will be KRB1 & KRB2.
- Post old tickets expiry they should renew tickets with new KRBTGT password (KRB2).
- Old KRBTGT password (KTB Old) not valid any more as password history is of 2.
- What could be potential impact based on our experiences?
- All AD dependent applications tickets will get invalidated.
- This will make all applications reach out to DCs for re authentication.
- This may spike LSASS as all machines will reach DCs at once.
- Historically we have observed some non-Windows clients are unable to request new tickets till the expiry of the existing tickets.
- Recovery of a single DC: Will not work anymore because the KRBTGT password is different, and replication will not work (Workaround just promote a new DC).
- Any DC which was not replicating while reset is performed may experience Trust issues.
- Post second Reset which are older than the time 1st reset was performed will get invalidated.
- All AD dependent applications tickets will get invalidated.
- Is there a security benefit of doing KRBTGT resets regularly?
This is a Million$ question and unfortunately there is no clear answer to this but hopefully the below pointers might help.
- Resetting the KRBTGT is only one part of a recovery strategy and alone will likely not prevent a previously successful attacker from obtaining unauthorized access to a compromised environment in the future.
- If you are suspecting an attack on the environment, please open a support ticket with Microsoft’s Incident Response team.
- If an attacker managed to reach the DCs and successfully hold a Golden Ticket (KRBTGT Account Hash) then it’s a game over where the periodic reset only will not mitigate that as attacker can have already built different ways from controlling DCs and reach to golden ticket again easily so best practice to detect malicious behaviors, close the back doors and ensure AD Security (details in FAQ #7): How Microsoft Advanced Threat Analytics detects golden ticket attacks – Microsoft Tech Community.
- Can Microsoft Defender for Identity help detect KRBTGT compromise.
- Indeed, Microsoft Defender for Identity should be able to help detect attacks on Golden Ticket.
- There are various scenarios in this, please see the article to see more details Microsoft Defender for Identity domain dominance security alerts.
- What should I do to protect my DC’s against an attack?
This is a very broad question without having knowledge of the infrastructure but maybe a way to start this project is by doing an AD Security Assessment from Microsoft which can help find Risk and help improve AD Security. Below are some of the areas where AD Security Assessment may help.
- Review of operational processes.
- Review of the privileged accounts/groups membership as well as regular account hygiene.
- Review of the forest and domain trusts.
- Review operating system configuration, security patch, and update levels.
- Review of domain and domain controller configuration compared to Microsoft recommended guidance.
- Review of key Active Directory object permission delegation.
- Review Tier Model is in place or not.
- Recommendations on using PAW etc.
- Is there a way to reset KRBTGT account safely without having any impact on the environment?
If you maintain a gap of 10 hours or more between KRBTGT account password resets, this may minimize the impact significantly and makes the auditors happy. However this may not add any benefit from a Security prespective.
- The recommendations and impacts are based on experience/ how it should ideally work. Different environments may observe different issues.
- The responses were based on specific scenarios and queries, it might be different based on scenarios.
Special thanks to my SfMC colleague Ahmed Badr and others at CIS Tech Community for proof reading and suggestions.
Hope this helps,