Jump to content

Buckit

Members
  • Content Count

    126
  • Joined

  • Last visited

  • Days Won

    2

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

    ELK and PasswordState

    @Sarge: Oof, that's a shame. Sorry to hear that! I'm currently running a PoC to try out a few logging platforms, and am definitely looking to push one through in the next two months. Ahh that's cool! For now I'm on a release from two months ago though, but I'm looking forward to the new features!
  2. Buckit

    ELK and PasswordState

    I'm currently fighting the syslog feed myself, putting it into Graylog (like @Sarge). In our case, I'm running into the issue that the default syslog parser reads the timestamp as the source name, leading to a large amount of different sources (instead of the single Passwordstate), with thousands of messages all appearing at 01:14:34 (for example).
  3. Buckit

    Slow download for upgrade package

    I was using the latter link, as that's the one that was shown in the error message of the failed upgrade. I'd started the upgrade, which failed in properly downloading the required file. The error message informed me to try again, or to download https://www.clickstudios.com.au/downloads/passwordstate_upgrade.zip . So I guess that path's still hard-coded into some parts of PasswordState. Might I suggest you change those Anywho, mystery solved :P
  4. Buckit

    Slow download for upgrade package

    Ooofff, it's been downloading for six hours now, sitting at 113/180MB. That's throughput from fifteen years ago
  5. Hi guys, I'm working on upgrading my DEV/TEST bed and I've noticed horrible download speeds on the upgrade package. I've snagged the URL from the upgrade process which points at passwordstate_upgrade.zip. This 180MB file will take all of three hours to download. O_O Is this a CDN issue? I'm grabbing it with my usual Macbook, on my normal network which works fine otherwise.
  6. Buckit

    New type: "Dumb" password

    Mmm, I'll take a look at this... Keep you posted.
  7. Hi guys, Lately we've been storing things like crypto-disk PINs and Java keystore passwords in PasswordState. We've had to shoehorn these passwords into an existing password type, but that's suboptimal. Would it be possible for you guys to build in a standard "dumb" password type? Something that will never be auto-managed, nor heartbeated. Something not tied to a hostname, nor to a username. Just a PIN/Password/Whatever. I could try and define my own type, but it'd be nicer if it was in the product. Cheers, Thomas
  8. 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
  9. 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 :)
  10. 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).
  11. 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.
  12. 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).
  13. 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.
  14. 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.
×