Sarge

The Active/Active design is the best way to achieve this and is supported by the vendor. You need to weigh up how often connection problems arise, my bet is not often enough to warrant not setting it up in a supported manner. The other option, although I'm not sure how this would work with licensing (you may still need the HA module), would be to have two seperate instances, and use the REST API to export the passwords from one instance and update them in the other instance. I doubt this would be a supported method, but its doable. You're basically using the API to homebrew a compare then update script.

Forms based authentication for Passwordstate, do users have password requirements? Minimum characters, complexity etc.

I messed around with the object inspector for about 30 minutes but gave up, however position:sticky seemed like it would have got me there if my CSS-foo was better. Although to be honest, I think each build should have its own release notes page containing the usual, whats new, whats fixed, whats changed, known bugs, then do away with the "change log" and turn it into a "release log" TOC linking to the builds release notes and their downloads (https://www.clickstudios.com.au/previous-builds.aspx).

How would this work? Given the passwords are salted, you can't compare at the database level. Compare the unencrypted data I assume?

This will certainly be a good addition for some customers, however I wouldn't like to see the in-application approvals disappear. Nope, see below. (I don't have any clue what this new mode of approval would be called, so lets go with "Other" for now) When creating the password list and specifying the approval settings "Handshake Approval" or "Other". When choosing Other a setting of "Users who approve access" with three sub-options of "List Administrators", "Specific Users/Groups" or "Specific List Administrators and/or Specific Users/Groups". The first option is pretty obvious - list administrators approve requests. The second option is pretty obvious - only specific users or groups approve requests The third option is basically a completely custom setup - If someone wants all or specific list administrators PLUS a "security" user to approve requests. In addition to approvers, list settings should dictate how many people are needed to approve requests - a customisable number. Want 4 users to approve requests before someone can have access? Then enter 4, and when choosing the users in the options above, it will throw an error if there is less than 4 approvers specified. In our instance, we want list administrators (Our teams admins, which vary from 1 admin on a list to 3) plus our security officer. So we would specify the list to have 2 approvers required, and use the third option, choosing any number of administrators plus the security officer. The net result being the list requires 2 approvers, but we've configured all admins of the list (3) plus the security officer. (Total of 4 approvers configured) Since our list has 4 approvers configured/notified about a request, but only 2 are required "first in first served" basis applies. This is where the in-application approval would be useful - the approvers get emails saying to login to approve the request, where the application can show previously actioned requests as well as outstanding ones (as well as more information about who can approve the request, who has, who is looking at it etc) I believe so. A lot of enterprise clients will have security officers - those users don't need the passwords, just the ability to authorise access requests. Our security officer would be configured to have no access to any password lists besides those he's requested access to (or maybe a private password list), and would have the ability to view auditing data/reports; and approve requests. Is that even possible? If so, should it be? How do those lists get deleted or modified? If a password list isn't getting permissions for someone (or some group) set as Admin permissions, the creation process should fail in my opinion. However, to answer the question, that would be an outlier situation where the creation process should be able to recognise there is no administrator for the list, and there for the "Other" approver option should be configured. I just went to answer this but apparently I already have lol. On a side note, is there password requirements for the application itself? I got asked that question today and I couldn't answer it lol.

On this, I had a discussion today with our security team as we look at expanding the usage of Passwordstate further, we need the ability to have multiple approvers to approve an access request, where they don't have to be logged in at the same time. So pretty much a less fancy version of handshake approval; as well as the ability to not let users decide who will approve the request via the request access dialog screen (Currently they can select individual list admins, or it defaults to all list admins, we need to be able to disable this).

Simple solution, add a custom field to your password list and populate it with the hostname via API. Your script could easily perform a reverse lookup on the IP of the host record, then populate the custom field with your hostname. However you should be doing everything via FQDNs anyway. Having poorly functioning DNS in an environment is not good, regardless of OS platform. I'd be looking to fix DNS.

I saw that, big update guys, nice work! Time to update my instance at home!

To write about every feature in that makes it a PAM solution would be akin to writing a thousand page essay. I think the better option would be if you could tell us what you are after in a PAM and what you're after Passwordstate to do? There's a good chance it does it. Yes.

Scratch that Buckit. Did a bit of the old googling and looks like this could be 'by design'. This seems similar to your problem: https://davidvielmetter.com/tricks/password-reset-delegation-not-working/ I'd bet this is happening for you. Further, I'd bet your break glass accounts won't remember the 'include inheritable permissions' checkbox because they are members of some protected AD groups. https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory https://technet.microsoft.com/en-us/library/2009.09.sdadminholder.aspx Is the process for updating the AdminSDHolder object. Full credit to the article and the commenters. You learn something new everyday! EDIT- For clarity Buckit, I wouldn't be modifying the AdminSDProp to enable inheritable permissions, I'd simply add a security group with your priv user being a member, and grant it the required roles to perform resets on AdminSDProp based objects. Wait for the SDProp process to run (1 hour ish), and you should be set. I don't like the idea of modifying the default ACL for protected objects, but I like the idea of enabling inheritable permissions even less. Also, i'd be taking screenshots of before and after for every change you make to the AdminSDProp object, and be documenting it fully.

Story of my life lol. I'd expect it to yeah, however I've properly read your opening post where you've said it usually works, except for the 'break glass' accounts. Is there anything special with those accounts? (MSAs etc?) I'll play around in dev this week and see if I can replicate the issue.

Windows here, blooding in on RHEL? Whats the issue? Delegation rights will work, assuming the right ones are set. Although the account will need WMI/RSMAN permissions as well.

This is detailed in the user manual on page 66. The option you are after is ‘Bulk Update Passwords’. https://clickstudios.com.au/downloads/version7/Passwordstate_User_Manual.pdf#page66

I could be wrong, but a quick scan of the Web API documentation, I believe you should be able to do this via that method as well, Azkabahn, as there is a ScriptID parameter. I could be wrong because I just did a Ctrl+F for ScriptID without actually reading anything though. I'm not following what the issue with the reset script is you're encountering? Generally speaking, most environments you can't SSH with root users, so you have to connect with a priv account, and pass the required passwords down the pipeline to sudo and passwd. I have password resets working for our root users and for our IPA based priv account, so I'm happy to help you get it working if I can.