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.
Field References (Ability to set different usernames for different websites using the same password)
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.
- username
- DOMAIN\username
- [email protected] (UPN or email)
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.
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?
URI1: https://www.example.com
URI2: https://adfs.example.com
URI3: https://service1.example.com
URI4: https://service2.example.com
URI5: https://example-my.sharepoint.com
@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:
- first.last
- AD-DOMAIN\first.last
- [email protected]
- [email protected]
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: https://www.example.com will only accept “first.last”
URI2: https://adfs.example.com will only accept “AD-DOMAIN\first.last”
URI3: https://service1.example.com will only accept “[email protected]”
URI4: https://example-my.sharepoint.com 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.
Please, this is the only feature I miss from Keepass. Voted!
Bitwardens main focus seems to be on “casual / browser-only” users. For these people Bitwarden offers a lot of great and useful features, but when it comes to admin / offline operations it’s lacking many many features such as Auto type, SSH Agent Support, this one here and some more. Personally I tried Bitwarden and KeePassXC in parallel but never made the switch to Bitwarden because it’s lacking too many useful features and now I’m not using it at all anymore.
I still watch and vote these topics, hoping the features might be implemented at some day. However, I’m not that optimistic seeing the current focus of the project to introduce a new stuff like the secrets manager.
Especially if the password of an account changes, this must be adjusted on all existing entries. It would be great to have an account entry that can be referenced by other entries. This way, the adjustment would only have to be made in one place and all other entries would always be up-to-date and no entry would be forgotten.
It would be handy if I could create one record and link it to another. Some examples of where this would be useful:
- If I have a credit card with a bank, a web login for the credit card, and a web login for the bank, it would be convenient to be able to link the records together. E.g., make an “address” record of contact information for the bank, and link that record as the contact information for the other records. Or link from the “credit card” record to its “web login” record.
- If I have an account where my login is via GitHub or FaceBook or OAUTH2 or OpenID, it would be convenient to be able to link to the web login in question. I use different kinds of 3rd party logins for different kinds of web sites and right now I have to remember which is which.
- Perhaps it would be handy to have a field allowing a drop-down of 3rd party logins, and to be able to flag different web logins as a 3rd party login to be added to that drop down.
It would be useful for me to know which account (Facebook / Google .etc) I used to log into this site with.
It would be useful to link one record to another, and if the password/TOTP key is updated on, it updates on the other. This is because often I have to input usernames in different formats:
DOMAIN\username
username@domain
username
but they are all authenticated using the same backend. I currently have to maintain 3 records (with identical passwords) to be able to accommodate this, but if I change the password on one, I have to remember to update the password on the other two.
The alternative option would be to allow for multiple usernames in the same record, and allow us to select the username style when filling in the field (or even better, give us the ability to specify on a per-site basis which username to use)