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 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.
- 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.
Note:
- 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,
Zoheb
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:
Outlook Calendaring Team
by Contributed | May 26, 2021 | Technology
This article is contributed. See the original author and article here.
Hello everyone, here is part 6 of a series focusing on Endpoint Protection integration with Configuration Manager. This series is recorded by @Steve Rachui, a Microsoft principal premier field engineer.
This session focuses on how Configuration Manager integrates with Exploit Guard and can be used to deliver Exploit Guard settings. Steve also discusses what Exploit Guard is and why it is important.
Next in the series Steve focuses on how Configuration Manager integrates with Windows Defender Application Guard and how it can be used to enforce Windows Defender Application Guard settings.
Posts in the series
Go straight to the playlist
by Contributed | May 26, 2021 | Dynamics 365, Microsoft 365, Technology
This article is contributed. See the original author and article here.
Most companies use sales pipeline data to gauge a very generalized picture of future sales. But imagine if your company’s data was accurate enough to predict next month’s revenue within a few cents? If an organization can standardize on top-performing sales processes and establish an accurate, targeted picture of the customer, pipeline data becomes far more reliableand future sales become far more predictable.
Insurance brokerage and advisory company Willis Towers Watson (WTW) collected extensive sales data across systems within the organization, but they lacked a centralized system to view the collected data. The company adoptedMicrosoft Dynamics 365 Salesto capture data in a single system where they could extract insights to optimize sales practices and prioritize high-converting customers. By using insights to drive success into sales practices, WTW has increased the reliability of their sales pipeline, making future revenue far more predictable.
“In January, we ran our numbers based on prior performance and predicted almost to the penny what the number would be for new business going forward. Probably very few companies have been able to do something like that.”Luis Maurette, CRB Global Head of Sales and Client Management, WTW
Sales predictability can be increased when sales leaders have two key things:
- An accurate picture of high-conversion customers: Seller conversion rate will increase and sales cycles will close faster if you can provide your sellers a picture of your highest-converting customers. With the right tools, customer profiles can easily be developed from the characteristics of existing customerssales intelligence you already have. According to LinkedIn, 74 percent of sales intelligence users said the tools are extremely critical or critical in closing deals.
- Better, faster sales processes: According to McKinsey, sales performance management can drive up to a 10 to 20 percent increase in revenue per salesperson. That means if you leverage tools that help you identify sales best practices and standardize them across your company, your sales cadence becomes predictable.
Fast access to data, fewer systems to pull data from, and easy collaboration with teammates and stakeholders optimize processes, and in turn makes sales cycles faster.
Identify customers more accurately, win more customers
A better understanding of the customers leads to higher conversion rates. Marcelo Fama, Head of Latin America CRB Ops at WTW says that with the new capabilities offered by Dynamics 365 Sales and Microsoft Relationship Sales (which includes LinkedIn Sales Navigator), “We identify more opportunities sooner with the highly effective, automated triggers in the sales process that come with the platform.” At WTW, they are now able to target unique audiences because of data in Dynamics 365, and have accelerated the sales process because clients recognize right out of the gate that they understand their clients’ needs.
Increase speed and collaboration with Teams
When sellers can quickly access account managers and subject matter experts for quick information within the context of a deal, sales cycles close faster. WTW plans to leverage the integration of the One Microsoft platform to optimize their sales processes. With Microsoft Teams embedded in Dynamics 365 Sales, sellers can share and edit CRM records within the context of chats and channels, providing the seamless collaboration between segments and regions critical to closing deals. “We have aspirations to become even more connected as a company and to accelerate growth through standardized processes,” says Maurette.
Success depends on making it stick
Historically, the failure rate for large-scale change efforts like new customer relationship management (CRM) programs has been as high as 70 percent. WTW reversed this trend and within six months of rapid deployment, 90 percent of WTW sellers were up to speed and using the new tools to work faster and more efficiently.
“In my 18 years at WTW, I don’t think we ever expected staff to adopt anything at above 80 percent, let alone a sales platform. It’s just outstanding.”Jim Blaney, Head of Sales and Client Management, Corporate Risk and Broking, North America, WTW
By tapping into the true value of Dynamics 365 Sales, WTW makes more data-driven decisions with consistency across the company rather than decisions based on guesswork. And the company has a deeper understanding of its clients and can better create targeted campaigns and deliver relevant, personalized services.
Learn more about Dynamics 365 Sales
Want to learn more about Dynamics 365 Sales? Watch Dynamics 365 Sales demos or take the Activate Digital Selling guided tour to see how Dynamics 365 Sales can empower your sellers with actionable insights.
Read more about how Willis Towers Watson brought predictability to their pipeline.
We’re always looking for feedback and would like to hear from you. Please head to the Dynamics 365 Community to start a discussion, ask questions, and tell us what you think.
The post Bring predictability to your revenue pipeline with Dynamics 365 Sales appeared first on Microsoft Dynamics 365 Blog.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
by Contributed | May 26, 2021 | Technology
This article is contributed. See the original author and article here.
Howdy folks,
Today we are starting the Conditional Access authentication context public preview. Authentication context allows apps to trigger policy enforcement when a user accesses sensitive data or actions, keeping users more productive and your sensitive resources secure.
We have added this capability for more granular policy targeting because of your feedback – let us know what you think!
Caleb Baker, from our PM team, will walk you through the details below.
Thanks,
Alex Simons
————————————————————————
Getting started with Conditional Access authentication context
Hey there, I am Caleb from the Azure AD team.
We’ve heard from many of you that you want to trigger a Conditional Access policy when sensitive content in your apps is accessed. This includes requiring multi-factor authentication, a compliant device or even GPS-based location. Existing app-level Conditional Access policies don’t support this level of resource granularity, so we’ve added support for authentication contexts.
Now that Conditional Access authentication context is in public preview it’s great to be able to go deeper into some of the details. I can’t wait to see how people use it and integrate authentication context into their own apps.
You can modify your line of business apps, or, thanks to integration with Microsoft Cloud App Security (MCAS), Microsoft Information Protection (MIP), and SharePoint Online, use it with all kinds of cloud apps right away!
Let’s get started!
When you use authentication context, first you will create a custom authentication context value. This is how apps will trigger Conditional Access policies when sensitive data or actions are accessed.
You can do this from the new Conditional Access authentication context tab, and clicking New authentication context.

You’ll then provide a display name and description for the new authentication context. We recommend using a name that captures the authentication requirements. For example, Controls trusted devices or Contoso strong auth.

After creating a new authentication context, you then attach it to Conditional Access policies. These are the policies that will be enforced when an application triggers the authentication context. You author these policies in the Conditional Access policy admin UX, the same as any other Conditional Access policy. The only difference is that instead of assigning policy to a cloud app you’ll assign it to an authentication context.
Now that you’ve created an authentication context apps can make use of it. I’ll show an example with MCAS session policy, this will enforce policy when a user downloads a file from an app. MIP label management in the Office Security and Compliance Center has a similar experience for applying authentication context values.

Now when a user attempts to download a sensitive file from an app that is configured to use the MCAS session policy, they will need to satisfy the attached Conditional Access policy.
Here are some of the ways customers have been using authentication context with MCAS and SharePoint.
- Requiring users to authenticate with multi-factor authentication (MFA) when they download sensitive files from any SaaS app on the web, like Office 365, Salesforce, Workday, and more.
- Require terms of use for SharePoint site collections that have been classified as confidential. For several customers this allows them to move sensitive documents to secured sites in SharePoint online, and complete their migration from on-premises.
These documents will help you to learn more about configuring these policies.
Adding authentication context into your apps
Any app using OpenID Connect/OAuth 2.0 for authentication can also use authentication context values, including apps developed by your organization. This allows your apps to better protect sensitive resources, like high-value transactions or viewing employee personal data.
We’ve built this support on a standards-based pattern, commonly used by apps prompting for multi-factor authentication, to help simplify app integration. Of course, you can also use the Microsoft Authentication Library (MSAL) to further simplify app development.
Apps can trigger a specific authentication context value by using an OpenID Connect claim challenge, to request a specific authentication context claim value.

Once the user has been challenged and satisfied policy, they will be issued a new sign-in token containing the required authentication context claim. The app can then use the presence of the claim to grant access.
Here are some additional resources to help with app development, using authentication context.
Next, we’ll be working toward GA and adding support for even more integrations, like Privileged Identity Management role activation!
As always, we’d love to hear from you. Please let us know what you think in the comments below or on the Azure AD feedback forum.
Thanks,
Caleb Baker
Learn more about Microsoft identity:
Recent Comments