Multiple Login's But One Password
Comments
-
I just spent some time grouping my work user login with multiple "websites" for each application server under the same login item, but I am facing an issue with servers/application websites that have self signed certificates (which I've added to my Windows Trust Store) as it is the case with Tableau's TSM Server - which cannot be changed to a Certificate Authority issued cert (https://help.tableau.com/current/server/en-us/sign_in_tsm.htm). The Tableau TSM is just an example, but I have several other servers/applications with a similar situation.
What I think happens when I try to submit my user/password using the Chrome Extension of the Desktop App in Windows is that 1Password recognizes the URL as a valid URL in my login item, but unsure of the authenticity of the URL it refreshes the page to the first website listed in the login item, effectively navigating away from the page I wanted to enter my credentials on.
For example:
Let's say I have a login item with WEBSITE1=app with valid SSL Cert WEBSITE2=self-signed SSL Cert WEBSITE3=self-signed SSL Cert
Submiting login while on WEBSITE2
Page refreshes and opens and logs in to WEBSITE1I've also tried this:
I have another login item with WEBSITE1=self-signed SSL Cert WEBSITE2=self-signed SSL Cert WEBSITE3=app with valid SSL Cert
Submitting login while on WEBSITE2
Page refreshes and opens and logs in to WEBSITE1Now this works as expected
I have another login item with WEBSITE1=self-signed SSL Cert WEBSITE2=self-signed SSL Cert WEBSITE3=app with valid SSL Cert
Submit login while on WEBSITE3 enters credentials and logs me into WEBSITE3
Can someone elaborate on this? I've already trusted the self-signed cert and Chrome says it is a valid certificate - shouldn't 1Password trust that? Maybe I need to add the self-signed cert to a different location in my Windows Trust Store?
This only happens for those servers/application websites with self-signed certs. Submitting the login to other servers with a valid SSL cert by our Certificate Authority actually logs me in correctly - as expected.
0 -
I just spent some time grouping my work user login with multiple "websites" for each application server under the same login item, but I am facing an issue with servers/application websites that have self signed certificates (which I've added to my Windows Trust Store) as it is the case with Tableau's TSM Server - which cannot be changed to a Certificate Authority issued cert (https://help.tableau.com/current/server/en-us/sign_in_tsm.htm). The Tableau TSM is just an example, but I have several other servers/applications with a similar situation.
What I think happens when I try to submit my user/password using the Chrome Extension of the Desktop App in Windows is that 1Password recognizes the URL as a valid URL in my login item, but unsure of the authenticity of the URL it refreshes the page to the first website listed in the login item, effectively navigating away from the page I wanted to enter my credentials on.
For example:
Let's say I have a login item with
WEBSITE1=URL with valid SSL Cert
WEBSITE2=URL with self-signed SSL Cert
WEBSITE3=URL with self-signed SSL CertSubmitting login while on WEBSITE2
Page refreshes, opens and logs in to WEBSITE1I've also tried this:
I have another login item with
WEBSITE1=URL with self-signed SSL Cert
WEBSITE2=URL with self-signed SSL Cert
WEBSITE3=URL with valid SSL CertSubmitting login while on WEBSITE2
Page refreshes, opens and logs in to WEBSITE1Now this one below works as expected:
I have another login item with
WEBSITE1=URL with self-signed SSL Cert
WEBSITE2=URL with self-signed SSL Cert
WEBSITE3=URL with valid SSL CertSubmit login while on WEBSITE3 enters credentials and logs me into WEBSITE3
Can someone elaborate on this? I've already trusted the self-signed cert and Chrome says it is a valid certificate - shouldn't 1Password trust that? Maybe I need to add the self-signed cert to a different location in my Windows Trust Store?
This only happens for those servers/application websites with self-signed certs. Submitting the login to other servers with a valid SSL cert by our Certificate Authority actually logs me in correctly - as expected.
0 -
How are you using 1Password to login to these websites exactly? Are you already on the website you want to login to when you call 1Password, or do you click on the "open and fill" button directly inside the 1Password desktop app?
Also, can you please let us know what version of the 1Password browser extension you are currently using?
0 -
@ag_ana - I navigate to the website first, then I submit the credentials with 1Password Mini. I just press the CTRL+\ shortcut and it auto-submit the login of the website I'm in. I am using 1P for Windows 7.4.767 with extension version 4.7.5.90. If relevant, I'm using Chrome Version 83.0.4103.97 and I can also replicate the same in MS Edge Version 83.0.478.45 (Official build) (64-bit).
0 -
Hi @Greg - none of them are localhost. They are internal network servers, as in I have to be in VPN to access them, but they all have their own IPs, different to that of my machine. Is there any way of producing a debug log to help provide more details? Thanks for getting back to me so quickly!
0 -
It sounds like 1Password isn't viewing these URLs as true matches to your Login item, @lerokie and is thus performing a Go & Fill rather than filling directly. I'm not suggesting this as a permanent solution by any means, but just to confirm my suspicions here, what happens if you click one of the URLs that normally doesn't fill properly directly from your Login item in your desktop app? Does that open and fill properly in that case? Basically, I'm trying to take matching out of the equation here. Since 1Password itself is opening the page, it shouldn't bother matching and will instead just fill because it's obviously able to trust itself. Give it a go and let me know if that works properly. :+1:
0 -
@bundtkate - I think you’re onto something. When clicking “Open and fill” it opens the website and fills the credentials correctly. It doesn’t auto-submit credentials when it does this, it just populates the username and password boxes. On the websites that work as expected (from the same login item) it does auto-submit them.
0 -
When it comes to submitting specifically, @lerokie, I'm going to be perfectly honest with you and just say that we've soured a bit on the whole concept. All the auto-submit does is fake an enter press and over the years that has proven both unreliable (as you're observing) and disruptive (particularly when CAPTCHAs are involved) to the degree that when Apple stopped allowing simulated key presses, we just decided to remove auto-submit from 1Password for Mac rather than reinvent that wheel. We probably could have done something, but we didn't feel it was worth it. When you see this happen, try actually pressing enter and see if it submits. If it doesn't, then focus is probably being moved out of the form – either by the website or something else – which means that we're not likely to be able to improve things. If it does submit, then it could be the site is ignoring that fake enter or, finally, it might be something where we can make some improvements.
When it comes to matching bit, my guess would be that the site is http and the URL in 1Password is https. Any chance that's the case? I'd certainly believe that there may be other things that would trigger this sort of behavior, but every time I've seen this in the past, http has been the answer. 1Password will be fine filling a site saved with an http URL on an https site – after all, https is better – but it will not be willing to fill a Login saved with https on http and will do the go & fill dance when you try to do so. Since you don't explicitly select which URL to open when filling from mini, it's always going to open the first website in its list, which is obviously not what you're after here, but it's the best it can do when you technically haven't told it which site to fill on. Go head and double-check those URLs in 1Password and make sure they match the sites' URLs in your browser exactly down to the http/s bits. If there are any mismatches at all, edit the item to correct them and try filling your normal way again. Let me know what you find. :+1:
0 -
@bundtkate - thanks for your quick reply.
[...] when Apple stopped allowing simulated key presses, we just decided to remove auto-submit from 1Password for Mac rather than reinvent that wheel.
Good to know. I will keep this in mind for when I use it in my Mac, but my current issue is in Windows - where it still works for most websites, just not the ones I’m having trouble with 😉
When it comes to matching bit, my guess would be that the site is http and the URL in 1Password is https. Any chance that's the case?
The URL and the URL stored in 1P are both HTTPS, they’re entered as exactly the same - a copy/paste from browser to 1P and still doesn’t work.
Related to that HTTP/S situation, I did mention these were self-signed certificates. By default, Chrome marks them as NOT SECURE with a crossed HTTPS in red - even though the URL shows up as HTTPS. However, I exported the certificates from the website through the browser and imported them into my Windows “Trusted Root Certification Authorities” Certificate Store (for all users - not just for my user account - difference is that for all users requires me to use administrator credentials). After adding the server certs to this Certificate Store, the browser stops complaining about it not having a valid certificate, and it shows up with the normal padlock, because now Windows Trusts it. However, it looks like 1P is looking somewhere else for the certificate validity and that might be causing this issue.
0 -
However, it looks like 1P is looking somewhere else for the certificate validity and that might be causing this issue.
This is possible, @lerokie, but I wouldn't think it likely. Reason being that I can't see where 1Password would get that info, given the permissions we have. I'm fairly certain the extension simply reads the URL in the address bar. Still, that would be an easy enough test so might as well – what happens if you change the URL in 1Password to
http? Better luck then? Watchtower is gonna yell at ya (sorry), but ignore it for now and let me know what you find. :+1:0 -
I tried using HTTP, and 1P marked it red (it did yell at me). This didn’t do anything from an Auto-Fill perspective. Unfortunately it didn’t work with“Open and fill” as the website couldn’t be reached in port 80 (web server only allows communication on SSL ports).
0 -
Thanks for trying, @lerokie! So I did the best testing I could (no self-signed certificates here) and I'm not personally able to reproduce any issues with filling Logins on websites lower in the list. My best theory at the moment is that this is possibly an issue with our filling brain as I have a newer one than you will since I'm on an internal build, but I don't feel like I can really rule out other causes given the inexact nature of my testing. Plus, I can't have you try the new brain yet to confirm because the update with that change isn't out to beta yet.
Give that, I decided to drop our extension developers a line to see if they have any thoughts. They're more the filling gurus than I am. If I learn anything exciting, I'll be sure to let you know. In the meantime, would you be okay giving the next beta a try when it's ready to see if that makes any difference? It could be out super soon, or it might take a bit – I don't want to make any promises as that's how I jinx us – but if we don't come up with anything better before it lands I think it's worth a go. Let me know what you think. :+1:
0 -
Thank you so much for following up on this, @bundtkate. I enabled Beta builds so hopefully I’ll get notified when the new version hits the shelves. I’ll give you an update then.
0 -
@bundtkate - 1P updated to the latest Beta but that didn't work out. Thanks for your help. I'll come back and update if future builds address the issue. I will separate those websites into their own Login item and wait for a future release that might address it. I like reading the release notes, so I'll keep an eye for anything that might reference this.
0 -
Thanks for trying, @lerokie, and sorry it didn't help. :frown: In my chats with our development team, it sounds like the URLs here could potentially matter even independently of them matching those saved in your Login item. Would you be willing to share one or more examples of those not working properly? If you don't want to share them publicly here, you're welcome to drop an email to
support+windows@1password.comwith those examples. Just mention that Kate asked for them on the forum and whoever sees the email will know to hunt me down. :+1:0 -
I see. The URLs that work are in the format
https://servername.domain.com:port. That made me play around with those that don’t work, and noticed that I can update some to use that format - so far so good Auto-fill worked great for these.Others, like the Tableau example I provided initially, only use the server name as the whole URL, as in
https://servername:port. In these instances, 1P tries to do “Open and fill”. Unfortunately because the configuration is generated by the software installation, if I add my domain.com to them, it doesn’t really even establish a connection, so I won’t be able to update those for ease of use.Thanks for staying with me on this, @bundtkate. Really appreciate the support!
0 -
That'll do it, @lerokie! Hostnames don't work for matching so if you don't have a domain (or at least a
.com, etc.), then those aren't going to fill properly at present. I believe it's something on our list to fix, but I wouldn't bank on it being super soon since it's a bit of niche need. That said, we know these work when doing a go & fill – do you have the option to put those with just the server name first in the list? Since we've got those that can be reformatted fixed up, the best bet in the meantime may be to use go & fill on purpose for those that are still giving you trouble. Hopefully that would at least limit the extras you need.Oh and one more tip – if you need to have an extra Login item for any of these, try to make the first URL in each match as closely as possible. I am not entirely certain how Watchtower will handle hostnames, but we do automatically skip flagging two Logins with the same domain and password as reused so there's a chance that ordering those URLs just right will save you some scolding from Watchtower. :+1:
0 -
I have a mild version of the original issue—one password and two usernames. All I'd like is a button to to tell 1Password that the two logins are linked and get rid of the duplicate password warning, just as you can remove a site from the two-factor list.
0 -
Hi @benmattison,
It is not possible to exclude passwords from Watchtower at the moment, but we are looking at different ways to improve this behaviour. Thank you for sharing your feedback regarding this!
If you have other questions, we are here to help. :+1:
ref: dev/projects/customer-feature-requests#130
0 -
My department is getting moved into 1Password from our previously shared encrypted KeePass. Overall, the functionality seems well laid out, and integrations are implemented well. I am, however, experiencing the same issue that other users have reported going back at least 3 years.
Note to developers, I believe everyone that has posted on this and other discussions, would benefit from field referencing. Great example would be the functionality of KeePass. You may set a field to reference a field of a different login. When you update the password on the parent login, no action is needed on the logins that reference the parent. This could also be written on the back end to ignore references automatically. This avoids the check box idea from being mis-used. Watchtower can simply be set to list reference accounts but not cause any kind of alert. This would simplify the usability, password management, and administration on the corporate side when completing an audit. Please kindly consider this as an option to impliment.
0 -
I definitely appreciate you putting your input in on things here @PaulSupport 😊
We certainly can see how field referencing would be a great addition to situations like yours, and hopefully that'll be something we can account for in one way or another moving forward in the future.
0 -
Just adding my +1, having the same issue. Company is using different login user names (full email, email without the domain, employee number) with the same password.
Would be happy to accept a hacky solution for this, e.g. labels for putting in the other user names.0 -
Thanks for sharing your feedback here as well @uhinze 🤗
Unfortunately there aren't any solutions for this at this point in time, even "hacky" ones, I'm afraid. We will follow up here on this thread if there are any changes to the way things are handled regarding this in the future, so keep an eye out!
0 -
Deleting my comment is just real dirty just saying... It doesn't eliminate the problem...
0 -
Is there an official workflow for features requests? I'd love to submit the "many to one multiple usernames to password" feature request.
My employer is the same way, where I have one AD account accessed in different ways. Direct AD can use DOMAIN\username or username@domain, for example. But going through the LDAP interface might just use the username.
I feel Enterprise authentication providers could step up their game and provide a consistent username across platforms, but until they do, being to associate multiple username/URL pairs to a single password would work in this use case.
1Password is a great application that satisfy 90%+ of my needs, so not doing this won't lose my business. It will make me appreciate my investment in 1Password all the more, however.
Now back to trying to download my paycheck, for which I know the password/2FA, but I have remember which username it wants. :palmface: Remember when the OTP was the hard part? I miss those days.
0 -
Is there an official workflow for features requests? I'd love to submit the "many to one multiple usernames to password" feature request.
You can open a new discussion or comment on an existing one here in the forum, and we can pass your request to the developers :+1: I have already done so for this specific one :)
ref: dev/projects/customer-feature-requests#16
0 -
I've been following this thread hoping for a feature announcement, but that hasn't happened yet :)
I have the same problem mentioned by previous commenters: My AD credentials require various permutations of a username to work:
- domain\username
- username
- username@domain.com
I followed the advice of tagging multiple login entries as "AD Credentials", but it feels like a bandaid solution.
0
