Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Buckit last won the day on April 26

Buckit had the most liked content!

About Buckit

  • Rank
    Senior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Buckit

    Passwordstate Folder Permissions

    With regards to that bypass you mentioned, through the admin-panel: I don't know if I've mentioned it before, but I'd love that same bypass possibility for folders on the Hosts tab. I have a few folders created by a colleague which we cannot access because they left (and we're not allowed to use their personal account) :D
  2. It took me a while to process what you were saying, now I understand it... Yeah, this seems to be an issue with overlapping DIVs, so it'd require some tweaks in another location (probably lowering the Y-axis of the main DIV by the height of the top bar). I really appreciate you looking into this so quickly though :)
  3. Buckit

    Randomize Local Admin Password

    But not on Linux boxes Buckit Okay, I'll leave that one alone now Hey now! I wasn't going on about Linux boxen thankyouverymuch, they were IoT-devices! My Linux boxen are just fine and dandy Sure, the IoT-devices also run Linux, but they're Special Little Snowflakes (tm).
  4. Buckit

    Randomize Local Admin Password

    The things you're asking are the actual point of the product PasswordState :) Yes every Windows-box can have its own, unique password. PasswordState can discover AD-connected hosts for you. On these AD-connected hosts, PasswordState can login and discover admin accounts for you. Upon discovery, each account can be given a unique password. The password for each account can be retrieved from the relevant user account object in PasswordState. Yes you can also manage the admin/root accounts on non-AD connected hosts, however you will not be able to use the discovery tools. You'll have to either add them manually or by using a script through the API. Not sure about Azure. :) I doubt that you want Powershell Remoting open on a box in the cloud. Perhaps someone else can weigh in on this topic.
  5. In one type of system yes and that's how we'll setup that sub-set, although they have another problem entirely which will need more scripting to solve :( Other types of devices have both root and "normal" users with root not being able to login. Of course we could forego changing the root password, but that would leave the console open. So in those cases we'll need that script I described (or we open root up for SSH, but naahhh).
  6. I appreciate it It's of course well and good for me to say "it should be as simple as ...", but that's a stupid remark of course. I have no way of knowing your code. The end-result may be simple (an added HTML tag), but there's no telling how the page gets generated. Something-something-assumptions.
  7. Thank you very much @support, for your patience with me. I honestly think we don't pay you guys enough to deal with the amount of shite I send your way. You are of course utterly correct. Thank you for snapping me out of my stuck-thinking: I was in some recursive loop, not properly thinking about how to tackle my current problem, also because I was avoiding something specific. As you say, the only right solution here would be to make use of the API by building a script to tackle the situation. New IoT device? Run the script which: Defines the host, Defines the privileged password object, Defines the privileged account and the Defines the other password object(s) and ties them to the C privileged account. The downside to this is that you'll get a wild-growth of priv.accounts. The reason I kept avoiding this solution, is because it means I have to write a lot of Powershell code. Why? Because I'm stubborn. I don't want to make a one-off script that works for one specific solution, with hardcoded script IDs and other hardcoded settings. No, Mr Smug here wants to make everything a lookup through the API There's a Powershell module out there already, but it uses API keys instead of kerbauth which we prefer right now. But yeah. You're right. I'll get over myself and start tackling this problem the right way. That module needed to be written anyway and I'm postponing the inevitable. It ain't gonna write itself.
  8. Hey guys, Just a tiny suggestion: would it be possible for you to update the PasswordState Change Log webpage to include anchor tags in each update's header? For example, if I'd like to specifically link to build 8180, it'd be great to have something like https://www.clickstudios.com.au/passwordstate-changelog.aspx#8180. The changelog has grown to considerable size, so it'd help my colleagues if they didn't have to <ctr><f> for a buildnum. It could be as simple as changing this: <h3> Passwordstate 8.1 - Build 8180 (21st November 2017)&nbsp; <img src="/images/dbschemaupdates.png" alt="Database Schema Updates in this Build" style="padding-bottom: 3px;"> </h3> ...to this: <h3> <a name="8180">Passwordstate 8.1 - Build 8180 (21st November 2017)</a>&nbsp; <img src="/images/dbschemaupdates.png" alt="Database Schema Updates in this Build" style="padding-bottom: 3px;"> </h3> Take care! :)
  9. Buckit

    SSH key rotation

    Glad to hear that it's been of some help! I have a setup where an AD-account is used as privileged Linux user for the password changes by PasswordState, it uses the SSH keys you can store in PState and does it exactly in the way I've explained: pubkey in AD. What's more, we even pull our SUDO commands for the account in question from AD, as explained on my blog. I'll have to look into automating the key rotation you've asked about, as that will up the security a bit more :)
  10. 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.
  11. Buckit

    SSH key rotation

    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.
  12. 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.
  13. 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?
  14. 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