Jump to content

Buckit

Members
  • Content Count

    134
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Buckit

  1. Backing up and restoring to a new host always seems the safest decision to me. But then again, I'm no DBA
  2. You know? I wouldn't mind receiving similar information, because our environment is also under pretty close scrutiny...
  3. Bingo, that'd be it. Thank you very much for your help! I appreciate it. EDIT: 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.
  4. 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 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.
  5. I'll get on it right away.. EDIT: 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 :)
  6. 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...
  7. 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 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. https://docs.microsoft.com/en-us/dotnet/api/system.web.httpresponse.end?redirectedfrom=MSDN&view=netframework-4.7.2#System_Web_HttpResponse_End 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() The "thread aborted" errors have shown up before on these forums:
  8. 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.
  9. @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!
  10. 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).
  11. 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
  12. Ooofff, it's been downloading for six hours now, sitting at 113/180MB. That's throughput from fifteen years ago
  13. 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.
  14. Mmm, I'll take a look at this... Keep you posted.
  15. 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
  16. 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
  17. 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 :)
  18. 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).
  19. 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.
  20. 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).
  21. 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.
  22. 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.
  23. 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! :)
  24. 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...