Add a reference to ConfigureCryptoDefaults.ps1 script for E19 in the TLS section of HealthChecker

[gabymuntean]

I have recently got an issue with incorrect TLS configuration set by Nartac IISCrypto tool. I was not aware of the ConfigureCryptoDefaults.ps1 script (that is available with E19 in the $ExInstall\Bin folder) which can easily be used to setup a more secure or more relaxed cipher suites list and configure correctly the other TLS settings, as we recommend.

[dpaulson45]

@gabymuntean what is the ask here? To throw a warning if E19 isn't configured any longer out of the box from setup?

[gabymuntean]

Hi @dpaulson45, AFAIK E19 comes out of the box with the TLS and Cipher Suite settings, as we would run the ".\ConfigureCryptoDefaults.ps1 -Mode Secure". I suggest adding a note saying that starting with E19, we have the ConfigureCryptoDefaults.ps1 script available, which can be used to easily configure TLS and cipher suites as we recommend. Adding the output of the script in both modes.

Thank you, Gabriel

ConfigureCryptoDefaults_Transition.txt ConfigureCryptoDefaults_Secure.txt

[dpaulson45]

Not sure if a call out stating this as a note every time would be beneficial, even against a 2019 Exchange Server. Some customers might have a reason to not disable TLS 1.0/1.1 for home grown applications and they needed to remove what we set to be the most secure for a time.

[gabymuntean]

Using ConfigureCryptoDefaults.ps1 script with the Transition parameter, keeps TLS 1.0 and 1.1 active, as well as enabling 15 ciphers (in comparing with 7 ciphers and only TLS 1.2 active in Secure mode). Not many our support colleagues are aware of this script, hence I thought it worth mentioning it.

Btw, do you think it worth checking other registry path under HKLM\System\CurrentControlSet\Control\Lsa\, beside LmCompatibilityLevel for NTLM auth? In my case, customer had under HKLM\System\CurrentControlSet\Control\Lsa\MSV1_0 the BackConnectionHostName configured, which caused issues with the client connectivity and also generated TLS replication errors for the Exchange servers.

[dpaulson45]

The problem is it is only in Exchange 2019. This might be something better to have on the wiki. Not sure what value it will have in Health Checker here.

Yes, we can include other registry keys related to auth. I just haven't run into any other ones to know what to put. Please create a new issue for that request that includes the location of the key, the default value if it doesn't exist ( similar to LmCompatibilityLevel where default value is 3 if not set ), documentation of the key, and if we want to just display the value or if there were a configuration issue that we would need to flag.

[dpaulson45]

@gabymuntean need to know what the other keys are related to TLS that we might want to include that we don't yet already.

I don't believe it is wise to include a reference to the script regarding how to configure TLS, just because of the mixed environments deal. We don't even run the ConfigureCryptoDefault.ps1 between CU build upgrades because of it messing with TLS that might have been there for a reason within the customer environment. Then depending on which CU they have installed, will depend on what all gets done and changed. So, if there was a mixed version of CUs, that could have different results which will not have the desired outcome.

[lusassl-msft]

@gabymuntean we discussed this internally and decided that we don’t want to reference the script yet. We’ve refactored the TLS documentation and replaced the more complex registry configuration steps with copy and paste PowerShell commands. The script itself was designed to run during setup and was not intended to run afterwards manually by customers. I will closely monitor the situation of TLS-related cases and we can re-open the discussion if we see a situation in which we should provide something for our customers.