FAQs from the field on KRBTGT reset

by Contributed | May 26, 2021 | Technology

This article is contributed. See the original author and article here.

FAQs from the field on KRBTGT reset

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. 

Introduction:

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 3^rd 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.

1. 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.

2. What happens when you reset KRBTGT account password once?
   
   
   
   1. After 1st reset the new KRBTGT password replicates to all the DC’s in the Domain.
   
   
   2. All new Tickets will use the new password (KRB1).
   
   
   3. Old tickets issued by old KRBTGT password (KRBOLD) should continue to work as password history is 2.
   
   
   4. Post old tickets expiry they should renew tickets with new KRBTGT password (KRB1).
   
   
   5. Present KRBTGT passwords will be KRB1 & KRBOLD.
   
   
   
   

3. What happens when you reset KRBTGT account password twice?
   
   
   
   1. After second reset new KRBTGT password replicates to all the DCs in domain.
   
   
   2. All new tickets will use the new password (KRB2).
   
   
   3. Old tickets issued by old KRBTGT password (KRB1) should continue to work as password history is 2.
   
   
   4. Present KRBTGT passwords will be KRB1 & KRB2.
   
   
   5. Post old tickets expiry they should renew tickets with new KRBTGT password (KRB2).
   
   
   6. Old KRBTGT password (KTB Old) not valid any more as password history is of 2.
      
      
   
   
   
   


4. What could be potential impact based on our experiences?
   
   
   
   1. All AD dependent applications tickets will get invalidated.
      
      
      
      1. This will make all applications reach out to DCs for re authentication.
      
      
      2. This may spike LSASS as all machines will reach DCs at once.
      
      
      3. Historically we have observed some non-Windows clients are unable to request new tickets till the expiry of the existing tickets.
      
      
      
      
   
   
   2. 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).
   
   
   3. Any DC which was not replicating while reset is performed may experience Trust issues.
   
   
   4. Post second Reset which are older than the time 1^st reset was performed will get invalidated.
   
   
   
   

5. 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.
   
   
   
   1. 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.
   
   
   2. If you are suspecting an attack on the environment, please open a support ticket with Microsoft’s Incident Response team.
   
   
   3. 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.
   
   
   
   

6. Can Microsoft Defender for Identity help detect KRBTGT compromise.
   
   
   
   1. Indeed, Microsoft Defender for Identity should be able to help detect attacks on Golden Ticket.
   
   
   2. There are various scenarios in this, please see the article to see more details Microsoft Defender for Identity domain dominance security alerts.
   
   
   
   

7. 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.

1. Review of operational processes.


2. Review of the privileged accounts/groups membership as well as regular account hygiene.


3. Review of the forest and domain trusts.


4. Review operating system configuration, security patch, and update levels.


5. Review of domain and domain controller configuration compared to Microsoft recommended guidance.


6. Review of key Active Directory object permission delegation.


7. Review Tier Model is in place or not.


8. Recommendations on using PAW etc.

8. 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.

Note:

1. The recommendations and impacts are based on experience/ how it should ideally work. Different environments may observe different issues.


2. 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,

Zoheb

Outlook for Windows Shared Calendar Public Notifications

by Contributed | May 26, 2021 | Technology

This article is contributed. See the original author and article here.

Hi there, Calendar Community!

It is with great excitement that we are announcing that we have graduated the shared calendar improvements in Outlook for Windows out of preview! This new shared calendar experience dramatically improves the reliability and sync latency for shared calendars & delegated calendars in all Outlook clients. The improvements have been released in Outlook on the web, the new Outlook for Mac, and mobile for a while now, and we’re excited that Outlook for Windows is now enabled as well.

Right now, about 10% of Outlook for Windows users in Current Channel with version 2103 have been enabled for those improvements, and we’ll keep expanding gradually throughout the spring and summer.

What exactly is changing?

In July 2019, we announced the preview in Outlook for Windows which has remained opt-in until now, as we turn this on in production. Eventually, it will be just “on”, but this is a journey and arguably the biggest change to Outlook for Windows since its initial release in 1997, so we want our every step to be cautious. With Version 2103 (March 2021 update), the new experience reached feature parity with the classic experience, so we have removed the preview label that was previously shown next to shared calendars that were enabled for the new experience. Since summer 2019, we polished the experience and fixed bugs, thanks to many customer reports. With tens of thousands of daily users on the preview, we feel confident now that the experience is going to delight calendar delegates.

What will your delegates notice?

Despite all the exciting statements above, our hope is that they don’t even notice anything changed. Why would we say that? This is one of those improvements that should be invisible because it eliminates issues but doesn’t change the core product functionality. Calendars will sync faster, and we have eliminated any reliability issues when managing a calendar. Delegates might only notice that things are smoother but no specific, obvious changes.

Please let us know if you have any suggestions or feedback on these improvements by emailing us at olk-calendar-preview[AT]microsoft.com! We cannot guarantee a response to every email, but we promise to read them all and do our very best to respond.

For more details, here are a few more articles for reference:

• Detailed overview of the new sharing platform


• How to manually opt-in to the improvements


• What to expect with these improvements

Outlook Calendaring Team