Jump to content

Buckit

Members
  • Content count

    35
  • Joined

  • Last visited

  • Days Won

    1

Buckit last won the day on December 1

Buckit had the most liked content!

About Buckit

  • Rank
    Advanced Member
  1. Hi again! Eyeing your page on the secure design and implementation of PasswordState, I noticed that it's not yet possible to integrate with HSMs: Hardware Security Modules. Right now, when installing PasswordState, we're given a password-protected ZIP file that has the encryption keys to the password database. These are a vulnerable target and will be a sought-after prize for any attacker. Instead of handling the encryption keys in such a manner, I would like to request that PasswordState be remodeled in such a way that all crypto keys can be locked away in an HSM. I've already put Thales nShield HSMs to good use in other use-cases and environments, and they've proven very valuable. Not only does an HSM ensure that your keys will never be stolen (if implemented correctly), depending on the make and model they will also ensure safe and secure backups of the keys. Many HSMs integrate nicely with Microsofts CNG API, thus providing a standard method for applications to hook into them.
  2. More verbose access log

    Not necessarily. There's a reason why "I swear I didn't change a thing!" is one of the oft-heard excuses at /r/talesfromtechsupport.
  3. Permissions for generating API key

    Yup! You will find the menu-bar configuration under Administration > Feature Access > Menu Access. There, you can define permissions for menu-blocks (Tools, Reports, Preferences, Help), but also per-item in each menu-block. In my case, I've set up the menus in such a way that my default users cannot see anything besides the "Request access..." items in the Passwords menu. All the other options are reserved to administrators and senior users.
  4. Nope, not seeing that because we have zero email capabilities, hence why I'd like to have more built-in logging capabilities.
  5. Permissions for generating API key

    Would you believe that the API documentation is actually tremendously well done? It hands-down beats the online documentation you guys have been showing in the screenshots! Just visit your PasswordState's API URL, for example: https://passwordstate/api or https://passwordstate/winapi The same URL you call with API calls also includes the full documentation with code examples! How sweet is that?!
  6. More verbose access log

    And sometimes the user will try to actively hide what they've done. So yeah, especially in high security environments, a detailed audit track would be recommended.
  7. Hiya, I was poking around the API and WINAPi documentation at https://passwordstate/api and https://passwordstate/winapi. First up: big kudos for your work over there! It's an awesome resource, very useful! I noticed a small detail that's off: at /winapi, all the URL and code examples still refer to /api instead of to /winapi. I realize it's such a small silly thing, but it may at some point throw off someone who's trying to use the Windows-integrated authentication instead of the API keys. Cheers, Thomas
  8. Bulk Password Resets

    Actually, that setting is not part of the account discovery configuration. It's part of the host discovery config. The account discovery will simply login to all found hosts and try to find local administrator accounts. If you feel iffy about having PasswordState run the account discovery for you, you could also create the user+password objects through the API. It's pretty darn wonderful! Assuming that you have some way of generating a list of hostnames from your CMDB (or other registration), it's a simple matter of a ForEach loop to create the required host and password objects. That's exactly what I'm doing right now for a few hundred IOT devices.
  9. Yes all of our Windows boxen should have a local admin account, but sometimes the privileged account used for discovery cannot login (due to AD policies). Right now, the discovery jobs do not seem to provide logging about these kinds of errors, which is why I'm asking for the report: this allows me to trace which hosts may have had login issues for the discovery account. Of course, I'd much rather also have a report or log about the recent discovery runs That would help me troubleshoot even better! The error console does not show these kinds of issues.
  10. Hi again! I've been dutifully adding hosts into PasswordState and I've also ran discoveries against them. However, only 60% of them reported local admin accounts. Figuring out which hosts don't have password objects yet is becoming a bit of a hassle. I'd love to have a report or two which tell me which hosts don't have password objects associated with'm. And the other way around, it'd be great if there's a report for orphaned password objects, where the host has gone missing or "unmanaged". Did I perhaps overlook an option that already allows this? Cheers!
  11. Temporary access

    That's a very thorough reply Support Thanks!
  12. Backup account: use a managed account

    That's awes That's ace! Thank you very much!
  13. Bug report: Windows password reset script

    Aye, I'll poke around some more in our global policies and settings. It's an interesting situation. In another test, I use the same commands with a proper admin account and while the password changing went off without errors, the validation still fails (suggesting that the change wasn't made). I'll report back when I've had the chance to poke around some more.
  14. Bug report: Windows password reset script

    Hi, thanks for your help. Everything you need to know is in my first post in this thread: reproduction, code analysis and a suggested fix. One easy way of reproducing the situation is by manually removing the Windows privileged user from the administrators group on the target host. This will ensure that the password change request fails. But as I showed, the itself will still report a success and will thus not report any errors. Of course... removing administrator rights form the account means you'll have to ensure that the account gets Powershell Remoting access in another way (see my other thread). Funnily enough, my Windows privileged account -DOES- have full admin rights and it still gets "access denied" on the $account.psbase.invoke. That's a WIP on my side, which led to the discovery of this bug. EDIT: I have just tested my suggested fix in my sandbox environment. The password script now correctly sets "reset status" to RED, with the correct error message as reported by the failing $account.psbase.invoke. Of course, that leaves all the other scripts to double-check for similar bugs
  15. Browser extension with SSL offloading

    No worries We've all been in those kinds of situations. Best of luck! Right. Given the sensitive nature of this data, that's far from ideal. But I guess they have their reasons for it. If I manage to find some time, I'll poke and prod some more into the code. See what I can figure out.
×