Sarge
-
Posts
200 -
Joined
-
Last visited
-
Days Won
8
Posts posted by Sarge
-
-
-
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).
- Eritherium and Mordecai
-
2
-
It would be fantastic to be able to customise what fields are included in the reports that can be scheduled.
-
The above was caused by Windows Server 2019 must be configured to use FIPS-compliant algorithms for encryption, hashing, and signing. (stigviewer.com)
The IIS errors are a red herring in this case.
-
These errors "It appears the user's session in IIS has been prematurely ended, causing the following error" also occur during the Out of Box setup wizard as you click "Next" to apply the "System Settings" if you've got the STIG for Windows Server 2019 applied.
We're still trying to find exactly what setting within the STIG is causing the issue. @support is there any guidance you can provide of what is occurring after clicking Next on the System Settings setup wizard screen?
-
-
A couple of suggestions:
1) Require users to select a password list template
Use case: Your organisation requires all Password Lists created to require "provide a reason" (or some other setting) additionally, you have multiple templates users can use because naturally, they aren't one size fits all.
A UAP can enforce users to use one specific template for settings and one specific template for permissions; however this doesn't work when users have multiple templates to choose from. There is nothing to stop users from not selecting a template to use for settings/permissions - thus bypassing the organisations requirement of all password lists configured to "require a reason".
Perhaps an additional UAP setting "Users must choose a template they have permission to when creating a Shared Password List" and "Users must choose a template when creating a Private Password List".
Setting D3 should still work as expected with the above suggestion.
2) Categories for Password List Templates: When copying settings from a template, only allow users to select a template marked as "Private Password List Template". Currently users can select any template they have access to, to copy settings from (Shared or Private). Thus the drop down for template selection can be needlessly cluttered. Current best solution for this is making sure templates are named appropriately.
3) Additionally, an option to prevent users using self-destruct messages on Private Password Lists, and exporting their passwords.
-
# PowerShell Request $PasswordstateUrl = 'https://passwordstate/api/passwords/<PasswordID>' Invoke-Restmethod -Method GET -Uri $PasswordstateUrl -Header @{ "APIKey" = "<apikey>" }By default this will return all data associated with the password record.
You can do this instead to select only the password.
$GetPassword = Invoke-Restmethod -Method GET -Uri $PasswordstateUrl -Header @{ "APIKey" = "<apikey>" } $Password = $GetPassword.Password.ToString() -
Hi Support,
Thanks for implementing this feature.
I've noticed a potential bug when testing it. I set the Web Site Allowed IP Ranges to *.*.*.* and hit save, the application stopped the entry from being saved as it should but an auditing event was still recorded for the attempted save.
It would also be great in a future build if the previous value and new value can be captured in the auditing data. -
Limited use cases this one, but in some circumstances, there are requirements to have passwords synchronised across hosts for a specific user.
We can achieve this through a custom script, but it'd be a lot easier if it was possible to associate multiple hosts with the same password item - so when it comes time for Password Resets & Validation the one password is used on multiple hosts/validated. -
Supporting this.
Important feature to have in secure environments.
-
On 8/21/2018 at 7:25 AM, texxx said:
Be nice if Passwordstate would allow me to set an option in the Duo configuration to automatically send a push request as soon as I get to the Duo step of the login. I’d also want to be able cancel the auto-push and be able to select a different auth method (text, phone call, passcode) in case push notifications are down.
Same for the Google Auth 2FA.
The Microsoft Authenticator app supports push notifications, just needs to be implemented on Passwordstate end.
-
9 minutes ago, support said:
We've also thought about this in the past, but not sure technically how we would achieve this - if you look at all the possible settings alone under the System Settings screen, there would be 100's if not 1000's of changes that would need to be somehow tracked, and reported. Hopefully one day we can come up with a solution for this.
No worries.
I'm probably showing my ignorance but I'd have thought it'd be a kin to showing the difference of a database value for the system setting prior to change and then after the change; while prepending the users unique identifier. -
It would be nice to have an audit log for all additions or modifications made via the application administration section; including what setting was changed to what.
Example:
"User XX changed XX setting from XX to XX".
"User XX added Active Directory security group XX from the domain XX""User XX granted Active Directory security group XX modify rights to the template XX"
In a multi-administrator environment being able to know these changes and revert them if required would be hugely beneficial; especially when many modifications are made but may not be captured in the work notes the user maintains.
-
On 8/13/2018 at 3:51 PM, sqhharsunen said:
Additionally schedule this to appear on predefined date/time.
I'm not bothered by the banner, but it can certainly have its uses.
However I'd like to see the ability to schedule Outage Notifications and schedule maintenance mode (both separately). This would make handling RFCs much easier.
-
On 8/22/2018 at 7:06 AM, support said:
Sorry, the WinAPI (Windows API) can only be called from Windows Machines using PowerShell.
Possibly. But I wouldn't suggest it in a production environment yet.
Powershell Core is GA on Linux and MacOS.
-
-
10 minutes ago, Alexey said:
Question: Do I need to manually make sure that I have encryption keys and web.config file stored elsewhere (have backups of them) or the automatic backup procedure does that for me?
Technically no, web.config and the database contain half of the encryption keys - put the halves together and you can decrypt the content of the database.
The ZIP contains everything in /inetpub/passwordstate
The Bak, as you pointed out, is the database. So with these two things you have everything you need.
We rotate then export our encryption keys every third upgrade and send them off site in a vault to be stored - but this isn't required.
We also ship our passwordstate generated backups to a different physical server at a different site, as well as sending to tapes which get stored at an offsite vault.At anyone one time we have some 365 copies we can restore from (on tapes, one for each day), and then 30 copies on the passwordstate server we can restore from, as well as those same ones on the second physical server in the second site.
-
Thanks guys.
This helped me resolve the issue I had setting up a quick demo site for a collegue.
How is your folder structure set up for cross-department access?
in General Hints and Tips
Posted
Folders per team
Password list templates per team
UAP per team
AD Groups per team, applied to templates/UAPs
Team leads are admins of lists
Passwords that need to be shared across departments can have that teams AD group applied to the password list or the individual password item.