Skip to main content
Version: 2.2.1-preview

AD-SPN-11 - User SPN non-FQDN hosts should be retrievable

Michael SouleMerill Fernando
Contributed by Michael Soule with Merill FernandoAll contributors →

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.

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.

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

Test Metadata​

FieldValue
Test IDAD-SPN-11
SeverityInfo
SuiteActive Directory
CategoryAD.SPN
PowerShell testTest-MtAdUserSpnNonFqdnHosts
TagsAD, AD-SPN-11, AD.SPN

Source​

  • Pester test: tests/ad/spn/Test-MtAdUserSpnNonFqdnHosts.Tests.ps1
  • PowerShell source: powershell/public/ad/spn/Test-MtAdUserSpnNonFqdnHosts.ps1