Sarge

I hadn't thought of that; but I think breaking the API call maybe the best option; with an exception message similar to "One or more targeted password lists require auditing data". Confusing the customers should be avoided. As long as the exception message is clear why the API call failed then I see no issues with it. Perhaps return the password list ID(s) that the API call failed on in the exception message. Also, log the API call exception in the password list auditing data table?

+1 This certainly has its uses when you have a busy day with Passwordstate and you keep getting idle timed out every 10 minutes.

Happens to us as well, isn’t it great lol That’s actualky the spot I was thinking when I was writing the post. I agree it’s most logical there.

Hi Guys, We're often faced with the situation we need to send Self Destruct messages to contractors who have no requirement to access Passwordstate; its tedious to have to manually type (or otherwise hunt around) for the contractors email address every time we need to send them a Self Destruct message. Obviously Passwordstate allows you to select users to send a message to, but it'd be nice if there was some form of "Address Book" that you could add contacts to for the same purpose. Adding a new contractor to the Passwordstate address book would then become part of the enrolment process for that contractor. When implementing such feature, it'd be nice to be able to change the Self Destruct UI to have radio buttons to indicate you wish to search (as you type) for a Passwordstate user or in the Address Book, or both, as well as some way to select multiple contacts and/or users.

It hasn't happened for us yet; but our current implementation was tested to have zero dependencies on anything else (besides the obvious like networking); additionally everything we need to restore Passwordstate has been documented, plus we have a restore kit securely stored offsite which contains copies of the documentation and Passwordstate passwords. We test restores monthly. Our recovery plan for Passwordstate is about 10 pages long. We're about to move to an Active/Active design, backed by a 4 node AAG across DCs which will host Passwordstate which will just improve our uptime. I just need to finalize the design with the other teams, but unfortunately its not my priority right now. Ultimately for us it would depend on why it was down. Generally speaking if we can't get it back up within 15 minutes we will be initiating a restore operation as its easier and faster for us. We don't predict Passwordstate being down for more than 30 minutes even if we had to restore. Which is critical, because it holds data for our backup software which we'd need to initiate restores in the event of a total failure of the DC.

And now to be annoying. Can it be set on a per password list setting as a requirement? IE: No reason provided, then data isn't returned. I should have included that request earlier lol

This should make scripting even easier then having to re-encrypt via ConvertTo-SecureString.

For a laymen like me, can you explain what it achieves? I might look to implement on our instance when we rebuild it for DR.

I'll +1 this.

Today I learned. Thats awesome guys!

Can you clarify your request bn8959? The purpose of the self destruct message is to share a created password to people who don't have access to the list or Passwordstate. Why would generating passwords in the share message (where they won't be saved for future use) be needed?

For the email templates in general; whichever templates it seems appropriate to have the variables available. But specifically for our use, then the self destruct messages at this stage.

Hi, As per my email it'd be great to have the ability to set additional fields in email templates, such as the notes fields. However I'd go so far as to say all standard fields, plus the 10 generic fields - which I'd envision working as [GenericField1], [GenericField2] etc, even though on the passwordlist display names for the fields maybe different. I'll +1 my own request

I believe this is a +3

I share this concern, but at the same time the Passwordlist can have ACLs configured. However if there's a feature request to add authentication to the REST API plus API key and ACL usage then I'd have to +1 it; although per-user API keys would probably also suffice.