Just set up a new WS2012 Enterprise CA. Server Manager run on the new CA works normally against local and remote WS2012 servers. But when I add the server to other servers' Server Manager, "All Servers" displays "Kerberos security error" and this event is logged:
Log Name: Microsoft-Windows-ServerManager-MultiMachine/Operational Source: Microsoft-Windows-ServerManager-MultiMachine Date: 7/27/2015 9:34:09 AM Event ID: 216 Task Category: Node access. Level: Error Keywords: User: DOMAIN\Username Computer: LOCALCOMPUTER.DOMAIN.local Description: Invoke method error. Server: REMOTECOMPUTER.DOMAIN.local, Namespace: root\microsoft\windows\servermanager, Class: MSFT_ServerManagerTasks, Method: GetServerInventory, Error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains. After checking for the above issues, try the following: -Check the Event Viewer for events related to authentication. -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport. Note that computers in the TrustedHosts list might not be authenticated. -For more information about WinRM configuration, run the following command: winrm help config.
All servers are in the same domain, I'm logged on as a Domain Admin, no SPNs have been manually added or deleted. Also tried with the firewall (just Windows firewall) turned off. I don't find any auth errors in the Security log on either the problem machine or the remote machines.
SETSPN -L run on the problem server returns this, which looks normal to me:
C:\Windows\system32>SETSPN -L COMPUTERNAME
Registered ServicePrincipalNames for CN=COMPUTERNAME,OU=OUName,OU=OUName,DC=DOMAIN,DC=local:
WSMAN/COMPUTERNAME.DOMAIN.local
TERMSRV/COMPUTERNAME.DOMAIN.local
RestrictedKrbHost/COMPUTERNAME.DOMAIN.local
HOST/COMPUTERNAME.DOMAIN.local
WSMAN/COMPUTERNAME
TERMSRV/COMPUTERNAME
RestrictedKrbHost/COMPUTERNAME
HOST/COMPUTERNAME
Ideas?
[edit]
Found this relevant Event in the System log of the remote Server Manager trying to connect to the problem server:
Log Name: System Source: Microsoft-Windows-Security-Kerberos Date: 7/27/2015 2:33:36 PM Event ID: 4 Task Category: None Level: Error Keywords: Classic User: N/A Computer: COMPUTER.DOMAIN.local Description: The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server REMOTECOMPUTER$. The target name used was HTTP/REMOTECOMPUTER.DOMAIN.local. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMAIN.LOCAL) is different from the client domain (DOMAIN.LOCAL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server....but I don't know what I need to do about it.
There are no duplicate DNS entries, no duplicate computer entries in AD, no user accounts with the same name, no clustering, all users and computers are in the same domain and forest.
- Edited by JRVCr Monday, July 27, 2015 8:22 PM
Other recent topics
