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 \\rexchinafsxp001. The customer suspects security groups or routing (via a firewall ENI) and asks to confirm network connectivity.
Environment (from packet capture):
- Client:
10.204.16.133 - FSx default DNS name:
amznfsxbzputqee.b2b.regn.net->10.204.184.38 - DNS alias (the name clients actually use):
rexchinafsxp001.b2b.regn.net - Domain controller / KDC:
10.221.161.37
Investigation
Packet capture analysis on the client:
DNS resolution works — the alias is a CNAME ultimately pointing to the FSx:
rexchinafsxp001.b2b.regn.net CNAME amznfsxbzputqee.b2b.regn.net A 10.204.184.38Network layer is fine — TCP handshakes to FSx 445 (SMB) and to KDC 88 (Kerberos) both succeed, and SMB2 Negotiate returns success:
10.204.16.133 -> 10.204.184.38:445 SYN/SYN-ACK/ACK normal
SMB2 Negotiate Protocol Response NT Status: STATUS_SUCCESSThe 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/rexchinafsxp001 , cifs/rexchinafsxp001.b2b.regn.net
KRB-ERROR error_code 7 = KDC_ERR_S_PRINCIPAL_UNKNOWNWithout a ticket, SMB2 Session Setup fails (STATUS_NO_LOGON_SERVERS); the client RSTs and retries repeatedly.
Root Cause
rexchinafsxp001 is a DNS alias configured for the FSx file system. When a client accesses a share via the alias, it requests a cifs/rexchinafsxp001 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 amznfsxbzputqee.b2b.regn.net 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/rexchinafsxp001
HOST/rexchinafsxp001.b2b.regn.netResolution
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-PowerShell2. 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 = "rexchinafsxp001.b2b.regn.net"
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 = "amznfsxbzputqee.b2b.regn.net"
$Alias = "rexchinafsxp001.b2b.regn.net"
$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 = "amznfsxbzputqee.b2b.regn.net"
$FileSystemHost = (Resolve-DnsName ${FileSystemDnsName} | Where Type -eq 'A')[0].Name.Split(".")[0]
$FSxAdComputer = (Get-AdComputer -Identity ${FileSystemHost})
SetSpn /L ${FSxAdComputer}.NameConfirm the output contains HOST/rexchinafsxp001 and HOST/rexchinafsxp001.b2b.regn.net.
5. Purge client tickets and retry
klist purgeRe-access \\rexchinafsxp001 and confirm the share opens normally.
Summary
This incident 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.