SharePoint Search fails after April 2026 updates with KDC encryption error

Initial Symptoms

Across multiple environments (SharePoint 2013 / 2016 / 2019 / Subscription Edition), Search suddenly became unavailable after the April 2026 Windows updates.

The most visible symptoms:

• Search Services stop working or fail to start reliably.
• WCF/remote invocation fails.
• Search admin endpoints are no longer reachable.

Affected endpoints:

• https://localhost:32844/Topology/topology.svc returns 503.
• http://localhost:32843/Topology/topology.svc terminates immediately when called (backend/app pool crashes).

Error Message in Detail

The first visible exception is often just:

System.ServiceModel.Security.SecurityNegotiationException: A call to SSPI failed

Unfortunately, that is only the surface symptom. The actual root cause appears in the inner exception:

The encryption type requested is not supported by the KDC

Why this matters:

• A WCF SecurityNegotiationException only tells you that authentication negotiation failed.
• SSPI failed means Windows Integrated Authentication (Kerberos/NTLM) could not be established internally.
• The critical hint is the KDC message: the domain controller (KDC) rejects the requested Kerberos encryption type.

What typically happens under the hood:

1. A SharePoint process requests a Kerberos ticket for a service account/SPN.
2. Client/service expects a specific encryption type (historically often RC4 in older setups).
3. After the security changes, the KDC no longer allows that type or prioritizes only AES-compatible types.
4. Ticket issuance fails, which causes WCF security negotiation to fail and then breaks Search communication.

This also explains why the issue looks like a pure WCF or endpoint problem, while the real root cause is AD/Kerberos encryption compatibility.

What Changed in April 2026

With the updates released on April 14, 2026, Microsoft changed KDC behavior related to DefaultDomainSupportedEncTypes.

Reference:

• https://support.microsoft.com/en-us/kb/5073381

There is also a SharePoint-specific troubleshooting article for AES configuration:

• https://learn.microsoft.com/en-us/troubleshoot/sharepoint/security/configuration-to-support-kerberos-aes-encryption

Quick Verification Checklist

If you suspect the same issue, verify these points first:

1. Check ULS/Event Logs for SecurityNegotiationException, SSPI failed, and encryption type requested is not supported by the KDC.
2. Validate service accounts/SPNs used by SharePoint Search components.
3. Confirm affected accounts/servers are configured for AES-capable Kerberos settings.
4. Confirm the outage started right after the April 2026 patch window.

Resolution Path

In practice, correcting Kerberos encryption type configuration (with a focus on AES support) stabilizes Search components.

Important:

• Avoid quick workarounds that roll security back to weaker encryption types.
• The sustainable fix is to align both SharePoint and AD with Microsoft’s required Kerberos/AES settings.

Use the Microsoft guidance above as the authoritative step-by-step baseline.

Conclusion

The visible error (SecurityNegotiationException) is deceptively generic. The actual defect is deeper: a Kerberos encryption type mismatch between SharePoint workloads and the KDC after the April 2026 security changes. Once you treat the inner exception as the primary signal and align AES configuration correctly, the issue becomes reproducible and fixable.