FSx for Windows DNS Alias Access Failure: Missing Kerberos SPN

Checo7/3/26About 2 min

FSx for Windows DNS Alias Access Failure: Missing Kerberos SPN

Clients cannot reach the FSx file server via a DNS alias. Packet capture shows the network path is fully reachable; the failure is in Kerberos — the KDC cannot find the service principal for the alias. The root cause is the alias missing a HOST/ SPN registered on the FSx AD computer object.

Background

Clients cannot access the file server \\fileserver01. Security groups or routing (via a firewall ENI) are initially suspected; network connectivity needs to be confirmed.

Environment (from packet capture):

Client: 10.0.1.100
FSx default DNS name: amznfsxexample.corp.example.com -> 10.0.2.10
DNS alias (the name clients actually use): fileserver01.corp.example.com
Domain controller / KDC: 10.0.3.5

Investigation

Packet capture analysis on the client:

DNS resolution works — the alias is a CNAME ultimately pointing to the FSx:

fileserver01.corp.example.com  CNAME  amznfsxexample.corp.example.com  A  10.0.2.10

Network layer is fine — TCP handshakes to FSx 445 (SMB) and to KDC 88 (Kerberos) both succeed, and SMB2 Negotiate returns success:

10.0.1.100 -> 10.0.2.10:445  SYN/SYN-ACK/ACK normal
SMB2 Negotiate Protocol Response   NT Status: STATUS_SUCCESS

The real failure is in Kerberos — the client requests a service ticket for the alias from the KDC, which returns error code 7:

TGS-REQ  SName: cifs/fileserver01 , cifs/fileserver01.corp.example.com
KRB-ERROR  error_code 7  = KDC_ERR_S_PRINCIPAL_UNKNOWN

Without a ticket, SMB2 Session Setup fails (STATUS_NO_LOGON_SERVERS); the client RSTs and retries repeatedly.

Root Cause

fileserver01 is a DNS alias configured for the FSx file system. When a client accesses a share via the alias, it requests a cifs/fileserver01 service ticket from the KDC. However, the corresponding HOST/ SPN was never registered on the FSx file system's AD computer object, so the KDC cannot find this service principal.

So this is not a security group, route table, or firewall ENI issue — the network is reachable. A quick way to verify: accessing the FSx via its default DNS name amznfsxexample.corp.example.com usually works; if the default name works but the alias does not, it is almost certainly an SPN problem.

When Kerberos is enabled, each DNS alias requires two SPNs:

HOST/fileserver01
HOST/fileserver01.corp.example.com

Resolution

Run on a Windows instance joined to the same AD domain, as administrator. This modifies AD computer object SPNs; perform within a change window.

1. Install the AD PowerShell module

Install-WindowsFeature RSAT-AD-PowerShell

2. Check whether the alias SPN is already taken

SPNs must be unique in the domain. Before adding, confirm the alias HOST/ SPN is not already registered on another computer object (e.g., the old file server before migration):

$ALIAS = "fileserver01.corp.example.com"
SetSPN /Q ("HOST/" + $ALIAS)
SetSPN /Q ("HOST/" + $ALIAS.Split(".")[0])

If already present, remove it from the old object first.

3. Set the alias SPN on the FSx computer object

$FSxDnsName = "amznfsxexample.corp.example.com"
$Alias = "fileserver01.corp.example.com"
$FileSystemHost = (Resolve-DnsName $FSxDnsName | Where Type -eq 'A')[0].Name.Split(".")[0]
$FSxAdComputer = (Get-AdComputer -Identity $FileSystemHost)
Set-AdComputer -Identity $FSxAdComputer -Add @{"msDS-AdditionalDnsHostname" = @($Alias, $Alias.Split(".")[0])}

4. Verify the SPN

$FileSystemDnsName = "amznfsxexample.corp.example.com"
$FileSystemHost = (Resolve-DnsName ${FileSystemDnsName} | Where Type -eq 'A')[0].Name.Split(".")[0]
$FSxAdComputer = (Get-AdComputer -Identity ${FileSystemHost})
SetSpn /L ${FSxAdComputer}.Name

Confirm the output contains HOST/fileserver01 and HOST/fileserver01.corp.example.com.

5. Purge client tickets and retry

klist purge

Re-access \\fileserver01 and confirm the share opens normally.

Summary

This issue had nothing to do with security groups, route tables, or the firewall ENI — the network path was fully reachable. The root cause was the DNS alias missing a HOST/ SPN on the FSx AD computer object, causing the KDC to return KDC_ERR_S_PRINCIPAL_UNKNOWN and SMB authentication to fail. Adding the two SPNs restores access.

Make "configure SPN" a standard onboarding step whenever associating a new DNS alias with an FSx file system.