none
Save website passwords not working properly with credential manager in windows 2012r2 RDS RRS feed

  • Question

  • Hello,

    I can not beleive that we are the only one with this problem. I started a question about this issue a long time ago. (see https://social.technet.microsoft.com/Forums/windowsserver/en-US/03d614d5-5fb8-44ed-a2f7-3e439a62d265/web-passwords-not-saved-in-credential-manager?forum=winserverTS)

    For now we had a workarround by using google chrome but because they will end the java and silverlight plugins we need to go back to Internet Explorer.

    The problem:

    When using Roaming Profiles in an RDS environment the Profiles are deleted at logoff (policy setting). The credential manager saves encrypted files in the directory "%USERPROFILE%\Appdata\Local\Microsoft\Vault . So when the profile is deleted at logoff the vault directory is lost and so are all the saved website passwords. So when we login to another server no saved website passwords are there.

    So now we are testing with Universal Profile Disks. With UPD the localappdata folder is retained when logging into another server. BUT the credential manager is still not working properly.

    When you save the passwords on server1 the passwords are saved in encrypted files in the users vault directory . When you login to server2 the files are still there but credential manager will not read them UNTIL you restart the credential manager service on that server.  When restarting the service then Credential manager will read the vault directory and show the saved passwords.

    I think the solution is that when a user logs on to a server then credential manager will need to read the password files in the vault directory. But that is not the case.

    I hope that someone can help because this is crazy. I also contacted MS support but had no luck finding a engineer that understands the problem.

    Thursday, June 25, 2015 2:33 PM

All replies

  • Hi,

    I suggest you check whether the website password component within Credential Manager functions smoothly on a non-RDS server in your environment.

    In addition, please ensure that RDS server is fully patched.

    Are there any related error message logged in Event Logs?

    Best Regards,

    Amy


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, June 29, 2015 8:22 AM
    Moderator
  • So i finally have found a workarround for this problem we have. It is not a decent workarround but its working. I believe that the credential manager service (VaultSvc) has a Bug. 

    When using Universal Profile Disk:

    1. For new users credential manager does not always make the appropiate folders in the %USERPROFILE%\Appdata\Local\Microsoft\Vault directory. So i have a loginscript (KIX) that checks if the folders are there and if not it is created.

      IF NOT EXIST ("%USERPROFILE%\Appdata\Local\Microsoft\Vault")
      MD ("%USERPROFILE%\Appdata\Local\Microsoft\Vault\4BF4C442-9B8A-41A0-B380-DD4A704DDB28")
      MD ("%USERPROFILE%\Appdata\Local\Microsoft\Vault\UserProfileRoaming")
      ENDIF

    2. passwords are saved in this folder and it is roaming between servers because of the Universal Profile Disk But credential manager is not always loading the saved credentials until the service is restarted.
      Create a batch file on each Remote Desktop server that will stop and start the VaultSvc service.

      @Echo off
      NET STOP "VaultSvc" /y
      NET START "VaultSvc" /y
      exit

    3. Create a scheduled task on each Remote Desktop server that wil start the batch file on each user logon.

      Create Basic Task
      Trigger: At Logon of any user
      Actions: Start a program (reffer to the batch file)

    When using Roaming Profiles:
    When using Roaming Profiles this folder %USERPROFILE%\Appdata\Local\Microsoft\Vault is not roaming and in our case deleted from the Remote Desktop server when a user logsoff.

    1. For new users credential manager does not always make the appropiate folders in the %USERPROFILE%\Appdata\Local\Microsoft\Vault directory. So i have a loginscript (KIX) that checks if the folders are there and if not it is created.

      IF NOT EXIST ("%USERPROFILE%\Appdata\Local\Microsoft\Vault")
      MD ("%USERPROFILE%\Appdata\Local\Microsoft\Vault\4BF4C442-9B8A-41A0-B380-DD4A704DDB28")
      MD ("%USERPROFILE%\Appdata\Local\Microsoft\Vault\UserProfileRoaming")
      ENDIF

    2. passwords are saved in this folder and it is roaming between servers because of the Universal Profile Disk But credential manager is not always loading the saved credentials until the service is restarted.
      Create a batch file on each Remote Desktop server that will stop and start the VaultSvc service.

      @Echo off
      NET STOP "VaultSvc" /y
      NET START "VaultSvc" /y
      exit

    3. Create a scheduled task on each Remote Desktop server that wil start the batch file on each user logon.

      Create Basic Task
      Trigger: At Logon of any user
      Actions: Start a program (reffer to the batch file)

    4. Create a logoff script oneach Remote Desktop server (I created this by using logoff script in our Group Policy under User Configuration policy).
      This will copy the %USERPROFILE%\Appdata\Local\Microsoft\Vault files to the users Home folder at logoff.

      @Echo off
      MD "M:\Vault"
      XCOPY "%USERPROFILE%\Appdata\local\Microsoft\Vault" "M:\Vault" /S /E /Y

    5. Now in our loginscript (KIX) the files must be copied back from the home folder to the Vault directory.

      COPY "M:\Vault" "%USERPROFILE%\Appdata\Local\Microsoft\Vault\" /s /h /c


    • Edited by Bbbbob Friday, July 31, 2015 9:59 AM
    • Proposed as answer by M_Petersen Tuesday, October 20, 2015 4:43 PM
    Friday, July 31, 2015 9:58 AM
  • Hi,

    I recently had exactly the same problem too, in a RDS 2012 R2 environment and solved it the way like Bbbob did it, except without restarting the VaultSvc. (Only step 1,4,5)

    But as he described, its just a workaround for a functionality that should work by default.

    Regards,
    Markus

    Tuesday, October 20, 2015 5:01 PM
  • Since this is a very well done post that most will search and find.

     I will add that the issue still exists with server 2016 and ie 11. Specifically, when using roaming profiles. The fix above needs one more directory added to step 4 and 5

    %USERPROFILE%\AppData\LocalLow\Microsoft\CryptnetUrlCache

    This needs to be copied at logoff and login. Or you will see only the credentials that were made on that server. (assuming you have more then one server in your farm)  

    Step 3 is also required. 

    Friday, December 22, 2017 1:02 AM
  • %USERPROFILE%\AppData\LocalLow\Microsoft\CryptnetUrlCache

    This needs to be copied at logoff and login. Or you will see only the credentials that were made on that server. (assuming you have more then one server in your farm)  

    Step 3 is also required. 

    Hi,

    I'm also figuring this out in our environment. The thing that strikes me though is what I put in bold above. How is it possible at all, when using roaming profiles, things are still accessible on that same server? We use roaming profiles, and we deleted cached profiles on logoff. So after syncing the roaming bits, the AppData\Local and LocalLow folders are removed from the server. Still, when I login to that same server again, the credentials stored for a user on that particular server are still accessible.

    In fact, when I completely delete that users roaming profile, forcing it to start with a clean profile, when I access the credentials manager / vault for that user, it still has the credentials that user stored on that server.

    PS C:\Windows\System32\WindowsPowerShell\v1.0> vaultcmd /list
    Currently loaded vaults:
            Vault: Web Credentials
            Vault Guid:4BF4C442-9B8A-41A0-B380-DD4A704DDB28
            Location: C:\Users\<username>\AppData\Local\Microsoft\Vault\4BF4C442-9B8A-41A0-B380-DD4A704DDB28

            Vault: Windows Credentials
            Vault Guid:77BC582B-F0A6-4E15-4E80-61736B6F3B29
            Location: C:\Users\<username>\AppData\Local\Microsoft\Vault

    So vaultcmd points to the user profile. Yet, when completely resetting a users profile as said, when that user lands on that same server, it still has its password remembered. So the vault must for some reason point to the local server, nothing else would make any sense to me.

    Has anyone ever worked that out?

    • Proposed as answer by CGEDVDL Wednesday, June 19, 2019 11:44 AM
    • Unproposed as answer by CGEDVDL Wednesday, June 19, 2019 11:44 AM
    Tuesday, November 20, 2018 8:28 AM
  • Hi Robert,

    Did you ever find the cause for what you describe?

    Tuesday, January 22, 2019 8:43 AM
  • So.... It might be a bug in the VaultSVC but this makes us just more furious that microsoft still hasn't fixed this. Instead, they might think the Credential Locker is a good idea - which isn't at all. I mean come on... we are in an enterprise environment here. this isn't acceptable at all! We have non-persistent Virtual Desktops using Windows 10 1809 (LTSB 2016 before) - but Microsoft is really unable to fix anything - instead they release new products with lesser features (see feature parity SfB and Teams - Teams is to this very date not able to communicate with Skype for Desktops and might never be).

    It is utterly fustrating. And your fix didn't work for us btw - also a Service Restart can't be a solution.

    Also why do they even store the vault in local instead of roaming?!

    I think we will start using chrome now. it's silly... because Microsoft isn't just able to use their own technologies how they should, we are forced to switch....

    Friday, February 15, 2019 7:02 PM
  • Thanks.

    Worked for me with Roaming Profiles and Scripts written in PowerShell.

    Sad Microsoft does not fix bugs in technologies supposed to be supported. Maybe they want to sell even more expensive VDI licenses.


    • Edited by CGEDVDL Wednesday, June 19, 2019 11:51 AM
    Wednesday, June 19, 2019 11:50 AM