Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Buckit

  1. 3 hours ago, support said:

    So without seeing your data, I would guess that possibly there was a different type of Account Type selected for your already existing records.


    Bingo, that'd be it.


    Thank you very much for your help! I appreciate it.


    Odd, even after syncing the account types, the discovery job still created the duplicate. I'll poke around some more.


    EDIT 2:

    Solved... I only  re-tested with the acounts for one host and would you believe that it was this particular host that was also mis-registered in AD? :D

    You were right @Support: the issue was with the type definition.

  2. I've compared the original and the duplicate discovered objects. Up until yesterday there were more differences, but right now the only differences are:


    * Description: their description is wildly different

    * Account Type: Linux vs CentOS

    * Password List: the original is in the desired list, while the newly discovered one is in the list I made specially for that purpose called "Newly Discovered".


    Now, I sincerely hope that the password list is not taken into account into determining whether an account should be imported :D


    I can understand that maybe the type would influence the decision, but I would not care for the description playing a role.


    For now, I will set the account type to what is found in AD. Then I'll clean up the dupes and rerun the discovery.

  3. I'll get on it right away..



    Ah darn, I just realized that I cannot show you the screenshots as they contain identifying information for our environment.


    Can you tell me which exact fields the discovery job uses to determine whether the object in question already exists? While waiting for you, I'll try and poke through the code to see if I can't find my answer :)

  4. Hi guys,


    In our environment we have a bunch of Unixen. When spinning up new hosts we frequently quickly add the host and its accounts manually into PasswordState. However, we've then noticed that the account discovery jobs creates a duplicate of the accounts in question. Is there a way to prevent this?


    * We've set up the object names to match the formating that the discovery job would add.

    * The identical username is used.

    * The object is linked to the exact same host.


    What gives? Is it better to just re-run discovery after upping a new host? I would certainly still like to know how to prevent this duplication though...


  5. 2 hours ago, support said:

    I think setting up a lab environment, with a clone of your production DB would be a good start


    Of course I sincerely hope that @SGauvin and colleagues are actually doing this: first trying the upgrade on Dev/Test/Acc, before moving to Production ;)




    It almost looks like possibly some Anti-Virus software is killing sessions on your web server during the upgrade - although this is just a guess based on the 'Thread was being aborted" errors.


    If I'm reading the linked knowledge base article correctly it's not that there's something actively aborting your connections. It's a matter of the programming language reacting to an error and aborting the thread by itself to handle the error.




    As far as I can tell, the threads are being killed because the upgrade application has run into errors with the PasswordState code. Specifically, there appear to be problems with Scott's environment and these specific functions:


    • Build_7721_CopyPassword()
    • Build_7721_UpdateNonActiveDirectoryAccounts()
    • Build_7721_Updates()




    We don't think there's an easy fix for this, as we've never seen these errors before

    The "thread aborted" errors have shown up before on these forums:



  6. To further demystify FreeIPA for @support: it really is plain LDAP as a directory, with Kerberos authentication and which has a bunch of management tools added onto it. Quite literally RedHat's answer to Active Directory. To further complicate matters there's also RedHat's Idm (Identity Manager), which is mostly similar but a paid-for product.


    What @wkleinhenz, @Sarge and myself would be looking for, is host and account discovery inside the respective LDAP OU's. Better yet if you make it configurable ;) All in all it would be very similar to how you handle AD discovery, with a few tweaks to the expected OUs and perhaps a few field names.

  7. @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.

    7 hours ago, support said:

    In the latest build, we' provided the option where you can specify your own date/time format for Syslog messages - go to the screen Administration -> System Settings -> Proxy & Syslog Servers, and you will see it.


    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!

  8. 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).

  9. 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

  10. 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.

  11. 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.






  12. 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

  13. 57 minutes ago, support said:

    Yes every Windows-box can have its own, unique 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).

  14. 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.

  15. 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).

  16. 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:

    1. Defines the host,
    2. Defines the privileged password object,
    3. Defines the privileged account and the 
    4. 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 :o 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. ;) 

  17. 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:

      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;">


    ...to this:

      <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;">


    Take care! :)

  18. 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 :)

  • Create New...