locked
Impact of resetting the password of the krbtgt account? RRS feed

  • Question

  • Hi,

    Currently a lot of effort and interest goes into the golden ticket scenario that mimikatz and metasploit are able to do using the krbtgt account.

    I know you would have to own a DC or get a NDTS dump to get the hash of the krbtgt account, but for the sake of this question let's assume we want to change the krbtgt password because a domain admin left the company, and could potentially have taken the DB with him.

    In a number of scenarios, part of the restore procedure or resolution to an issue is to reset the password of the krbtgt account (for example: http://technet.microsoft.com/en-us/library/cc733991(WS.10).aspx)

    As part of a forest recovery procedure you have to change the password of the krbtgt account twice to make sure replication no longer occurs. Wouldn't this mean that existing replication breaks as well when you change the password, as the steer is in a lot of blogs, recommendations or technet articles?

    In short, I'm wondering what would break when you change the password of the krbtgt account, and if anything does, for how long and will it automatically repair? It wouldn't be nice to have to tell a customer to do a forest recovery because they followed steer from security companies telling them to change their krbtgt password.

    Thanks in advance for your responses!

    Friday, August 8, 2014 10:26 PM

Answers

    1. Yes you have to technically reset it twice to protect the domain if someone steals the hash for krbtgt account, but you have to do it in steps and make sure that all writable domain controllers in that domain get the first reset before you do the 2:nd reset - otherwise the replication will break. Best way to do this is to watch metadata for the krbtgt account and monitor the version for unicodePwd. It will look something like this:

    repadmin /showobjmeta eur-fle-dc02 "CN=krbtgt,CN=users,DC=e
    r,DC=corp,DC=chrisse,DC=com"
    
    35 entries.
    Loc.USN                           Originating DSA  Org.USN  Org.Time/Date
     Ver Attribute
    =======                           =============== ========= =============
     === =========
       7202      dc95de70-859e-4f39-a489-73380dd1896f     12299 2005-03-19 16:40:16
       2 unicodePwd

    1. You don't need to restart servers, clients or do anything about service accounts, what I would recommend doing to restart the KDC service on all DCs. Actually what you might not know is that the krbtgt account always have it's password reset while a domain has it's functional level raised to Windows Server 2008 or later to support Kerberos AES256 keys, you can read about the impact of that here: http://visualplanet.org/blog/?p=20 and here http://imav8n.wordpress.com/2007/12/19/replication-version-number-for-your-krbtgt-account-password/ - the solution is as stated to restart the KDC service to get raid of a cache.

    Enfo Zipper
    Christoffer Andersson – Principal Advisor
    http://blogs.chrisse.se - Directory Services Blog

    • Marked as answer by Vivian_Wang Thursday, August 14, 2014 6:36 AM
    Saturday, August 9, 2014 12:10 PM

All replies

    1. if someone has taken the DB with them, they do also have access to all previously used password hashes as far as your password history goes.
    2. Why would one relay on issuing a domain/forest password reset if 1. has happened, once you finally have resetting all passwords - How do you know one has been used to implement a backdoor to one of the DCs? I would have inited a forest/domain wide recovery in a such case.

    3. Replication would not break, because the krbtgt account has a hardcoded password history of "2" regardless of the domain password policy. That's why you have to reset it twice in a forest recovery (then replication will break)

    4. In unsecure locations where you have untrusted administrators, don't let them be DA/EAs and use RODCs, RODCs have separate krbtgt accounts and never store the hashes for the domain wide krbtgt account.

    Enfo Zipper
    Christoffer Andersson – Principal Advisor
    http://blogs.chrisse.se - Directory Services Blog

    Saturday, August 9, 2014 3:14 AM
  • Hi Christoffer,

    Thanks for your response.

    I understand the impact, and I understand the need for a forest recovery. I think I misphrased the question.

    What I'm trying to do is grasp the impact of resetting the krbtgt password.

    What will happen when you reset it once, will all existing Kerberos tickets be invalidated (because it can no longer decrypt them)? If so, would the remediation for this be to reboot the machine, so it can request a new ticket?

    CERT of Europe for example states on http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_07_PassTheGolden_Ticket_v1_1.pdf that you need to reset the krbtgt account password twice to mitigate a golden ticket issue. I understand why this needs to be done, but I'm looking for the exact impact. As it states there, end-users will automatically request a new ticket. But how about computer accounts? Do they need to be restarted before they have a SCHANNEL again? Service accounts?

    Saturday, August 9, 2014 8:12 AM
    1. Yes you have to technically reset it twice to protect the domain if someone steals the hash for krbtgt account, but you have to do it in steps and make sure that all writable domain controllers in that domain get the first reset before you do the 2:nd reset - otherwise the replication will break. Best way to do this is to watch metadata for the krbtgt account and monitor the version for unicodePwd. It will look something like this:

    repadmin /showobjmeta eur-fle-dc02 "CN=krbtgt,CN=users,DC=e
    r,DC=corp,DC=chrisse,DC=com"
    
    35 entries.
    Loc.USN                           Originating DSA  Org.USN  Org.Time/Date
     Ver Attribute
    =======                           =============== ========= =============
     === =========
       7202      dc95de70-859e-4f39-a489-73380dd1896f     12299 2005-03-19 16:40:16
       2 unicodePwd

    1. You don't need to restart servers, clients or do anything about service accounts, what I would recommend doing to restart the KDC service on all DCs. Actually what you might not know is that the krbtgt account always have it's password reset while a domain has it's functional level raised to Windows Server 2008 or later to support Kerberos AES256 keys, you can read about the impact of that here: http://visualplanet.org/blog/?p=20 and here http://imav8n.wordpress.com/2007/12/19/replication-version-number-for-your-krbtgt-account-password/ - the solution is as stated to restart the KDC service to get raid of a cache.

    Enfo Zipper
    Christoffer Andersson – Principal Advisor
    http://blogs.chrisse.se - Directory Services Blog

    • Marked as answer by Vivian_Wang Thursday, August 14, 2014 6:36 AM
    Saturday, August 9, 2014 12:10 PM
  • Hi,

    I just want to confirm the current situation.

    Did you read this article?

    A Heraclean Task? Active Directory, Kerberos and the krbtgt account.

    http://multiplechoicesystemengineer.wordpress.com/2011/11/11/a-hercaclean-task-active-directory-kerberos-and-the-krbtgt-account/

    Please feel free to let us know if you need further assistance.

    Regards.

    If you have any feedback on our support, please click here


    Vivian Wang

    • Marked as answer by Vivian_Wang Thursday, August 14, 2014 6:36 AM
    • Unmarked as answer by Mahdi Tehrani Saturday, August 12, 2017 3:41 AM
    Wednesday, August 13, 2014 7:17 AM
  • Hi Vivian,

    Yes, I did. Christoffer's comments were most helpful to assess the situation. Thanks for your help.

    Regards,

    Stefan Hazenbroek

    Thursday, August 14, 2014 6:39 AM