User SPN non-FQDN hosts should be investigated

Contributed by Michael SouleAll contributors →

Part of Active Directory · Active Directory · Service principal names · All checks

Run this check

Invoke-Maester -TestId AD-SPN-11

Overview

User account SPNs with non-FQDN hosts can cause:

• Authentication failures: Kerberos may fail to resolve short names
• Cross-domain issues: Non-FQDNs don’t work across domain trusts
• Service disruptions: Applications may fail to authenticate
• Configuration drift: Indicates inconsistent SPN management

Since user accounts with SPNs are already high-value targets, ensuring proper FQDN configuration is essential.

Control Type

Operational

Security Recommendation

Review and fix non-FQDN user SPNs:

• Update SPNs to use fully qualified domain names
• Establish SPN registration standards
• Use FQDNs consistently for all service principal names
• Consider this as part of a migration to gMSAs

How the Test Works

This test parses all user SPNs and checks if the host portion contains a dot (indicating FQDN format). SPNs without dots in the host portion are flagged as non-FQDN.

Related Tests

• Test-MtAdComputerSpnNonFqdnHosts - Checks computer SPNs for non-FQDN hosts
• Test-MtAdUserSpnTotalCount - Overall user SPN analysis

Details

Every attribute of this check

Field	Value
Test ID	AD-SPN-11
Severity	Info
Suite	Active Directory
Product	Active Directory
Feature	Service principal names
Area	Authentication
Resource type	User
MITRE ATT&CK	None
PowerShell test	Test-MtAdUserSpnNonFqdnHosts
Services	ActiveDirectory
Permissions	ActiveDirectory:Ldap:user:ReadProperty

Source

• Test: tests/ad/spn/Test.AD-SPN-11.ps1
• Documentation: tests/ad/spn/Test.AD-SPN-11.md