Cannot Create new Password Generator Profile In Non-enforced Configuration > 자유게시판

I'm using a "regular" installation of KeePass on a Windows server by way of RDP. Everything appears to work usually, besides the password generator: When making an attempt to save lots of a user-outlined profile, the Ok button has the additional "shield icon", and when i try to save lots of, I'm requested for the administrator password (which I don't have for the server). I tend to consider it is a bug in KeePass, as a result of once i tried the same on one other machine (Windows 10 Pro, native login), it worked. Trying it I see that a temporary file is created in %APPDATA%\Local\Temp after which renamed to %APPDATA%\Roaming\KeePass.config.xml

On the server with the problem %APPDATA%\Roaming\KeePass.config.xml may be modified, so I don't understand the problem. Version is KeePass 2.54

Last edit: Ulrich Windl 2023-11-29

wellread1 - 2023-11-29

Password Profiles are stored in the enforced configuration file starting with KeePass 2.54. See the Important section of the KeePass 2.54 launch notes. If writing to the KeePass program directory requires administrative privileges, they're additionally required to avoid wasting password profiles. An administrator can create just a few effectively designed general use password profiles and save them to the enforced configuration file.

Last edit: wellread1 2023-11-29

Ulrich Windl - 2023-11-30

So if an enforced profile doesn't exist, and the password generator profiles are saved within the user's profile, any new password generator profiles could be saved in a newly-created enforced profile, whereas a consumer could still define new password generator profiles by simply editing the consumer's profile? If that is true, that is at the least a really unhealthy design, but I believe that is simply a bug (function not utterly implemented).

Despite of that I think the text in the release notes is quite complicated:

If you want to continue utilizing your profiles, open the 'Password Generator' dialog (through the principle menu merchandise 'Tools' → 'Generate Password'), click on the shield button (prime right) and examine all profiles (with regard to safety, privacy, functionality, compatibility, etc.).

The "you" that may want to use his/her profiles is probably not the "you" that did install the software (and thus has admin rights), meaning: The "shield icon" is barely available for directors, right?

Last edit: Ulrich Windl 2023-11-30

You can save profiles within the database (form of) as an alternative to the config file. https://sourceforge.net/p/keepass/dialogue/329220/thread/41d6d34b9d/

Paul - 2023-11-30

Profiles are moved to the enforced config file. You may no longer use / retailer them within the user config file.

wellread1 - 2023-11-30

So if an enforced profile doesn't exist, and the password generator profiles are saved in the user’s profile, any new password generator profiles could be saved in a newly-created enforced profile, whereas a consumer could nonetheless define new password generator profiles by simply enhancing the user’s profile?

The assumptions within the assertion above are incorrect. If the enforced profile (enforced configuration file) does not exist, KeePass ignores and discards password generator profiles added to the consumer config file. The brand new design improves safety. It prevents a malicious actor with consumer level entry to a pc from surreptitiously including or modifying password generator profiles.

I believe the release notes should point out clearly what the administrator should do to permit customers to create or continue utilizing their password generator profiles.

There are a couple of options:

- The administrator can install, or permit customers to install, a private copy of KeePass right into a user writable listing.

- The administrator can add just a few customized password profiles that collectively fulfill 99% of the password composition necessities imposed by websites. A few handy password era profiles which might be organizationally authorised, extensively compatible, and generate robust passwords will enhance the organization’s security and relieve the burden on customers, whose lives probably don’t revolve around creating sturdy passwords. This job should fall effectively within the abilities of an administrator that has experience creating passwords.

- The administrator can edit the enforced configuration file and add MergeContentMode="Merge" to the /Configuration/PasswordGenerator/UserProfiles element.See the Content Modes - Attribute ‘MergeContentMode’ (2.x) section, and the warning therein, of the KeePass Endorced Configuration documentation. The user will then be able so as to add as many customized password generator profiles as they wish by editing their native copy of the keepass.config.xml.

Dom - 2023-12-24

It seems to me that this change has had a unfavorable affect on common users ( non- company & residence person ) and I am trying to know why this has been inflicted on us. Up to now all I can find is imprecise references to "security concerns', what are these concerns and the place is the discussion of them. Can anybody explain the rational behind this alteration?

Paul - 2023-12-25

https://sourceforge.net/p/keepass/dialogue/329220/thread/a146e5cf6b/

Dom - 2023-12-25

Thanks for the short reply. No desirous to drag up am previous ( and messy concern ) however... If I read that appropriately there was a theoretical problem with triggers and exporting databases with out prompting the consumer, which if Keepass was configured via enforced config to require a password for export was an non concern. Type of line being on the opposite side of an airtight hatch as Raymond Chen would say.

And now because of that discussion there are no extra per consumer triggers or password generator profiles and there is no configuration choices to have these per user ?

Cheers, Dom

Theoretical, yes.

Triggers/password profiles are nonetheless out there. Either retailer them in the enforced config (requires admin entry), or use KeePass portable.

Either retailer them within the enforced config (requires admin access), or use KeePass portable.

The enforced config file is shared so that isn't per person.

As far as I can inform Portable would required a separate copy per person so no potential for any central admin.

For my use case we've shared computers with one Admin user and multiple regular users I can't have correct per user triggers without giving up all enforced config. These are household computers and previous to this transformation I was able to set per person triggers to open the right database for my children after they logged on without them having to have the grasp password. From a security point of view that is acceptable as it will require the techniques is already compromised or admin rights for another person to changes these.

This seems like this is a worst of each worlds type compromise, are there any plan to evaluation this design decision ?

are there any plan to evaluate this design resolution ?

And replace it with? All options welcome. :)

Hi Paul,

Perhaps an possibility in the enforced config file that allows per person triggers. There is/was one "MergeContentMode" which appeared like it will do precisely this with a price of 'merge' however in my testing does not. Either make MergeContentMode="Merge'/ "substitute implicitly allow per consumer triggers or add a brand new config parameter that explicitly enable, one thing like true beneath Application >> TriggerSystem

The second approach might be higher then no one can complain, like in the thread you referenced, that it's a safety issue as it is specific management of a 'new' function and can't be performed without write permissions to the app listing. That manner these of who need this and may take duty for our own security can allow it.

Perhaps for the Password generator profiles a parameter true alongside the present true. In case of conflicts with names then the Enforced config profile wins.

Given a choice between these two I would vote for the per consumer triggers to be accessible over the per person password profiles.

Thanks, Dom

Last edit: Dom 2023-12-26

Paul - 2023-12-26

At present the triggers within the user config are disabled so the "merge" operate now not works. We'd in all probability want a new mechanism to comprise / management per user triggers. Trigger within the database have been prompt, however that would not work in your situation, but password profiles in the database would.

Last edit: Paul 2023-12-27

At present the triggers within the user config are disabled so the "merge" function no longer works. We'd most likely need a new mechanism to comprise / control per consumer triggers.

How about the idea of a 'PerUserTriggersEnabled' config parameter in the Triggers config part of the enforced config file ?

Already doable, there's simply no UI. See https://sourceforge.internet/p/keepass/discussion/329220/thread/f3a64df33e/?restrict=250#ed64/7fe7.

Thanks for the enter and may I say I actually admire the work you do to make this wonderful software.

I have adopted that once more and I've it working again with Triggers and Password Generator profiles in my KeePass.config.xml under \AppData\Roaming\KeePass. If I edit the triggers in the GUI they all get copied to the enforced config file. I am pretty certain that's where I got misplaced in this got here right here searching for solutions.

I assume that they are going to then run for all customers and we will see permission errors as we try to read from different users directories ?

Dominik Reichl - 2023-12-26

I'm glad that you want KeePass :-)

You can create person-specific triggers as described on this web page: https://keepass.information/assist/v2/triggers.html (section 'User-Specific Triggers').

Best regards, Dominik

Dom - 2023-12-26

Hi Dominik,

Ok. Then I am greatest not to even strive per user triggers, just have all of them within the enforced config files predefined by an admin person and the use the atmosphere variable characteristic to make them only run when specific customers are logged on in order to only open the right customers database ?

Surely I can't be the just one who thinks this is lots of hoops to leap thru to get back performance that was in Keepass up till a couple of version in the past. Doubly so as these modifications stem from a claimed security challenge that seems extra primarily based on the mus-understanding of home windows security model by one consumer that being an actual problem.

I really do hope you see clear to overview this and make it's configuration and operation less like a check of endurance though I can perceive if are past it and wish to move on with other features..

Regards, Dom

Actually now I've given this somewhat more thought I believe this feature is working backwards. The way in which it really works proper now non enterprise users have to jump via hoops to get the software program to behave as one would reasonably anticipate. If company /enterprise admins want enforced config it must be on them to choose in by creating and deploying the enforced config file. In absence of a enforced config file Keepass should do the setting as per consumer store within the customers profile.

Mathias Hjärtström - 2024-05-14

I'm very annoyed with this new "function", because it solely appear to make life much tougher.

Using KeePass in portable mode, I cannot seem to edit either the regular or enforced configuration in order that the settings in PasswordGenerator UserProfiles are dealt with in even a remotely understandable means. I've tried MergeContentMode in Merge/Replace, setting values in in both the person or enforced configurations, or both, eradicating the setting from both of them or whatever...

I simply need to have a dependable configuration file that truly does what it claims to do. If I make a change, it should apply next time I open this system and if I copy the configuration files the identical settings should apply the identical way each and every time!

Have you ever even tried operating this system in portable mode...?

Working superb for me using V2.Fifty six portable.

How have you ever installed KeePass? Is the folder containing KeePass.exe writable? Do you could have this in KeePass.config.xml?

false

cheers, Paul

Mathias Hjärtström - 2024-05-15

I've simply unpacked the compressed file into a directory, where the config files are saved alongside the KeePass executable. It's writable and the mentioned setting is current in the file, yes.

Ahmad MughaL - 2024-05-15

Very Helpful content material

For those who want to discuss with this remark someplace else in this challenge, copy and paste the following hyperlink:

-

Paul - 2024-05-15

If you already had KeePass put in the portable model would choose up these settings and attempt to save lots of the profiles within the installation directory.

To fix this, make a new KeePass.config.xml in the portable directory. See this put up.

In case you loved this short article and you would want to receive details regarding super password generator i implore you to visit the site.