Great idea, although it would be far easier to have a registry key that forces a particular ini file (network share/default profile) so no other config changes need to be made in code. This is also more cross platform. Would this work for you?

@droidmonkey how would your scenario work if we only want to enforce certain options, such as locking timeout? The advantage to using the registry seems to be that we can be selective about properties that are enforced.

Good point, perhaps the registry key would only override the security settings from the pointed to ini file.

Is anything like this possible in the meantime? I'd like to disable update check for the whole organization.

You'd have to control their entire config file which locks out many other settings. So no, this is not possible yet.

OK, then the only solution so far is a script that runs on user login and changes the values in %APPDATA%\KeePassXC\keepassxc.ini.
Thanks anyway for the info!

EDIT: Run (Get-Content $env:APPDATA\KeePassXC\keepassxc.ini) -replace "CheckForUpdates=true","CheckForUpdates=false" -replace "UpdateCheckMessageShown=false","UpdateCheckMessageShown=true" | Set-Content $env:APPDATA\KeePassXC\keepassxc.ini

Hi, all. I noticed that the wording implies that this is not an issue / is available for Linux and Mac, but I couldn't find anything on tiered configuration setups for those either. Have I misunderstood the scope here?

Hi, is there any progress at this topic @droidmonkey? We would like to deploy KeepassXC in our company software store but a not forced configuration is a real disadvantage compared to Keepass. And scripting the user ini file is a bad workaround unless you cant really force and lock settings.

None made at this time.

do you have any timeline? What do you need to get it done?

If you have a cloning machine, that would be very useful ☺️

If you have a cloning machine, that would be very useful ☺️

☺️

Two things on this:

1. Everything saved in the Registry under HKCU or the user folder (%Appdata%) can be changed by the user without having administrative permissions. It is not enforced.
2. To enforce settings they have to be saved at a place where normal users don't have write permissions.
3. I suggest to have two files in the application folder to solve this and other "global config" problems. For best flexibility each entry should be evaluated individually.
   • keepassxc_defaults.ini (not enforced but used for settings initialisation)
   • keepassxc_enforced.ini (enforced and override all other config files.)

HKLM is where we would look for these settings. Adding config files to an installation folder is not going to happen. At worst we would consider ProgramData subfolder. For macOS and Linux, I am open to suggestions.

As macOS and Linux also use the keepassxc.ini I actually would not use the registry on Windows.

Usining a keepassxc_enforced.ini is a simple way to overwrite settings of a keepassxc.ini. An admin just has to set correct file permission rights on that file.

As macOS and Linux also use the keepassxc.ini I actually would not use the registry on Windows.

Usining a keepassxc_enforced.ini is a simple way to overwrite settings of a keepassxc.ini.

I agree.

An admin just has to set correct file permission rights on that file.

This happens automatically when C:\ProgramData or the installation directory is used. I thought for compatibility with macOS and Linux the program folder is the easiest way to go.

HKLM is where we would look for these settings. Adding config files to an installation folder is not going to happen.

@droidmonkey
Why? What is the reason for not using a file.

As macOS and Linux also use the keepassxc.ini I actually would not use the registry on Windows.

Usining a keepassxc_enforced.ini is a simple way to overwrite settings of a keepassxc.ini. An admin just has to set correct file permission rights on that file.

From an IT deployment perspective, expanding the ini model with hierarchical precedence would be an elegant solution for us in deploying KeepassXC across Windows, Mac & Linux.

Deploying defaults and enforced settings separately (as per the above _defaults.ini) is a good idea too. I did see that you can run Keepass with the -o option to load a config. Does this persist after first run? If so, perhaps there's a way to initialise this way. Perhaps another option is to set a "Default Roaming Config Template" environment variable with the default template configuration as well?

HKLM is where we would look for these settings. Adding config files to an installation folder is not going to happen.

@droidmonkey
Why? What is the reason for not using a file.

Almost all policy enforcement on Windows is done via the registry. That goes for GPO and Intune management. It's just the way Windows "prefers" to handle security policies.

Any solution we implement would likely be both file based and registry based.

any solution is welcome and yes i would prefer also registry over file but then you should use hklm\software\policies instead of hklm\software so even administrators are not able to change settings directly on the client (which is the weak point if you do it via file like keepass is doing it)

The registry route will likely take considerably more time to implement and only covers one OS, so I'd imagine the file method would be the way to go first with a view to enhancing Windows specific functionality further down the line. I see there is appetite for this, given the incorporation of Windows Hello for authentication.

Almost all policy enforcement on Windows is done via the registry. That goes for GPO and Intune management. It's just the way Windows "prefers" to handle security policies.

As someone who has to manage a bunch of Windows computers with software from various vendors I can say that it is a mess anyways 😄
Rule of thumb: The more expensive the software is, the bigger is the mess managing it 🙈

i would prefer also registry over file but then you should use hklm\software\policies instead of hklm\software so even administrators are not able to change settings directly on the client

Then admx files have to be provided. Because this policy path is not write protected for administrative users. The important point ist that gpos are reapplied periodically.

Then admx files have to be provided. Because this policy path is not write protected for administrative users. The important point ist that gpos are reapplied periodically.

even with admin rights you cant change policies path. You have to be SYSTEM user to do so. Yes, if you have admin rights you also can get SYSTEM rights but you need to know how and most admins dont know so its an extra step to achieve this.

And, yes admx files would be the icing on the cake.

@droidmonkey hi, any news here? Maybe some ETA? Yes i am still full of hope :)

Haven't worked on this at all, sorry.

hope is gone

What about saving override settings in each KeePassXC database in an additionally encrypted field * along with a check\hash?
'* Calling it: Encrypted Database Settings Field (EDSF)'

WHEN USER OPENS THE DATABASE:
When the user open the application and\or opens another KeePassXC database...
Then the application does the following:

1. unencrypts this additionally encrypted EDSF field (which are the override settings and the check\hash). See "Settings Encryption Key\Password" below.
2. Checks the settings against the check\hash (maybe not needed. Or maybe better stored encrypted elsewhere in the file.)
3. If all checks out, it sets all the values that are in the EDSF and greys out and makes them read-only to the user.

Settings Encryption Key\Password
The Settings Encryption Key\Password would be a special field of which the values can only be changed by an "Admin" account that logs into the database. So, there would need to be a new "Admin" account per database of which the "KeePassXC Database Admin" account and it's password (changeable by that account) would be stored in the database as a hash (with salt) of the password. The Encryption Key\Password settings value could possibly be an additional hash -with salt (or a FEW additional hashes-with salt) of the hash of the "Admin" password for that database.

So,

• your settings in KeePassXC would be dependent upon the database that you have open.
• And (depending on which particular KeePassXC database you have open) you may not be able to change some settings for that database.
• And administrators could pre-create a KeePassXC database using that databases "admin" account (and authentication) and then publish that database either as the default database of KeePassXC or as a shared KeePassXC database.

This obviously is some significant rework within the application itself. But, if it were all stored in each KeePassXC database, it would be platform agnostic (including registry issues etc.) and I believe meet the need here.

It's just an idea that I am offering here. But, I "think" this might work? Of course this doesn't solve the problem that it still requires man-hours of work on the application. But, maybe this is more "do-able"?

Or maybe it's not do-able at all. I don't know what I don't know. Thoughts? Feedback?

Saving settings internal to the database is a different request. This is about system administrators setting defaults for the application itself.

hi, now that passkeys is added 👍 maybe there is a time to implement a forced configuration? 🏃‍♂️