Buckit

Backing up and restoring to a new host always seems the safest decision to me. But then again, I'm no DBA

You know? I wouldn't mind receiving similar information, because our environment is also under pretty close scrutiny...

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.

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.

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

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

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:

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.

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

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

Ace

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

Ooofff, it's been downloading for six hours now, sitting at 113/180MB. That's throughput from fifteen years ago

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.

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