Jump to content

Sarge

Members
  • Content Count

    165
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Sarge

  1. Thanks, what build is that available on? We're on 8650 and that report doesn't appear to be available via the API doco?
  2. Hi, Is there a method to pull a list of Managed hosts (IE: Those that have a password entry managed) from the API? The current documentation only seems to show basic host information.
  3. Hi There, We have multiple authentication domains attached to Passwordstate, some users continuously forget which domain to use for authentication, thus raising constant support issues for PEBKAC. Is it possible to use a browser cookie (or some other mechanism) to remember the default domain the user chooses after a successful login?
  4. Agreed. Notes being encrypted makes searching more difficult.
  5. Ah beautiful, didn't know that existed Thanks!
  6. Hi Guys, Whats the process for upgrading Passwordstate, when there are 2 * Application Servers, 2 * Self Destruct Servers, 2 * Reset portals & 1 * Gateway server? What needs to be upgraded first? 2 * Database Servers One per datacenter, Active/Cold with automatic failover. 2 * Application Servers One per datacenter, presented through load balancers to distribute traffic evenly and provide Active/Active HA services. 2 * Self Destruct Servers One per datacenter, presented through load balancers, all traffic routed to node 1, only rou
  7. No, the self-destruct message data is stored in a SQLLite database on the Self-Destruct web server, Passwordstate web server pushes data to it. If you round robin to two nodes (or more), one of them will get the data (say, self-destruct server1) , while the one the user hits to access the data (self-destruct server2) won't have it. All self-destruct data needs to go to a single node, hence why an Active/Cold setup works.
  8. Sort of, if you have the load balancers capable of doing it. Self Destruct uses its own SQL-Lite database where it stores the shared messages/credentials pushed to it by the main Passwordstate website. We have our Self Destruct web sites installed on the same web nodes as Passwordstate, bound to a seperate IP address. Our load balancers then direct all traffic for the self destruct HA URL to node 1 unless that node is offline. This way the self destruct messages are always available until the node is offline. It's HA in an Active/Cold configuration. In a disaster we still maintain
  9. This request seems akin to a "CREATOR OWNER" equivalent setting, where the user creating the list can control it - which can already be achieved with the following administrative setting "When a new Shared Password List is created, apply the following permission to the user who created the list:"
  10. Access can be gained via Administration > Password Folders.
  11. Agreed. I think this goes right down to the password resets as well. Install WSL on Server 2016/2019 and use the native tools for running the scripts rather than modules (IE: Posh-SSH etc)
  12. Same for the Google Auth 2FA. The Microsoft Authenticator app supports push notifications, just needs to be implemented on Passwordstate end.
  13. Check that this is actually occurring. For the "Passwordstate" and "Passwordstate-Gateway" service. Majority of the time I do an IPU the service for Passwordstate doesn't actually stop, so I manually stop it and carry on with the upgrade - I've not performed an upgrade since having the gateway in place, so can't confirm if it occurs with the Passwordstate-Gateway service as well.
  14. That would depend on how Passwordstate has been configured in your environment. If all password list permissions are linked to a password list template then it would be as simple as adjusting the permissions on the password list template to include your user group (and/or user account). You can also navigate to Administration > Password Lists. From here you can use the drop down menu next to each password list to view, and assign permissions (Assuming permissions aren't linked to a password list template). Whoever configured the application may also have granted t
  15. Ideally yes. It should be an option at setup - If you plan to run in HA, would you rather status 200 and dynamic pages, or 503 and static pages? If the user chooses 503 and static pages, then your setup installer would configure the attached. If the user chooses 200 and dynamic pages, then leave it as it currently is. How this could be retrofitted to existing installs I'm not sure.
  16. Yes, but some load balances can't check for string matches on the page - only status codes. You should still be able to do that through IIS. https://docs.microsoft.com/en-us/iis/configuration/system.webserver/httperrors/ Or networks team has accidentally misconfigured something, trust relationship of the web node to the domain controllers has been isolated, or someone did something on one of the nodes they shouldn't have. This issue would extend to maintenance mode as well - enter a web node into maintenance mode, it still returns status 200 - thus load ba
  17. Azure aside, its an issue with the application in HA configuration. If one of the web nodes can't get a connection to the database for whatever reason then the health checks continue to work as the application still returns a HTTP status 200 - even though it can't reach the database. If Passwordstate deems it can't connect to the database it should be returning a status code 503 instead of 200, that way when the load balances perform their health checks they'll get hit with a 503 status code and redirect traffic to the web node that is returning status 200. As it stands, users hit th
  18. While our Browser Based Gateway is working, when our users do are yet to trust the SSL Cert and use the "Test SSL Certificate" link, they receive a page with nothing other than "Not Found" rather than the expected ssltest.html page.
  19. This is an excellent point and I hadn't considered it for our own HA implementation. We use F5s across two DCs rather than having Passwordstate in Azure, but we'd have the same issue. A 503 should be thrown, with a custom error page detailing the exact nature of the failure. IE: "Application is up, database is down". Suggest this be moved to feature requests for implementation.
  20. True, but I can't integrate that with Slack lol EDIT-- Scratch that, yes i can
  21. Definitely, but I still think it should be per-password list instead rather than just an export of all passwords the user can access. Mitigates the security risk slightly - the user would have to export all lists they had access to themselves - either via API or manually. I'd also like to see the password list that is exported marked as "offline" in some manner that can prevent other users from updating passwords until the list is marked as "online" again (by and security admin or the original user).
  22. Hi, It'd be wonderfully useful to have an RSS Feed provided we can subscribe too, to alert us about new builds. It'd allowed integration into Slack, email clients and other colab tools and prevent checking every couple of days for new builds.
×
×
  • Create New...