Microsoft Kerberos OOB Updates Fix Domain Controller Sign in Failures (2022)

Microsoft has quietly shipped a set of emergency, out‑of‑band updates to repair a Kerberos authentication regression that broke sign‑ins and remote access on domain controllers after the November 8, 2022 Patch Tuesday rollup — and administrators must install the fixes manually on every Domain Controller in their environment to fully remediate the problem.

Background​

Kerberos is the authentication backbone for Active Directory environments: domain clients request tickets from the Key Distribution Center (KDC) on a Domain Controller (DC) and then present those tickets to access services without re‑sending passwords. When a change in how Kerberos keys or encryption types are handled introduces incompatibility, the result can be widespread sign‑in failures, Remote Desktop drops, failed service account authentication, and other domain authentication faults. This is what unfolded following Microsoft’s November 8, 2022 updates. In short: the November 8 updates hardened Netlogon and Kerberos behavior in some environments that had disabled the RC4 encryption type via the SupportedEncryptionTypes setting or where account attributes were configured to exclude RC4. That hardening exposed a compatibility gap that caused DCs to log Microsoft‑Windows‑Kerberos‑Key‑Distribution‑Center Event ID 14 with text indicating a “missing key has an ID of 1”, and triggered authentication failures for domain users, service accounts (including gMSAs), Remote Desktop sessions, and access to file shares.

---

What Microsoft released (the fixes and where to get them)​

Microsoft responded by releasing a family of out‑of‑band (OOB) updates on November 17–18, 2022 specifically targeted at Domain Controllers. These packages include both cumulative updates and standalone patches depending on the Windows Server version:

• Windows Server 2022 — KB5021656 (cumulative out‑of‑band).
• Windows Server 2019 — KB5021655 (cumulative out‑of‑band).
• Windows Server 2016 — KB5021654 (cumulative out‑of‑band).
• Windows Server 2012 R2 — KB5021653 (standalone).
• Windows Server 2012 — KB5021652 (standalone).
• Windows Server 2008 SP2 — KB5021657 (standalone).
• Windows Server 2008 R2 SP1 (ESU) — KB5021651 was published on November 18, 2022 for eligible ESU customers.

Microsoft’s guidance makes two critical operational points clear:

• These out‑of‑band updates must be installed on all Domain Controllers in your environment to resolve the Kerberos failures. You do not need to install them on non‑DC servers or client workstations just to fix this particular issue.
• The patches are not offered automatically via Windows Update; administrators must download and deploy the packages from the Microsoft Update Catalog, or import the standalone packages into WSUS / Configuration Manager.

---

Symptoms, scope, and immediate operational impact​

The real‑world symptoms reported by administrators matched Microsoft’s known‑issue text:

• Domain user sign‑in failures (interactive and non‑interactive).
• Active Directory Federation Services (AD FS) authentication failures in some environments.
• Remote Desktop (RDP) connections using domain credentials failing to authenticate.
• Service accounts and Group Managed Service Accounts (gMSAs) failing to acquire service tickets, impacting IIS and other services.
• Event ID 14 from the Kerberos KDC indicating a missing key (ID 1) — a direct diagnostic clue pointing to encryption type / key mismatches.

This is a classic compatibility failure: changes that harden or remove legacy ciphers (RC4) are desirable for security, but if any accounts, service principals, or clients still depend on older keys or the domain has mixed encryption settings, authentication flows can break. Administrators who had previously configured SupportedEncryptionTypes to exclude RC4 (either at domain level or per account) were disproportionately affected.

---

Why the November updates triggered the problem​

Two technical conditions had to coincide to reproduce the failures:

• A Domain Controller had the November 8, 2022 cumulative update (or later) installed, and
• The domain or specific account(s) were configured to remove RC4 by setting SupportedEncryptionTypes (or by account attributes that limited accepted etypes).

In some cases the account attribute ms‑DS‑SupportedEncryptionTypes contained values (even 0x0) that caused the KDC to present or request incompatible keys, producing the Event ID 14 error that referenced the missing key with ID 1. Microsoft documented this diagnostic behavior in its KB articles and follow‑ups.

---

What administrators should do now — practical remediation and checklist​

Microsoft’s required remediation path is straightforward but operationally sensitive: install the appropriate out‑of‑band KB on every Domain Controller, verify authentication flows, and remove any prior mitigations once the environment is patched. Follow this action plan:

• Inventory: Identify every Domain Controller and confirm which November 2022 updates (if any) have been installed. Use SCCM/WSUS/Intune inventory tools or scripts to enumerate installed KBs.
• Download OOB updates: Get the correct KB package(s) for each DC’s OS SKU from the Microsoft Update Catalog. These packages are not pushed via Windows Update.
• Pilot: Apply the out‑of‑band update to a small set of non‑production DCs first, or to a single DC in a lab/staging environment. Validate domain logons, RDP sign‑ins, AD‑integrated services (IIS, file shares), and AD FS if in use.
• Rollout: After successful validation, deploy to all remaining DCs in a controlled, staged manner and schedule reboots if required. Validate replication health and authentication flows after each stage.
• Revert temporary mitigations: If you used registry workarounds (for example KrbtgtFullPacSignature) or took other mitigations, revert them only after all DCs are patched and authentication verifies correctly. Microsoft explicitly recommended removing temporary mitigations once the OOB updates were applied.
• Monitor logs and telemetry: Increase scrutiny of Kerberos events (KDC, Event ID 14, 11, 21/22 if present) and LSASS memory use after patching. Microsoft noted some OOB updates could, in certain builds, coincide with an LSASS memory leak — track memory and have contingency plans.

Key commands and checks (concise):

• Check for Event ID 14 in System logs on each DC.
• Use AD attribute checks to list ms‑DS‑SupportedEncryptionTypes or query for accounts with non‑default etypes configured.
• Confirm the exact KB installed on each DC and match to the Microsoft KB→SKU mapping before deployment.

---

Nuances: security‑only vs monthly rollups, WSUS import, and ESU considerations​

• Security‑only updates are not cumulative. If your organization uses security‑only servicing, the OOB standalone security packages (e.g., KB5021653/KB5021652/KB5021657) should be treated as the November 2022 security‑only packages and installed along with prior security‑only updates to be fully current. Microsoft’s guidance clarifies the distinction.
• If you use Monthly Rollups, note that the rollups are cumulative and include quality updates; however, Microsoft recommended installing the OOB standalone updates and the November 8 monthly rollups where necessary to have the full set of fixes for November. Validate your servicing model before deploying only a subset of packages.
• Older servers outside mainstream support (Windows Server 2008/2008 R2) require Extended Security Updates (ESU) to receive these 2022 fixes. Microsoft published dedicated OOB packages for Windows Server 2008 SP2 (KB5021657) and 2008 R2 ESU (KB5021651) with ESU prerequisites and licensing notes. Organizations still running unsupported builds should confirm ESU entitlement before importing those KBs.
• WSUS / Configuration Manager import: The Update Catalog packages can be imported into WSUS or MECM for centralized deployment. Microsoft published procedural guidance for importing OOB packages — follow the standard WSUS catalog import procedures.

---

Community experience and issues to watch for​

Early reports from administrators and Microsoft Q&A threads highlighted real friction points:

• Some environments saw AD FS broken after partial deployments; full resolution required applying the OOB updates to all DCs or clearing ms‑DS‑SupportedEncryptionTypes on problematic accounts.
• A minority of environments observed LSASS memory growth after installing certain OOB packages; Microsoft tracked this as a known issue for particular builds and provided follow‑up guidance (and corrective KBs) as needed. Monitor LSASS memory during the rollout.
• The diagnosis often pivoted on Event ID 14 and the “missing key has an ID of 1” text — treat that event as high‑priority telemetry that points to encryption type mismatches between the KDC and the account or client.

Forum and community analyses reinforced that this was not a universal failure: only domains with specific encryption configurations or account attributes were affected — but when it hit, the blast radius was large because authentication is central to so many services.

---

Technical analysis — what went wrong and why the fix was necessary​

The core tension here is between security hardening and compatibility:

• Microsoft’s November 8 updates implemented Kerberos/Netlogon hardening and more restrictive handling of legacy encryption types (RC4). Hardening is the correct long‑term direction — RC4 is weak and legacy, and reducing its usage is security‑positive.
• However, many enterprise environments contain legacy service accounts, appliances, or applications that implicitly relied on RC4 or had account attributes set in ways that left them unable to negotiate newer etypes. The KDC receiving requests lacking the expected keys or etypes led to ticket validation failures and Event ID 14.
• The OOB updates aligned KDC behavior and key handling to address the regression — essentially restoring correct processing across the mixed environments while preserving the security posture Microsoft intended. Administrators can then safely complete the migration to stronger etypes and remove temporary allowances.

---

Strengths and weaknesses of Microsoft’s handling​

Strengths

• Speed: Microsoft released targeted out‑of‑band fixes within nine days of the Patch Tuesday release, which mitigated extended operational disruption. That responsiveness reduced the window during which organizations had to rely on fragile workarounds.
• Granularity: The vendor provided OS‑specific KBs and explicit guidance to apply the fixes only to Domain Controllers, lowering the risk of unnecessary client updates.
• Transparency in guidance: Microsoft documented the diagnostic signals (Event ID 14 text) and provided remediation steps and update catalog references.

Risks and shortcomings

• Manual deployment friction: Because the OOB KBs were not pushed automatically via Windows Update, administrators had to download, stage and install packages manually (or via WSUS import). That increases operational friction and the chance of partial or inconsistent deployments across DCs.
• Potential knock‑on issues: Some OOB packages had interactions (LSASS memory growth, AD FS hiccups) that produced secondary operational headaches. Rapid emergency fixes can introduce edge‑case regressions, so cautious piloting is vital.
• Legacy server complexity: Organizations running 2008/2008 R2 required ESU eligibility to receive OOB patches — yet many enterprises still running those systems might not have ESU, complicating remediation.

---

Recommended post‑remediation hardening steps​

Once OOB updates are deployed and service stability is confirmed, teams should finish the security work that triggered the compatibility issue in the first place:

• Validate and audit account encryption settings (ms‑DS‑SupportedEncryptionTypes) and confirm all accounts are compatible with modern etypes (AES‑128/256, etc.. Remove any lingering dependence on RC4.
• Re‑enable enforcement of Kerberos PAC signature policies where appropriate (adjust KrbtgtFullPacSignature back to stronger settings) after ensuring all clients and services can interoperate. Microsoft provided temporary registry guidance during the incident and recommended restoring secure settings after patching.
• Expand testing coverage for authentication flows in your update validation process: include AD FS, RDS hosts, file servers, and appliances that integrate with the domain. Track AD replication health and authentication telemetry during future monthly rollouts.
• Maintain a documented, automated inventory of DCs and their exact KBs so that similar manual OOB rollouts can be executed consistently in future emergencies. Use SCCM/WSUS/Intune reporting to ensure zero DCs are missed.

---

Final assessment — what this episode means for Windows infrastructure teams​

This Kerberos incident is a sober reminder of a perennial trade‑off in managed infrastructures: security hardening improves the resilience of an estate in the long term, but incremental compatibility checks and staged rollouts are essential to prevent short‑term operational damage.
Microsoft’s fast OOB response fixed the functional breakage, and the vendor’s guidance—install the OOB KBs on all Domain Controllers and remove temporary mitigations afterward—must be treated as authoritative. Still, the episode exposed process gaps in many organizations:

• incomplete inventory of account and service encryption settings,
• fragmented patching workflows that struggle with manual OOB KBs, and
• reliance on legacy systems without ESU that complicate remediation.

From a practical standpoint, prioritize the following outcomes:

• Ensure every Domain Controller in production has the November 17–18 OOB updates applied (or the ESU equivalent where relevant).
• Reconcile account and domain encryption settings with modern Kerberos etypes to permanently remove the need for RC4 allowances.
• Harden deployment and validation processes so that future emergency updates can be staged, piloted, and rolled out without service interruptions.

This was a painful but instructive incident: it reinforced that authentication subsystems are critical infrastructure, and that careful, automated inventory + staged patching + telemetry monitoring are not optional for teams operating enterprise Active Directory at scale.

---

Microsoft’s out‑of‑band updates for November 17–18, 2022 stopped the immediate Kerberos failures — but the larger lesson remains: plan for compatibility as you harden. Apply the OOB KBs to all Domain Controllers, validate authentication flows, remove temporary mitigations, and complete the transition to modern Kerberos encryption types so that the next security hardening does not cause the next operational outage.

---

Source: BetaNews Microsoft releases emergency patches to fix Kerberos authentication issues on multiple versions of Windows