The error message: "The security database on the server does not have a computer account for this workstation trust relationship"
Seeing the message, the first suspicion is that something is wrong with the secure channel that the computer uses to communicate with Active Directory.
I logged into the computer using a local account, launched PowerShell to check the status of Secure Channel:
PS> Test-ComputerSecureChannel
True
OK. That is not the issue then! If it had returned "False", I could have used the -repairChannel parameter to fix it (need to run that in PowerShell Admin console).
PS> Test-ComputerSecureChannel -Repair
BTW, good old 'nltest' can be used to test and reset secure channel too, as shown below, but no need to bother when you have PowerShell?
PS H:\> nltest /sc_query:adilhindistan.com
Flags: 30 HAS_IP HAS_TIMESERV
Trusted DC Name \\MyDCName.adilhindistan.com
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully
Similarly, the following would reset it.
nltest /sc_reset:adilhindistan.com
Looking at Event logs revealed that this was related to an Service Principal Name issue:
WORKSTATION:
Log Name: System
Source: Microsoft-Windows-Security-Kerberos
Date: 10/7/2013 3:59:14 PM
Event ID: 3
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: testcomputer.adilhindistan.com
Description:
A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 20:59:14.0000 10/7/2013 Z
Error Code: 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN
Extended Error: 0xc0000035 KLIN(0) <===== STATUS_OBJECT_NAME_COLLISION (Object Name Already Exists)
Client Realm:
Client Name:
Server Realm: adilhindistan.com
Server Name: host/testcomputer.adilhindistan.com
Target Name: host/testcomputer.adilhindistan.com@adilhindistan.com
Error Text:
File: 9
Line: f09
Error Data is in record data.
DOMAIN CONTROLLER:
Log Name: System
Source: Microsoft-Windows-Kerberos-Key-Distribution-Center
Date: 10/7/2013 3:59:14 PM
Event ID: 11
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: mydc.adilhindistan.com
Description:
The KDC encountered duplicate names while processing a Kerberos authentication request. The duplicate name is host/testcomputer.adilhindistan.com (of type DS_SERVICE_PRINCIPAL_NAME). This may result in authentication failures or downgrades to NTLM. In order to prevent this from occuring remove the duplicate entries for host/testcomputer.adilhindistan.com in Active Directory.
setspn.exe -X -P
Looked at results, yet the computername I was concerned was not listed. By the way, there is a detailed Microsoft article on SPN and setspn.exe usage here.
setspn.exe -Q HOST/testcomputer
Checking domain DC=adilhindistan,DC=com
CN=testcomputer,OU=Workstations,DC=adilhindistan,DC=com
TERMSRV/testcomputer.adilhindistan.com
WSMAN/testcomputer.adilhindistan.com
RestrictedKrbHost/testcomputer.adilhindistan.com
HOST/testcomputer.adilhindistan.com
TERMSRV/testcomputer
WSMAN/testcomputer
RestrictedKrbHost/testcomputer
HOST/testcomputer
Existing SPN found!
That showed me the current SPN and it looked right but did not help with detecting the computer that's causing the conflict. This did the trick:
setspn.exe -Q HOST/testcomputer.adilhindistan.com
Checking domain DC=adilhindistan,DC=com
CN=testcomputer1,OU=Workstations,DC=adilhindistan,DC=com
HOST/testcomputer.adilhindistan.com
HOST/testcomputer1
CN=testcomputer,OU=Workstations,DC=adilhindistan,DC=com
TERMSRV/testcomputer.adilhindistan.com
WSMAN/testcomputer.adilhindistan.com
RestrictedKrbHost/testcomputer.adilhindistan.com
HOST/testcomputer.adilhindistan.com
TERMSRV/testcomputer
WSMAN/testcomputer
RestrictedKrbHost/testcomputer
HOST/testcomputer
Existing SPN found!
So, 'testcomputer1' was incorrectly claiming the SPN HOST/testcomputer.adilhindistan.com and causing the issue.
While on the subject here is another link that might help in other relevant cases:
Kerberos Error Code: 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN
No comments:
Post a Comment