In September 2024 CU a new security fix was included which added a restriction for Workflow actions. Only actions in namespaces which are explicitly allow listed by an administrator through an authorizedType entry in the web.config and owstimer.exe.config can be used.
As this modification is also required for workflow actions in 1st party assemblies shipped with SharePoint it caused significant efforts and concerns.
With December CU Microsoft has released an update to mitigate this: all required Namespaces for Workflow actions shipped with SharePoint are now automatically allow listed.
To achieve this the following entries are added to the web.config and the owstimer.exe.config files when running the SharePoint configuration wizard after applying December 2024 CU:
<authorizedType Assembly="Microsoft.Office.Access.Server.Application, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.Office.Access.Server.Macro.Runtime" TypeName="*" Authorized="True" /> <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.CodeDom" TypeName="*" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null" Namespace="Microsoft.SharePoint.WorkflowActions.WithKey" TypeName="*" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.WorkflowActions.WithKey" TypeName="*" Authorized="True" />
Permalink
Good afternoon, Stefan.
Just curious if we already applied the workaround to the web.configs in September, do we need to make any changes or reverts before applying the December CU or just go ahead and install?
Thank you and Happy Holidays!
Daniel
Permalink
Hi Daniel,
you can just install it – but I would still double check if any duplicates are in the web.config afterwards (e.g. due to different formatting)
They do not hurt but unnecessarily increase the size of the web.config file.
Cheers,
Stefan
Permalink
Thanks again, Stefan – On Nintex farms, if there are no authorizedtype assemblies listed in owstimer.exe.config at all, then Nintex workflows running in the owstimer.exe process (site workflows and list workflows that have pauses, state changes, or another action that would cause them to move from w3wp.exe processing to owstimer.exe processing) refer to the authorizedtype assemblies in the web.config file of the corresponding web application.
With this December SharePoint update injecting authorized types into owstimer.exe.config, it seems that we should be on the lookout for additional missing assemblies that Nintex may require in owstimer.exe.config. Sound accurate?
Permalink
Hi Brett,
yes. 3rd party assemblies and namespaces are not added by SharePoint.
If such assemblies/namespaces are required they need to be added either through custom features coming with the 3rd party or manually added by a SharePoint admin.
Cheers,
Stefan
Permalink
Here is an example of an OWS Timer exe config file from one of our WFE’s:
<appDomainManagerAssembly value="Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<appDomainManagerType value="Microsoft.SharePoint.SPAppDomainManager" />
As you can see, there are no Authorized type assemblies for Nintex.
Does this mean that a manual update of all OWS config files is required.
Many thanks
Permalink
On thing I struggle with all that stuff is. I have a workflow that try to retrieve Emails from a multiple user fields in a SharePoint 2010 Workflow. I get the claims back but without patching non of the Email adresses will get returned by the workflow and they crash with an unspecific error.
It was partiall fixed with:
<targetFx version="v4.0"><authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null" Namespace="Microsoft.SharePoint.WorkflowActions.WithKey" TypeName="*" Authorized="True" />
</targetFx>
</authorizedTypes>
and
$farm.EnablePreParseSecurityCheckForWorkflow = $false
Any thoughts on that?
Permalink
Hi Stefan,
do not use $farm.EnablePreParseSecurityCheckForWorkflow = $false
This will disable several security fixes.
In addition as it did not help the issue seems to be unrelated. I would suggest to open a support case with Microsoft to investigate where the unspecified error comes from.
Cheers,
Stefan
Permalink
With all the entries provided above the EnablePreParseSecurityCheckForWorkflow = $false is not required anymore.
Thanks for your help throughout the years.
Permalink
Hi Stefan,
I came across a SharePoint 2010 workflow in our environment that was still having issues after applying the December 2024 CU. It was being executed in owstimer, and this authorized type was not listed in owstimer.exe.config on any server in our farm:
The workflow uses an out-of-the-box Feedback Process activity. Just wanted to pass this along.
Permalink
The authroizedType block was stripped from my previous comment. Trying again.
authorizedType Assembly=”Microsoft.Office.Workflow.Actions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” Namespace=”Microsoft.Office.Workflow.Actions” TypeName=”*” Authorized=”True”
Permalink
Hello,
We applied the Dec 2024 CU to both our Production farms prior to Xmas break, and have returned to a number of WF’s giving a fail to start etc.
Based on the information, I am under the impression that Dec CU now negates the need to manually update the web config files, and that entries in the OWSTimer Config files are no longer required.
Please confirm this is the case, or do I need to update all OWSTimer files?
Many thanks
Permalink
Hi Scott,
with December CU SharePoint adds all required SharePoint namespaces as authorizedType as well to the web.config and the owstimer.exe.config file.
Manual updates are only required for namespaces for 3rd party or custom workflow actions integrated with SharePoint.
Cheers,
Stefan
Permalink
Anyone have any news on this? Nintex support points me to the September 2024 post issue fix, but the fix is already applied.
That said, it tells me I need to ask Microsoft. Is it possible that after a month of the patch being released there is no evidence of a fix?
Permalink
Hi Massimiliano,
December 2024 CU includes a fix which updates the config files with all namespaces required by workflow actions shipped with SharePoint.
Nintex specific workflow actions have to be allow listed manually be the administrator. Nintex owns this and needs to provide guidance on the specific namespaces that need to be allow listed.
About your question related that a month after a patch is released no fix is available: cut of date for the next CU is usually the day before releasing the previous CU. So the earliest CU a fix can be included would be the 2 months later than the CU that introduced the issue. But only if the issue was reported very quick after the CU has been released, Support was able to identify the issue as a regression and the PG was able to implement a fix in only a couple of days. If this takes longer a fix would be in a later CU.
Cheers,
Stefan