Field References (Ability to set different usernames for different websites using the same password)

In my use case, I’m logging into multiple different web interfaces which require different username schemas (e.g. username, domain\username, username@domain, etc), but which all share the same password. I can use the custom field for some of these, but many web interfaces use the same name for the ‘username’ field (i.e. username), so even this doesn’t work in all cases.

Either the ability to sync a password between multiple separate entries (such as the field reference feature requested here), or the ability to create custom field on a per-site basis so that I could configure it separately for each site.

1 Like


There is a typical use case where you have the same password for different sites, but the username for the login is not the same one. The reason for that is because the authentication service for different sites is an integration with a idP (for example something like an LDAP) and it uses in one site the email of the user and in the other the username. For example, imagine the user James Smith with an user id jsmith and an email [email protected], and the password in LDAP is 123

then there are 2 websites:

It would be great to have a way to say in some way the username for each of the URLs we add for the autofill, or a way to link to reuse the password for another entry. I know it is not a good practise to reuse password for different domains, but it is not really that it is a different domain, it is just that it is relaying in an identity provider which uses the email of just the user id.



In general the reuse of a password is horrible OPSec, which you seem to know from your post. If for some reason you want to do it anyway you could accomplish what you need by creating a different login for each website. Then you would copy/paste the common password into the login file in your BW vault. So, you enter XYZ website and BW brings up the login with the unique username and the duplicated password. If you then go to another website that unique login would pop up in BW and you would login easily. While I hate the idea of even one duplicate password I know that you are NOT alone in your usage application. I hope the creation of different logins solves your issues.

I like the idea. However, there are a few topics already.
I guess this has the most votes (24) currently

@OpSec The described scenario is not a re-use of password, but this is actually being the same account with LDAP/SSO auth. For example, in private networks, LDAP is used so it’s username+password, but when using 3rd party with SSO authentication, it’s email+password. Both are internally the same account, just different auth path.

This is a very common scenario for me too.

1 Like

Agreed, we have many systems at work that are all tied into our LDAP authentication. The username formatting varies, but the password is the same. Please add this feature.

I have been trying to figure this out for a while also. Everything authenticates back to active directory at work. The usernames is different depending the the service.

  • User Principal Name
  • SAM Account Name
  • Domain\Sam Account Name

I was hoping to do something with the custom field, but to many are named username.
Since I have to change my password so often, I don’t really want to update dozens of logins.

+1 on this. I really miss having this option

Feature name

  • Better handling of login items which have a organization domain name associated with them.

Feature function

I have several items in my vault which are flagging in the Reused Passwords Report. All the items are for accounts which are in our organization’s domain, and while the passwords are the same, the usernames have different variations of the domain, as required by the particular service. For instance:

  • One item has the username @, which is used to sign into a set of specific websites.
  • Another item is <username>, which is used to sign into a different service which requires this form of the username to work properly.
  • Yet another item has the username @, as it requires the fully qualified domain name.

Of course, this is the same account in all instances, so the password is identical, but different services require different forms of the domain, so I need to have multiple items in order for autofill to work. Most of these services are third-party tools, so I don’t have the option of asking the developers to change the behaviour. I figure this is likely a common occurrence for Bitwarden users who are members of an organization which uses Active Directory, and especially so for IT people like myself.

It would be nice if I could get these false positives cleared from my Reused Passwords Report. I see two potential solutions:

  • Include an additional field for URIs to indicate domain name, and whether that domain name is a prefix or a suffix.
  • Include an option to exclude or hide specific items from a report.

Related topics + references

+1 This would help organization settings immensely

This feature may also provide a work-around or alternative solution to meet some of the needs expressed in the More than one TOTP per item Feature Request (which currently has 37 votes), as explained here.

+1 voted

I have lots of services that login is a entry in my LDAP server, AD server and so on.

It would be nice if we could save a reference for the password registered in another entry.

Maybe mark a flag setting a field as a reference and writing something like {id[3c20af82-6b0f-4239-9604-ae943012804d].password} or {b3a15aca-5234-424d-aee5-ade90132aaf3.username}, for example.

In some cases, mostly with Active Directory Accounts, I have one Account so that the password is always the same. But dependent on the used application to login the “username” is accepted different formats. E.g.

So the problem is, that if I would create three accounts for autofill, I would need to change the password every time on all three items.
It would great if there will be some feature, that I can create an login where the password is linked / inherited from another Bitwarden login item (within the same vault) so that only one password change is needed.

1 Like

Here’s a similar request with more votes:

I would like to request this feature too. This is the only feature blocking us from moving away from Keepass.
A lot of our systems use AD/SAML/SSO and updating all the passwords for the different systems is quite the hassle.

@One234 Welcome to the forum!

Could you not store the URLs for each site in the same login item, as shown below?


@grb storing all sites uris would not solve the problem. I’ll try to explain it again.

Lets say the Active Directory account is [email protected]. Active Directory accepts different writing style of the same account. All types that I know are:

As I said its all the same account! And yes the AD-Domain and DNS-Domain can be different which is not unsual in Active Directory environments. But now comes the problem:

Every application that has implemented functionalities to authenticate against LDAP / Active Directory can force a specific writing style for the account. For example:

URI1: will only accept “first.last”
URI2: will only accept “AD-DOMAIN\first.last”
URI3: will only accept “[email protected]
URI4: will only accept “[email protected]

I hope I was able to explain it clearly.

Yes, you are right, thank you for reminding me of that use-case. This request really is identical to the earlier one, so I will go ahead and merge it.

Perfect description of my problems with Bitwarden aswell.
As good as the functions it has are working right now, KeePass does field-references, and solves this in a really ‘easy’ way.

Additionally, the Auto-Type function of KeePass is usable on literal Windows Windows, as in “Run As…” dialogs, which helps a ton with programs that have timeouts and are not web-based, as many Admin tools are.

1 Like

Please, this is the only feature I miss from Keepass. Voted!