Alternatives to Referencing Custom Field that isn't overly complicated.

  • MarsXmc

    MarsXmc - 2014-04-11

    Hello all,

    I'm curious about Reference fields and their implementation with Custom Fields. I've opened two feature requests however it was suggested that I open a discussion instead, if you wish to see the tickets I've open you can go here: Ticket #1848 and Ticket #1849

    The Thing is that according to the documentation in regards to this matter:
    "Referencing fields of other entries only works with standard fields, not with custom user strings. If you want to reference a custom user string, you need to place a redirection in a standard field of the entry with the custom string, using {S:<Name>}, and reference the standard field."

    Which although it is nice in some situation, is definitively not ideal for those things that have many custom fields. From my understanding of the above it seems to me that it means that if I wanted to use a custom field in another entry I would first have to reference it into either {Title | User Name | Password | URL | Notes} then reference one of those fields to the new entry.

    Definitively not ideal if I already used up those entries. Maybe perhaps it can be referenced in the notes and then the notes can be searched in but I haven't tried that and not sure how that would go. I don't think those are reference fields but placeholder's and I'm not sure you can use that as a reference.

    Since wellread1 suggested that only a "very compelling use case" could spur on this implementation I'm tempted to list my use case and perhaps others can do the same to see if this is really just me that wants it implemented this way or if all of you also would like it if this feature was available, and maybe somebody out there has already found a work around that isn't as cumbersome as the double entry of referencing the custom field in a main field.

    My Use Case:
    O=Custom Fields

    User: Sysadmin
    Folder: Physical/Virtual Server 
        2 Entries:
            *Linux Root User Credentials
                Has {TUPAN} {O}[2]: Server Management URL
                                     Web space Management URL
                Has {TN}

    In this very top level I could combine the Notes of both of these entries all into custom fields so that I can have

    Custom Parameters
    IP Range:
    SSH Port:
    Server Administration URL:
    User Admin URL:
    Email Access:
    Subsequent folders under the server are: {email | MySQL | Web Accounts}
    Web Accounts has each individual website account under it {Account1 | Account2 | etc... }

    │├Web Account 1
    │├Web Account 2
    │├Web Account 3
    │└Web Account 4

    Now In the Website Account folder I have an entry for the administrative user.
    which has a Username and A Password

    It's custom field could reference the User Admin URL discussed earlier as well as the IP it's assigned to. Ports Excetera.

    Under the Email section each user could have the Email url link with the port, IP, username could be partly referenced where the user name might be username@{REF:SiteDomain} things like that.

    It would save a lot of retyping when say an IP changes. Domains don't really change that often but their location or ports can. Usernames might change on some occasions. Email login method if you move servers can get complicated. Moving from one system to the next required me to change 100 some odd records from user+domainname.topleveldomain to emailuser.domainusername which was a pain. In that case I would still have to change the format but I wouldn't have to retype everything. Unsure if I'm making a good point or not.

    We also have SSH properties and my team members have a hard time knowing how to use them as it's complex, I refuse to retype everything in the notes or in custom fields as it's repetitive and if those changes well there again I have to change a bunch of entries

    That's my use case. Anybody have a more compelling one to share?
    Anybody have alternatives to circumnavigate repetitive entries?

    Thanks for any feedback.

  • wellread1

    wellread1 - 2014-04-11

    As I understand your problem you have a need to store and reference multiple pieces of 'Master Data' such as: URLs, IP addresses, port numbers, site Domains, etc. You wish to reference the 'Master Data' in multiple subordinate entries using field references. You feel it would be most convenient if you could store the Master data in one or a few entries (e.g. a 'Sysadmin' entry) and reference them in the other entries, but you are limited to five standard fields that can be used in field references.

    • I believe it would be more efficient to create a limited number of entries that contain just the 'Master Data' and that by carefully defining the correct master entries it should be possible to create a well organized structure within KeePass that permits easy maintenance of the 'Master Data', easy reference in the subordinate entries, and informative search display. While the reference of 'standard fields only' is a limitation, it is a manageable one.

    Caveat : KeePass is primarily a password manager not a sysadmin tool.

    Your example entry (shown below), presumably describes a Sysadmin account, and includes the following custom string fields:

    Custom Parameters [Sysadmin account entry?]

    IP Range:
    SSH Port:
    Server Administration URL:
    User Admin URL:
    Email Access:

    It does not appear to me that any of the example Custom Parameters (with the exception of a URL used to login to the Sysadmin account) are true properties of the Sysadmin account. Rather they are related info. These custom fields should contain field references that reference 'Master Data' from other entries.

    The Group organization that you depict looks reasonable, but does not explicitly describe where the 'Master Data' should be stored. Do these groups contain Master entries, Subordinate entries or a mix of Master & Subordinate entries?

    A better organization is to create entry(s) that represent each primary object that contain parameter(s) of interest. Then, when a change is made to a parameter of a primary object, one edits the entry that contains the field representing the parameter that was changed and the result is propagated to all entries that reference the property.

    Example of a possible entry organization scheme for a hypothetical DHCP server

    For example dynamic or static leased IP addresses are normally assigned by a DHCP server, and static IP addresses are associated with a particular device.

    While it might be convenient to store a entire DHCP table in a single entry using string fields, such a scheme could become cumbersome. An alternative is to use KeePass groups to organize individual DHCP entries and use a systematic entry naming scheme to facilitate search and display. For example

    Various entries might look like:

    DHCP Servers
    Group: DHCP servers

    Title: DHCP server/router name
    Username: starting IP address of managed range
    Password: ending IP address of manage
    URL: whatever
    Notes: whatever

    leased addresses
    Subgroup of 'DHCP servers'
    Group: leased addressed

    Title: {REF:T@I:UUID of DHCP Server Entry}
    Username: xxxx.xxxx.xxxx.xxxx (e.g. a leased IP address)
    Password: device Hostname
    URL: Mac address
    Notes: client lease time

    port forwards
    Subgroup of 'leased addresses'
    Group: port forwards

    Title: {REF:T@I:UUID of DHCP Server Entry} - {REF:T@I:UUID leased addresses Entry}
    Username: from Port
    Password: to Port
    URL: protocol
    Notes: Application - enabled/disabled

    Similar entry treatment is possible for: Email url links with the corresponding mail ports, Site Domains, SSH properties, various other URLs, and other application information (e.g. mySQL).

    As can be seen from the above it may be necessary to make some decisions on how to organize the data if there is naturally more than 4 pieces of data associated with an element of an object, but this can be managed using multiple entries and/or subgroups, combined with a systematic entry naming scheme.


    An advantage of this organization is that searching is logical and systematic. One searches the appropriate named object instead of 'Sysadmin'. The above scheme is efficiently searched if 'Resolve field references in quick searches (slow)' is selected. For example to find all of the port forwards for a particular address one would search DHCP servername - IP address. To find everything related to a DHCP server one would search for DHCP servername. The search results are also easy to interpret because the content that caused an entry to be found is in one of the standard fields which is almost always displayed.

    Another advantage is that individual subordinate entries can reference the various bits of 'Master Data' from the unique data stored in an entry describing a named object.

    In the above scheme, creating a new leased address would be simple. Just duplicate a related existing entry and update the entry's 'Master Data'.

    Useful Plugin

    The KPEnhancedEntryView plugin is particularly helpful for visualizing the data in the subordinate entries for two reasons:

    1. It presents a structured display of the selected entry's custom fields in the entry view of the KeePass main window.
    2. It dereferences any field references contained in the custom fields to display the 'Master Data' values.

    Final comment

    • It appears that you are managing the account credentials of multiple users in a single database. This undermines a basic principal of good security and audit-ability because account credentials are no longer private and rigorously associated with an individual.

    Last edit: wellread1 2014-04-11
  • MarsXmc

    MarsXmc - 2014-04-11

    Thanks for the detailed comment. I'm going to reread it over the weekend before I analyze and formulate a reply but I want to immediately address your Final Comment since that is a different topic that's a little less involved, and I am interested in seeing your views. Anything to improve security.

    In regards to security.

    Only two people access this file.
    The boss (As he needs the ability to get into the systems should I die crossing the street tomorrow) and the head of IT, which is me.

    Does this still undermine the security, if The boss and I are the only two that have this file (and regularly sync). Would I really have to make a different keypass db for sub accounts. I would be fairly annoyed but my boss would be livid at the complexity. Any sub users get to have their very own and completely different keepass db file that contains only credentials related to them, and no one else. (Otherwise what's the point, they could change passwords to everything and we'ld be sol)

    If only I could force them to pick a absolutely wonderful master password that they won't write down and leave at their desk, =( I would be super happy. At least I force them to have a long one that they can remember without writing it down.

  • wellread1

    wellread1 - 2014-04-12

    Only two people access this file.
    Does this still undermine the security,...

    Yes, when account credentials are shared it may not be possible to establish who is responsible for a serious failure. In such situations, honest individuals may find themselves in the position of bearing the burden of proving their innocence. The business might also have reason to be concerned by reduced accountability, because the perception of accountability can discourage unethical behavior.

    The boss .... needs the ability to get into the systems should I die crossing the street tomorrow...

    In a small organization it may be necessary to accept the loss of accountability and the higher level of risk associated with sharing a single set of credentials with elevated access rights. But the number of trust relationships should be kept to a minimum because a small organization can still be victimized by unethical behavior.

    The ideal solution is for you and another trusted employee (or your boss) to have separate credentials with elevated access rights, and to verify by regular use, access to the mission critical systems using the individual credentials. That way at least two individuals would have access to mission critical systems in an emergency, including each other's account, but not without leaving a trail of who did what, when.

    KeePass 2.x can manage individual multiple open databases easily using the KeeAutoExec plugin and a Database activation on lock/close trigger. Therefore a solution that created two individual databases that contain the individual elevated account credentials, and a third shared 'configuration' database, might be feasible. Note that field references will not cross database boundaries, so one can not blend or merge password information contained in one database with sysadmin entries contained in a different database.

    Last edit: wellread1 2014-04-12

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks