Jump to content

Sarge

Members
  • Posts

    198
  • Joined

  • Last visited

  • Days Won

    8

Posts posted by Sarge

  1. +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).

  2. +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. 

  3. On 10/20/2023 at 1:55 AM, Mordecai said:

    But we don't want to make the System Wide API Key generally known to so many people for this.

    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. 

  4. +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. 

  5. 2 hours ago, support said:

    Hi NateG,

     

    Thanks, and we did overlook that customers can enable Maintenance Mode when logged in with Emergency login account, and we will need to update our documentation for this.

    Regards

    Click Studios

     

    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 = ''

  6. 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.

  7. On 10/25/2023 at 4:28 PM, SDFD said:

    . Copied the "connectionStrings and AppSettings" (unencrypted).

    Just copy the whole web.config, and update connection strings as required.

    On 10/25/2023 at 4:28 PM, SDFD said:

    Can't i just install a new instance, according to documentation, and simply use my existing keys? I don't really need the data from production to test stuff out.

    If you don't need production data why are you trying to migrate the database as well? Just install a new, clean instance?

    • It would be fantastic to be able to customise what fields are included in the reports that can be scheduled.
      • For example a Password List used to store SSL certificates with a number of custom fields; currently the report only shows the title and expiry date as we don't use any of the other default fields - we'd love to be able to select which fields to show on the report (exclude empty fields and include custom fields).
    • If they could be scheduled from the administration area as well rather than in a specific users context that would be great as well so all administrators can see/modify the reports easily.
    • If the wording of the report email could be customised in the same manner other email templates are. 
    • Ability to allow users to run reports without giving them the reporting security administrator role. (We have separate accounts for security administrator roles).
×
×
  • Create New...