However, keytab usage is rare in the Windows AD world because people don't seem to comprehend what a keytab is and does, and why it is far better than using passwords for services.
There's also the knock-on effect of Kerberos being mostly hidden in Active Directory and creating keytabs requiring CLI tooling -- from way back when AD was a GUI only (mostly) affair for AD admins.
No 3rd party AD-integrated software, of which there were plenty of non-MSFT stuff, did I ever have to create a keytab for when playing Domain Admin at work.
The mitigations are there but it takes time for Microsoft's Customers to move to the new versions. I don't think that's Microsoft's problem. That's just their market. I don't think Prof. Green has an understanding of that side of it.
I guess one could argue that Microsoft should backport the new code to older products and give it to Customers who aren't actively paying for maintenance or subscription licensing. They made the business decision not to.
But I don't really accept this explanation. I always understand that there are legacy deployments and Microsoft needs to support them, but Kerberos-misconfiguration issues are extremely subtle in their implications, and MS should understand that one blog post (or some knowledge base articles) isn't going to get the message across to the hundreds/thousands of AD admins whose networks are currently at risk.
What I think recent versions of the MS software could do: (1) automatically scan configurations for accounts set up this way, (2) be incredibly annoying about changing the configuration (there are a handful of ways to do this that should be workable for many legacy configurations). If admins want to override the annoying and explicit warnings, that would be on them and not MS. As far as I can tell, Microsoft isn't doing this. But if I'm wrong, please let me know.
The financial incentives drive Microsoft to support every possible (mis)configuration, forever. It's the tireless work of a few folk at Microsoft like Ned Pyle, Steve Syfus, and Mark Morowczynski that have landed the changes so far.
There could absolutely be a "security check" tool deployed by default with Server 2025 or similar that looks for Kerberoastable user accounts (any account with a ServicePrincipalName is technically Kerberoastable, like computer accounts), AS-REP roastable accounts, weak encryption types, etc. That would probably get more traction than changing defaults out of the box for everyone, as that's another way to phrase "breaking customer environments when they upgrade".
Are they doing the same for AD? From the article it sounds like it falls back to RC4 automatically out of the box. That is something they should have started migrating away from at least a decade ago - gradually, with options for backwards compatibility to support their customers - but the fact that it is enabled by default in 2025 seems insane.
Is this really a useful mitigation here? If someone has suitable presence to make requests to the TGS, then the time window for cracking and exploiting those tickets (if they are exploitable) is surely always going to be small compared to the rotation window. Hackers don't typically have the patience to sit running hashcat on an old GPU for weeks, they just find some way to get ephemeral access to a bunch of faster GPUs.