Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Yesterday
  3. Thanks Hatface13 for posting this, we really appreciate it and we hope it helps someone else out too. Regards, Support
  4. I believe I've resolved this. For anyone else who comes along behind me, the failing servers also failed to update to WMF5.1 somewhere in the past. These were all servers that had in place upgrades performed on them. They all still held on to powershell version 4.0. All working machines were on 5.1 or newer. Updated one of the non-working machines to 5.1 and it started working as expected. Going to test with a few more machines but this appears to have resolved the issue for me.
  5. Last week
  6. I found this post as I need the same functionality. I was able to get it to work by adding my full domain to the user account. Example below. ## Enable sudo rootpw for Passwordstate Privileged Account Defaults Defaults:svc_password_reset@example.com rootpw I personally added it to a /etc/sudoers.d/some_sudoers_file as I do not like to modify the original sudoers file, /etc/sudoers, if I can help it. It works in either of these locations.
  7. Hi Guys, We have this coming in V9, with a native app for iOS and Android. Regards Click Studios
  8. Hi Guys, We've had this feature for a little while now - sorry we did not update this forum post. Please see screenshot below. Regards Click Studios
  9. Hi Guys, We've had this feature for a little while now - sorry we did not update this forum post. Please see screenshot below. Regards Click Studios
  10. +1 I'd like to see this as well. Maybe make this an optional setting via a checkbox in misc. Or possibly a per passwordlist setting as I could see us wanting to apply this to a specific list, but not to another.
  11. I think in offline version would be nice -- in our current setup Passwordstate is only accessible when onsite or connected to VPN. However, I do agree that there needs to be someway for administrators to limit what can be made available in an offline state --- perhaps only certain types of lists or a flag on the list itself that can only be controlled by a Security Administrator.
  12. We would like to have the browser extension prompt the end user for a reason when using credentials located within a "provide a reason" list. Currently the browser extension will allow usage of the credentials without explanation when in a provide a reason list (an audit entry is still created) and only prompts when accessing via the normal user interface. Alternatively, if prompting is not a viable option, perhaps provide an option on the list that would exclude them from being used in the browser extension.
  13. Maybe we could also exclude Password Lists where the 'Provide a Reason' is checked, but this might upset quite a few of our other customers. Probably best to log a feature request to see how many customers are interested in needing to provide a reason for logging into a web site. Regards Click Studios
  14. Hello, The browser extensions have been designed to be as simple as possible, without the requirement for user input. As you're the first customer to request this, would you be able to log a feature request in the 'Feature Requests' sections of this forum, and this will allow us to prioritize based on the voting system we have. Unfortunately you cannot restrict users in the Browser Extension, but not in the UI. If you've been given access to a Password List, it will be available in both. With your second query, it looks like you've found a bug for us, as only Password Lists with the URL field selected should be used in the Browser Extensions. I've logged this to be fixed in the next release, and thanks again for reporting it. We'll post back here once the new release is available. Regards Click Studios
  15. This seems very counter intuitive. I (and I assume many others) would assume that restrictions placed on the UI would apply across ALL products not just one of them. Might I suggest that for the sake of security and continuity of the product(s) this design be reconsidered? The browser extension does not appear to use the API since the API restriction options available for lists do not have any effect on the browser extension. If this is intended design, then how do we restrict users from using this list within the extension but still be able to access it in the UI? The only work around we have found is to remove the URL field value and instead place the URL in a custom field. Any other options? Are we approaching this the wrong way? On a somewhat related note we also noted that linked entries do not apply the security restrictions of the contained list but revert back to the security settings of the least restrictive list. As an example we linked an entry to an entry with a URL field value to a list without a URL field and the browser extension still recognizes it.
  16. Hi KC_BREC, This is be design for our browser extension, and certain Password List settings are only applicable in the UI, and not in other modules like the Browser Extensions. Regards Click Studios
  17. We have noticed what we think may be a bug, or at least not working as we intended. We have a password list that is shared but must provide a reason to view the password. This list contains entries that include URLs. These entries show up as usable by the browser extension when visiting the URL in a browser. The browser extension will allow you to use it but does not prompt for a reason before filling the form fields. An entry shows up in the audit log that it was used but that's all it displays. We tried setting the API usage to mandate a reason when using the API but then you can't use the entry at all and the extension never prompts for a password. Is this by design or a bug in the software? Should (or can) the browser extension prompt for a reason before filling the form fields?
  18. Good afternoon everyone! I'm trying to work out the errors in the Windows Dependency Account scan. I'm seeing this across a handful of hosts: Error = Could not find a part of the path '\\\'.. Has anyone else figured out how to go about working through this error? I've verified DNS is good, and tested by IP(changed hostname to IP in PasswordState host settings), which gave a winrm error until i finagled trustedhosts but once I cleared that up it went back to the above error. I get this on a good chunk of the hosts I am trying to scan, including some that share the same OU/GPOs, but not all of them. Nothing in Error Console. I've got a handful of powershell Events that do look to include the discovery scan that I can forward to support if needbe. Open to any ideas, hoping someone else has run up against this and worked their way through it. Thanks!
  19. Hi Robb, There can also be restrictions in AD as to how frequently users are allowed to reset their passwords - a lot of customers run into this issue when testing the portal, as they're testing multiple resets. Below is a screenshot of this from Fine Grained Password Policies - can you check that out? Regards Click Studios
  20. Default password complexity is configured and applied, and matches Internal password policy. New password meets requirements, system will not accept, and warns of failed complexity requirements. Any ideas?
  1. Load more activity
×
×
  • Create New...