Sarge

+1

We have the ability to use SSH Templates - Remote Shell or Remote Commands to create custom scripts for Password Resets; but we don't have the ability to use similar SSH Templates for custom validation/heartbeat scripts. This would be a great addition.

You need to log out of Passwordstate. Just closing the browser won't do it.

Hi There, Has anyone tried to use a newer version of ODAC than what the documentation says? Passwordstate Privileged Account Management Manual (clickstudios.com.au) section 21, points to ODAC122cR1 which was released in May 31, 2017. Can anyone confirm if a newer version works/is supported from here: Oracle .NET, Visual Studio, and VS Code ODAC Downloads for Oracle Database

+1 In our instance we have about 1000 passwords we'd like to reset on the same day. Currently you can only schedule X days or X months - which means over time 'drift' occurs. Being able to say reset on the 1st of every month, would stop the drift from occurring; along with an option to 'reset on the next scheduled reset' in the event of a failed reset. (IE: Rather than try again the following day, wait until the next schedule occurs).

+1

+1 For change control, we have to document everything within the administration tab. Currently we have a custom spreadsheet with screenshots of every setting (and their sub settings such as permissions applied to list templates!) massive time sink. A way to compile this information either by report or API calls or database queries would be amazing.

+1

+1 Need this. Also a way to manage host folders from administration tab.

+1; but this probably makes more sense as both a password list template option and user account policy option.

+1

+1

+1

+1

What we do is run the script as a service account (Passwordstate automatically updates the password every XX days); with the Sys Wide API key being a user environment variable in the service account context. the script sets and API variable to that of the environment variable. Doesn’t get captured in logging, doesn’t get committed to Git. no one knows the key except security administrator(s) with the required security role, no one can see the key without knowing the service account password.

+1

+1 We’re also encountering a situation where we need the API to return nested object IDs. folders to return password list ids password lists to return password ids With nested object IDs being returned we could then use loops to process those returned objects. Having to maintain a list of specific password IDs to target with a script is time consuming.

Configure the API on the affected password list to return a blank value instead of the actual password. List Administrator Actions > Edit Password List Properties > API Key & Settings > (tick) Return blank Password value

This may not be required. There is documentation (section 7) of the "Passwordstate_Upgrade_Instructions.pdf" which covers this already. Specifically, UPDATE SystemSettings SET MaintenanceModeUserID = ''

There is a STIG requirement to reset KRBTGT password every 180 days: The password for the krbtgt account on a domain must be reset at least every 180 days. (stigviewer.com) It would be nice to be able to have Passwordstate handle this in the recommended manner; which is to reset the password twice with at least a 10 hour pause between each reset. AD Forest Recovery - Resetting the krbtgt password | Microsoft Learn We're currently doing this through a custom script and the API; but native support would be appreciated.

List administrator actions. There is a checkbox to not allow passwords to be exported in password list properties. In the list administration actions drop down there is also an option to export.

Someone else has requested custom reporting:

You can already export all passwords and individual password lists as required. You can also mark password lists as not exportable.

Just copy the whole web.config, and update connection strings as required. If you don't need production data why are you trying to migrate the database as well? Just install a new, clean instance?

+1, however it needs to be optional. In our environment lockouts have to be handled manually.