System Center 2019 Operations Manager (SCOM) installation routine and the unsecure Kerberos encryption
This article is intended to help all, who are installing the newest version of System Center Operations Manager (SCOM) – 2019 (this applies also to SCOM 2016) and cannot proceed with the installation wizard, because the service account cannot be validated.
There is already a blog post on the topic regarding SCOM 2016, written by Nathan Gau. The reason this behavior is being described all over again is because users, need a reminder that the problem exists also in SCOM 2019 and also ease the troubleshooting for all of them by providing some additional log output. This should make it easier for all affected by the issue to find the information in the Internet.
One other consideration would be that with the increased security requirements in the IT sphere, this behaviour will be experienced much more often than before.
The problem
While installing SCOM, when you get to point, where you need to specify your service accounts, the following error is displayed, and you are unable to proceed with installation (The option “Next” in the installation wizard is greyed out):
“One or more accounts provided could not be validated. Please provide valid user names and passwords.”
Challenges
Troubleshooting
Before doing the usual review of the installation logs, if you experience the same behavior, make sure that the account names and their passwords are entered properly. Usually passwords are copied and pasted it in the “Password” field and this can lead to an additional blank character being added to the password. So, please make sure you have entered the passwords also manually.
You need to also make sure that the passwords have no special characters, which can somehow lead to verification problems.
As a next step you can do a standard troubleshooting– reviewing the installation logs and in particular the OpsMgrSetupWizard.log. All the logs are found under %LocalAppData%\SCOM\Log or by default c:\users\UserName>\Appdata\Local\SCOM\Logs where <UserName> is the name of the user, who does the installation.
The confusion can come after reviewing the installation logs. When you try to verify the accounts in the GUI, you get the error and if you open the “OpsMgrSetupWizard.log” the only thing you see is:
[16:41:07]: Always: :Entering Page: AccountsInformationPage
[16:44:29]: Info: :Info:AccountsInformationPage: In OnNextFinalValidationsDoWork to validate account access.
[16:44:29]: Error: :Error:Failed to log in with account DOMAIN\MSA_ACCOUNT
[16:44:29]: Error: :Error:Failed to log in with account DOMAIN\SDK_ACCOUNT
*[16:44:29]: Info: :Info:AccountsInformationPage: Async account validation thread returned to UI thread.
*
This part, which is mentioned in referenced blog post by Nathan Gau is usually logged always around a minute later. So, at the time you are doing troubleshooting this info is not available in the log. It is not clear if it gets added when you close the wizard or just after some time, no matter what you do, but in both cases, this is not helpful. This are the install records that you find a while after getting the error:
[17:20:17]: Error: :Error:Failed to log in with account DOMAIN\SDK_ACCOUNT
[17:20:17]: Info: :Info:AccountsInformationPage: Async account validation thread returned to UI thread.
[17:24:28]: Error: :UserName format is incorrect. It should contain one and only one \as a separator character.
[17:25:43]: Info: :Info:AccountsInformationPage: In OnNextFinalValidationsDoWork to validate account access.
[17:25:43]: Error: :GetCrackNameResult() DS_NAME_RESULT_ITEM crack failed with error = DS_NAME_ERROR_NOT_FOUND
[17:25:43]: Error: :ValidateEssentialsAdministratorAccount() failed to crack NT4 format.
[17:25:43]: Info: :ValidateEssentialsAdministratorAccount() Try to crack account with directory searcher.
[17:25:43]: Error: :Error:Failed to log in with account DOMAIN\MSA_ACCOUNT
[17:25:43]: Error: :GetCrackNameResult() DS_NAME_RESULT_ITEM crack failed with error = DS_NAME_ERROR_NOT_FOUND
[17:25:43]: Error: :ValidateEssentialsAdministratorAccount() failed to crack NT4 format.
*[17:25:43]: Info: :ValidateEssentialsAdministratorAccount() Try to crack account with directory searcher.
*
The problem is that users usually open the logs right away after the error is shown in the console, so the entries above are still not present.
-
Security
The other challenge in this case is the Security aspect. Paying attention to Security related recommendations or implementing Security best practices is nonnegotiable in the modern IT. So, when talking about Active Directory authentication and the Kerberos protocol in particular, all Microsoft recommendations should be followed.
The things is, Microsoft states that RC4 Kerberos encryption is not that secure and even recommends disabling it when it comes to security hardening of domain members:
From KB 4492348
“RC4 encryption is considered less secure than the newer encryption types, AES128-CTS-HMAC-SHA1-96 and AES256-CTS-HMAC-SHA1-96. Security guides such as the Windows 10 Security Technical Implementation Guide provide instructions for improving the security of a computer by configuring it to use only AES128 and/or AES256 encryption (see Kerberos encryption types must be configured to prevent the use of DES and RC4 encryption suites).”
-
Information or Warning during the installation process
It is nowhere indicated that the SCOM 2019 uses an older (or unsecure) Kerberos encryption type. The wizard also doesn’t show any Information or Warnings. In high secure environments, this leads to confusion as the wizard (GUI) only shows that that the accounts cannot be verified. I would love to see some kind of notification about this.
Solution
Workaround
Currently there isn’t a “clean” solution to this problem, only a workaround, but Microsoft is already aware of that and hopefully it will be fixed soon enough. Until then, the way to solve this would be temporary enabling RC4 for Kerberos until the last management server is installed. How you can do that? There are different ways – using a registry key:
Registry Hive: HKEY_LOCAL_MACHINE
Registry Path: \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\
Value Name: SupportedEncryptionTypes
or a Group Policy setting:
Network security: Configure encryption types allowed for Kerberos
/en-us/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos
There is one more thing you need to be aware of. Depending on configuration of your environment, you may have to set this policy at the domain level to apply to the OU, where your SCOM server are located or, you may have to set this policy at the organizational unit (OU) of the domain controllers in your domain.
-
Solution
The SCOM product group is aware of the behavior and the impact it could have on the installation process. The reason they are aware of that is that approximately 1 year ago this has been reported on the SCOM User Voice page, which is being actively monitored by Microsoft and contains all types of feedback (ideas, bug fix requests, feature requests), related to SCOM:
SCOM Installer Failure with RC4 Protocol Disabled
The great thing about this particular request is that its status has recently (on the 10.03.2020) been changed to “Under Review”, so we will expect this to reviewed by the SCOM Product Group and hopefully fixed as soon as possible. If you want to speed up the process just go to the SCOM User Voice and upvote this request.
Conclusion
A few important takeaways:
- First things first – keep your environment secure and disable RC4 for Kerberos
- If you encounter this particular issue and need to enable RC4 encryption in your environment, do this only temporary, during the setup process of your servers and disable it afterwards.
- If you want to help shaping the product (Operations Manager) or speed up the implementation of a specific request, please post it on the SCOM User Voice site and/or upvote the existing requests.
- Make sure your do a thorough research on the Internet, using the related information from the installation logs.
References
SCOM Installer Failure with RC4 Protocol Disabled
https://nathangau.wordpress.com/2018/06/22/scom-installer-failure-with-rc4-protocol-disabled/
SCOM Installer Failure with RC4 Protocol Disabled
AD DS: Security: Kerberos "Unsupported etype" error when accessing a resource in a trusted domain
See also
Tough Questions Answered: Can I disable RC4 Etype for Kerberos on Windows 10?