The AES checkbox is set, but the second node fails

An application runs on two Linux nodes behind a load balancer. Both use the same AD service account and local keytabs. Authentication initially works after moving to AES. At the next failover it fails: only the active node received the new key material. The AD configuration was correct, but the application was not ready.

Another global Kerberos setting will not resolve this class of failure. This article addresses the technical migration of individual service paths: from available keys and keytab versions to acceptance testing of tickets and application sessions. Patch schedules, general service account hygiene and krbtgt rotation are separate work packages.

The target is verifiable: every approved path uses AES, including restart, failover and required backend access. RC4 either has an explicitly time-limited exception or no remaining production dependency.

Four layers must agree

AD attribute: msDS-SupportedEncryptionTypes describes supported algorithms. It neither creates keys nor proves successful use. A missing value does not automatically mean RC4-only; the result depends on factors including the KDC default.

Key material: The account needs suitable AES keys in AD. Old passwords can leave this prerequisite unmet. A controlled password change can generate missing AES keys; participating services must receive the same new secret or the keys derived from it.

Host and application: Windows policies, Kerberos libraries and product configuration determine what is actually offered and accepted. A Windows GPO alone does not migrate a Linux service.

Live exchange: Ticket encryption and the session key are separate results. An AES session key does not prove that the service ticket itself was protected with AES. Acceptance evidence must preserve this distinction.

Create a migration record for each service path

Record the client type, requested DNS name, expected SPN, associated AD account, every service node and any backend or trust boundary. Add the keytab location, managing deployment process, vendor support status, owner and maintenance window. Record metadata, never keytab contents or passwords in the ticketing system.

A targeted, read-only query of the known service object provides a starting point. Replace the example distinguished name; ordinary delegated read access is sufficient with typical AD permissions. The ActiveDirectory module is required.

Set-StrictMode -Version Latest
Import-Module ActiveDirectory -ErrorAction Stop
$serviceIdentity = 'CN=svc-app,OU=Service Accounts,DC=example,DC=org'
$properties = @(
    'servicePrincipalName', 'msDS-SupportedEncryptionTypes',
    'msDS-KeyVersionNumber', 'pwdLastSet'
)
Get-ADObject -Identity $serviceIdentity -Properties $properties `
    -ErrorAction Stop |
    Select-Object DistinguishedName, servicePrincipalName,
        msDS-SupportedEncryptionTypes, msDS-KeyVersionNumber, pwdLastSet

This query exposes neither secret keys nor proof that they work. The password timestamp informs planning; it is not an AES test. Computer accounts, gMSAs and conventional user accounts require treatment appropriate to their management model.

Change keytabs and key versions together

A keytab contains long-term secret keys. Its entries differ by properties including principal, encryption type and Key Version Number, or KVNO. A correct filename or an existing AES entry is insufficient.

Plan the migration as one coordinated service change:

  1. Verify AES support in the deployed product and library versions. Establish which process loads the keytab and when it picks up changes.
  2. Preserve the previous configuration and a vendor-supported recovery procedure. An old keytab backup is not automatically usable after changing the AD password.
  3. Generate required AES keys through the designated password and keytab process. Account for the exact principal, capitalization, salt and key version.
  4. Distribute the current keytab securely to every authorized node. Restrict file permissions to the intended service identities.
  5. Verify the principal, AES types and matching KVNO using metadata and a fresh ticket. Matching version numbers alone do not prove that the key matches.
  6. Reload keys through the intended service restart or reload and test every node deliberately. Control test routing while retaining the intended service DNS name and SPN; a different backend name would test a different identity path.

Do not generate a keytab as an incidental diagnostic action: tools such as ktpass can affect account mapping, the password and consequently other consumers. Passwords must also stay out of command lines and shell history.

Allow AES and remove RC4 deliberately

Restrict allowed cryptography after the key and application tests succeed. On Windows, the setting is located under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos.

For the agreed AES-SHA1 baseline, allow AES128_HMAC_SHA1 and AES256_HMAC_SHA1; remove RC4 and DES within the approved scope. Additional newer algorithms follow the tested platform baseline. Deploy first to a pilot group and schedule required restarts. Then check effective policy, not just the GPO editor.

Handle account attributes separately. Their bitmask uses 0x4 for RC4, 0x8 for AES128 and 0x10 for AES256. Do not blindly replace existing values with 0x18: other capability bits can matter. For Windows computer accounts, computer configuration also manages the attribute.

Inventory explicit KDC defaults and account exceptions as well. A current DC patch level alone does not demonstrate a complete RC4 ban. Updates released from July 2026 no longer support the former global audit rollback through RC4DefaultDisablementPhase.

Test tickets and application success separately

The DCs need an effective Advanced Audit Policy: under Account Logon, capture Audit Kerberos Authentication Service and Audit Kerberos Service Ticket Operations with Success and Failure for the agreed scope. Check forwarding and retention against expected event volume. DC update levels and event versions determine which additional fields are available; missing fields do not demonstrate secure encryption.

Collect Security events 4768 and 4769 from the relevant DCs using controlled read access or centralized forwarding. For service tickets, 4769 provides fields including TicketEncryptionType, SessionKeyEncryptionType, status and service account. Parse XML field names rather than fixed field positions.

Displayed supported algorithms can be processed values rather than the unchanged AD attribute. RC4 listed under Available Keys also does not demonstrate RC4 use. Assess available keys separately from the encryption actually selected.

For ticket etypes, 0x11 means AES128, 0x12 AES256 and 0x17 RC4; 0x18 means RC4-HMAC-EXP here, not AES. These values differ from the AD bitmask. A successful request with status 0x0 demonstrates ticket issuance; only the application test shows that the service accepts it. The event's ServiceName identifies the target account and is not a reliable substitute for the complete requested SPN.

The test matrix should include at least:

  • a fresh logon in an isolated test session using the intended DNS name;
  • access to every service node followed by failover;
  • service restart or reload followed by another access test;
  • real background jobs and required backend or delegation paths;
  • access across affected domain or forest boundaries in every required direction;
  • evidence that an unnoticed NTLM fallback does not explain success.

Existing tickets and long-lived connections can hide failures. Create fresh test sessions in a controlled way; do not purge ticket caches belonging to unrelated production sessions. Also observe infrequent operations such as monthly jobs. A quiet log outside their execution window is not acceptance evidence.

Resolve failures according to their cause

No common algorithm: Check advertised types and effective policy on client, service and KDC. Ticket issued, service rejects it: Check SPN mapping, selected keytab, principal, KVNO and the key material actually loaded. Only some nodes fail: Compare deployment state and process restarts. DNS, time and replication remain additional checks.

A necessary exception records its account, affected systems, owner, expiry date and specific replacement plan. It must not restore RC4 across the domain. After remediation, repeat the same fresh functional test and remove the exception. Recover a production password change through an agreed procedure, rather than copying back an arbitrary old keytab.

Benefits

  • RC4 disappears from verified service paths, exposing weak compatibility assumptions.
  • Coordinated key and keytab distribution reduces failures during restart and failover.
  • Separate ticket and session criteria make acceptance technically meaningful.
  • Ownership and recovery procedures remain useful for later rotation.

Disadvantages and limitations

  • Distributed applications need coordinated maintenance windows and vendor-specific tests.
  • Older products can require an upgrade or replacement; an AD attribute cannot fix a missing implementation.
  • AES prevents neither Kerberoasting against weak secrets nor misuse of an already compromised service.
  • Disabling RC4 in Kerberos does not disable NTLM. That protocol needs separate controls.
  • A limited observation window does not prove that infrequently used dependencies work.

Project checklist

  • [ ] Service paths, including SPNs, nodes, backends and trust boundaries, documented.
  • [ ] AES support verified for the products actually deployed.
  • [ ] Available keys assessed separately from attribute values and host policies.
  • [ ] Keytab distribution, principal, KVNO and file permissions checked on every node.
  • [ ] Password change, reload and recovery coordinated with every consumer.
  • [ ] Account and KDC exceptions and effective Windows policies reviewed.
  • [ ] Audit subcategories, event versions, forwarding and retention verified.
  • [ ] Ticket and session types verified separately using fresh logons.
  • [ ] Failover, restart, background jobs and required trust paths tested.
  • [ ] Application success confirmed and NTLM fallback ruled out.
  • [ ] Remaining RC4 exceptions time-limited with a committed removal date.