Er zijn in Augustus 2022 weer enkele belangrijke security updates voor Exchange uitgebracht. Helaas worden deze updates pas volledig effectief wanneer je de zogenaamde Windows Extended Protection toepast.
Voordat je deze kunt toepassen moet Windows Authentication als onderdeel van je Web Server (IIS) geinstalleerd zijn op je Exchange Server.
De zelfstandige updatepakketen (KB5015322 – Exchange 2016 en 2019) (KB5015321 – Exchange 2013) zijn te downloaden via het Microsoft Downloadcentrum:
- Microsoft Exchange Server 2019 CU12 : Download
- Microsoft Exchange Server 2019 CU11 : Download
- Microsoft Exchange Server 2016 CU23 : Download
- Microsoft Exchange Server 2016 CU22 : Download
- Microsoft Exchange Server 2013 CU23 : Download
Met behulp van de onderstaande powershell opdracht, controlleer je je versie nr en kun je bekijken op https://docs.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019 of je nog een ronde CU updates moet uitvoeren vooraf.:
Get-Command Exsetup.exe | ForEach {$_.FileVersionInfo}
Bij het uitvoeren van de update zorgt Microsoft ervoor dat de update elevated wordt gestart, dat dan weer wel…
Vervolgens kun je op de Microsoft – CSS-Exchange github pagina de laatste versie van het ExchangeExtendedProtectionManagement script downloaden. Dit script draai je in een elevated Exchange Management Shell…
Het wordt overigens sterk aanbevolen om voorafgaand aan het uitvoeren van het script om na te lezen of je omgeving wel geschikt is. Meer informatie daarover vind je op deze pagina: https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/
Zo moet je oppassen wanneer je Public Filders gebruikt in een omgeving met Exchange 2013 naast 2016/2019. de Public Folder mailbox moet dan eerst gemigreerd worden naar de 2016/2019 exchange.
Heb je een 2016 of 2019 exchange server kun je het beste eerst naar de laatste CU bijwerken. Let ook op wanneer je software van derden op je exchange draait, voor handtekeningen, emails archiveren of spamscanning.
Bij het uitvoeren wordt er een controle uitgevoerd of aan alle voorwaarden voor installatie wordt voldaan.
In het geval van mijn lab server wordt de eerste prerequisite check niet gehaald.
Test Failed: SchUseStrongCrypto is not configured as expected
System affected: MX01
Action required: Configure SchUseStrongCrypto for NETv4 as described here: https://aka.ms/ExchangeEPDoc
Om te voldoen moet er nog een aanpassing in de TLS instellingen van .NETv4 plaatsvinden. Zie https://docs.microsoft.com/nl-nl/Exchange/exchange-tls-configuration?view=exchserver-2019
TLS 1.2 registry aanpassing (copy past naar .reg file):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
.NETv4 schannel aanpassing (copy past naar .reg file):
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001
Herstart nu de betreffende server om deze instellingen te laten. Daarmee zijn de TLS benodigdheden gereed en kunnen we verder.
In mijn geval moest ik SSLOffloading eveneens nog activeren. Het commando wordt je alvast voorgekauwd. Daarna draai je nogmaals .\ExchangeExtendedProtectionManagement.ps1 waarbij je melding krijgt dat de aanpassing is doorgevoerd en je eventueel een configuratie backup achter de hand hebt.
Set-OutlookAnywhere -Identity 'MX01\RPC (Default Web Site)' -SSLOffloading $false -InternalClientsRequireSsl $true -ExternalClientsRequireSsl $true
Voer nu nogmaals het script uit:
.\ExchangeExtendedProtectionManagement.ps1
Klaar…
Bij een enkele omgeving kwam er bij users een melding:
There is a problem with the proxy server's security certificate. The name on the security certificate is invalid or does not match the name of the target site. Outlook is unable to connect to the proxy server (Error Code 10)
Dit kun je verhelpen door Mapi over HTTP aan te zetten. Test dit eerst met een enkele gebruiker alvorens je dit aanzet voor de gehele organisatie.
Set-CasMailbox <user or mailbox ID> -MapiHttpEnabled $true
Voor de gehele organisatie gebruik je:
Set-OrganizationConfig -MapiHttpEnabled $true
Krijg je een standaard certificaat melding, voer dan het onderstaande door op je exchange server:
$Server = "exchange2016" $HTTPS_FQDN = "mail.steijvers.com" Set-ClientAccessService -Identity $Server -AutodiscoverServiceInternalURI https://$($HTTPS_FQDN)/Autodiscover/Autodiscover.xml Get-OWAVirtualDirectory -Server $Server | Set-OWAVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/owa" -ExternalURL "https://$($HTTPS_FQDN)/owa" Get-ECPVirtualDirectory -Server $Server | Set-ECPVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/ecp" -ExternalURL "https://$($HTTPS_FQDN)/ecp" Get-OABVirtualDirectory -Server $Server | Set-OABVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/oab" -ExternalURL "https://$($HTTPS_FQDN)/oab" Get-ActiveSyncVirtualDirectory -Server $Server | Set-ActiveSyncVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/Microsoft-Server-ActiveSync" -ExternalURL "https://$($HTTPS_FQDN)/Microsoft-Server-ActiveSync" Get-WebServicesVirtualDirectory -Server $Server | Set-WebServicesVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/EWS/Exchange.asmx" -ExternalURL "https://$($HTTPS_FQDN)/EWS/Exchange.asmx" Get-MapiVirtualDirectory -Server $Server | Set-MapiVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/mapi" -ExternalURL https://$($HTTPS_FQDN)/mapi
Ga vervolgens naar het ECP en ga naar Servers en dubbelklik daar op je server. Ga in de pop-up naar Outlook Anywhere en voer hier je FQDN nogmaals in (authenticatie dan wel op NEGIOTIATE, het screenshot hieronder was van toepassing bij een migratie en stond tijdelijk op NTLM).
In een enkel geval dien je als quick fix een nieuw outlook profiel aan te maken voor een gebruiker. Gebruik het onderstaande commando om de profile selecter tevoorschijn te toveren:
outlook.exe /profile profile_name
Verwijder vervolgens het bestaande outlook profiel en maak daarna een nieuw profiel aan.
Een andere situatie die ik heb ervaren is een WARNING: This script requires to be run inside of Exchange Management Shell. Please run on an Exchange Management Server or an Exchange Server with Exchange Management Shell.
In dit geval heb je het mitigatie script mogelijk op een eerder gedownload waarbij er een bug in zat. Download de laatste versie van het script op de eerder gemelde pagina en je zult deze melding niet krijgen.