Reset krbtgt Password

Question

Hi,

I have found few article about this, but i'm still wondering few thing about the process. I'm really appreciate if someone can help.

1. I have test the script provided by Microsoft and successfully reset the password for first time. Then after 30 minute later, i continue for second time reset. But i have noticed some error:

Article: https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51

Second Reset

Checking if all tickets based on the previous (N-1) krbtgt key have expired...failed

May i know what of this error? Is it safe enough to proceed for second reset if this error appear? Based on my test environment, im just proceed it and dont see any issue. But unsure whether it safe or not for production. From the script i also found another info:

Kerberos maximum lifetime for user ticket (TGT lifetime): 10 hours.

Is it mean we need to wait after 10 hour before proceed the second reset? I'm a bit confuse about this because most article mention, we just need to ensure replication completed to all DC (for first Reset) then proceed second reset.

2.For another method, can i do first reset example by today, and second reset on next day to ensure first reset successfully replicated to all DC? Any issue on that approach? I have plan to do manual reset (without using script) and make it on different day for first and second reset.

3.What actually will happen to end user if this process went wrong? Example if i reset second password without waiting first password being complete replicate to all DC. Is it user unable to authenticate to DC? Or it just impact for DC replication? How to fix this, those problematic DC require to demote and promote?

Thanks

Answer 1

Hi,

Before going further, i would like to explain why we need to reset the password 2 times :
The Kerberos TGT is encrypted and signed by the KRBTGT account. This means that anyone can create a valid Kerberos TGT if they have the KRBTGT password hash. Furthermore, despite the Active Directory domain policy for Kerberos ticket lifetime, the KDC trusts the TGT, so the custom ticket can include a custom ticket lifetime.
If the krbtgt account is compromised, attackers can create valid Kerberos Ticket Granting Tickets (TGT).It attempts to decrypt with the current password and if that fails, it attempts again with the previous one (assuming it has it).So the password must be changed twice to effectively remove the password history. Changing once, waiting for replication to complete and changing again reduces the risk of issues. Changing twice in rapid succession forces clients to re-authenticate (including application services) but is desired if a compromise is suspected.

For your questions:
1,There is no need to wait 10 hours, only need to wait for the replication.There are Two Change Scenarios as following for different situations (both you mentioned):

If there are any chance that the KRBTGT account is compromised.
Breach Recovery: Changing the KRBTGT account password twice in rapid succession (before AD replication completes) will invalidate all existing TGTs forcing clients to re-authenticate since the KDC service will be unable to decrypt the existing TGTs. Choosing this path will likely require rebooting application servers (or at least re-starting application services to get them talking Kerberos correctly again).

Maintenance: Changing the KRBTGT account password once, waiting for replication to complete (and the forest converge), and then changing the password a second time, provides a solid process for ensuring the KRBTGT account is protected and reduces risk (Kerberos and application issues).

2, For your second question:From my personal understanding, if it is a regular maintenance it is totally ok to reset the password at the nest day to wait for the replication if you have multi-sites.

3, As mentioned above,changing the KRBTGT account password twice in rapid succession (before AD replication completes) will invalidate all existing TGTs forcing clients to re-authenticate since the KDC service will be unable to decrypt the existing TGTs.
Choosing this path will likely require rebooting application servers (or at least re-starting application services to get them talking Kerberos correctly again).

So before changing the password, i would recommend you to check the replication status before perform this task, to be sure that the new passwords will be replicated on all domain controllers.Following command :
Repadmin /showrepl >C:\repl.txt
Repadmin /showreps * 
Repadmin /syncall /APeD

For more information about the KRBTGT account, you can refer to the following link:
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn745899(v=ws.11)?redirectedfrom=MSDN#Anchor_5

Best Regards,

Answer 2

Hi FanFan,

Thanks, im really impress by your answer. So i can conclude:

1. We can proceed with second reset without waiting for 10 hour as long as replication completed.
2. Yes, this is just regular maintenance, not the emergency case. So since you mention no issue with this approach, we will proceed with this method. Divide first and second reset by day. The reason why because we have multiple site across the country. So we more comfortable to wait for one day gap before proceed for second time reset.
3. Ok meaning the impact only for client and application site, is it? I thought it will impact domain controller replication. i remember read one article that mention replication could be broken and Domain Controller need to demote and re-promote in order to fix it. So i can conclude the real impact is only about authentication request by user/client.

Thanks

Answer 3

Hi FanFan,

Sure, normally we have run AD Health Check script (provide by Microsoft) on daily basis. So we will know if got any issue on AD site. Anyway, for sure we will run those command provided by u before changing the krbtgt password.

So we will do manual reset instead of using script, from ADUC search krbtgt, right click and reset the password. Should be no issue with this approach rite?

Thanks