Operations Manager 2012 R2 Agent on Domain Controllers cannot report to Management Server
One of my customers is working on a project to monitor all Active Directory domain controllers using System Center 2012 R2 Operations Manager. He uses push installation to deploy Operations Manager 2012 R2 agent to all domain controllers. The agent installation is completed successfully, but the agent stays in "Installation in Progress" under Pending Management. I am able to reproduce the problem in my testing environment. Here is what it looks like.
Event ID 20071 and 21016 are logged on the domain controller, complaining that it cannot communicate to the management server.
Log Name: Operations Manager
Source: OpsMgr Connector
Date: 5/2/2015 2:33:14 PM
Event ID: 20071
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: SG1DC02.contoso.azure
Description:
The OpsMgr Connector connected to OM12R2DEV02.contoso.azure, but the connection was closed immediately without authentication taking place. The most likely cause of this error is a failure to authenticate either this agent or the server . Check the event log on the server and on the agent for events which indicate a failure to authenticate.
Log Name: Operations Manager
Source: OpsMgr Connector
Date: 5/2/2015 2:33:19 PM
Event ID: 21016
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: SG1DC02.contoso.azure
Description:
OpsMgr was unable to set up a communications channel to OM12R2DEV02.contoso.azure and there are no failover hosts. Communication will resume when OM12R2DEV02.contoso.azure is available and communication from this computer is allowed.
Since the management server is actually in the same domain as the domain controller, it doesn't make sense that Kerberos authentication could fail. Checking the Security Event Log on the management server reveals the problem: the domain controller "has not been granted the requested logon type at this machine."
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 5/2/2015 2:33:19 PM
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: OM12R2DEV02.contoso.azure
Description:
An account failed to log on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: SG1DC02$
Account Domain: CONTOSO.AZURE
Failure Information:
Failure Reason: The user has not been granted the requested logon type at this machine.
Status: 0xC000015B
Sub Status: 0x0
Process Information:
Caller Process ID: 0x0
Caller Process Name: -
Network Information:
Workstation Name: -
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).
It turns out that the customer has a domain group policy similar as below, which only grants Administrators and Domain Computers group with the user right "Access this computer from the network". Unfortunately, Domain Controllers are not members of Domain Computers group. And it causes the problem you see above.
The solution is simple: Add Domain Controllers group into local administrators group on each Management Servers. The customer will also discuss with his security team if the domain group policy should be modified to include Domain Controllers group in "Access this computer from network".
By the way, here is the default setting of "Access this computer from the network" policy.
