Windows

WinRM/PowerShell Remoting fails with CredSSP errors after domain controller TLS cert rotation

Environment

Environment

Enterprise Windows domain (AD) with Windows Server 2016 DCs. DCs underwent TLS certificate rotation for LDAPS and LDAPS termination on load balancer changed certificates. Management automation uses PowerShell Remoting (WinRM) with Negotiate/Kerberos and occasional CredSSP for double-hop scenarios.

Symptoms

Symptoms

Automated scripts that call Enter-PSSession or Invoke-Command intermittently fail with 'CredSSP authentication is currently disabled on the client' or 'The server authentication certificate does not match the expected certificate' after DC cert rotation. New interactive logons OK, but remote commands that authenticate via Kerberos fail sporadically from some management hosts.

Observations

Observations

Event Viewer on management host shows: 'WinRM client attempted to use Kerberos but KDC returned KRB_AP_ERR_MODIFIED' for some SPNs. DCs log shows LDAP over TLS certificate subject changed and replication healthy. Some hosts cache KDC/LDAPS certificates and SPN resolution via DNS round-robin; clearing Kerberos ticket-cache (klist purge) temporarily restores functionality for that host.

Already attempted

Already attempted

Purged Kerberos tickets on a failing host (klist purge) and WinRM began working for a short period. Restarting WinRM service temporarily fixed some hosts. Did not change DC certs back. Collected network traces showing TCP to DCs on 636 and Kerberos traffic to KDCs.

Question

Question

What are the likely causes for WinRM/Kerberos/CredSSP failures following DC TLS certificate rotation, and what safe mitigation and diagnostic steps should be performed cluster-wide to restore reliable remoting?

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses
AI DIAGNOSTICS

Incident analysis

Updated 2d ago• Trouble ID

Most likely causes

Clients caching old LDAPS certificates or KDC endpoints (DNS round-robin) leading to ticket validation against unexpected host. 95%
Kerberos service ticket validation failing due to DCs presenting differing credentials or SPN mismatch after load balancer TLS termination change. 90%
Group Policy or CredSSP policy not propagated; some clients are not configured to allow CredSSP to updated targets. 50%

Summary

Kerberos KRB_AP_ERR_MODIFIED typically indicates SPN/Service ticket validation mismatch — often caused by load-balanced DCs or multiple domain controllers presenting different service credentials or when a client resolves a service to an endpoint with a certificate/SPN mismatch. Rotating LDAPS certificates or changing load balancer TLS termination can affect client behavior if CRL/OCSP, DNS, or SPN mappings are inconsistent. Credential Delegation (CredSSP) depends on trust between client and target; certificate changes can trigger errors. Temporary fixes (purging tickets, service restarts) suggest cached tickets or resolver mapping to inconsistent endpoints.

Suggested Fixes

Diagnostic step 1
On a failing client, run 'klist purge' to clear Kerberos tickets, then attempt WinRM to check whether the issue is resolved temporarily; collect logs for comparison.
Diagnostic step 2
Verify DNS and SPN mappings: ensure SRV records for KDCs are correct and clients resolve to expected domain controllers. Use 'setspn -Q' on DCs to validate SPNs for host/service names used by WinRM/LDAPS.
Diagnostic step 3
Check that LDAPS certificate chains on all DCs are valid and have matching subject/subjectAltNames for the service name clients use. Confirm CRL/OCSP is reachable from clients.