SentinelOne Can’t Connect from Server 2012R2

I recently deployed SentinelOne on a couple Server 2012R2 machines. On the one where I had run Nartec’s IIS Crypto tool to set Best Practices cipher suites, SentinelOne was not able to connect to the management host.

Too Long, Didn’t Read <TL;DR>

The solution was to open IIS Crypto, enable these two cipher suites, and reboot:

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Nartec’s IIS Crypto omits these two ciphers from its Best Practices list. SSL Labs’ client tester says they’re safe. I have no idea who’s right.

Troubleshooting

Troubleshooting this issue was compounded by two SentinelOne issues:

1. The NFR server, to which my in-house 2012R2 test machine connects successfully, has different cipher requirements than the production server. So getting the production machine ciphers to match the test machine ciphers was not enough.

2. SentinelOne supplies a CipherSuite Check script, written in PowerShell, that is supposed to identify which ciphers are enabled on the machine and compare them to (a fixed list of) which ciphers are supported on their servers. Version 2.5 of the script kept telling me that four ciphers enabled on the machine were also supported by their servers, but Nartec IIS Crypto told me that those four were not enabled.

Script Issue and Enhancement

Digging into the CipherSuite Check script, I discovered that it pulls the machine cipher suites from this registry value:

HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002\Functions

By default, that key lists all the ciphers supported by the machine and the order in which they should be used. It is no doubt possible to limit and re-order ciphers by manipulating this registry value. Nartec’s IIS Crypto, however, takes the more elegant approach of overriding that value with the value that would be set by Group Policy (see the bottom of this page):

HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\Functions

Using this value allows the system value to remain untouched. However, the SentinelOne script doesn’t take this “group policy” override into account, so it reports cipher suites as active that IIS Crypto has in fact disabled.

Here is a script modification that will read the value under Policies if it is present, then if not, fall back to the value under CurrentControlSet:

# Check for system cipher suites under the Policies key first, then the default CurrentControlSet key.
[Boolean]$GroupPolicyValueFound = $false
$Path = "HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002"
if (Test-Path -Path $Path) {
  $keyValue = (Get-ItemProperty -Path $Path -Name Functions -ErrorAction SilentlyContinue).Functions
  if ($keyValue) { # Functions value is not null and not empty
    $GroupPolicyValueFound = $true 
    # This is a comma-separated REG_SZ value. Convert the commas to line breaks to match REG_MULTI_SZ output
    $keyValue = $keyValue -replace ",","`r`n"
    Write-Host "Retrieved system cipher suites from Group Policy registry key, which overrides default registry key."
  } 
}
if (-not $GroupPolicyValueFound) {
  $keyValue = (Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002 -Name Functions).Functions
  Write-Host "Retrieved system cipher suites from default CurrentControlSet registry location."
  # This value is a REG_MULTI_SZ, so it already has one cipher suite per line--not need to add line breaks.
}