Windows 10 2004/20H2 and the broken 'Credentials Manager': Cause and Workaround – Part 2

[German]Credentials Manager is unusable on Windows 10 May 2020 Update (version 2004) and Windows 10 20H2 because it forgets credentials of applications based on this feature. In part 1 I already mentioned this topic. In part 2 I will now add some additional information about a possible cause.

In the article Windows 10 2004/20H2 and the broken 'Credentials Manager': Root Cause and Workaround – Part 1 I have discussed the problem of forgotten credentials in Windows 10 2004/20H2. There you can find the hint that the information is still stored in the credentials manager. A broken manifest, caused by one of the last Windows 10 updates, should cause the Data Protection API encryption with a user key to fail. The system key must be used – which I have outlined in the article as a workaround.

The root cause

German blog reader Bernhard Diener pointed out in this comment that Tavis Ormandy from Google Project Zero had already analyzed this error some time ago. Ormandi disclosed his findings in a series of tweets at the end of September 2020.

At the same time I came across this article from the colleagues from Bleeping Computer, which also addresses this. In the Microsoft Answers forum there is this extensive thread where someone complains about the system-wide password loss initially. Many users confirm the bug. Ormandy found out during his analysis that a certain scheduled task can interrupt the CryptUnprotectData(). Execute the following command in an administrative PowerShell console:

Get-ScheduledTask | foreach { If ($_.Principal.LogonType -eq 'S4U') { $_ } }

and tasks appear there, there is a problem. Once the tasks are executed, DPAPI will not work until a re-authentication is performed.  This is caused by scheduled tasks created with the S4U (Services For User) option of the Task Scheduler.

This is caused by a bug in the RPC UBPM (Unified Background Process Manager) which causes stored credentials in the Local Security Authority Subsystem Service (LSASS) to be removed. As a result, applications either lose logon status or users log off their accounts. In the Event Viewer, the Eventid 8198 or NTE_BAD_KEY_STATE should then be entered as an event.

A suggested workaround

Ormadis proposes, to disable all scheduled tasks executed by S4U. To do this, execute the following command in an administrative PowerShell console:

Get-ScheduledTask | foreach { If (([xml](Export-ScheduledTask -TaskName $_.TaskName -TaskPath $_.TaskPath)).GetElementsByTagName("LogonType").'#text' -eq "S4U") { $_.TaskName } }

The command lists the tasks that are scheduled by S4U. Note all scheduled tasks listed as output of the command and disable them using the Windows Task Scheduler. This can be opened as administrator via the search field in the task bar. After all tasks have been deactivated, Windows should be restarted. As long as the tasks are not running, the credentials should be preserved.

Microsoft investigated, Fix not yet available

Eric Law from Microsoft contacted Ormandi in this chromium bug tracker thread at the end of September 2020 and announced that they were investigating the bug. But until November 9, 2020, Microsoft did not give any feedback if and when this bug will be fixed (only this article about Outlook was published on November 6, 2020, see also the following comments). Currently, it is recommended to go back to Windows 10 version 1909, or to try the approach mentioned in part 1.

Addendum: A fix is probably available with Windows 10 November 2020 patches, see Patchday: Windows 10-Updates (November 10, 2020).

Article series:
Windows 10 2004/20H2 and the broken 'Credentials Manager': Root Cause and Workaround – Part 1
Windows 10 2004/20H2 and the broken 'Credentials Manager': Cause and Workaround – Part 2

Similar articles:
Windows 10 2004: 'Credentials Manager' broken [Workaround]
Windows 10 forgets certificates during upgrade
Microsoft confirms certificate loss on Windows 10 upgrades