Hi everyone,

I'm battling a frustrating intermittent Kerberos issue with AVD and FSLogix profiles on Azure Files (AD DS integrated), and Microsoft Support is currently spinning their wheels ...

We recently ran the Microsoft script to update our Azure Files AD computer object to AES-256 to comply with the recent April 2026 Kerberos Hardening (CVE-2026-20833 / RC4 deprecation). Since then, we've had random FSLogix mount failures.

The Symptoms

• Users randomly fail to mount profiles with FSLogix Error: [ERROR:000004f1] FindFile failed... (The system cannot contact a domain controller to service the authentication request.)
• The weird workaround: If a VM is failing, rebooting it and immediately logging in via RDP with an Admin account "warms up" the Kerberos cache. Subsequent standard users connecting via the AVD Windows App to that same host will work perfectly for the rest of the day.
• Running klist -li 0x3e7 purge to clear the SYSTEM cache sometimes allows it to pull a fresh ticket and recover, pointing to a "DC Roulette" issue where some DCs hand out bad tickets or reject the request.

The Hard Evidence & Troubleshooting

We bypassed FSLogix to test raw SMB/Kerberos and found the following:

1. Manual Ticket Request Fails: Running klist get cifs/name.file.core.windows.net on a failing AVD returns:Error calling API LsaCallAuthenticationPackage... 0x6fb klist failed with 0xc000018b/-1073741429: The SAM database on the Windows Server does not have a computer account for this workstation trust relationship.
2. VM Trust is 100% Healthy: Test-ComputerSecureChannel is True. The DC Event Logs (Event 4768) show the AVD VM successfully getting a TGT using AES-256 (0x12).
3. The Drop (Event 4769): When the VM asks the DC for the service ticket to the Azure Files share, the DC throws Failure Code 0x6 (KDC_ERR_C_PRINCIPAL_UNKNOWN) and Ticket Encryption Type 0xFFFFFFFF.
4. Encryption Attributes are Correct: * Azure Files Object (msDS-SupportedEncryptionTypes): 16 (AES-256)
   • AVD Session Hosts: 24
   • Domain Controllers: 28
5. The Basics are Covered: No duplicate SPNs (setspn -Q). AD Replication is perfectly healthy across all DCs (repadmin /showrepl). Line of sight is fine.

Our Theory

Since the VM trust is fine and AD replication is healthy, we suspect the AES-256 script we ran successfully updated the attributes, but caused a Key Version Number (KVNO) / Password hash mismatch between the Azure Files storage account backend and the AD DS computer object. When the AVD asks a DC for a ticket, the DC uses a mismatched key and throws the trust error.

My Questions

1. Has anyone else experienced this exact 0xc000018b / 0x6 error specifically after running the Azure Files AES-256 rotation scripts?
2. Before I pull the trigger in production, has running Update-AzStorageAccountADObjectPassword permanently fixed this KVNO sync issue for you, or did it break things further?
3. Is there a deeper KDC caching issue at play here with the April 2026 patches?