Jump to content


  • Content count

  • Joined

  • Last visited

  1. AD-integrated access to API

    We also need this. We manage providing granular access to passwords through AD user/group permissions. Creating separate password lists for every set of passwords that is accessible by the same group of people and then updating all of those people's API keys when any one of them should no longer have access isn't feasible. We really need to be able to leverage the investment we already made in defining the security of the password list once via AD user/group membership when accessing passwords through the API which in our world is fast becoming the more common means of accessing passwords as we leverage PowerShell modules like this one.
  2. Thanks for the explanation. That definitely makes sense. My thought on this would be that when a password gets linked, any of the dependencies, hosts, etc. are copied to each of the members of the linked credential. Dependency and hosts are visible on all linked members. If one gets updated, the reset scripts and dependencies are triggered from this 'control' entry. All others members of the linked credential get temporary bit/setting/etc. set to make sure they do not trigger any actions but instead wait for the controlling member to complete the reset actions. At that time, all non-control members update their passwords. The 'control' member is whichever member of the linked group is updated/reset. If this is something that is possible in a future release, we would greatly benefit from it.
  3. We use the copy and link feature extensively to share passwords between teams. With the recent upgrade, we began adding hosts and using Passwordstate to automatically manage password resets on hosts. However, the copy and link feature is not available for passwords enabled for resets. It would be extremely beneficial to us if we were able to share a credential between lists/teams and still have it enabled for reset. This way, whenever any of these shared credentials expires, or changes, it will queue the reset task and update within all linked records. This would imply some changes on the back end so each linked record wouldn't queue its own reset task. Is this something being looked at for future updates, or is there some way to work around this at the current version?