I'm testing Azure Files with Active Directory Domain Services identity-based access, and the setup is working for most users. One user consistently receives username and password errors when connecting to the share. The user has certificate-based authentication (CBA) configured, so I'm wondering whether that could interfere with Kerberos.
Running `klist get cifs/testshare.file.core.windows.net` on the affected device returns:
`Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x6fb`
`klist failed with 0xc000018b: The SAM database on the Windows Server does not have a computer account for this workstation trust relationship.`
The device is hybrid domain joined, DNS appears to resolve correctly, and the user can access other domain-joined resources. Has anyone seen CBA or another Kerberos configuration cause this behavior with Azure Files?
3 Answers
We saw similar behavior during a transition between Microsoft Entra Kerberos and AD DS Kerberos. Some machines had cloud Kerberos ticket retrieval enabled and tried to obtain tickets through the cloud Kerberos path instead of the domain. Disabling that policy and rebooting allowed them to authenticate with normal AD DS Kerberos tickets. Cloud ticket retrieval should generally be enabled only when the storage accounts are configured to use Microsoft Entra Kerberos.
For hybrid-joined devices, check whether the computer account used for the Azure Files integration exists in Active Directory. If the storage account was joined with the Azure Files hybrid identity tooling, rerunning that configuration may recreate or repair the required account and permissions.
That error usually points to a broken or missing workstation trust relationship rather than CBA itself. Confirm that the device is still joined to the AD DS domain, then run `Test-ComputerSecureChannel` in PowerShell. Also verify DNS and time synchronization. If the secure channel cannot be repaired, removing and rejoining the device to the domain may be necessary.
I found the cause. This user had previously been testing Azure Files with Microsoft Entra Kerberos, which had enabled `CloudKerberosTicketRetrievalEnabled = 1` through the Kerberos policy OMA-URI. The device was receiving only cloud Kerberos tickets. After removing that policy, it obtained an AD DS Kerberos ticket and connected to the share successfully. A coexistence configuration may be needed when both authentication methods are being used.