Share via

SCOM Installer Failure with RC4 Protocol Disabled

  • Article

Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.

I need to start this by tipping my hat to a couple colleagues, Louise Willis for pointing me to Ryan Christman, who dealt with the same issue about a month prior and was able to save me a support call.

To set the stage, we were doing a SCOM 2016 install on a hardened Server 2016 OS with SQL 2016 running in the background.  I want to emphasize that the OS was hardened, so those of you doing SCOM installs in a higher security environment will likely face this issue. There’s not much out there on the subject. The install failed at the account validation section with the UI stating that the run as accounts for all four SCOM accounts could not be validated. Switching to local system also failed for what it was worth. The following errors were prevalent in the OpsMgrSetupWizard log:

Error:     :GetCrackNameResult() DS_NAME_RESULT_ITEM crack failed with error = DS_NAME_ERROR_NOT_FOUND

Error:     :ValidateEssentialsAdministratorAccount() failed to crack NT4 format.

Info:      :ValidateEssentialsAdministratorAccount() Try to crack account with directory searcher.

Info:      :No need to validate Data Reader and Data Writer are the same as the Management Group.

Switching to the SCOM 2012 R2 media produced the same results. There really wasn’t much in terms of public documentation on the issue. I was aware of some issues with the SCOM installer failing with TLS shut off, but this didn’t appear to be the issue here, as enabling TLS did not allow us to proceed. Perhaps that was due to a tatooed registry GPO or something like that, but the culprit ultimately ended up being RC4.

The registry key in question is HLKM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\

The Dword Value is “SupportedEncryptionTypes” which needs to be set to a decimal value of 2147483644

Via GPO, this can be addressed by adding RC 4 to the following GPO setting:

Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options >> "Network security: Configure encryption types allowed for Kerberos"  If RC 4 is missing here and this setting is enabled, you will want to change it.

There are a couple things worth noting about this. This appears to only affect the install. You can back this out post install. It’s an issue with the installer itself that prevents account validation.

As well, this is a fix where two end points may need to be addressed. In speaking with Ryan, they were dealing with a hardened Domain Controller effectively blocking it. On our end, it was the SCOM 2016 server itself that had the offending policy set. If you come across this, you may need to address the domain controller servicing the authentication requests as well.

Comments

  • Anonymous
    July 05, 2018
    Hi NathanMy question is a bit OT, but do you know a source that describes how to place a SCOM management group into the Microsoft Tier Modell (ESAE).One of my customers is implementing ESAE, and I am not sure if to put SCOM incl. DB into tier 0, or if it is better to install a dedicated Management Group for tier 0 and one for tier 1.Thanks in advanceMichael
    • Anonymous
      July 18, 2018
      I've started a series on this. You can find it here:https://blogs.technet.microsoft.com/nathangau/2018/07/17/securing-scom-in-a-privilege-tiered-access-model-part-1/Reach out on linked in if you have more questions.
  • Anonymous
    July 11, 2018
    I just recently found this out the hard way. Premier support suggests to turn on "The other domain supports Kerberos AES Encryption" in domains and trusts to allow AES encryption to work for user accounts. Below is verabatim from them. I have had to put this on hold for now, but wanted to share to see what you think.  For configuring AES encryption we need to follow below mentioned steps:1. We need to configure the group policy “Network security: Configure encryption types allowed for Kerberos option” for AES encryption protocol on server where we are installing SCOM Agent and SCOM Management Server where SCOM agent is reporting.2. After configuring group policy, we need to reboot the SCOM agent server and SCOM Management server.3. For AES encryption to work, we need to raise the Active Directory domain and forest functional level to minimum “windows server 2008”. After raising domain/forest functional level we need to restart KDC service on all domain controllers part of forest. 4. We will have to enable option “The other domain supports Kerberos AES Encryption” for user accounts/computer accounts used for communication between SCOM Agent and Parent Management Server. In our case it will “Local System” account or domain account used as Agent Action account for servers. For computer accounts we will have to reset secure channel on the SCOM Agent server using below steps: Install windows feature “Remote Server Administration Tools” on the SCOM Agent server and then run command “netdom reset /d:yourdomainname SCOMAgentServerName” in Administrator windows powershell.For windows domain accounts, go to domain controller and then go to DSA.MSC and search for the windows domain account and open its properties. After opening properties, go to “Account” section and check “This account supports Kerberos AES 128 bit/256 bit encryption” for the user account. After doing this change, user account will support AES encryption. 5. For parent/child domain scenario we will have to enable option “This domain supports AES encryption” through Active Directory domain and trusts. Please find below link for the same: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd145414(v=ws.11)
    • Anonymous
      July 18, 2018
      I may be misunderstanding what you're getting at, but this particular issue I've discussed affects the SCOM installer itself, not the agents, or are you suggesting doing this with the account that is doing the SCOM install to get around this issue? That might be an interesting work around worth testing. Personally, I hope they simply fix the installer. This is going to be a pain point for a lot of customers, and I suspect SCOM won't be the only product affected. I doubt that very few product installers have been updated in years.