Microsoft schließt mit dem Update im September die als kritisch eingestufte Sicherheitslücke CVE-2018-8421. Sie ermöglicht nach eigenen Angaben „Remote-Code-Ausführung“. Dabei passt Microsoft die Sicherheitseinstellungen in SharePoint an und verhindert, dass Workflows ausgeführt werden. Davon sind sowohl SharePoint native als auch Nintex Workflows betroffen.
Fehlerbild
Das Fehlerbild zeigt sich, indem Workflows nicht gestartet werden können. Die Fehlermeldung lautet „Fehler beim Start von <WorkflowName>“ und „Der Workflow ‚<WorkflowName>‘ wurde von Systemkonto abgebrochen“. Hierbei ist die Komplexität des Workflows und die Aktionen irrelevant. Darüber hinaus lassen sich Workflows auch nicht mehr veröffentlichen, da dort eine unhandled execption geworfen wird.
„SharePoint Foundation Workflow Infrastructure 72fs Unexpected RunWorkflow: Microsoft.SharePoint.SPException: <Error><CompilerError Line=“-1″ Column=“-1″ Text=“Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.“ />“
Diese hat uns jedoch zur Lösung geführt.
Lösung
Zur Lösung des Fehlers müssen Anpassungen an der web.config aller Web-Applikationen auf allen Web-Frontend-Servern (WFE) vorgenommen werden.
Die web.config im jeweiligen Ordner des iis. Default: C:\inetpub\wwwroot\wss\VirtualDirectories\
Diese müssen um folgende Einträge ergänzt werden:
<System.Workflow.ComponentModel.WorkflowCompiler>
<authorizedTypes>
<targetFx>
<authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeBinaryOperatorExpression" Authorized="True" />
<authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodePrimitiveExpression" Authorized="True" />
<authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeMethodInvokeExpression" Authorized="True" />
<authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeMethodReferenceExpression" Authorized="True" />
<authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeFieldReferenceExpression" Authorized="True" />
<authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeThisReferenceExpression" Authorized="True" />
<authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodePropertyReferenceExpression" Authorized="True" />
<authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeTypeReferenceExpression" Authorized="True" />
</targetFx>
</authorizedTypes>
</System.Workflow.ComponentModel.WorkflowCompiler>
Zeile 11 wird allerdings nur benötigt, wenn Drittanbieterlösungen wie Nintex eingesetzt werden.
Für frühere SharePoint-Versionen und weitere Details steht dieser Blog-Artikel von Microsoft zur Verfügung, der mir auch als Quelle und Lösung diente.
Update (25.09.2018)
Das Ändern der OWSTIMER.EXE.config führte dazu, dass der Timer-Service nicht mehr läuft. Daher sollte diese nur geändert werden, wenn nach der Anpassung der web.config weiterhin Fehler in der Ausführung der Workflows im ULS-Log auftauchen.
Der eigentliche Artikel wurde angepasst und die Änderung der Timer-Service-Config entfernt.
