Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Buckit

  1. Good morning everyone :) The past two weeks we've discussed this a bit, so I thought I'd make it a real feature suggestion. I would very much like the possibility to define one-to-many relationships for accounts to hosts (1:N). The biggest use case I can think of for this, is Linux privileged user accounts in Linux/Unix environments where a centralized IAM-platform is not available. For example, a network with many IoT devices which allow SSH for management functions, but which cannot integrate with AD or LDAP. In such a case it would be a great hassle to define privileged accounts on a 1:1 basis. If I would be able to define one Linux account, with a strong SSH keypair (or a frequently rotating strong password), that is to be used on the relevant systems as the designated privileged user, that would be ever-so-helpful. #RunOnSentence.
  2. Aye, it should be possible to achieve, but it'll need some work on multiple ends of things. The biggest problem is the distribution of the private key. @1527460Kevin suggests generating them on the Linux box and then pushing them out to PasswordState. Personally, that's not something I'd recommend because now you're transporting the literal key to your system, which either is not password protected, or your transporting along with its password. That could/would be not a problem, except that you're wanting to do it unattended. I mean, if you're doing it personally, you can immediately tell if something's gone wrong. The prettiest solution I can think of is to: Generate the new keypair on the PasswordState box using puttygen. Import the private key into the appropriate account object into PasswordState using the API and remove the original file from the file system. Have the Linux/Unix hosts use AD for their authentication backend (through SSSD). Push the public key into the relevant user's altSecurityIdentities field in AD. All this should be doable with Powershell, combined with API calls to PasswordState. It also takes care of the public key distribution, saving you the effort of sending the pubkey to X amount of servers. Alternatively you could of course push the pubkey to each of the X servers that the account exists on, using pscp (the Putty CLI SCP client). However, that brings me back to an issue I was having earlier last week: PasswordState does not have a way of linking one account to X amount of hosts. Unless it's an AD account, you'll find 1:1 - account:host relationships. That's not always ideal.
  3. Touché! Sorry, I did not mean to be patronizing, or whatever the word that applies may be. Snarky? Dickish? Either way, I didn't mean to do that The methods you describe sound pretty solid! Sounds a bit like sudo-but-on-windows. As I said, I'm still a Windows rookie.
  4. Yikes, you sure about that? I'm not overly familiar with Windows security, so I could be wrong, but to me that reads like you''re giving your web application full write access to its own source files. That's not usually something you want, right? "Hellooooo LFI vulnerabilities!" - Yakko Warner (probably) Is this a temporary change that can be undone when the upgrade has completed?
  5. Dang, was afraid of that.I also gave it a quick try to kludge this together as a dependency, but unfortunately that doesn't work Now, what I've seen in the past, working with CyberArk, is the possibility of defining one password+account object which references multiple hosts. I reckon that would be the most elegant solution. This would be a very useful feature to have, especially with IoT devices like the ones I'm working with. #FeatureRequest
  6. Hi guys, I've searched through the manuals but couldn't find anything that covers my question. Funnily enough I do know that there's a report that checks whether what I want to do is happening. Question: I know it's not a good idea and I know it's against good practices, but: is there a way to link or sync individual accounts across multiple hosts, so they share the exact same password? Use case: Let's say I have Nx100 amount of IoT devices that have both a root account and a remote access account (let's call it "remote"). These boxen cannot hook up to a centralized accountsdatabase, like LDAP or AD, but we do want to manage both the passwords of root and of remote. Currently we are stuck following this process: Make a host object for the device (X). Define the remote user and password for host X in PState. Define a privileged user linked to the remote user for host X. Define the root user for host X and set its management through the privileged user for host X. Repeat ad nauseam, for Nx100 systems. *shudder* Things would be a bit easier if we could make one (1) privileged user which is linked to one of the remote user accounts, with the huge amount of remote user accounts linked in such a way that all of them share the same password. Or perhaps: Now perhaps I'm thinking about this the entire wrong way. Is it possible to make one user record that applies to N amount of hosts? Any tips would be useful!
  7. I've said it before and I'll say it again: you guys are amazing. The turnaround on feature requests and bug reports is astounding.
  8. Ditto for the "handshake" feature, where you will need approval from another person to access a password. To sum it all up, I suggest you simply start reading here and work your way out from there.
  9. Even more impressive than the "request a password which auto-expires" is the built-in "request access and get an RDP/SSH session" functionality, which will never show you an actual password
  10. Dude... You guys are bleeping brilliant! Over the Easter weekend no less?! Man, I'm looking forward to upgrading already
  11. You sir, are awesome That seems to be absolutely on the nose! I'll run that through DevTest sometime soon! There's a few other things demanding my immediate attention, but this is a seriously great find Sarge!
  12. Man @Sarge you lost me with that message. Seems that you wrote that late at night You're saying that it should work as expected? Mmm... Depends of course on how you define "the right ones" when it comes to delegation rights. My 4-step list above shows exactly what I did, which I guess wasn't enough.
  13. That could work yea, were it not that I'm in a network where we cannot send email. At all. So, manual reporting it is :/
  14. Ahhh, another useful tidbit: it happens that a dependent service has been disabled. The password change will then report a failure for this particular dep, even if it isn't one: the service is not intended to be (re)started. Would be good if there's a check for that before/while restarting.
  15. Here's another feature that I would love, related to this topic. Currently if you change a service account's password, it'll show up green/OK if the account change worked on the AD-side. However, there are zero indicators that adjusting the password on the dependency-side failed, unless you actually open up the object's dep-list. It would be much, much appreciated if there was a way to indicate that deps had failed resets.
  16. Dang... I'll have to look into the workings of AD some more. Of course it makes sense that normal user A cannot change the password for super-user B (escalation of privileges etc). I'm a Unix-admin by origins, so I'm still learning this AD/Win stuff
  17. Hiya, I've been struggling with a few things in our ACC and PROD environments; thought it'd be better to ask for your help. For starters, there's this one: I've defined a privileged account that's used to expire both local Windows passwords and passwords in AD. Conforming to the manuals I've set up the account to be local admin on the Win boxen and to have delegated password management rights on the AD domain. The latter is done through ADUC (Basically like this article describes): Right-click the domain's top / root, choose "Delegate control". Add the privileged account as the user that gets delegated control. Choose the task "Reset user passwords and force password change at next logon". Click Finish. In many cases this works just fine. But not with a number of break-glass accounts that we've built in AD; they're accounts with elevated privileges. In their case I find myself having to edit the Security settings of the account in question, adding the PasswordState privileged user and giving it both "change password" and "reset password" privs. Did I foul things up with the delegation at the AD-level? I thought this'd be enough. Cheers, Thomas
  18. ACK! That's absolutely my point. Because every time that you change the password object itself, it will restart every single dependent service. You really do NOT want that. So, in my example of 3/20 failures, I only want to re-sync the password to the three failed dependencies. And because we're moving into troubleshooting-country I'd like to be able to do it on an individual basis, one dep at a time.
  19. Nope, sorry for not being clear enough. I'd love a button to push, to ask PState to retry setting the password if it failed.
  20. Hey guys, Here's another feature request: add an option for existing dependencies to manually re-sync the password in the dependent task/service. I've just discovered one account that has 20 dependencies. Expiring the password went fine and for 17 out of 20 deps the password was updated on the dependent side. For 3 of them however, the change failed with cause "Unknown error". This means that I'll have to visit the boxen in question and manually update the password. For 3 services that's doable, for 30 that's gonna suck. But I also don't want to re-expire the password, because that means I'll be restarting the 17 services that -were- okay to begin with. So, please add a command to re-apply the current password to a dependent service.
  21. Yeah that was exactly my point Discovery puts an account in a list you've indicated and if that list has a default sched, it'll apply. That could lead to all manner of fun.
  22. Whelp, looking back I realize that this would also be a wonderfully easy way to kill a lot of services in one fell swoop Especially when the target password list that accounts are added to adds auto-expiry to the passwords. Wouldn't it suck for your prod applications to restart in the middle of the day, because PState had a scheduled password reset? Let's tread carefully.
  23. Personally, I'd expect one to be able to edit anything one has added Nothing's set in stone. Wait what? O_o Time to hit the manuals again! You mean to say that I don't have to manually add 150+ dependencies for that task that runs on all my boxen? NICE!
  24. Hey guys, I'm still running an older version in my DEV environment, 8180. After defining a dependency for one of my password objects, I discover that I cannot edit the created dep. I can only add a new one and remove the existing one. That feels really sloppy. Was this fixed in a newer version, or is this a "FIXME" for a future release? EDIT: Here's another one! Instead of asking us to select both a script AND a dependency type, could you please make this an implicit action? Either you choose the "Reset Scheduled Task Password" script, or you choose the "Scheduled Task" dependency type. It's too easy to forget to change one of these and it leads to messy situations. Especially if you can't edit defined dependencies EDIT 2: Could you also consider renaming the "Reset Scheduled Task Password" script to "Reset Windows Scheduled Task Password"? Similar for the IIS app pool and the COM+ components. That will neatly group the four related scripts together in the pulldown menus. Cheers, Thomas
  • Create New...