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.