Closed BenKu82 closed 4 years ago
Where does that path variable inside ...\appdata\local\KeepassXC\org.keepassxc.keepassxc_browser_edge.json
point to?
This is the content:
{ "allowed_origins": [ "chrome-extension://pdffhmdngciaglkoonimfcmckehcpafo/", "chrome-extension://oboonakemofpalcgghocfoadofidjkkk/" ], "description": "KeePassXC integration with native messaging support", "name": "org.keepassxc.keepassxc_browser", "path": "C:\\Program Files\\KeePassXC\\keepassxc-proxy.exe", "type": "stdio" }
Is keepassxc-proxy.exe
running when you start the browser?
Yes, it is running.
In this case your only chance is to use https://docs.microsoft.com/en-us/sysinternals/downloads/procmon and find anything related to KeePassXC. It could show what registries and files Edge tries to load.
Ok, I made a run with Procmon.
Is it correct, that msedge.exe is searching in a Google Chrome registry path?
High Resolution Date & Time: 12.08.2020 14:06:48,4952256 Event Class: Registry Operation: RegOpenKey Result: NAME NOT FOUND Path: HKLM\SOFTWARE\WOW6432Node\Google\Chrome\NativeMessagingHosts\org.keepassxc.keepassxc_browser TID: 16668 Duration: 0.0000399 Desired Access: Query Value
No that's definitely not correct. But it's not the first time we've heard that Chromium-based browsers are searching for Chrome's registry paths.
Try to enable Chrome support in KeePassXC if that solves the problem.
Now I tested every possible constellation of activated and deactivated browser supports.
It does not solve the Problem.
It´s funny. msedge.exe is searching in both registry pathes. For Google Chrome and for Edge.
High Resolution Date & Time: 12.08.2020 14:06:48,4947416 Event Class: Registry Operation: RegOpenKey Result: NAME NOT FOUND Path: HKLM\SOFTWARE\WOW6432Node\Microsoft\Edge\NativeMessagingHosts TID: 16668 Duration: 0.0000260 Desired Access: Query Value
So, does it also look for HKEY_CURRENT_USER\Software\Microsoft\Edge\NativeMessagingHosts
or just the registry paths under WOW6423Node
? If so, you could try to copy the values from the first registry path.
Why are you running 32 bit edge on 64 bit windows
In HKLM iit is searching for, but it does not exist. In HKCU it is not search for, but it does exist. We are running MS edge in 64bit on Win10 64bit. Funny is, that Microsoft is still installing the 64bit version to Program Files (x86).
That's really odd. Is edge installed in enterprise managed mode? FWIW edge integration has worked flawlessly since we introduced this to the code base.
I experience the same problem. Edge is installed in enterprise management mode however. Will that make an effect?
Is "Isolated Browsing" via MS Defender Application Guard enabled?
In my case (corporate computer with corporate MS Edge) Isolated Browsing is not installed.
I believe I've found the issue. Microsoft publishes security baselines for several of their products in the form of group policy objects (which we're applying at my company), and one of the policies therein is causing this problem. User-level native messaging hosts are blocked in the baseline policy, which prevents Edge from searching HKCU for the manifest:
I was able to publish the same path to HKLM, which got browser integration working, but this is definitely a hack:
Creating a second configuration file at C:\ProgramData\keepassxc\org.keepassxc.keepassxc_browser_edge.json for KeepassXC during its installation with a matching registry entry in HKLM seems like a much cleaner solution, perhaps selecting specifically for installations by users with administrative privileges.
@gnr8shn You can verify that this policy is applying on your PC by asking your IT department or (if you have local admin rights) running gpresult /h {filename}.html
in an elevated CMD or PowerShell session and reviewing the output.
Hi @detharonil gpresult showed the following: Software\Policies\Microsoft\Edge\NativeMessagingUserLevelHosts | 0 | C - Microsoft Edge The ADMX was not available so it's raw, but importantly the value is 0 which seems to align with "disabled".
I copied the setting from HKCU to HKLM which worked.
So a good result for those on non-shared machines with administrative privileges. A hack indeed, but we're trying to circumvent an administrative/corporate lockdown so this is fair.
Thanks for following this up!
It looks like a few changes can be made to src/Browser/NativeMessageInstaller.cpp to make the non-portable version create the json files in C:\ProgramData and write the appropriate entries into HKLM instead of HKCU, but I'm not sure what changes would be needed to force KeePassXC to create all of the files at install time rather than when they are enabled in the UI. Here's the diff, if it could be useful, but I won't make a pull request out of this due to its incompleteness:
diff --git a/src/browser/NativeMessageInstaller.cpp b/src/browser/NativeMessageInstaller.cpp index 8b038f61..15172fc5 100644 --- a/src/browser/NativeMessageInstaller.cpp +++ b/src/browser/NativeMessageInstaller.cpp @@ -52,16 +52,16 @@ namespace const QString TARGET_DIR_EDGE = QStringLiteral("/Library/Application Support/Microsoft Edge/NativeMessagingHosts"); #elif defined(Q_OS_WIN) const QString TARGET_DIR_CHROME = QStringLiteral( - "HKEY_CURRENT_USER\\Software\\Google\\Chrome\\NativeMessagingHosts\\org.keepassxc.keepassxc_browser"); + "HKEY_LOCAL_MACHINE\\Software\\Google\\Chrome\\NativeMessagingHosts\\org.keepassxc.keepassxc_browser"); const QString TARGET_DIR_CHROMIUM = - QStringLiteral("HKEY_CURRENT_USER\\Software\\Chromium\\NativeMessagingHosts\\org.keepassxc.keepassxc_browser"); + QStringLiteral("HKEY_LOCAL_MACHINE\\Software\\Chromium\\NativeMessagingHosts\\org.keepassxc.keepassxc_browser"); const QString TARGET_DIR_FIREFOX = - QStringLiteral("HKEY_CURRENT_USER\\Software\\Mozilla\\NativeMessagingHosts\\org.keepassxc.keepassxc_browser"); + QStringLiteral("HKEY_LOCAL_MACHINE\\Software\\Mozilla\\NativeMessagingHosts\\org.keepassxc.keepassxc_browser"); const QString TARGET_DIR_VIVALDI = TARGET_DIR_CHROME; const QString TARGET_DIR_TOR_BROWSER = TARGET_DIR_FIREFOX; const QString TARGET_DIR_BRAVE = TARGET_DIR_CHROME; const QString TARGET_DIR_EDGE = QStringLiteral( - "HKEY_CURRENT_USER\\Software\\Microsoft\\Edge\\NativeMessagingHosts\\org.keepassxc.keepassxc_browser"); + "HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Edge\\NativeMessagingHosts\\org.keepassxc.keepassxc_browser"); #else const QString TARGET_DIR_CHROME = QStringLiteral("/google-chrome/NativeMessagingHosts"); const QString TARGET_DIR_CHROMIUM = QStringLiteral("/chromium/NativeMessagingHosts"); @@ -211,7 +211,7 @@ QString NativeMessageInstaller::getNativeMessagePath(SupportedBrowsers browser) if (QFile::exists(QCoreApplication::applicationDirPath() + QStringLiteral("/keepassxc.ini"))) { basePath = QCoreApplication::applicationDirPath(); } else { - basePath = QStandardPaths::writableLocation(QStandardPaths::DataLocation); + basePath = QStandardPaths::standardLocations(QStandardPaths::AppConfigLocation).at(1); }
The implications of that could also be ugly, as browser integration could only be globally enabled or disabled rather than selected for a given browser. I'm not sure what to suggest beyond that.
EDIT: The above remark may be inaccurate; the presence of the .json files doesn't appear to impact the program's ability to accept or reject browser connections. I'll let someone more familiar with this chime in.
This is not the solution as it will break normal Edge deployments (ie, non managed). Given that managed deployments are controlled by sys admins, they should manually deploy the registry key to point to a valid json configuration file using GPO.
The custom browser option originally had a feature to add custom registry paths with Windows. Maybe we should try to bring it back and finish the feature?
The problem here is that any competent IT department would have HKLM locked down for the users. They are not able to make changes to that part of the registry.
If the program's installation requires admin privileges, then how would placing the .json files in C:\ProgramData and the pointers in HKLM break operation for typical users? If KeePassXC is capable of accepting or rejecting browser plugin connections based on its configuration rather than the presence of these files, then why not let that be the point of control? Sure, our IT department can modify the installation to perform the steps above, but I can't seem to figure out why it's not done that way from the start since the default installation of KeePassXC is multi-user.
You are missing the point. We don't pre-install any registry keys for native messaging, they are controlled by the user. As a result, in order to support native messaging in a controlled computing environment (eg. HKLM registry) then it will need to be done by the system administrators.
Solution via GPO and software deployment:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Edge\org.keepassxc.keepassxc_browser] @="C:\ProgramData\KeepassXC\org.keepassxc.keepassxc_browser_edge.json" `
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge] "NativeMessagingUserLevelHosts"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallAllowlist] "1"="pdffhmdngciaglkoonimfcmckehcpafo"
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\NativeMessagingAllowlist] "1"="org.keepassxc.keepassxc_browser" `
@detharonil Thank you very much for your research result!
We'll add that to the documentation
That said, an installer option to pre-install these makes total sense.
@BenKu82
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Edge\org.keepassxc.keepassxc_browser]
The path is [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Edge\NativeMessagingHosts\org.keepassxc.keepassxc_browser]
any tips on fixing this for Edge on Linux? I'm having the same problem with KeePassXC 2.6.6 and Edge 97
Use the custom browser option under the advanced tab. We don't support beta browsers natively through the gui. Although they released a stable edge on Linux.
I had found this article mentioning the custom browser field under the advanced tab, but mine doesn't have it?
Also, in the General tab, it only says that "browsers installed as snaps are currently not supported" and there are no checkboxes for "enable integration for these browsers", like shown in the article
While I do have bad memory, I don't remember installing Edge via snap (and bash history supports that, heh)
@joaociocca It should be on the advanced tab. Another solution is to copy or make a symbolic link of the JSON script file. Probably the path is something like /microsoft-edge-beta/NativeMessagingHosts
instead of the default /microsoft-edge/NativeMessagingHosts
under your .config
.
This helped me in 2024. Thank you. After updating KeePassXC within the last 3 days the browser extension started saying it couldn't connect to the database. When trying to reset the connection, both in the program and extension and restarting each program, the KeePassXC-Browser wouldn't respond when selecting Connect, nothing would pop-up to prompt anything. Additionally, removing the browser extension and reinstalling it didn't resolve. After confirming everything else was configured, working and running properly, copying the regkey from current_user to local_machine and restarting the browser worked.
@bsarrowood Glad the bruises on my forehead weren’t for nothing, lol
Overview
KeepassXC Extension is not connecting to database in Edge.
Steps to Reproduce
Expected Behavior
Opening Browser Access Request.
Actual Behavior
Message: Cannot connect to KeePassXC. Check that browser integration is enabled in KeePassXC settings.
Message after clicking Reload: Key exchange was not successful.
Context
Debug info: KeePassXC - unknown KeePassXC-Browser - 1.6.6 Operating system: Win32 Browser: Microsoft Edge 83.0.478.61
We are using KeepassXC 2.6.0
Operating System: Windows 10 x64 1809 LTSC