Released: October 2023 Exchange Server Security Updates

[The_Exchange_Team]

Microsoft has released Security Updates (SUs) for vulnerabilities found in:

• Exchange Server 2019
• Exchange Server 2016

SUs are available for the following specific versions of Exchange Server:

• Exchange Server 2019 CU12 and CU13
• Exchange Server 2016 CU23

The October 2023 SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes. Although we are not aware of any active exploits in the wild, our recommendation is to immediately install these updates to protect your environment.

These vulnerabilities affect Exchange Server. Exchange Online customers are already protected from the vulnerabilities addressed by these SUs and do not need to take any action other than updating any Exchange servers or Exchange Management tools workstations in their environment.

More details about specific CVEs can be found in the Security Update Guide (filter on Exchange Server under Product Family).

CVE-2023-21709 now has a better solution: install update for CVE-2023-36434

During the release of August 2023 SUs, we recommended to use a manual or scripted solution and disable the IIS Token Cache module as a way of addressing CVE-2023-21709. Today, Windows team has released the IIS fix for root cause of this vulnerability, in the form of fix for CVE-2023-36434. We recommend installing the IIS fix after which you can re-enable Token Cache module on your Exchange servers.

If you did not do anything to address CVE-2023-21709 yet:

• Install update for CVE-2023-36434 on all your Exchange Servers.

If you have followed our August 2023 recommendation and disabled the Token Cache module (either by using single-line command or our CVE-2023-21709.ps1 script), or want to address possible performance concerns you have seen since disabling the module, do the following:

• Install update for CVE-2023-36434 on all your Exchange Servers.
• Re-enable IIS Token Cache module by doing one of the following:
  • To enable Token Cache module on individual server only, run the following from the elevated PowerShell window:

New-WebGlobalModule -Name "TokenCacheModule" -Image "%windir%\System32\inetsrv\cachtokn.dll"

• • To enable Token Cache module on all servers in the organization (after Windows Updates were installed), you can use our CVE-2023-21709.ps1 as Administrator in Exchange Management Shell (EMS):

.\CVE-2023-21709.ps1 -Rollback

We are making updates to all related August 2023 documentation pages and scripts as well as Health Checker to reflect our new recommendation.

Update installation

The following update paths are available:

• Install the latest CU. Use the Exchange Update Wizard to choose your current CU and your target CU to get directions.
• Inventory your Exchange Servers to determine which updates are needed using the Exchange Server Health Checker script. Running this script will tell you if any of your Exchange Servers are behind on updates (CUs, SUs, or manual actions).
• Re-run the Health Checker after you install an SU to see if any further actions are needed.
• If you encounter errors during or after installation of Exchange Server, run the SetupAssist script. If something does not work properly after updates, see Repair failed installations of Exchange Cumulative and Security updates.

Known issues with this release

• There are no known issues with this update.

Issues resolved in this release (see KB for full list)

• Users in account forest can’t change expired password in OWA in multi-forest Exchange deployments af... (please note that additional steps are necessary)
• Extended Protection causes Outlook for Mac to fail to download the OAB (we are releasing the new version of the Extended Protection script)

FAQs

We are running a non-English operating system, and the October 2023 SU fails with an "Error 0x80070534: failed to get sid for account: Network Service" error. Help!
As outlined in Re-release of August 2023 Exchange Server Security Update packages, it is crucial to uninstall the August 2023 SUv1 and revert the workaround prior installing the October 2023 SU. If you are unsure if/which August 2023 update package you run, make sure to run the latest version of the Exchange Health Checker script first and keep an eye out for the following warning which indicates that the August 2023 SUv1 package is installed: "Error: August 2023 SU 1 Problem Detected. More Information: https://aka.ms/HC-Aug23SUIssue".

We disabled IIS Token Cache as a part of August 2023 update. Does Exchange require IIS Token Cache to run? Must we re-enable it?
Re-enabling IIS Token Cache after installing the update for CVE-2023-36434 is optional. Exchange Server does not require IIS Token Cache. We wanted to call the CVE-2023-36434 update because we heard from some customers who had concerns about performance of their clients after IIS Token Cache is disabled. If you already disabled IIS Token Cache and want to keep it disabled, Exchange Server does not require it. But please make sure to install all Windows Updates anyway. 

Our organization is in Hybrid mode with Exchange Online. Do we need to do anything?
Exchange Online is already protected, but this SU needs to be installed on your Exchange servers, even if they are used only for management purposes. If you change the auth certificate after installing an SU, you should re-run the Hybrid Configuration Wizard.

The last SU we installed is a few months old. Do we need to install all SUs in order to install the latest one?
SUs are cumulative. If you are running a CU supported by the SU, you do not need to install all SUs in sequential order; simply install the latest SU. Please see this blog post for more information.

Do we need to install SUs on all Exchange Servers within our organization? What about ‘Management Tools only’ machines?
Our recommendation is to install SUs on all Exchange Servers and all servers and workstations running the Exchange Management Tools to ensure compatibility between management tools clients and servers. If you are trying to update the Exchange Management Tools in the environment with no running Exchange servers, please see this.

Documentation may not be fully available at the time this post is published.

Updates to this blog post:

• 10/12/23: Added a note that additional steps might be necessary to address password prompts in multi-forest deployments (issues resolved section)
• 10/11/23: Added a FAQ for setup error that can be encountered if August 2023 SUv1 was installed on Exchange running on non-English OS
• 10/11/23: Added a FAQ clarifying that re-enabling IIS Token Cache is not required but is optional

The Exchange Server Team

[Julian_Haupt]

Works as expected on German Exchange 2016 CU23 w/ Windows Server 2016. Thanks.

[Sam_T]

@The_Exchange_Team 

From KB5030877 "Description of the security update for Microsoft Exchange Server 2019, 2016, and 2013: October 10, 2023"    Exchange 2013 ?

Description of the security update for Microsoft Exchange Server 2019, 2016, and 2013: October 10, 2... 

[Nino Bilic]

@Sam_T Yup, typo. Fixed.

[fw888888]

Install update for CVE-2023-36434 on all your Exchange Servers.

CVE-2023-36434 is KB5031362,which is monthly security update as well.

So I just need to run windows update to get the hotfix from WSUS, let windows update install by himself, then Re-enable IIS Token Cache module, right?

Thanks in advanced.

[Lukas Sassl]

@fw888888 that's correct. The fix for CVE-2023-36434 is a Windows Security Update as it affects a component of IIS which is part of Windows. After the update has been installed, the TokenCacheModul can be added back as described in this blog post. 

[DennisLichtenthaeler]

Hi Nino,

we're facing the same problems reported back in August on a German Exchange 2016 installation.

In the setup log files at C:\Program Files\Microsoft\Exchange Server\V15\Logging\Update\msi\ExchangeUpdate-....log we found the following entry:

ExecSecureObjects: Error 0x80070534: failed to get sid for account: Network Service

Is this really the same issue like in August? We have not used the temporary workaround mentioned in august (manually creating a user named "Network Service"). Do folks who have successfully installed the October update on a German system still have the manually created account?

Regards,

Dennis

[Lukas Sassl]

@DennisLichtenthaeler have you installed the August 2023 SUv1 and did you experience any issue during the August 2023 installation?

[DennisLichtenthaeler]

@Lukas SasslWe had been holding out on the August SU until the fixed version was available. We haven't performed the manual steps that were listed as a workaround between the first and second version of the update.

[lewismartin]

Any issue with installing the October Exchange SU now and leaving the token cache disabled and the Windows SU install to a later date?

[nak_87]

I ran updated HealthChecker script and have not installed October SU yet. I'm curious about this part:

Extended Protection Enabled (Any VDir): True
Default Web Site/OAB - Current Value: 'Require' Expected Value: 'Allow'
The current Extended Protection settings may cause issues with some clients types on this protocol.
It is recommended to set the EP setting to the recommended value if you are having issues with that protocol.
More Information: https://aka.ms/ExchangeEPDoc

I compared it with a prior healthchecker log a week ago and this was not the case. Has anything been modified in EP or is it because of missing October SU?

[Lukas Sassl]

@nak_87 yes, we've updated the recommended EP settings to address the following issue: Extended Protection causes Outlook for Mac not to update the OAB - Microsoft Support

[Nino Bilic]

@lewismartin As far as Exchange is concerned, this is not an issue. We wanted to be clear that customers can re-enable Token Cache because there have been some reports that some customers (depending on usage patterns) have seen performance issues with Token Cache disabled.

Now - on the Windows side of things, I just want to say that we always recommend that all updates are installed ASAP. Windows and Exchange.

[Nino Bilic]

@DennisLichtenthaeler Hmm... the thing is - the dependency on the Network account was introduced in the environment in some way... you should follow this blog post to roll back the dependency on the account:

https://techcommunity.microsoft.com/t5/exchange-team-blog/re-release-of-august-2023-exchange-server-...

Ultimately, even though Aug SUv1 was not installed, it seems like it was at least attempted. My recommendation would be to double check (perhaps running Health Checker) what exactly is the status of all servers. It appears that somewhere, Aug SUv1 was introduced into the environment.

[Rpena2930]

We made no changes to address CVE-2023-21709. Does it matter in what order we apply the Windows update KB5031362 and the latest SU for Exchange 2016?

[DennisLichtenthaeler]

@Nino BilicWow, what a trip - that seems to have worked. I had to recreate the Network Service user in order to uninstall the August SU. Afterwards, I was able to delete the user and install the October SU. I'll keep monitoring the situation but that one machine looks fine now. Thanks!

[Lukas Sassl]

@Rpena2930 it doesn't matter whether you install the Windows Update or Exchange October 23 SU first.

[Nino Bilic]

@DennisLichtenthaeler Good to know! @Lukas Sassl and I just added a FAQ to the blog post related to this; I expect you might not be the only one who had installed Aug 2023 v1 update so this scenario should be called out...

[Lennart-Live1220]

@Nino Bilic ,

In the last "healthchecker" there is a remark that states:

Default Web Site/OAB - Current Value: 'Require' Expected Value: 'Allow'

The current Extended Protection settings may cause issues with some clients types on this protocol.
It is recommended to set the EP setting to the recommended value if you are having issues with that protocol.

But when i do a check on IIS/OAB there is no option to select 'Allow' only 1) Required 2) Accept 3) Off

Could there be something wrong with the healthchecker? Or can i ignor this one?

I already run the updated script for extended protection.

Have a nice day. 

Greetings from Holland.

Lennart 

[Andres Bohren]

Hi  @Lennart-Live1220 

I had the same issue

After running the updated Script https://microsoft.github.io/CSS-Exchange/Security/ExchangeExtendedProtectionManagement/ 

.\ExchangeExtendedProtectionManagement.ps1

And rerun the HealthChecker the Warning was not shown.

Regards

Andres

[Lukas Sassl]

@Lennart-Live1220 the values in the UI are different to the values that needs to be set if you perform the task programmatically as the ExchangeExtendedProtectionManagement.ps1 script does. 

You can find more details here: https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/#enabling-extended-protection

However, the easiest and recommended way is, as already mentioned by @Andres Bohren to use our script which can be downloaded from here: https://aka.ms/ExchangeEPScript

[adixro]

@Nino BilicMight have missed information related to performance hits for some customers. Care to share some information related?

Thank you.

[Tonibert]

@Lukas Sassl  

The message :TokenCacheModule loaded: False is only displayed in the console output but not in the HTML export.

Maybe that's not intentional. That's why I wanted to share it with you

Exchange Health Checker v23.10.10.1648

[Lennart-Live1220]

@Lukas Sassl @Andres Bohren @Nino Bilic ,

This one did the trick. Warning is gone now. Thank you.

https://microsoft.github.io/CSS-Exchange/Security/ExchangeExtendedProtectionManagement/

Version: 23-10-10-1648

[Nino Bilic]

@adixro I do not have much to share, though. Back in August, we had a few comments on the blog (and I have seen some on other forums) where some of our customers said that disabling IIS Token Cache would create a noticeable delay for their client logons. Then, most of those comments stopped. Our hypothesis was that yes, this can happen during the first logon (because app pools get restarted), but then it should not really be noticeable. I also heard that some customers were not disabling Token Cache because of such concerns. We never got any specific support tickets on this (that I'm aware of). The bottom line is - if someone was concerned with IIS Token Cache perf impact - now there is a way to not disable it and address the vulnerabilities (or re-enable it after updating Windows).

[wolfgang-frey]

Hei there,

i have another little question or maybe just a hint:

In the KB you write "after Windows Updates were installed" in the part concerning the IIS Token Cache module re-enabling for all the servers in the organization. Might it be that there has been a little confusion with Exchange Security Updates instead of Windows Updates?

Regards

Wolfgang

[Nino Bilic]

@wolfgang-frey Hmmm yeah this is a bit confusing but:

The long version: CVE-2023-21709 (Exchange vulnerability disclosed in August) had a solution (at the time) of disabling the IIS Token Cache. Now (October 2023) - IIS team has released a fix for the root cause of this issue, as an update for Windows (IIS really) and has disclosed this vulnerability as CVE-2023-36434. Which is not an Exchange vulnerability (as it is a vuln in IIS). So what we are saying is - install Windows Updates first (this will get you fixed for CVE-2023-36434) and then you can safely re-enable Token Cache if you disabled it between now and August 2023 as our original guidance for CVE-2023-21709 suggested.

In other words - I think our wording is correct; the confusing part is that the previously disclosed Exchange vuln is really a subset of the later disclosed IIS vuln and the recommended way to address both is to install the fix for IIS via Windows Update.

[Lukas Sassl]

@Tonibert thanks for reporting this. I will add the TokenCacheModule output to the HTML report with the next release of HC. It looks like we forgot to add it there.

[j_ware]

The vulnerability for this SU is related to an authenticated exchange user on the intranet making a remote powershell connection to an Exchange server, would using Set-User to set RemotePowerShellEnabled to False be a workaround mitigation while we test and get approval to install the new SU?

[JS2022]

Hi,

Idid remove TokenCacheModule using CVE-2023-21709 when previous SU was released and now I have run the updated script with -RollBack. Apparently previous state was correctly restored:

[PS] C:\ftp>Get-WebGlobalModule -Name "TokenCacheModule"

Name Image
---- -----
TokenCacheModule %windir%\System32\inetsrv\cachtokn.dll

yet, when I run the latest healthChecker script I get this warning:

TokenCacheModule loaded: False
The module wasn't found and as a result, CVE-2023-21709 and CVE-2023-36434 are mitigated. Windows has released a Security Update that addresses the vulnerability.
It should be installed on all Exchange servers and then, the TokenCacheModule can be added back to IIS (by running .\CVE-2023-21709.ps1 -Rollback).
ore Information: https://aka.ms/CVE-2023-21709ScriptDoc

Are there additional steps to take to get it to load or is the warning actually incorrect and should be ignored?

EDIT:

In IIS console->modules->  I can see the module is available in all its sites except "Default Web Site" so I assume the warning is correct. How can I add it to the list so the warning goes away?

TIA & rgds

[FranManuel86]

Hi,

In our case we have a multiforest exchange 2019 with multiple domain trust relationships, in the following article explains that we have to deploy a New-SettingOverride:

https://support.microsoft.com/en-us/topic/users-in-account-forest-can-t-change-expired-password-in-o...

Do we have to add all domains where user accounts are located to the setting? Maybe in the following way:

New-SettingOverride -Name "DomainList" -Component OwaServer -Section DomainSettings -Parameters @("ValidDomainList=TrustedDomain1.com,TrustedDomain1, TrustedDomain2.com,TrustedDomain2, TrustedDomain3.com,TrustedDomain3,…") -Reason "Configure list of additional domains"

[aarife]

Hi,

We did not enabled EP on our onpremise Exchange 2016. Do we have to do this before or after installing this October SU ?

[Lukas Sassl]

@aarife EP doesn't have a dependency to the October 2023 SU release. We've addressed an issue by making an adjustment to the EP enabling script (https://microsoft.github.io/CSS-Exchange/Security/ExchangeExtendedProtectionManagement/).

However, as you have not had EP enabled before, I'd recommend to install the update, make sure that everything works as expected and then switch on EP.

@FranManuel86 that's correct. You need to add all the domains which are used in user forests where user resides who have a mailbox on Exchange Server which is running in the resource forest. If you miss to add a domain, users who are using this domain will not be able to change their password via OWA in case that it has already expired (as described in the KB).

@JS2022 can you tell me which Windows Server version do you run?

[JS2022]

@Lukas Sassl

I'm using Exchange 2016 on 2012 R2 (will migrate to Ex 2019 on 2022 as soon CU14 comes out ;))

[Lukas Sassl]

@JS2022 okay, thanks for the information. It looks like this is a false-positive in HealthChecker that occurs on Windows Server versions < 2016. I’m working on a fix and we’ll release an updated version of HC. If the rollback was completed without any error, you should be good.

[Lukas Sassl]

@JS2022 @We’ve released a new version of HealthChecker. It should address the issue that you described. Please give it a try and let us know if it works for you.

[JS2022]

@Lukas Sassl 

New version of the script works, the warning is gone. Thank you

[ceantuco]

Installed Windows Server 2019 updates and Exchange 2019 CU12 OCT SU. No issues. I will leave the Token cache disabled since we did not experience any performance issues when we disabled it back in August. 

I will run the new Extended Protection script next week. 

Thanks Microsoft Team! @Lukas Sassl @The_Exchange_Team @Nino Bilic 

[mmason117]

Anyone else having issues with Oct SU installing after installing latest Windows Updates? We installed the following KB's this morning: KB5031010, KB5031361, Servicing Stack 10.0.17763.4965 and the Exchange SU installer is failing with an error about an incompatible version. It's asking that the Aug SU be uninstalled first. Trying to take the server out of maintenance mode is proving challenging as numerous services are disabled / not running.

Thoughts? 

[mmason117]

Additional information, when running the Health Checker script, we receive the following notice:

Exchange Health Checker version 23.10.17.1458
WARNING: An error occurred while accessing the registry on the server "HX-MXX.XXXX.INT". The error that occurred is:
"The network path was not found.
".

[MichaelRuebel]

We have an english OS and had no problems with installing the August update. But the october update fails with error "1603" and the log file entry: "Installation cannot continue. The Setup Wizard has determined that this Interim Update is incompatible with the current Microsoft Exchange Server 2016 Cumulative Update 23 configuration."

We had to uninstall the August update to get the October update installed. 

Not funny....

[Andreas-Mueller]

@MichaelRuebel 

We also have the same problem here with Exchange Server 2019 CU13 in the German version and August SU KB5030524 installed.
Operating system is Windows Server 2022 German. We are waiting for the next CU to see whether it works.

[Lukas Sassl]

@Andreas-Mueller @MichaelRuebel quick question on this: Have you had the August 2023 SUv1 or SUv2 installed? You can check the build number to find out which package was installed: https://learn.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchser...

[MichaelRuebel]

@Lukas Sassl We had the V1 installed. But - as I wrote - not in any localized version. We have only english OS, so back in August, we felt no urge to implement V2 of the update. And we had no problem to implement V1 in August...

[Andreas-Mueller]

@Lukas Sassl  We only had version SUv2 installed.

[mmason117]

@Lukas Sassl For what it's worth, we had only installed the SUv2 from the August updates. We had not installed the v1 update from August and held off until the v2 was released.

We were able install the October updates by temporarily removing the option to "Check for publisher's certificate revocation" in the security settings of the Internet Options.

[MarioSaric]

I haven't installed August SU, but I am trying now to install Octobers SU, but It's failing.

What could it be wrong ?

All the time I am getting error 0x80070643?

And ofcourse all Microsoft Exchange services remained "Disabled"...

@Lukas Sassl  any idea about this error ?  Thanks

[Lukas Sassl]

@MichaelRuebel 1603 is a generic error code. It just means that the installation failed. There are multiple reasons why this could happen. You can share the log file with us and I could have a quick look. Send me a PM if you want to do that and I can provide more details.

@mmason117 setup could take longer or in some scenarios fail if CRL checking is not possible but enforced via a system setting. Which error did you get before publisher CRL checking was disabled? 

@MarioSaric reasons for 0x80070643 could be different and could be caused by other components on the system (for example, Exchange SU installation might fail due to a faulty other component like .Net Framework on the system).

Hard to tell without checking additional logs. If you experience the issue multiple times and on multiple systems, it would be good to file a support case with use so that we can collect the data that we need for troubleshooting this issue.

[MarioSaric]

@Lukas Sassl  This is first time that i have a such experience...

As I am doing this in LAB environment and not in production... I have now installed manually SU 10 for Exchange 2016 CU23...

So with Windows Update It's not working but manually installation of October SU10 works...

What logs do you preffer I should check ?

Thnx

[Sam_T]

@The_Exchange_Team 

Only a few short weeks left in CY 2023.  Should we expect 2023 H2 CU for Exchange Server 2019 (CU14) before the end of the year or are we in for another unhappy surprise?

[ceantuco]

@Lukas Sassl @Nino Bilic quick question, I enabled extended protection back in February 2023. Do I have to roll back the old extended protection script and run the new one? or can I just run the new script by: 

.\ExchangeExtendedProtectionManagement.ps1

Please advise! 

Thanks! 

Single Exchange 2019 CU12 OCT SU server running on Server 2019.