Bitwarden problems - same user vault; works on one PC, not on another

Same problem

Hello

The engineering department were able to reproduce the issue on their side, a ticket is open for a fix!

Best Regards,

Any indication if this is software release fix or something on Bitwarden's side? I've opened a ticket with Bitwarden as well.

Hello,

Most likely an update on Bitwarden's side that broke our integration, we are still looking into it!

Best Regards,

Is this a common problem? We were about to move from LP to Bitwarden, but half (3/6) the RDM installs we've tested can't connect to Bitwarden.

I will not speculate on the impact, but this issue is quite painful for me. I have a couple dozen passwords, with a few rotating ones. I have thousands of configurations, all pointing to a my BW vault. I'm stuck using Quick Connects for everything now.

Hello,

RDM 2022.3.33 has just been released, and it contains the fix for the Bitwarden issue. Please let us know if you still have any issues after updating!

Download page: https://devolutions.net/remote-desktop-manager/home/downloadenterprise

Best regards,

Only tested one so far, but it's fixed. Thanks :)

I've updated to 2022.3.33. Still having issues. New error message now. Error message is PasswordManagerAccess.Common.BadCredentialsException: Client ID or secret is incorrect.

I've checked, rechecked, and even changed my API key. The irony is that I can query my Bitwarden vault to select a login, but when I attempt to make the connection to RDP server, website, etc., it fails.

This is the full error.

PasswordManagerAccess.Common.BadCredentialsException: Client ID or secret is incorrect
at PasswordManagerAccess.Bitwarden.Client.LoginCliApi(String clientId, String clientSecret, String deviceId, RestClient rest)
at PasswordManagerAccess.Bitwarden.Client.OpenVaultCliApi(String clientId, String clientSecret, String password, String deviceId, String baseUrl, IRestTransport transport)
at PasswordManagerAccess.Bitwarden.Vault.Open(ClientInfoCliApi clientInfo, String baseUrl)
at Devolutions.RemoteDesktopManager.Managers.BitwardenManager.InitializeAPIKey(String clientId, String clientSecret, String password, String customUrl, Boolean isSilent)
------------------------ extended stack ------------------------
at Devolutions.RemoteDesktopManager.Managers.LogManager.LogError(Exception e)
at Devolutions.RemoteDesktopManager.Managers.BitwardenManager.InitializeAPIKey(String clientId, String clientSecret, String password, String customUrl, Boolean isSilent)
at Devolutions.RemoteDesktopManager.Business.CredentialBitwardenResolver.Execute(Connection credConnection, Connection owner, CredentialRepositoryDestination destination)
at Devolutions.RemoteDesktopManager.Managers.CredentialTypeManager.ResolveCredentials(Connection connectionCredential, Connection owner, CredentialRepositoryDestination destination, CredentialResolveMode credentialResolveMode, Boolean resolveSensitive)
at Devolutions.RemoteDesktopManager.Business.CredentialPersonalCredentialResolver.Execute(Connection credConnection, Connection owner, CredentialRepositoryDestination destination)
at Devolutions.RemoteDesktopManager.Managers.CredentialTypeManager.GetCredentialResolved(Connection connection, String credentialConnectionID, CredentialRepositoryDestination destination, CredentialResolveMode credentialResolveMode, Connection inheritingConnection, OpenConnectionParameter openConnectionParameters, CredentialsResult credentialsResult)
at Devolutions.RemoteDesktopManager.Managers.CredentialTypeManager.PrepareCredentials(Connection connection, String credentialConnectionID, CredentialRepositoryDestination destination, String privateVaultSearchString, CredentialResolveMode credentialResolveMode, Connection inheritingConnection, OpenConnectionParameter openConnectionParameters, CredentialsResult credentialsResult)
at Devolutions.RemoteDesktopManager.Managers.ConnectionManager.Prepare(Connection connection, Boolean applyCredentials, Boolean applyAlternate, Boolean applyVPN, Boolean copy, Boolean applyOverrideCredentials, Boolean isOverrideCredentials, CredentialResolveMode credentialResolveMode, OpenConnectionParameter openConnectionParameters, CredentialsResult credentialsResult, Boolean isClosing)
at Devolutions.RemoteDesktopManager.Managers.ConnectionManager.OpenConnection(Connection connection, OpenConnectionParameter parameter)
at Devolutions.RemoteDesktopManager.Managers.ConnectionManager.OpenConnections(Connection[] connectionList, OpenConnectionParameter parameter)
at Devolutions.RemoteDesktopManager.Managers.ActionManager.DoOpenConnection(Connection[] currentConnections, OpenConnectionMode openConnectionMode, IConnectionSource source, Dictionary`2 openingAttributes)
at Devolutions.RemoteDesktopManager.Managers.ActionManager.OpenConnections(Connection[] currentConnections, OpenConnectionMode openConnectionMode, IConnectionSource source, Boolean checkOpenedConnection)
at Devolutions.RemoteDesktopManager.Frames.ConnectionViews.FreConnectionTreeListView.OpenOnDoubleClick(Boolean isEmbedded)
at Devolutions.RemoteDesktopManager.Managers.ThreadManager.PushTimer_Tick(Object sender, EventArgs e)
at System.Windows.Forms.Timer.OnTick(EventArgs e)
at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at Devolutions.RemoteDesktopManager.Program.Main(String[] args)

Hello,

@Krishaven - thank you for reporting it is now working.

@AuxMax001 - it is unusual you can see the credential list, but cannot use it afterward. Could you try to create a new Bitwarden entry (not a duplicate) and see if you get the same error? If you do, could you go to Help > Application logs and see if it is the only error being returned?

Best regards,

I've tried to delete and recreate the Bitwarden entry. No change. The application log error was pulled from RDM. It is the only error message being returned.

I continued to troubleshoot this morning. Some further discoveries.

• I deleted all references to Bitwarden and created a brand-new entry, located in a different folder with a different name.
• Obviously, this will invalidate my saved entries, so I updated one connection with the new credential entry. It was an RDP connection. The Bitwarden error does not appear, but the RDP connection is prompting for a username and password, despite being linked to the credential entry.
• Initially, I had the API configuration as part of my "My Account Settings", using the checkbox to reference these settings. I've also tried entering the same API information into the credential entry. I'm still getting prompted for a username and password.
• As noted before, I have each connection entry setup as a Linked (Vault), referencing the Credential entry, and selecting the correct authentication from the Bitwarden Vault entries.

Thank you for the continuing assistance

Hello,

As a test, would it be possible for you to create a portable installation of the latest version of RDM and see if this issue still occurs? To do so, you will need to do the following:

1- Download the .zip file below:
https://remotedesktopmanager.com/home/thankyou/rdmbin
2- Create a new folder on your Desktop
3- Extract the content of the .zip file into the folder created at #2
4- Go to this folder once the .zip file has been extracted and run remotedesktopmanager.exe

Using the local data source of the portable version, add a Bitwarden entry and an RDP session and verify if the issue still occurs. This test will allow us to rule out your local installation of RDM as a possible cause for this issue.

Is it still gives an error, we will investigate further on our end.

Best regards,

Thanks for the reply. I found the problem. It was misconfiguration on small number of heavily used connection entries. I forgot to undo some of my trial and error settings when the initial Bitwarden problems started. Sorry for the fire drill.

Hello,

Great, glad to hear it works!

Best regards,

Strange, we have the problem again this morning, although we have installed 2022.3.33.0

PasswordManagerAccess.Common.InternalErrorException: Server responded with an error: 'Traffic from your network looks unusual. Connect to a different network or try again later. [Error Code 2]'
bei PasswordManagerAccess.Bitwarden.Client.LoginCliApi(String clientId, String clientSecret, String deviceId, RestClient rest)
bei PasswordManagerAccess.Bitwarden.Client.OpenVaultCliApi(String clientId, String clientSecret, String password, String deviceId, String baseUrl, IRestTransport transport)
bei PasswordManagerAccess.Bitwarden.Vault.Open(ClientInfoCliApi clientInfo, String baseUrl)

here also again the same problem

Yeah, mine's broken again too.

Ditto. Broken this morning.

Hello,

The engineering team is currently working on the issue. We will report their findings once we have more details.

Best regards,

Hello,

The issue should now be fixed for Bitwarden, the issue was on their end.

Best regards,

It appears to work for the first authentication attempt, but any after that fail.

Hello Roland,

Thank you for the feedback, I provided it to the engineering team; we will keep you posted.

Best regards,

Hello Roland,

Are you using one Bitwarden entry or multiple ones? When we try it on our end with 2022.3.33, if we do a view password multiple times on the same entry, it works as expected.

Best regards,

I am running 2022.3.33 (As of this morning).

I have tried with multiple credential entries in RDM that point to different credentials in Bitwarden.

The only other thing I'd mention is that I rotated my API key earlier this morning when things when I discovered things were failing, and before I came to the forums and didn't know I wasn't the only person with the issue.

If I close RDM, and reopen it, I can successfully retrieve a credential once. After that it fails. It does not seem to matter if I use the same credential twice, or two different credentials.

Hello Roland,

The engineering team would like to know if you are using Win 10 or Win11? Our tests were performed on Win 10, the behaviour may be different on Win 11.

Best regards,

I'm on Windows 11.

I'm seeing that "only works first time" problem too. The Windows 11 VDI that didn't work at all before only works once, while the Windows 10 PC that worked during the problems before works normally at the moment.

Hello,

Thank you both for confirm the issue seems to occur only on Win 11. The engineering team is currently working on the issue, we will keep you posted.

Best regards,

I have the problem on windows 10, but since today it is working again ...

Still a problem this morning. Will also work the first time after unlocking RDM, but second attempt errors.

Still a problem this morning. Will also work the first time after unlocking RDM, but second attempt errors.

I tried this, but it did not work for me. Locking/Unlocking does not allow me to retrieve a credential.

Well, did work once after I reconnected to my VDI via remote desktop and unlocked RDM

Hello,

Thank you for the updates. Unfortunately, the engineer that handles the Bitwarden integration is not available until next week, we will need to wait until he can verify what the issue is.

Best regards,

today again it is not working ....

Yeah...dead in the water as well this morning. This is getting irritating.

I just sent a support request directly from RDM. I'm using version 2022.3.35 64-bit on Windows 10 and I have the same issue. The error message in the logs reads:

Traffic from your network looks unusual. Connect to a different network or try again later.

As is described on the Bitwarden help page, this is not necessarily a network issue but can be an issue with the client used to access Bitwarden. Since I can run the cli fine on the same PC, it's clear that the issue is with RDM.

I'm in the same position as some of the other users in this thread, if Bitwarden doesn't work in RDM, things get very complicated for me.

Hello,

Thank you for the updates. The engineer that handles the Bitwarden integration will be able to look at the issue this week, we will keep you posted on his progress.

Best regards,

Any updates on this issue with Bitwarden?

Hello,

The engineer is working on the issue, but we do not have an ETA yet when a fix will be available. We will keep you posted when we have more details.

Best regards,

We have continued moving forward with our LastPass to Bitwarden migration on the understanding that is would be an important enough problem that it would be resolved quickly. The outage is now starting to bite, limiting the migration project to specific PCs, and confusing some of the users attempting to get set up to use some of our new processes. It is now extremely urgent. If the outage continues for much longer, we can only assume that future outages will be of a similar duration and reconsider the services and products we rely on.

Hello,
I understand your frustration but you have to also understand that we are not the developer of Bitwarden. It's a third party that we integrate and we haven't broken anything. We have to find a solution to fix something done on their side. I assure you that we don't like this situation but it's not something simple to fix. I could offer you to try Devolutions Hub Business and even give you a free one year licence. I just hope you don't think that we do that on purpose to sell or product because it's not the case. I'm offering you this because we have full control over the code and the hosting.

https://blog.devolutions.net/2023/02/devolutions-hub-business-security-first-from-day-one/

Regards

Hello,
I understand your frustration but you have to also understand that we are not the developer of Bitwarden. It's a third party that we integrate and we haven't broken anything. We have to find a solution to fix something done on their side. I assure you that we don't like this situation but it's not something simple to fix. I could offer you to try Devolutions Hub Business and even give you a free one year licence. I just hope you don't think that we do that on purpose to sell or product because it's not the case. I'm offering you this because we have full control over the code and the hosting.

Hi David,

Thank you. After an internal discussion, we believe that our best risk-management approach is for our remote connection tool and our password manager to be from the same vendor, since smooth function is mission critical. The owner where I work will reach out to your marketing team.

Switching to another password manager is not a solution for us, unfortunately, at least not at this time.

You're saying the problem is "not easy to fix". I think most of us in the forum are quite technical people, some of us with a development background. It may alleviate some of the tension if you offered more transparency about what the issue actually is and what you're doing to fix it, specifically. If it's really Bitwarden that needs to do something, I'd be happy to push them from my side as well but I need to understand what to push them for.

Hello vt,

We haven't been able to reproduce this issue in our debug environment, which is one source of why it's taking us longer than we'd like to identify and fix the issue.

What we think is the problem, is that Bitwarden uses a system like Cloudflare to detect suspicious/bot traffic and blocks calls coming from RDM. The library we use is based on the Bitwarden CLI, but it's not exactly 1-to-1 to it. We haven't changed anything in the integration recently, and we know that Bitwarden had a few maintenances recently to upgrade their infrastructure. There's a good chance it started happening around that time.

At present, we're not sure what could be causing the trigger on Bitwarden's side. A theory is that maybe TLS sessions at the OS levels are reused and it triggers the bot protection system Bitwarden uses.

I hope this helps answer your questions. We're still in the investigation phase and we have someone actively looking into it. It's a priority for us since it's affecting many of our users. As David said, integrating different password managers and third party tools is core to RDM's philosophy, and we hope to fix this as soon as we can.

Regards,

After Hubert's much appreciated explanation of the problem, I got curious, particularly since he mentioned that nothing was actually changed in the integration. So, I decided to address Bitwarden directly and ask them to support the team here.

They asked me if it was error code 2 I was affected by. After my confirmation, they requested my external IP and some time later asked me to try it again. Voilà, all worked again.

I asked them to explain what the problem was. Here's the answer I received.

I think you were getting caught up in one of our systems; we needed to release the IP address.

So, anyone else affected by this issue, I strongly recommend to get in touch with Bitwarden. It seems we're blaming the wrong people. Color me embarrassed.

Hello vt,

I'm glad you could get this solved! I have forwarded this information to Richard who will recommend this solution to our other users who have reported encountering this issue. It's a hassle, but it confirms that (unless I'm wrong) it's caused by Bitwarden's systems and not by our integration. Thank you for getting back to us with this information.

Still, I'm still bothered by some of the behaviors. Namely, some of our users (and some of our machines, from testing internally) are able to connect to Bitwarden once, but any subsequent connection will fail with that error. Restarting RDM seems to solve the issue, but it will still only let you connect once before starting to fail again. It doesn't seem consistent with a strict IP block from their system, but maybe it's the same system causing that issue. We will keep investigating on our end to see if we can find out anything our integration may be doing improperly.

Regards,

We have multiple IP address at work. I moved my problematic VDI from one gateway to another, to one that also has working RDMs, and experienced the exact same problem. If Bitwarden needs to exclude IPs from their security filter so that third-party integrations work, this makes me feel even better about our main support app and our password manager coming from the same place.

Best of luck to the Devolutions team.

I am runiing Windows 11 - RDM 2022.3.35.0 and experienced the connect once issue and then fail.
I reached out to Bitwarden support supplying them with my static IP and 12 hours later problem resolved!!

Hi,

Had some contact with Bitwarden support for this issue and today I got the following response:
Hi
Matthew,
I'm sorry that I didn't manage to get back to you before the weekend.  Our
cloudops team has now made some changes - could you please confirm whether you
are now able to log in?


Everything works fine for me from all IP addresses now on our side!

Regards,
Matthew

Hello,

Thank you everyone for confirming the issue is on the Bitwarden side. The engineer in charge of the integration was not able to replicate the issue, but it seems there is nothing we can do on our end, you (unfortunately) need to contact Bitwarden directly.

Best regards,

Thank you Matthew and Tim for getting back to us. I'm glad it now works for you, especially since it seems to even solve the issue where the first connection worked but not the next ones.

Regards,

Just dropped by to confirm that everything is working for me as well today.

I'd like to thank everyone that worked on this.

Thanks again!
Roland