Make SCOM all functionalities working in a full Kerberos environment
Make SCOM all functionnalities working in a full Kerberos environment
We have implemented NTML restriction in our AD envionment because of a prioritized recommendation in the Azure AD Security assessment : Place privileged users in the Protected Users Group. The protected users groups provides additional security, because users can only authenticate using Kerberos (everything else is blocked) and hardenning is applied to the Kerberos authentication used by enforcing AES encryption.
BUT placing privileged users in Protected Users Group or implementing authentication policy to restrict usage of NTLM on admin accounts make SCOM loosing some functionalities.
Approving installation on agent in pending required update after having applied KB4601269 on Management Servers is failing with an access denied message. I need here to add that the SCOM environment is dedicated to AD servers so given credentials on the task are Domain Admin credentials.
This error generate an error event 10607, source Health Service Modules in the Operations Manager Event Log:
The Operations Manager Server cannot process the install/uninstall request for computer <Computer Name> due to failure of operating system version verification.
Operation: Agent Install
Install account: <Admin Account>
Error Code: 80070005
Error Description: Access is denied.
And in the same time, an event 4625 is raised with status "0xc000006e" for the account used in the deployment task on the domain controller that has been used for authentication. It indicates that the account is trying a network logon (type 3) with authentication Package NTLM, authentication information is valid but some user account restriction has prevented successful authentication.
The Event description adds that ‘NTLM authentication failed because access control restrictions are required.’ and it gives the name of our Authentication Policy we have implmented in the AD environment.
NTLM usage block is a known consequence of the Authentication Polices configuration and reverting the Authentication Policy from ‘Enforce Policy Restriction’ to ‘Only audit policy restriction’ for the account use in the deployment task is solving the issue. In audit mode, we always see event in AD for NTLM usage but NTLM authentication stay allowed.
I was thinking that SCOM uses whatever mechanism is available to open a RPC connection at start the installation and then open an SMB connection to copy updates but this shows that without NTLM V2, (NTLMV1 was disabled since year now in our environment), the deployment cannot be successful.
A Microsoft case has been open for this specified issue and analysing network traces confirms that
1. The deployement start by creating an RPC connection and this connection is well using Kerberos authentication.
2. Then it uses an SMB session by using IP address and since IP address alway use NTLM, kerberos is not used at this step.
At this step, Microsoft support indicates that no configuration can be done in SCOM as it is by design, however, we can configure the operating System to use Kerberos even for IP adresses by following this article: https://docs.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip
After applying the change, new traces have been analysed by Microsoft and the SMB session is well initiated using Kerberos ! However, we can see later in the trace that we have another RPC session, starts with authentication using Kerberos, but later in the same session, it reverts to NTLM, even though the session was successfully running on Kerberos.
So it appears that in all cases, SCOM will always use NTLM authentication (because using IP adresses) and this doesn't follow the AD Security assessment recommendation for privileged users.
In order to be able to deploy agent update, we need to manage an exception in our Domain Admin account to allow NTLM authentication, even temporarly, or to think about an other way to deploy and also loose the SCOM functionality.
I think that the majority of Microsoft customers have disabled NTLM and kept NTLM V2 and maybe we are the first to implement NTLM restriction but the recommendations of the Azure AD security assessment are clear, it is necessary to force privileged accounts to use Kerberos.
SCOM Product used for AD monitoring is using privileged accounts and should follow the Azure AD security recommendations.
Tristan B commented
I forget to tell that I'm actually working with SCOM 2019 UR2.