SCOM Installer Failure with RC4 Protocol Disabled
SCOM 1801/1807 installer and discovery wizard fails to work until I had to enable RC4 on the DC, SCOM management server, and the SCOM database server. Please remove the RC4 dependency. I had to find this article to figure out that RC4 was my issue. https://nathangau.wordpress.com/2018/06/22/scom-installer-failure-with-rc4-protocol-disabled/
Mihai Sarbulescu commented
SCOM simply uses Win32 API DsCrackNames (https://docs.microsoft.com/en-us/windows/win32/api/ntdsapi/nf-ntdsapi-dscracknamesw) to validate the User Accounts added in the setup. It does not "enforce" any Kerberos encryption cypher. If RC4 is disabled, then AES must be enabled for those User Accounts (msDS-SupportedEncryptionTypes) or the Domain Controller will say that it did not find any matching results (DS_NAME_ERROR_NOT_FOUND) because they don't support the encryption set as it always falls back to RC4 if AES is not enabled for the users.
Tyson Paul commented
This dependency ruined my afternoon as well. In my case the failure appeared during installation of the Reporting component because the user account was a member of the Protected Users Security Group. At least that's what the evidence suggests so far.
Stoyan Chalakov commented
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). ”
It is nowhere indicated that the SCOM 2019 uses an older Kerberos encryption type nor the wizard indicates that. In high secure environments, this leads to confusion as the wizard (GUI) only shows that security account cannot be verified.
In my particular case, the confusion came after reviewing the installation logs.
When you try to verify the accounts in the GUI, you get the error and you open the “OpsMgrSetupWizard.log” the only thing you see is:
[16:33:26]: Always: :Entering Page: AccountsInformationPage
[16:33:46]: Info: :Info:AccountsInformationPage: In OnNextFinalValidationsDoWork to validate account access.
[16:33:46]: Error: :Error:Failed to log in with account DOMAIN\SDKACCOUNT
[16:33:46]: Error: :Error:Failed to log in with account DOMAIN \MSAACCOUNT
The part that helped me find the Blog is logged always 1 Minute later and I found it after I accidentally found the article of Nathan. Gau. So, at the time you are doing live troubleshooting (open the log file at the point, where the accounts cannot be verified) this information is not available in the log. I am not sure if it gets added when you close the wizard or just after 1 Minute, no matter what you do, but in both cases, this is not optimal.
Suggestions for improvement
• Make sure the SCOM 2019 Installer (or installers of the newer SCOM Versions) does not the RC4 encryption algorithm for Keberos tickets, because it is considered insecure for a long time now. (I think for the SCOM 2019 Installer it is already too later, hopefully I am wrong)
• Make sure the additional troubleshooting info:
[16:34:23]: Error: :GetCrackNameResult() DS_NAME_RESULT_ITEM crack failed with error = DS_NAME_ERROR_NOT_FOUND
[16:34:23]: Error: :ValidateEssentialsAdministratorAccount() failed to crack NT4 format.
[16:34:23]: Info: :ValidateEssentialsAdministratorAccount() Try to crack account with directory searcher.
Is logged at the time when the Account check is done in the UI, otherwise it is not easily found during live troubleshooting.
We should move away from older vulnerable protocols the same way our customers are moving away from them and have no dependencies on these older protocols at the least.
Scott Brown commented
This is a critical issue, and should be addressed with the installer. Microsoft has been telling customers to disable RC4 since 2013, yet neither the 2016 or 2019 versions of SCOM will properly install if it is disabled.
The cause was the the service accounts for action, sdk, reader, and writer had an attribute called msDS-SupportedEncryptionTypes which was set to 0 or non-set. This would cause it to default to RC4. The fix is setting the attribute to 24 to explicitly set it to use AES. References: https://blogs.technet.microsoft.com/runcmd/the-rc4-removal-files-part-1-whats-in-an-error-message/ https://blogs.technet.microsoft.com/runcmd/the-rc4-removal-files-part-2-in-aes-we-trust/ https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/6cfc7b50-11ed-4b4d-846d-6f08f0812919
Please remove RC4 dependency. It should be able use whatever is the highest available encryption.