Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. support

    Multiple Authentication Types

    Hi Rob, I do not believe this will work if all you're doing is closing the tab - sorry, but this is outside of our control unfortunately. Regards Click Studios
  3. RobMiller

    Multiple Authentication Types

    Let me rephrase the example above: Locate a computer in a disallowed subnet Reboot that computer, log in to Windows Open Chrome, sign into Okta but not PWS Click the PWS chiclet in Okta A 2nd tab is spawned for PWS, PWS correctly identifies you are off-site, doesn't log you in with SAML, prompts for forms based auth At this forms based authentication prompt, do not authenticate with your username and password, instead, simply close this tab. At this point, you are now on a computer, that has been rebooted, and you have never authenticated to PWS in this Windows session Now on tab 1, the Okta tab, click the PWS chiclet again, it will spawn tab 2 with PWS again, but this time, instead of PWS prompting you again for forms based auth, as it should since you did not authenticate in the previous step, PWS will log you in with SAML, even though it's not supposed to. I could reset the PWS password of a user, not tell it to them, then have them start at step 1 above, and they will still be able to access PWS from an off-site desktop computer.
  4. Jonathan Collins

    Browser plugin - Extra login fields

    Although they are rare, I work with a few sites that use more than just the username and password for login (eg, user, password and account number) it would be great if the browser plugin could be configured to auto fill additional fields.
  5. Jonathan Collins

    Browser plugin - Auto submit

    If only one set of credentials exist for a website, add an option to optionally auto submit the login form.
  6. Jonathan Collins

    ScreenConnect/Control Integration

    +1
  7. RobMiller

    Multiple Authentication Types

    You are realizing that no one is ever authenticating in the above example correct? Why close the browser if I never authenticated to PWS? I understand that would matter if I previously authenticated, but that is not the case here. Users right now, off-site, in a disallowed subnet, can completely bypass the authentication requirements of PWS while never authenticating even once using the assigned auth. I'm sorry but I can't help but feel you are not understanding the situation. Closing a tab instead of a browser should only matter if I somehow authenticated in that browser previously. The users are never authenticating, they don't even need to know their password. They could not know the pass, be using a brand new out of the box PC, log in to Windows for the very first time, all while in a PWS restricted subnet, and still authenticate via the default auth mechanism by closing a tab instead of authing normally. Would it help if I made a video of this behavior? I could do that. Rob
  8. Last week
  9. support

    Multiple Authentication Types

    Hi Rob, I think the issue is your Step 5 above. I asked what happens if you close your browser, not close your tab. The only way to kill your sessions in IIS is to log out of Passwordstate, or close your browser altogether. Just closing the tab will not do this. Regards Click Studios
  10. support

    "add to home screen"-icon for iOS Safari

    Hello, Thanks for your request. We did try getting this to work some time ago, but were not successful, but we will give it another go and see what we can do. Regards Click Studios
  11. Hello, Sorry you're having some issues. If you have uploaded a logo of the exact same name, then yes this would be the issue. I've attached the default logo for you, and you will need to save this into the folder C:\inetpub\Passwordstate\images\logos Regards Click Studios
  12. RobMiller

    Multiple Authentication Types

    Nope. Steps to reproduce using Chrome: 1. Close all instances of Chrome, starting fresh 2. Open Chrome, sign into Okta 3. Click the PWS chiclet 4. A 2nd tab is spawned for PWS, PWS correctly identifies you are off-site, doesn't log you in with SAML, prompts for forms based auth 5. At this forms based authentication prompt, do not authenticate, instead, simply close this tab 6. On tab 1, the previous Okta tab, click the PWS chiclet again, it will spawn tab 2 again, but this time, instead of prompting you again for forms based auth as it should since you did not authenticate in previous step, it will log you in with SAML, even though it's not supposed to So you see, even using a fresh browser with all instances closed, and never authenticating with forms based auth while being at an off-site location, it will allow you to use default auth on the 2nd attempt. Definitely looks and acts like a bug. So as of now, I still can't force off-site users to auth a different way, as they can simply bypass it by closing the first tab, and clicking it again. Rob
  13. The "Restore Default Logo"-Button on the [System Settings] -> [Branding] is not working properly: I can't switch back to the factory default logo. The failure might be: Uploading a new logo with the same file name as the logo default filename overrides the default logo.
  14. For Passwordstate Mobile access: it would be wonderful if the iOS Safari "add to Home Screen" function (see printscreen) is supported with a nice icon. It can be easily implemented: <link rel="apple-touch-icon" href="INSERT_FILE_PATH_HERE"> https://www.create.net/support/adding-an-ios-home-screen-icon-for-your-website
  15. findusHai

    API / Error when moving Password to Recycle bin

    Hi, sorry for the Late follow up. I looked into your links but we noticed that the Problem only occurs in our test environment and everything works fine on our production server so we stopped looking for the Issue. Thanks for your help anyway. Greetings Florian
  16. Hello Constantin, As we don't have the sort of feature you need, we recommend not configuring a Password Lists with Authentication options which users cannot use. In the unlikely event somebody did this, Security Administrators can always turn it off/change it via the screen Administration -> Password Lists. For authentication into Passwordstate, all we can suggest for now is multiple User Account Policies - this will enforce it for you. If possible, and we certainly understand if it's not, but consolidating the number of 2FA methods you use may help as well - we find most of our customers try to do this as it does simplify things, and reduces your support costs. Regards Click Studios
  17. Yes I've seen this. But If we allow the users to choose their own authentication method via preferences, they could also set this to just "Manual AD" and bypass the second factor. And this would be an security risk. There must be an enforcement to have them choose an second factor option. On the other hand there is the disadvantag for users creating password lists and enforcing the password list to have the authentication method Manual + AD and SecureID for example. But what happens when a user without this method enabled - tries to access the password list? It shows the authentication window, but the user cannot authenticate because he does not support this method. So for single password lists there should be also the possibility to say: Hey normal AD authentication is not enough, we need a second factor. But Which one - doesnt matter - because this could be different per user. Is there maybe a workaround for this? Kind Regards, Constantin
  18. Hi, Thanks for the feedback, but we think this approach would be problematic. We auto-populate a lot of the Authentication fields on users Preferences screen, even if they are not using those Authentication options i.e. SecurID Username is populated for all accounts. Do you know users can chose their own Authentication Method on their Preferences screen? I think this might be a better option for you, as you then would not need to worry about all those User Account Policies. Regards Click Studios
  19. Yes you are right, from technical view maybe this could be done with an check like: Which 2-FA Option is enabled for User XY? --- RSA --- OTP Multiple 2-FA Options detected -> Which one is set as Prefered? --- RSA Then display login form/window for this 2FA method. When only one 2FA Method is activated by the user then the prefered step is not needed and it is directly choosen.
  20. Chris Gribbin

    Issues adding passwords via webapi

    At least I'm not crazy! Thanks for all your hard work. -Grib
  21. Hi Constantin, Thanks for the clarification, and no that is not possible sorry. I'm not sure if we would consider this as a feature request sorry, unless we had many customers interested in it - an no-one has expressed an interest before. Technically we're not sure how this would event work - would we just randomly present a 2FA option to the user - what is they don't use SecurID, as an example. Regards Click Studios
  22. Hi there, i've seen this but this does not fit with our needs. For example I have a team of about 10 users. 2 are using google authenticator 1 is using rsa secure id 4 are using OTP 1 is using email and so one..... With the policy's I can force a user to use one specific authentication option. So i would have to manage 4 different user policys and add the users per their need to the right user policy based on their choosen second factor application. I would like to have the option to specify that the users have to authentication with ANY second factor option, so they can choose their favorite application. (Ensure that 2-Factor authentication is used, with no enforcement on a specific method) Is this possible? Or it looks like an Feature Request? Kind regards, Constantin
  23. Hi Constantin, With the user of User Account Policies, found under the Administration menu, you can have different authentication options for different sets of users. Can you investigate this, and let us know if this is what you need. Regards Click Studios
  24. support

    Issues adding passwords via webapi

    Hi Chris, Thanks for your help, and patience, in trying to troubleshoot this, and we can confirm we see the same thing if the Password List is for a Remote Site Location. So we'll look into getting this fixed for the next release, and test all other methods as well to make sure there are no other issues. Thanks again. Regards Click Studios
  25. support

    Improved Branding/Customisation

    Yes, that would work
  1. Load more activity
×