Click on the Category button to get more articles regarding that product.
Here you will find all steps to protect from CVE-2024-21410 Exchange Leak. This sample handels and standlaone Exchange 2016 running on Server 2016. The customer has no DAG (Cluster),
He is NOT in Hybrid Mode Classic or Modern (He has no CLOUD connection), all latest 02/2024 Windows Updates are installed, the latest CU for Exchnage 2016 is installed.
You will find all steps to enable EP Extended Protection on your Exchange Server IIS.
For the current Exchange NTLM Leaks CVE-2024-21410
For older Leaks: CVE-2022-24516,CVE-2022-21979,CVE-2022-21980,CVE-2022-24477,CVE-2022-30134
This is HOW it looks in Webserver IIS which exchngne runs on.
|
|
|
Here is what to do:
- Check and fix that the OAUTH Certificate is not expired (Renew if expired) > See end of blog Problems we have seen with customers:
-
Check and fix if the internal 5 year self signed “Exchange Server” is not Expired (Renew if expired) > See end of blog Problems we have seen with customers:
If above is VALID/Both are NON Expired you can JUMP Direct to section:
Enable Extended Protection for Exchange 2016 (on-premise, no hybrid, no DAG) sample all steps explained
- FIX: Turn OFF SSLOffloading on outlookanywhere VDIR
- FIX: Change .NET SchUseStrongCrypto for NETv4 in Registry
- Enable Enhanced Protection with the Script ExchangeExtendedProtectionManagement.ps1 (Which also checks all above)
https://microsoft.github.io/CSS-Exchange/Security/ExchangeExtendedProtectionManagement/
Powershell: ExchangeExtendedProtectionManagement.ps1 (EP)
https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/
Powershell: HealthChecker.ps1
IMPORTANT: Please READ outr other BLOG if you have any keypoints below in red:
|
There are things you have to stop right NOW and read other things first: If you have no Expensive Load Balancer, you have no DAG-Cluster, You have no 2013 Exchange and Public Folder, you are NOT in Cloud Hybrid Mode of any kind (No M365/EXO/CLOUD) than skip this part.
For all other please better READ:
|
|
Enable Extended Protection for Exchange 2016 (on-premise, no hybrid, no DAG) sample all steps explained
To clarify who can proceed and enable Enhanced Protection:
- You do NOT have Hybrid Mode (On-premises <>M365/EXO/CLOUD mix)
- You do NOT have Load Balancer lik Big/F5/KEMP
- You installed all 02/2024 Windows Update and the latest CU for Exchange
- You did a check of your exchange with HealthChecker.ps1
- You downloaded ExchangeExtendedProtectionManagement.ps1
You understood and have read above points. This is not a TRIAL and ERROR update. (It will check and help a lot but still high risk if done wrong)
Sample we have done > SRV OS 2016, Exchange 2016 latest CU, latest 02/2024 Windows Updates installed > first RUN:
ExchangeExtendedProtectionManagement.ps1
|
OS2016, Exchange 2016 latest CU first RUN: ExchangeExtendedProtectionManagement.ps1 |
|
[02/22/2024 15:11:22] : Calling: Invoke-ExtendedProtectionTlsPrerequisitesCheck [02/22/2024 15:11:22] : Working on Server * SERVER12 [02/22/2024 15:11:22] : Added new grouped result because of server * SERVER12 [02/22/2024 15:11:22] : SchUseStrongCrypto doesn’t match the expected configuration [02/22/2024 15:11:22] : SystemDefaultTlsVersions doesn’t match the expected configuration [02/22/2024 15:11:22] : Calling: Invoke-ExtendedProtectionTlsPrerequisitesCheck [02/22/2024 15:11:22] : Working on Server * SERVER12 [02/22/2024 15:11:22] : Added new grouped result because of server * SERVER12 [02/22/2024 15:11:22] : SchUseStrongCrypto doesn’t match the expected configuration [02/22/2024 15:11:22] : SystemDefaultTlsVersions doesn’t match the expected configuration [02/22/2024 15:11:22] : Test Failed: SchUseStrongCrypto is not configured as expected [02/22/2024 15:11:22] : System affected: * SERVER12 [02/22/2024 15:11:22] : Action required: Configure SchUseStrongCrypto for NETv4 as described here: https://aka.ms/ExchangeEPDoc [02/22/2024 15:11:22] : [02/22/2024 15:11:22] : Test Failed: SystemDefaultTlsVersions is not configured as expected [02/22/2024 15:11:22] : System affected: * SERVER12 [02/22/2024 15:11:22] : Action required: Configure SystemDefaultTlsVersions for NETv4 as described here: https://aka.ms/ExchangeEPDoc [02/22/2024 15:11:22] : [02/22/2024 15:11:22] : WARNING: Failed to pass the TLS prerequisites for the servers you are trying to enable Extended Protection. Unable to continue. [02/22/2024 15:11:22] : [02/22/2024 15:11:22] : Servers trying to enable: * SERVER12 [02/22/2024 15:11:22] : Write-Progress Activity: ‘Prerequisites Check’ Completed: False CurrentOperation: ” Id: 1 ParentId: -1 PercentComplete: 0 SecondsRemaining: -1 SourceId: 0 Status: ‘Running Get-OutlookAnywhere’ [02/22/2024 15:11:22] : Write-Progress Activity: ‘Collecting Get-OutlookAnywhere Results’ Completed: False CurrentOperation: ” Id: 0 ParentId: 1 PercentComplete: 0 SecondsRemaining: -1 SourceId: 0 Status: ” [02/22/2024 15:11:24] : Write-Progress Activity: ‘Collecting Get-OutlookAnywhere Results’ Completed: False CurrentOperation: ” Id: 0 ParentId: 1 PercentComplete: 100 SecondsRemaining: -1 SourceId: 0 Status: ” [02/22/2024 15:11:24] : Write-Progress Activity: ‘Prerequisites Check’ Completed: False CurrentOperation: ” Id: 1 ParentId: -1 PercentComplete: 100 SecondsRemaining: -1 SourceId: 0 Status: ‘Checking RPC FE SSLOffloading – * SERVER12’ [02/22/2024 15:11:24] : ‘* SERVER12\RPC (Default Web Site)’ has SSLOffloading set to true. Therefore, we can not configure Extended Protection. [02/22/2024 15:11:24] : WARNING: ‘* SERVER12\RPC (Default Web Site)’ has SSLOffloading set to true. Therefore, we can not configure Extended Protection. [02/22/2024 15:11:24] : Write-Progress Activity: ‘Prerequisites Check’ Completed: True CurrentOperation: ” Id: 1 ParentId: -1 PercentComplete: 100 SecondsRemaining: -1 SourceId: 0 Status: ‘Checking RPC FE SSLOffloading – * SERVER12’ [02/22/2024 15:11:24] : WARNING: Please address the following server regarding RPC (Default Web Site) and SSL Offloading: * SERVER12 [02/22/2024 15:11:24] : WARNING: The following cmdlet should be run against each of the servers: Set-OutlookAnywhere ‘SERVERNAME\RPC (Default Web Site)’ -SSLOffloading $false -InternalClientsRequireSsl $true -ExternalClientsRequireSsl $true [02/22/2024 15:11:24] : All servers that we are trying to currently configure for Extended Protection have RPC (Default Web Site) set to false for SSLOffloading. [02/22/2024 15:11:24] : WARNING: Unable to continue due to the required prerequisites to enable Extended Protection in the environment. Please address the above issues. |
Changes to be done before it can run we had to do on SRV 2016 and Exchange 2016 latest CU
- Turn OFF SSLOffloading on outlookanywhere VDIR
- Change .NET SchUseStrongCrypto for NETv4
Set-OutlookAnywhere -Identity “EXCH1\rpc (Default Web Site)” -SSLOffloading $false -InternalClientsRequireSsl $true -ExternalClientsRequireSsl $true
get-outlookanywhere | fl
VORHER/BEFORE:
SSLOffloading : True
ExternalClientsRequireSsl : True
InternalClientsRequireSsl : True
NACHER/AFTER:
SSLOffloading : False
ExternalClientsRequireSsl : True
InternalClientsRequireSsl : True
Our PS:
Set-OutlookAnywhere -Identity ” SERVER12\Rpc (Default Web Site)” -SSLOffloading $false -InternalClientsRequireSsl $true -ExternalClientsRequireSsl $true
RETRY OS2016, Exchange 2016 latest CU Second run: ExchangeExtendedProtectionManagement.ps1
The Outlook Anywhere alert is away after we changed it: All servers that we are trying to currently configure for Extended Protection have RPC (Default Web Site) set to false for SSLOffloading.
|
ExchangeExtendedProtectionManagement.ps1 Other alerts because of TLS SchUseStrongCrypto regarding .NET 4.X |
|
Test Failed: SchUseStrongCrypto is not configured as expected System affected: SERVER12 Action required: Configure SchUseStrongCrypto for NETv4 as described here: https://aka.ms/ExchangeEPDoc
Test Failed: SystemDefaultTlsVersions is not configured as expected System affected: SERVER12 Action required: Configure SystemDefaultTlsVersions for NETv4 as described here: https://aka.ms/ExchangeEPDoc |
|
TLS requirements
|
|
Before enabling Extended Protection, you must ensure that all TLS configurations are consistent across all Exchange servers. For example, if one of the servers uses TLS 1.2, you must ensure that all the servers in the organization are configured using TLS 1.2. Any variation in TLS version use across servers can cause client or server to server connections to fail. In addition to this requirement, the value of SchUseStrongCrypto registry value must be set to a value of 1 across all the Exchange servers within the organization. If this value isn’t explicitly set to 1, the default value of this key can be interpreted as 0 or 1 depending on the .NET version in use by the Exchange Server binaries and there is a chance that you experience connection issues in server to server communication. This can happen, especially if different versions of Exchange Server (for example, Exchange Server 2016 and Exchange Server 2019) are in use. The same applies to the SystemDefaultTlsVersions registry value, which must also be explicitly set to a value of 1. If these registry values aren’t configured as expected, this misconfiguration can cause TLS mismatch in server to server or client to server communication and as a result, could lead to connectivity issues. Refer to this Exchange Server TLS configuration best practices guide to configure the required TLS settings on your Exchange servers. |
2019
2016
We needed those on a OS SRV 2016 and Exchange 2016 with latest CU
|
Enable .NET Framework 4.x Schannel inheritance |
|
Set-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319” -Name “SystemDefaultTlsVersions” -Value 1 -Type DWord Set-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319” -Name “SchUseStrongCrypto” -Value 1 -Type DWord Set-ItemProperty -Path “HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319” -Name “SystemDefaultTlsVersions” -Value 1 -Type DWord Set-ItemProperty -Path “HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319” -Name “SchUseStrongCrypto” -Value 1 -Type DWord |
Framework 3.5 was not done and not neeeded to change on 2016
RETRY OS2016, Exchange 2016 latest CU third run:
ExchangeExtendedProtectionManagement.ps1
Where you run the ExchangeExtendedProtectionManagement.ps1
Check logfile ExchangeExtendedProtectionManagement-20240*****-Debug.log
[02/22/2024 15:49:25] : Configure Extended Protection was successful on the following servers: IMBSRV12
Crosscheck what we have done and not to get it running:
The “HealthChecker.ps1” still shows some erros regarding TLS for 1.0/1.1 but that did not interest the EP
script SO these error will NOT stop you activating EP. Just so you don’t solve those also just for the EP.
Check IIS MMC
Check with OWA
Problems we have seen with customers:
Running ExchangeExtendedProtectionManagement.ps1 we have just seen a case where the OAUTH Certificate was expired.
To run the ExchangeExtendedProtectionManagement.ps1 your OAUTHcertificate has to be valid and also your INTERNAL Self Signed 5 years “Exchange Server” certificate (builtin) has to be non-expired.
EP Run script ELEVATED and check the “OAUTH” and internal “Exchange Certificate”
Here is how to renew the OAUTH cert (Plan 1-2H waiting time because of timezone bug)
Already Expired:
Some tool to catch the moment you have to renew (Because of the time zone difference behaviour)
https://microsoft.github.io/CSS-Exchange/Admin/MonitorExchangeAuthCertificate/
For OAUTH please take care if you are in hybrid mode also here. The change of the OAUTH certificate normaly should be DONE
prior it getting expired. See more info (And why this happens) with time zone difference here: https://www.butsch.ch/post/M365Exchange-Hybrid-OAuth-Testing-command-OAuth-Cert-out-of-sync-4001-IIS-VDIR-OAuth-wrong/
