Jump to content

Buckit

Members
  • Content Count

    134
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Buckit

  1. Yep, that's exactly the issue I was trying to explain. And what I expected is what you explained: it's an additional layer of security. Glad to know things work as designed. Now I just have to make sure that particular checkbox cannot be unchecked Thanks for further explaining!
  2. Hi guys, I'm playing around in our DEV sandbox, with PasswordState. Stumbled upon something that I wanted to discuss briefly. Reproduction: Install PasswordState. Setup my own AD account as the first admin account. Create a group in AD, "pstate-admins". Add multiple AD users to AD group "pstate-admins", including myself. Import the AD group "pstate-admins" as an AD security group into PasswordState. Go to security Administrators and try to add the security group "pstate-admins" with privileges. The group in question stays greyed out and cannot be adjusted. Is this a bug, or is it a design feature to prevent me from expanding my current set of access permissions? I could understand it being the latter, now that I think of it. But on the other hand, the account I'm currently working with is the primary / first full admin user. You'd expect that one to not be limited Then again, proper security considerations would suggest that even the primary admin is limited by access permissions. Workaround would be to remove myself from the AD group, then add permissions, then re-add myself to the group. Yup. However, now I get stuck when working with password lists! I've set up a few lists and I want to ensure that the "pstate-admins" can administer the lists in question. I cannot add list admin rights to "pstate-admins", because I'm a member of that group. Despite my account already having full access to the lists, because I'm the one who created the list. This is a bit messy :/ Suggestions? I could remove my account from the AD-group again, but in the long run I want the first admin account (mine) to be removed in full, so my rights work through the AD-group.
  3. Now that's what I call speedy service! Many thanks!
  4. Hi guys, For security's sake, I would very much appreciate it if you'd publish the hashes or checksums of the various packages you offer for download (for example on the archives page). That's one of the requirements from our software download and import policies: before implementing software, verify the hash of the package against the hash published by the vendor. Cheers!
  5. Another potential use-case would be remote-access user accounts for external support companies. You'd usually want these accounts locked out, only to be unlocked and a password to be set when there's a specific support case that the external party needs to work on.
  6. You guys, that sounds like you're on the nose and like I need to read the manual from cover to cover. Sarge's suggestion sounds exactly like what I need! I'll go test some more! Apologies for making a needless thread. On the other hand, Support's suggested Feature Request does sound like a good idea: defining a default target security group for request emails. Thanks guys!
  7. Hi there, Right now I'm still very much a newbie, so I hope this hasn't been requested yet. I'm in the process of running a limited PoC before moving towards the Enterprise level purchase. Instead of sending approval requests for password usage to one or two specific people, I would very much prefer the possibility to assign the approval request to a security group. This will allow us to designate a team of security officers to the task of approving password usage. I would also like the possibility to apply these requirements to a password list as a whole, or to specific security groups. E.G. Junior admins will always require approval for all their requests from all Linux lists, while Senior admins only require approval for Linux PROD but not for Linux DEV. Cheers, Buckit.
×
×
  • Create New...