How to fix ERROR_DS_CANT_DERIVE_SPN_WITHOUT_SERVER_REF (8589 | 0x218D | 0x8007218D) – Cannot derive SPN without serverReference

Error code equivalence (same error, different formats)​

What this error really means​

• Represent physical or virtual servers in the domain
• Track Kerberos SPNs for mutual authentication
• Maintain linked attributes (serverReference) for the computer or server object

• AD cannot determine the correct SPN
• Kerberos authentication fails
• Certain replication or remote operations may fail

Common real-world scenarios that trigger this error​

1) Restored or migrated server objects​

• Server object was restored from backup or imported without serverReference
• Linked attributes did not replicate properly

• SPN-related errors in Event Viewer
• Kerberos authentication to the server fails
• Object appears in ADUC but lacks proper attributes

2) Schema or replication inconsistencies​

• DC replication issues
• Linked attribute did not replicate

• Only one DC shows the error
• repadmin /showobjmeta reveals missing serverReference

3) Manual AD modifications or automation errors​

• Scripts created server objects without linking to serverReference
• Third-party tools modifying AD schema incorrectly

• Newly added server objects cannot authenticate with Kerberos
• SPN generation fails

4) Domain controller promotion issues​

• New DC added via DCPromo
• Server object did not receive a proper serverReference link

• DC cannot authenticate with other DCs
• SPN-related errors in Event Viewer → System or Directory Service logs

What this error is NOT​

• Not a permission issue
• Not DNS or network related
• Not transient — requires attribute fix

Real fixes & solutions (correct order matters)​

Step 1: Identify the affected server object​

• Use ADUC or PowerShell:

Get-ADComputer -Identity <ServerName> -Properties serverReference

• Confirm whether serverReference is populated

Step 2: Determine correct serverReference​

• The serverReference attribute should point to the server object that represents the physical or virtual host
• Typically, this is automatically set during DC promotion or object creation

Step 3: Update or restore the serverReference attribute​

• Use ADSI Edit or PowerShell to link the attribute:

Set-ADComputer -Identity <ServerName> -Add @{serverReference="CN=<ServerObject>,CN=Servers,CN=<Site>,CN=Sites,CN=Configuration,DC=domain,DC=com"}

• Ensure DN is correct and exists in AD

⚠ Warning: Incorrect edits in ADSI Edit can corrupt AD objects. Backup first.

Click to expand...

Step 4: Validate SPN generation​

• After updating serverReference, SPNs should be derivable:

Set-ADComputer -Identity <ServerName> -ServicePrincipalNames @("HOST/<ServerName>","HOST/<ServerFQDN>")

• Use setspn -L <ServerName> to verify SPNs

Step 5: Test Kerberos authentication​

• From client or another DC:

klist purge
klist tickets

• Ensure Kerberos tickets are generated for the server
• Verify mutual authentication succeeds

Step 6: Ensure replication consistency​

• Run:

repadmin /showrepl
dcdiag /v

• Confirm that serverReference and SPNs replicate to all DCs

Fast “symptom → fix” mapping​

• Kerberos authentication fails for server → Check serverReference → Restore or link correctly
• DCPromo or new DC SPN issues → Verify server object attributes
• Replication inconsistencies → Ensure attribute replicates across DCs

Related schema and SPN errors (context map)​

Practical diagnostic checklist​

• Does the server object exist in AD?
• Is serverReference populated correctly?
• Are SPNs registered for the server?
• Has replication propagated the attribute to all DCs?
• Are Kerberos tickets being issued correctly after fix?

Note​

• SPN generation depends on the serverReference attribute.
• The fix is to populate or restore serverReference correctly, verify SPNs, and ensure replication across DCs.