support

Issue: One or more users are locked out of the system. Closing the browser and reopening , and browsing to Passwordstate does not not resolve the issue. Error message you get is as per screenshot below: Cause: In Passwordstate 9, and new Brute Force Attack feature was introduced, to mitigate against scripted attacks, especially when exposing Passwordstate on the internet. Once a computer has tried several unsuccessful attempts to access your site, they will be locked out permanently until a Passwordstate Security Administrator manually removes the blocked IP Address from the system Where to Do This? Under Administration -> Blocked IP Addresses: If you find you are locked out of the system, you should access Passwordstate via the Emergency Account to unblock the IP Address. Please see this forum post for more information on this: https://www.clickstudios.com.au/community/index.php?/topic/1887-recover-emergency-access-password/ More Information: If you use a Proxy Server, Load Balancer or Firewall in front of your Passwordstate website, and the IP Address of that device is captured as a Brute Force lockout, logging directly into your Passwordstate web server and deleting the IP Address using the method above will fix this. But for a more permanent solution you should set your Device details under the Administration -> System Settings -> Proxy & Syslog Servers -> X-Forwarded-For Support section. This way it will lock out the IP Address of the users device, not the Proxy server itself. Note: Any network devices such as a Load Balancer, Proxy or Firewall that are being reported as being locked out may need configuring X-Forwarded-For support. You can relax the Brute Force attack rules under System Settings, as per below screenshot: Regards, Support

Excellent - thanks for letting us know. Regards Click Studios

Hi Lennart, No sorry there has not been, as we've never seen the issue ourselves - we need to replicate an issue in order to fix it. And we believe it's some sort of IIS caching issue, and a reboot of the web server normally fixes it - so it's not a code thing we are able to provide a fix for. Are you still seeing this after a reboot? If so, can you please edit the file c:\inetpub\passwordstate\web.config file, and turn CustomErrors off. When you save the file and access the site again, does it report the error? Is your screen reporting this generalerror.aspx, or customerror.aspx? Thanks Click Studios

Hello KC_BREC, We did upload a new build to the Google store a couple of days ago - can you check if there is an update for this phone. In this build we increase the tolerance for the phone's camera to scan the QR Code, and if it still fails, you would then be giving the opportunity to try different camera resolutions for your phone - in case the auto-detect resolution does not work for some reason. Regards Click Studios

Hello Ondrej, Can you please try editing your host, and adding additional parameters, as per the screenshot below. Hopefully this will work for you.

Hi David, Upgrading to version 9 is a two step process - first you will be upgraded to build 8995, and then given the option to upgrade to the latest build of version 9 if you want. So just follow the normal upgrade process you've followed in the past, but leave it at 8995 when you are done. PS: there are no changes in 8995 which you can use - just changes in preparate for V9 upgrade. Regards Click Studios

Hello Emil, For this discovery job, can you please check that the OU's you have specified are still valid? Regards Click Studios

Hello Maicon, Unfrotunately we do not have any customization for this. If you need this, we could log a feature request for you? Regards Click Studios

Thanks, and yes that makes sense. Regards Click Studios

Hello Phaust, For your comment of "as the machine they will be accessing Passwordstate API from", can you tell us why this is - are they using Windows Machines or Linux? Thanks Click Studios

Hi Dave, Have you looked into our browse extenstions for HTTPS? Regards Click Studios

Hello, If you navigate to the screen Administration -> Password Lists, and click on the appropriate Password List here, you can check them in as a Security Administrator. Regards Click Studios

Hi Willy, Yes, we do have our machines joined to the domain, but it should still work without it. Regards Click Studios

Hi Willy, Sorry you're having some issues, but we have not had any other reports of this, nor have we experienced it ourselves. Maybe try some trace routes from your web server to domain controller, to see if you can spot why it is taking a long time to authenticate. Maybe the tool like Wireshark will help as well, but it does take a little learning to understand the traffic monitoring aspects. Regards Click Studios

Hi Guys, Just letting you know it's unlikely we will be working on this feature - we do not really want to be building change management processes into our software, when established processes should exist for all systems. Regards Click Studios

Hi Kyle, Have you tried putting S1W or S2W into the "Host Name Filter" field? There is also the 'Hosts to be Queried' tab where you can test what Hosts the discovery job will execute against. Does this help at all? Regards Click Studios

Hi Kyle, Our Tag field is the only real option to filter based on the Host Discovery Job. Are you specifying multiple OU's with your Host Discovery Job, and that's why you need Wildcard matching on the Account Discovery Jobs? If you are using multiple OU's, is there any part of the OU's that would be unique to each of your jobs? Regards Click Studios

Hello Juan, I also forgot to mention some improvements coming in V9 for discovery jobs and resets: Multi-threading for the discovery jobs - making the process a lot quicker And when accounts are discovered and added into a Password List, you can randomize the schedule for resets to be between two time-slots - so that you won't have all 7000 accounts trying to be reset at the same time We expect a beta of V9 available later this month, and official release during January next year. Regards Click Studios

Hello Juan, Thanks for your post, and please see answers below: What happens if a laptop is off the network for an extended period of time? (e.g. after the password reset time). This is very common in our environment, especially now with the amount of people that we have WFH. If a device is not contactable, the reset engine will reschedule the reset for the same time the following day. If the device is no longer trusted on the domain, due to being offline for a long period, then you will most likely get an error when trying to perform the next reset Does the reset script only run at the specified time? How often does it retry to reset a pwd? As per the previous question, we have a lot of users coming and going. Yes, it only runs at the specific time, and it will keep trying daily at the same time In the screenshot above it looks like the password reset is being set for 1 host. Is there an easy way to do this for all of our hosts? (over 7000). We recommend using our Discovery Jobs for this - found under the Tools Menu. Under the Hosts Menu, you can also create a Hist Discovery Job, which monitors AD and can automatically import your host records. Used in conjuction with each other, you do not need to manually create any records. If possible, it might pay to see if you can split the discovery job results between multiple Password Lists, and 7000 records in one List might slow down the UI a bit - it won't be too bad though if you have paging set for 10 records on the grid Are there any drawbacks of using this instead of LAPS? No that we are aware of. By default LAPS stores the passwords in unencrypted format in AD, so our solution is more secure as well. Regards Click Studios

Hi Steve, Sorry we missed this post. When you trigger a password reset via our API, it does use our own reset scripts to perform the reset. It sounds like what you want to do though is give a user access to a password for a specific amount of time, and this can be achieved through the User Interface, which would be much easier. This could either be achieved through requesting access to a password, and the approver can set how long the access lasts for. Or you could use the Check IN? Check Out feature, which will give the user exclusive access to the password for a set amount of time, and can automatically change the password when they are finished with it. Regards, Support

Hello stdgde, In speaking with another collegue here, I think I must have misunderstood you when you said 'on the Client' - I thought you meant from your desktop itself, and not in the remote session itself. By default, the desktop is disabled with RDP sessions, to improve performance and file sizes of recorded sessions. If you need a feature for this, could you log this as a feature request in our forums - or I can move this post for you if you like? Regards Click Studio

Hello stdgde, The browser based launcher runs sessions in your web browser, and should not be able to interact with your client operating system or applications at all. Is anyone else in the community seeing the same issue? Regards Click Studios

Hello Marcin, Yes, you can import via CSV in two ways: Directly to a single Password List - under the List Administrator's Actions dropdown list beneath the grid, you will see the Import menu Of into multiple Password Lists at once - although you need to know all the PasswordListID values. You can do this from the screen Administration -> Password Lists -> Perform Bulk Processing We hope this helps. Regards Click Studios

We’ve had a couple of reports of the error screen below after upgrading Passwordstate, and we believe this is a transient IIS caching issue. To fix this, simply restart each of the Passwordstate Application Pools in IIS, or reboot your server, and this will fix it. We will continue to investigate if we can reproduce this consistently, so we can work on a fix. Regards Click Studios