Listen to this Post
Introduction:
A critical yet often overlooked misconfiguration in Active Directory environments is the absence of Service Principal Names (SPNs) on service accounts. This oversight forces authentication to fall back to the weaker NTLM protocol, creating a significant vulnerability that attackers can exploit for lateral movement and credential theft. Understanding how to identify and remediate these accounts is essential for maintaining a robust security posture.
Learning Objectives:
- Understand the critical role of Service Principal Names (SPNs) in Kerberos authentication and the risks of falling back to NTLM.
- Learn how to use PowerShell to identify service accounts missing SPNs based on customizable naming conventions.
- Master the process of properly configuring SPNs on service accounts to enforce Kerberos authentication and mitigate security risks.
You Should Know:
- The Critical Role of SPNs in Kerberos Authentication
An SPN is a unique identifier for a service instance within an Active Directory domain. Kerberos uses SPNs to associate a service with a specific service account, enabling secure authentication without transmitting passwords.Step-by-step guide: Kerberos authentication works by having a client request a service ticket from the Domain Controller (DC). The DC uses the SPN to locate the correct service account in AD and encrypts the ticket with that account’s password. The service then uses its own password to decrypt the ticket. If no SPN is registered, the service cannot decrypt the Kerberos ticket, causing authentication to fail and the system to automatically revert to NTLM, a much less secure protocol.
2. Identifying Service Accounts Missing SPNs with PowerShell
The primary method for discovering these vulnerable accounts is through Active Directory PowerShell modules. The provided script filters for enabled user accounts that have no SPN set and match common service account naming patterns.
Verified Command:
Define common service account name patterns
$Pattern = "svc_","sql_","app_","backup_","web_","mssql_"
Query AD for enabled accounts with no SPN and matching the pattern
Get-ADUser -Filter { (ServicePrincipalName -notlike "") -and (Enabled -eq $true) } `
-Properties SamAccountName, ServicePrincipalName, Enabled |
Where-Object {
$user = $<em>.SamAccountName
$Pattern | Where-Object { $user -like $</em> }
} |
Select-Object SamAccountName, Enabled, DistinguishedName
Step-by-step guide: This command queries Active Directory for all enabled user accounts where the `ServicePrincipalName` property is empty. It then filters the results to only those accounts whose `SamAccountName` matches one of the patterns defined in the `$Pattern` variable. The output displays the account name, its enabled status, and its distinguished name for easy identification and remediation.
3. Expanding the Search with LDAP Filtering
For environments where PowerShell remoting is restricted, or for integration into other tools, direct LDAP queries can be used to find accounts missing SPNs.
Verified Command (for use with dsquery or other LDAP tools):
dsquery "CN=Users,DC=yourdomain,DC=com" -filter "(&(objectCategory=person)(objectClass=user)(servicePrincipalName=!)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" -attr sAMAccountName
Step-by-step guide: This LDAP query searches for all user objects (person and user) that are enabled (the bitwise filter `!(userAccountControl:1.2.840.113556.1.4.803:=2)` excludes disabled accounts) and have an empty `servicePrincipalName` attribute. Replace `”CN=Users,DC=yourdomain,DC=com”` with your domain’s base Distinguished Name.
- Setting a Correct SPN on a Service Account
Once a vulnerable account is identified, the appropriate SPN must be set. The SPN format is crucial and depends on the service being run.
Verified Command:
Example: Setting an SPN for a SQL Server service
Set-ADUser -Identity "svc_sqlprod" -Add @{servicePrincipalName="MSSQLSvc/sqlserver01.corp.domain.com:1433"}
To view the set SPNs
Get-ADUser -Identity "svc_sqlprod" -Properties servicePrincipalName | Select-Object -ExpandProperty servicePrincipalName
Step-by-step guide: Use the `Set-ADUser` cmdlet with the `-Add` parameter to modify the `servicePrincipalName` attribute. The SPN string is typically in the format SERVICE/HOST:PORT. After setting the SPN, verify it was applied correctly by retrieving the account’s properties. This allows the service to now participate in Kerberos authentication.
5. Preventing SPN Duplication Conflicts
A core security feature of Kerberos is that SPNs must be unique. Attempting to set a duplicate SPN will fail, which can also be an indicator of potential security issues like service account duplication.
Verified Command:
Check for duplicate SPNs across the domain
Get-ADUser -Filter -Properties servicePrincipalName | Where-Object {$<em>.servicePrincipalName} | Select-Object SamAccountName, @{name='SPNs';expression={$</em>.servicePrincipalName}} | ForEach-Object {
$user = $<em>.SamAccountName
$</em>.SPNs | ForEach-Object {
[bash]@{
SPN = $_
Account = $user
}
}
} | Group-Object SPN | Where-Object {$_.Count -gt 1}
Step-by-step guide: This script enumerates all SPNs in the domain, breaks them out, and groups them by the SPN string itself. It then filters for any groups with a count greater than one, indicating a duplicate. Duplicate SPNs must be resolved by reassigning one of the services to a different account or changing the SPN to be unique.
6. Auditing for NTLM Usage in the Environment
To understand the prevalence of NTLM and measure the impact of missing SPNs, you should enable and monitor NTLM audit logs on Domain Controllers.
Verified Command (Group Policy Management Console – GPMC):
Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy -> Audit Logon Events -> Success, Failure
Step-by-step guide: Enabling success and failure auditing for Logon Events on Domain Controllers will generate Event ID 4624 in the Security log for each authentication. The `Logon Process` field within the event will indicate whether `Kerberos` or `NtLmSsp` was used. A high volume of `NtLmSsp` events can indicate widespread misconfigurations, including missing SPNs.
7. Mitigating NTLM Relay Attacks with SMB Signing
While enforcing Kerberos is the primary goal, a critical defense-in-depth measure is to mandate SMB signing to mitigate NTLM Relay (PtH) attacks, which are enabled by NTLM fallback.
Verified Command (Group Policy to enforce SMB signing):
Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options: - Microsoft network client: Digitally sign communications (always) -> Enabled - Microsoft network server: Digitally sign communications (always) -> Enabled
Step-by-step guide: Configuring these Group Policy settings forces SMB packet signing, which effectively neutralizes SMB-based NTLM relay attacks. This is a crucial compensating control in environments where legacy systems prevent the complete disabling of NTLM.
What Undercode Say:
- Key Takeaway 1: Missing SPNs are not a minor configuration oversight but a critical security failure that actively weakens your domain’s authentication fabric by forcing the use of NTLM.
- Key Takeaway 2: Proactive, automated discovery and remediation of these accounts is a high-ROI activity that significantly reduces the attack surface for lateral movement.
The analysis from security professionals highlights that this issue is pervasive and dangerously underestimated. The forced fallback to NTLM creates a predictable and exploitable weakness that offensive security tools readily leverage. Relying on weak naming conventions for discovery is insufficient; a comprehensive audit of all enabled accounts without SPNs is necessary. The remediation process—correctly setting the SPN—is simple, but the initial discovery and organizational push to fix legacy systems require dedicated effort. This represents a clear gap between perceived and actual security posture in many enterprises.
Prediction:
The continued discovery and exploitation of misconfigured service accounts will drive a push towards greater automation in identity security. We predict a rise in integrated Identity Threat Detection and Response (ITDR) solutions that will continuously monitor for anomalies like missing SPNs and automatically remediate them or trigger high-severity alerts. Furthermore, as Kerberos-based attacks also evolve, the industry will gradually move towards mandating SMB signing and eventually disabling NTLM entirely, making the correct configuration of SPNs a non-negotiable prerequisite for a secure, modern AD environment.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Timo Sch%C3%B6nfeld – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
