The Incident That Shouldn't Have Happened
Yes, Citrix — I’m looking at you. Or rather, I’m looking at the way the Citrix environment has been configured and managed with a fundamental misunderstanding of authentication. NTLM is still being relied upon in places where it has no business existing in 2025, purely because the environment has never been transitioned to proper Kerberos-based authentication.
This isn’t a Citrix problem. It’s a configuration problem. And when you balance a modern environment on outdated, insecure authentication protocols, you effectively build the entire platform on thin ice. It only takes the slightest amount of pressure — like applying a perfectly normal CIS Level 1 hardening policy — for that ice to crack and for everything to plunge straight into the cold, dark water beneath.
This pressure as a "CIS Level 1 security baseline" Within hours, their entire Citrix FAS infrastructure collapsed. Users couldn't authenticate, sessions wouldn't launch, and the help desk was overwhelmed.
The root cause? A single Group Policy setting that refused legacy NTLM authentication.
The real problem? This should never have happened in a properly configured environment.
The Technical Breakdown: Why FAS Failed
The critical policy setting:
Network security: LAN Manager authentication level =
Send NTLMv2 response only. Refuse LM & NTLM
This setting makes domain controllers refuse ALL NTLM version 1 authentication attempts. Here's the key:
The policy was applied to the FAS servers and VDAs, NOT the domain controllers. The DCs still accepted all NTLM versions.
What this revealed: Citrix FAS, despite being a modern certificate-based authentication system, was randomly using either NTLMv1 or NTLMv2 - because Kerberos was never properly configured.
Understanding NTLM Version Fallback
"NTLM authentication version is not negotiated by the protocol. It has to be configured on both the client and the server prior to authentication". "In Windows-land NTLM and Kerberos are mostly interchangeable because they're wrapped in SPNEGO" which "tries Kerberos first, and falls back to NTLM if Kerberos fails".
Why does Windows sometimes use NTLMv1 instead of NTLMv2? Several factors:
- Default Behavior: Many Windows services "will use NTLMv1 by default" unless explicitly configured for NTLMv2
- Registry Configuration: The LmCompatibilityLevel registry setting must be explicitly set
- Service-Specific Defaults: Different Windows services have different default behaviors
- No Negotiation: Unlike choosing between Kerberos and NTLM, there's no negotiation between NTLM versions
Step-by-Step: What Actually Happened
Step 1-3: Certificate Generation
- User authenticated to StoreFront
- StoreFront requested certificate from FAS
- FAS successfully generated certificates from CA
- Certificates were being issued correctly
Step 2: The Authentication Lottery
- VDA received the valid certificate
- VDA attempted Windows authentication with the certificate
- Critical Point: Because Kerberos wasn't configured, authentication fell back to NTLM
- FAS randomly used either:
- NTLMv2: Authentication succeeded ✓
- NTLMv1: Policy blocked it → Manual login prompt → "BEAR\username"
- Password entry always failed (FAS doesn't have actual passwords)
Why This Reveals Profound Technical Incompetence
This wasn't a case of "everything broke." It was worse - an inconsistent, unpredictable failure pattern that exposed:
- No Kerberos Configuration: Despite FAS being designed for Kerberos, it was left to use NTLM
- No NTLM Version Control: FAS was randomly choosing between NTLMv1 and NTLMv2
- Authentication by Accident: Some users worked purely by chance - when FAS happened to use NTLMv2
- Zero Understanding: The team didn't even know their authentication was a lottery
"Anything less than level 3 means NTLMv1 will be requested by the client". Without explicit configuration, Windows services default to the lowest common denominator.
The Uncomfortable Truth
This organization had:
- A working PKI infrastructure (the hard part)
- Valid certificates being issued
- Modern FAS servers deployed
- But authentication running on 1990s protocols by default
They were one security policy away from complete failure because they never:
- Configured Kerberos delegation
- Set explicit NTLM version requirements
- Tested with security baselines
- Understood what they had deployed
Why CIS L1 was the "ice breaker"
CIS Level 1 baseline is not aggressive. It's the MINIMUM security standard. If L1 breaks your infrastructure, the problem isn't the baseline - it's that your infrastructure was already broken and running on borrowed time.
The fact that "Refuse LM & NTLM" exposed this issue proves the infrastructure was:
- Dependent on random NTLM version selection
- Never properly configured for modern authentication
- A security incident waiting to happen
The Path Forward
To fix this properly (not just re-enable NTLMv1):
Configure Kerberos Properly
- Set SPNs for all services
- Configure delegation correctly
- Test with NTLM completely disabled
If You Must Use NTLM, Control It
- Set LmCompatibilityLevel to 3 or higher on all systems
- Force NTLMv2 only
- Monitor NTLM usage with proper auditing
Understand Your Authentication Flow
- Document what uses Kerberos vs NTLM
- Know WHY fallbacks occur
- Fix the root causes, not the symptoms
Conclusion
"NTLM is the default fallback for when Kerberos does not work, which turns out to be pretty regularly". But "regularly" doesn't mean "acceptably."
Today, having critical infrastructure randomly choosing between 1990s authentication protocols is not a configuration issue - it's a competence issue. CIS L1 didn't break this environment. It revealed what was already broken: an authentication architecture built on defaults, assumptions, and a fundamental unwillingness to implement technology correctly