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

Indicators

• \\fileserver.domain.local\share returns 'Access Denied' or 'The network path was not found' when accessed by FQDN or hostname
• Direct IP-based access to the same share (e.g., \\192.168.x.x\share) succeeds without error
• setspn -X audit reveals duplicate SPNs registered to multiple AD computer or service accounts for the same file server name
• Kerberos ticket acquisition fails for the target server's HOST/ or cifs/ SPN when queried from the client
• Business-critical ERP application UNC paths and mapped network drives break simultaneously for affected departments

Likely causes

• Duplicate SPNs registered across multiple AD objects for the same file server name, causing Kerberos KDC to reject ticket issuance due to ambiguity
• Enforced Kerberos authentication hardening changes that strictly reject NTLM fallback when an exact Service Principal Name (SPN) mismatch or duplicate is found across AD objects
• DNS CNAME alias records for the file server not accompanied by corresponding HOST/ SPN attributes on the computer account, causing Kerberos to fail to resolve the correct service ticket target
• Computer account rename or migration leaving stale SPNs on old or orphaned AD objects

Diagnostic steps

1. Run setspn -X from an administrative command prompt on a Domain Controller to audit the entire domain for duplicate SPNs
   Identifies all duplicate SPN registrations across AD objects — a duplicate matching the target file server name confirms the root cause
2. Review setspn -X output for any HOST/, cifs/, or related SPNs that appear on more than one AD object for the affected file server name (e.g., HOST/fileserver, HOST/fileserver.domain.local)
   Pinpoints the exact duplicate SPN entries that are causing Kerberos KDC rejection and must be removed or reassigned
3. Verify DNS records for the file server: confirm whether a CNAME alias is in use and check whether the corresponding computer account has HOST/ SPN attributes registered for that alias
   Determines if a CNAME without a matching HOST/ SPN is contributing to Kerberos authentication failure when clients resolve the alias
4. Attempt to access the share by FQDN from a client workstation and simultaneously attempt access by IP to confirm the IP-vs-FQDN failure pattern holds
   Confirms the issue is specifically in the Kerberos authentication path (FQDN triggers Kerberos; IP triggers NTLM) and rules out other network or share permission causes
5. Run 'setspn -L <computername>' against the file server computer account to enumerate all currently registered SPNs and cross-reference against the CNAME and DNS A records in use
   Provides a complete inventory of SPNs on the specific computer account to identify missing HOST/ entries for CNAME aliases or leftover stale entries from renames

Resolution path

• Remove the duplicate SPN identified by setspn -X from the incorrect or stale AD object using: setspn -D <SPN> <AccountName> — e.g., 'setspn -D HOST/fileserver.domain.local stale-computer-account'
• If a DNS CNAME alias is required for the file server, register the corresponding HOST/ SPN on the correct computer account using: setspn -A HOST/<cname-alias> <fileserver-computer-account> and setspn -A HOST/<cname-alias.domain.local> <fileserver-computer-account>
• Allow AD replication to propagate the SPN changes across all Domain Controllers (allow up to 15 minutes in multi-site environments)
• Purge the Kerberos ticket cache on an affected client using: klist purge
• Re-run setspn -X to confirm no duplicate SPNs remain for the affected file server name before declaring the issue resolved

Prevention

• Establish a routine SPN audit schedule: run 'setspn -X' against the domain monthly or after any server rename, migration, or CNAME DNS change to catch duplicate registrations before they cause outages
• Enforce a policy that any new DNS CNAME alias created for a Windows file server or application server must be accompanied by immediate registration of the corresponding HOST/ SPN on the correct computer account — include this as a checklist item in change management procedures
• Before applying Kerberos authentication hardening policies or security patches that restrict NTLM fallback, audit the domain for SPN duplicates and gaps using setspn -X as a pre-change validation step
• Document all SPNs associated with critical file servers and maintain a configuration record that is updated whenever computer accounts are renamed, decommissioned, or CNAME aliases are modified

Tools

• setspn.exe (audits, lists, adds, and removes SPNs on AD objects — built-in Windows tool)
• klist.exe (displays and purges Kerberos ticket cache on client machines — built-in Windows tool)
• Active Directory Users and Computers / ADSI Edit (GUI tools for reviewing and editing AD computer account attributes)
• DNS Manager (verifies A records and CNAME aliases for the file server)

References

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