January 2022 Quality Update Breaks passing domain credentials from VPN connection to remote servers

[Makhorkin]

VPN connections on Windows have UseRasCredentials option which allow user on non-domain machine work with domain resources using his/her VPN credentials

Under the hood, when this option is enabled, Windows creates stored credentials for a VPN session:

cmdkey /list
Currently stored credentials:
    Target: Domain:target=*Session
    Type: Domain Password
    User: dom\username
    Saved for this logon only

We found that on machines with latest updates installed it doesn't work and users aren't able to connect to domain resources (File shares, SQL servers) even when they connected to VPN with their domain credentials

To prove that it's related to latest updates, we launched an old VM (windows 10.0.17763.1577) and everything is working like a charm.

But on new VMs, created from Azure images "Windows 10 Pro 20H2 -Gen1" and "Windows 10 Enterprise 2019 LTSC - Gen1" when user connected to VPN, cmdkey /list not showing credentials for Target: Domain:target=*Session and users aren't able to work with on-prem resources.

As workaround we manually added credentials with

cmdkey /add:Domain:target=* /user:dom\username /pass

where Domain is an exact word "Domain" and dom\username- user login, domain resources became accessible over VPN from non-domain machine.

We also checked rasphone.pbk files (AppData\Roaming\Microsoft\Network\Connections\Pbk\rasphone.pbk) and it have UseRasCredentials=1

Thanks

[#2]

Did you ever find a permanent fix for this? We have the same issue.

[#3]

@rrafluap 

As workaround we manually added credentials with

cmdkey /add:Domain:target=* /user:dom\username /pass

where Domain is an exact word "Domain" and dom\username- user login.

It works well unless user change the password - in that case stored credentials need to be manually updated. And of course it's insecure - we need to have credentials stored locally on remote machine.

Thanks

[#4]

@Makhorkin 

Thanks for the update. Really odd that future updates haven't corrected the issue but great that there's a workaround. If I figure out the cause/a fix, I'll let you know.

[#5]

The problem is in rasmans.dll, we take this file from the December working assembly, in the register in the rasman service we change the path to the old file. restart the computer. Everything will work as before. All the latest updates can be installed.

[#6]

@object_mxm 

How do I find the "December working assembly" to replace the current one? My tech does not know how to do this, and Dell wants to rebuild my OS completely. According to this chain, that will spend a huge amount of time and won't fix the problem.

[#7]

We take this file from the same version of the system with a full update for December.

[#8]

@Makhorkin 

I have finally found someone with this problem ! Fortunately most of my users have domain joined computers so no issues. Still I would like to know if this will get fixed or it is gone forever. Please Microsoft.

[#9]

Did you finally fix that issue? If yes, kindly respond. We are also facing the same issue.

[#10]

Not yet. My IT person has not looked at it, and when I look up the service pack, I can find the full download, but not that specific file. Windows did a new update that was supposed to fix this, but it only worked for 2 days and the problem came back.

For now my solution is to turn off the VPN when I need to update/run rules or see images in my email. At least it lets me see if images have been properly sized in my email or not...

[#11]

This one is starting to get old - constantly back-reving the rasmans dll. Another update to rasmans just last week and still the issue persists. Has there been any acklowedgement by MS that this is a bug that will get fixed anytime?

[#12]

Does anyone know if there will be a fix for this? Or if there is workaround that can be deployed (except putting credentials in credential managed)?