Sarge

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.

A system wide setting I don't agree with, however perhaps one that is configurable by User Account Policies, and overwritable via the user from their User Preferences screen. Not sure how nicely that would play with the password lists settings for number of records to display. Perhaps the individual password list settings would take precedence over the user preferences settings, and the user preferences settings could be set to a default (but changeable) value via User Account Policies.

Oh yeah right. Welp that’s embarrassing Leave me alone it’s Friday!

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.

Based on that screenshot, you need to match the Passwordstates regional settings to that of your host operating system. The bottom/first error is the real error that needs to be resolve, the second error is the side effect of the process failing because of the mismatching regional settings. @support does the application really need regional settings? Wouldn't it be better to just inherit the operating systems regional settings? I can't think of a reason for application specific regional settings, but I'm sure there is a reason for it

Thanks guys. This helped me resolve the issue I had setting up a quick demo site for a collegue.

Looks great. What do you use for the ssh sessions? Can we choose our own backend client?