SMB File Shares Accessible via IP but Failing via FQDN — Kerberos SPN Mismatch or Duplicate Fault

Indicators

• UNC path access via FQDN (\\fileserver.domain.local\share) returns 'Access Denied' or 'The network path was not found'
• Direct IP-based access to the same share (\\<IP>\share) succeeds without error
• Failure is consistent across all Windows 10/11 enterprise clients in the domain
• Business-critical mapped drives and legacy ERP UNC paths stop resolving
• Issue correlates with a recent Kerberos authentication hardening policy change
• Event ID 4771 or 4769 logged in Windows Security event logs indicating Kerberos ticket failures

Likely causes

• Enforced Kerberos authentication hardening that strictly rejects fallback to NTLM when an exact SPN mismatch is detected for the target file server
• Duplicate SPN registrations across multiple AD computer or service accounts for the same file server name, causing Kerberos ticket issuance to fail
• DNS CNAME (alias) records pointing to the file server without corresponding HOST/ SPN attributes registered on the computer account, preventing Kerberos from resolving the correct service target

Diagnostic steps

1. Open an administrative command prompt on a Domain Controller and run: setspn -X
   Audits the entire domain for duplicate SPN registrations, identifying any conflicting SPN entries associated with the target file server name
2. Review the output of setspn -X and note any duplicate HOST/ or cifs/ SPNs that reference the file server's NetBIOS name or FQDN across more than one AD object
   Pinpoints which AD objects carry conflicting SPN registrations that cause Kerberos to fail when the client requests a service ticket for the file server FQDN
3. Verify whether DNS CNAME records are in use for the file server by running: nslookup <fileserver-alias>
   Determines if CNAME aliases are contributing to the SPN mismatch, since Kerberos requires the SPN to match the canonical name, not the alias
4. Have an affected user test both \\<IP>\share and \\fileserver.domain.local\share from their workstation
   Validates that the failure mode is specifically Kerberos/SPN-related (IP access triggers NTLM, FQDN access requires Kerberos), ruling out general network or share permission issues
5. Check Windows Security event logs on both the client and file server for Event ID 4771 and 4769 around the time of access failures
   Provides additional evidence of Kerberos ticket failures and may reveal the specific SPN that cannot be resolved or is duplicated
6. On the file server, run: setspn -L <FileServerComputerAccount>
   Lists all SPNs currently registered on the file server's computer account to verify expected entries exist

Resolution path

• 1. Run 'setspn -X' on a Domain Controller to identify all duplicate SPN entries across AD objects
• 2. For each duplicate SPN identified, remove the erroneous entry from the incorrect AD object: setspn -D <SPN> <AccountName> — where <SPN> is the duplicate (e.g., HOST/fileserver.domain.local) and <AccountName> is the AD object that should NOT own it
• 3. Ensure the correct SPN is registered on the file server's own computer account. If missing, add it: setspn -S HOST/fileserver.domain.local DOMAIN\FileServerComputerAccount
• 4. If DNS CNAME aliases are required for the file server, register corresponding HOST/ SPN attributes for each alias name on the computer account: setspn -S HOST/<alias-name> DOMAIN\FileServerComputerAccount and setspn -S HOST/<alias-fqdn> DOMAIN\FileServerComputerAccount
• 5. Force replication across domain controllers if operating in a multi-DC environment: repadmin /syncall /AdeP
• 6. Have affected users clear their Kerberos ticket cache and retry: klist purge, then re-attempt FQDN-based share access

Prevention

• Implement a routine SPN audit schedule (e.g., monthly) using 'setspn -X' on a Domain Controller to proactively detect and remediate duplicate SPN registrations before they cause production outages
• Establish a change management procedure requiring that any DNS CNAME alias created for a server resource is accompanied by a corresponding HOST/ SPN registration on the computer account — enforced as a pre-requisite in the DNS/AD change process
• When enforcing Kerberos hardening policies (e.g., disabling NTLM fallback), validate SPN health across all file and application servers in a test environment before rolling out to production
• Document all SPN registrations for critical infrastructure servers (file servers, application servers) in a configuration management database (CMDB) to enable rapid auditing and reduce the risk of accidental duplicates during server migrations or renames

Tools

• setspn.exe — Active Directory SPN audit and management (built-in Windows Server tool)
• klist.exe — Kerberos ticket list and purge utility (built-in Windows client tool)
• nslookup — DNS name resolution verification
• repadmin — Active Directory replication management and forced sync
• Active Directory Users and Computers / ADSI Edit — GUI tools for reviewing and editing AD object SPN attributes

References

• SMB File Shares Accessible via IP but Failing via FQDN (Kerberos SPN Faults) — The Triage Manual