support

Hi Guys, We plan on working on this for version 10, which we're currently working on. Regards Click Studios

Hello Valentijn, It's a statement, in case you weren't aware. Until we can work on a feature for this, possibly you could trying educating your Passwordstate users to action the emails they receive. Just a suggestion to stop the support tickets going to the "global passwordstate admins". Regards Click Studios

Fantastic feedback Goossens, we really appreciate you documenting this here. Hopefully this helps out other customers with the same issue. Regards, Support

Hello Valentijn, Just to clarify, the approvers to receive emails for these requests, and a notification in the Notification Centre every time they log into Passwordstate. Regards Click Studios

**Update on this 27th January 2023** A customer has reported that they had their server hosted in Azure, so by default this server came with the Microsoft Monitoring Agent (MMA). He then said that he also had the MMA deployed to his On-Premise network, but this was done via SCOM and he confirmed that the two agents were different builds. He then uninstalled the MMA version on Azure server, and reinstalled the On-Prem MMA version, and this solved the issue. (Thanks to Aaron for supplying this info) Regards, Click Studios.

A customer has requested an architectural change for how the Browser Based Gateway functions, so that it will work with Azure App Proxy. Instead of access the files in the html folder where the gateway is installed, the customer requests that the files are instead accessed from the local Passwordstate instance. We will work on a new System Setting option to give customers the option to choose. For gateways installed externally, and this feature request for using the local html folder, this causes issues with some browsers with the copy file function, which is why the design was changed. Click Studios

Purpose: If you are an MSP, typically you would like to have a folder and Password Lost structure that is exactly the same for all customers. This Forum post describes how you can achieve this using the API, which is much quicker that cloning a folder one at a time. This will also set the Advanced Permission model which means all Folders and Password Lists will have the same permissions set from the top level down, so you must be running Passwordstate 9 for this to work. Preparation: First, manually create a Folder, call it anything you like, and set the Advanced Permission Model. The create as many password lists as you like beneath this Folder. Take note of the Password List IDs for each List you have created: Step 1: Step 2: Take note of your System Wide API Key, generate one if needed. This can be achieved under Administration -> System Settings-> API tab. Step 3: Create a csv file with your customer names, Save this to disk. Ensure formatting is like this screenshot below: Step 4: It's always a good idea to back up your database just prior to doing any operation like this. This way, you can quickly restore your database if something doesn't work out as you expect. This forum post explains how to quickly backup, and restore your database if needed: https://forums.clickstudios.com.au/topic/2480-sql-script-to-quickly-backup-and-restore-passwordstate-database/ Running The Script: Copy the contents below and paste it into a Powershell ISE shell. Change the top 4 lines wheer it is bold to suit your Passwordstate environment, and run the script: $PasswordstateURL = "https://Passwordstate.demo.com" $SystemWideAPIKey = "6ab8dc9437f532eeb36d2f54c38a7948" $Customers = Import-csv -Path "c:\data\local scripts\customers.csv" $PasswordListIDs = @('7429','7430','7431') #No Need to Modify these $FolderAPIURL = "$PasswordstateURL/api/folders" $PasswordListAPIURL = "$PasswordstateURL/api/passwordlists" $Permissions = Get-Random $PasswordListIDs #Loop through all customers in CSV file and create Folder for each, then create all Password Lists nested beneath that Folder. foreach ($Customer in $Customers) { #Set the customer name to a variable $CustomerName = $Customer.customername #Create the Folder in the root of Passwords Home. Set to Advanced and copy permissions from a nested Password List $jsonString = ' { "FolderName":"' + $CustomerName + '", "CopyPermissionsFromPasswordListID":"' + $Permissions + '", “PropagatePermissions”:”true”, "NestUnderFolderID":"0", "APIKey":"' + $SystemWideAPIKey + '" } ' $result = Invoke-Restmethod -Method POST -Uri $FolderAPIURL -ContentType "application/json" -Body $jsonString $FolderID = $result.FolderID #Now loop through $PasswordListIDs array and create a password List for each. First, we search to obtain the Name of the List foreach ($ID in $PasswordListIDs) { $URL = "$PasswordListAPIURL/$ID" $Search = Invoke-Restmethod -Method GET -Uri $URL -Header @{ "APIKey" = $SystemWideAPIKey } $PasswordListName = $Search.PasswordList #Now we have the name, begin creating lists $jsonString = ' { "PasswordList":"' + $PasswordListName + '", "CopySettingsFromPasswordListID":"' + $ID + '", "NestUnderFolderID":"' + $FolderID + '", "APIKey":"' + $SystemWideAPIKey + '" } ' Write-Host $jsonString $result2 = Invoke-Restmethod -Method POST -Uri $PasswordListAPIURL -ContentType "application/json" -Body $jsonString } } Results: If the script runs without errors, you should now see a new folder for each customer, along with a mirror of all the Password Lists that you created: Regards, Support

Hi Matthew, We do have a feature for this, and you can find it on the screen Administration -> System Settings -> Password List Options tab. Look for the option "Modify permissions for Password Lists can". Regards Click Studios

Okay thanks Philipp. We'll look into it further to see what we can do.

Hi Philip, Can you please try upgrading to build 9665, as this should resolve it for you. Here is a link to our changelog page - https://www.clickstudios.com.au/passwordstate-changelog.aspx Regards Click Studios

Hello Everyone, Today we have released build 9665. For full details, please refer to our changelog here https://www.clickstudios.com.au/passwordstate-changelog.aspx Regards Click Studios

Issue: A frequent question we get is Passwordstate will not accept the QR code that Microsoft supply for their online portal access. The error being reported is the QR code being uploaded is an "invalid QR code". There is a trick to this that is documented below, which will allow you to save an alternative QR code from Microsoft, and this can be uploaded into Passwordstate, which you can then use to authenticate to Microsoft portals. Edit October 2023: Microsoft have chnaged some screens and the below instruction may not work for you. If you find this process will not upload a valid QR code into Passwordstate, please try following this new forum post instead with updated screenshots: https://forums.clickstudios.com.au/topic/15415-uploading-microsoft-qr-otp-codes-into-passwordstate-updated-october-2023/ Step 1: After applying 2FA to your account in the MS Portal, log into your MS Portal and you will be asked to set up 2FA for your login. The QR code on this screen is not a standard QR code and uploading this into Passwordstate will throw an error. Instead, click on this link: Step 2: On this next page you'll notice the QR code changes slightly, and this is the code you can save to disk: Step 3: Now in Passwordstate, upload the QR code and it will start giving you the relevant 6 digit code to authenticate with: Step 4: Don't forget to delete the QR code off your disk! Regards, Support.

Just wanted to say thanks to Jack for working with us on this issue. We found out that if your Username has a decimal place in it, then the third party remote session gateway that we've integrated into our software, will replace this decimal place with an underscore in the file name. This is now resolved in build 9661. Regards Click Studios

Hello Everyone, Today we have released build 9661. For full details, please refer to our changelog here https://www.clickstudios.com.au/passwordstate-changelog.aspx Regards Click Studios

Hi Chris, Thanks for your email. In a recent build of Passwordstate, a change was made to do a post back to your web server every time you click on the copy to clipboard button. Previously this was just client side meaning the browser extension copied the data directly out of the browser, rather than retrieving the information from the server. When this post back occurs, we also perform a permission check just like we do on any other page, so these changes may be causing this issue for you. These changes were made with security in mind, to help mitigate against the off chance someone could get access to one of your passwords if you left your computer unlocked and your clipboard hadn't cleared, specifically after your computer awoke from a sleep state. Please consider these suggestions to see if this will help troubleshoot this in your environment, if it still doesn't help, can you please log a support call with Click Studios? Here is a video of what the performance of the copy to clipboard on the build you are running: https://www.youtube.com/watch?v=oTzsrbcFdpQ. This is the expected performance you should see, and please note our webserver we recorded this video on is a standard Virtual machine, with two processors and 8 gig ram. Try reducing the number of rows in your Grid to 10 rows, on the Password List where you using the copy function on. See Screenshot #1 below for this If you have any extra fields enabled to be displayed on your page when clicking on a Password List, then try hiding these fields if they are not required. The less data that is displayed on the webpage the better. See Screenshot #2 for this As a test to rule out bandwidth issues between the browser and the web server, try creating a LocalHost binding in IIS on your Passwordstate webserver, and then remote directly into your server and try test the copy to clipboard function again using https://localhost. Does this speed things up? https://forums.clickstudios.com.au/topic/14938-using-local-host-binding-for-testing-purposes/ If you have any Antivirus software on your web server, try disabling this and test again to see if this helps. Possibly putting in an exclusion for your Passwordstate install folder and IIS process (w3wp.exe) may help. Please note this is just a temporary test to see if it is causing the issue Try opening developer tools in your browser, and under the network tab you will see how much data is being transferred when you try doing a copy to clipboard test, along with the total time. My results can be seen in the Screenshot #3 below. If your data transfer is similar in size to the example below, but is still taking multiple seconds to perform the copy, then perhaps there is something throttling traffic between your browser, and your webserver (100 - 300 milliseconds is the average speed for this.) Try rebooting your Passwordstate webserver and then try performing a copy function in another browser, possibly on another machine if needed. **Edit 25th January 2023** A customer has reported that an AV solution on their Desktop machine where they are accessing Passwordstate from was causing a 2 second delay whilst it interrogated the payload that needs to be sent to the Passwordstate server. We'd recommend temporarily disabling AV on your Desktop as a troubleshooting step to see if that speeds things up. **Edit 14th March 2023** Try disabling any Ad Blockers in the browser and test again If using Alt + Tab to quickly move to another application after copying a password, please give it more than half a second to perform this action. If you Alt-Tab before the round trip has finished, then the password will not be copied to the clipboard. Encourage users not to double click the Copy button. It just requires a single click, and double clicking it as if you were trying to open a file within a Windows folder will only double the payload. If you see the error DOMException: Document is not focused, this is caused by changing to another tab before the round trip for the copy function has finished. The call requires the same tab to be active whilst it’s completing the function, and I think this is just a security feature in the Java script library. If you have Passwordstate browser extensions installed, it's possible they are clearing the contents of the clipboard if the user has any other value other than 0 in personal preferences, which can be seen in Screenshot #4 If your users are double clicking the copy button, or clicking it multiple times in quick succession, this will cause the function to fail. Try using single clicks only You don't have to wait for the message at the bottom of the screen to appear to know that the data is in the clipboard. It is in the clipboard as soon as you see the icon in the top right hand corner, Screenshot #5 Screenshot #1 Screenshot #2 Screenshot #3 Screenshot #4 Screenshot #5 Regards, Support

Hi Razvan, I've just had a quick look on how to remove the double logon, and possibly this might help? Not sure as mentioned above, we don't have a switch to test on. Can you try running these commands on your switch, and does this get rid of the double logon? config t ip ssh password-auth Regards, Support

Hi Razvan, Understood and having a look back at your screenshot, I don't think we could developer a script to get around this. We cannot issue commands to the switch until a SSH session is established. I'll put in a request for us to purchase a switch and we'll try to do some testing against it. Is there nowhere in that OS where you can disable the double username requirement? Regards, Support.

Hi All, Just in case some of you are not aware, there is a recycle bin for password records, but not entire Password Lists. If required, you can also restore a backup to a test environment, if you find this is required months later, to a test environment - ensuring you do not overwrite any production data. We do wish to work on this feature, but it is a considerable amount of work to achieve i.e. do we go through the entire code stack to exclude Password Lists from being used (if deleted), or do we have a copy of certain tables and move data backwards and forwards as required. Regards Click Studios

Hi Razvan, Can you please let me know if the following information helps resetting passwords on this device? The Cisco Small Business Server OS is a cut down version of the standard Cisco iOS, and of this reason not all standard command work when issuing Password resets to them. We do have a work around for this though, and we’d encourage you to build your own Password Reset Script using our SSH Templates, as per Section 16 in this manual: https://www.clickstudios.com.au/downloads/version9/Passwordstate_Privileged_Account_Management_Manual.pdf When building this script, we have had another customer test these commands and can confirm these work: Configure Username [HostName] algorithm-type sha256 secret [NewPassword] [OldPassword] Exit Exit Exit An example of this is as follows: If you now assign this reset script to your Password Record, does it reset correctly? Regards, Support.

SendGrid is a popular email delivery system that can be used in Passwordstate, to send our email notifications and deliver reports etc. If you have an account with Send Grid and would like to use this system as your SMTP server in Passwordstate, below are the instructions for this: 1. Log into your Sendgrid account and generate your API (refer to Sendgrid documentation for this) 2. In Passwordstate, the settings for your server can be set under Administration -> System Settings -> Email, Proxy & Syslog Servers. See example screenshot below - Note the username should be "apikey" and the password is your actual API key from Sendgrid: You should now be able to send a test email and receive it in your inbox. Regards, Support

Hi Amy, Thanks for your request, but you should not need to calculate a new date. When you open a record, and the calender, it selects the data in the Expiry Date field. All you need to do is click through the months, as per the screenshot below, and click the new date.

**EDIT - Updated 25th January 2023** Troubleshooting steps to help speed this up can be found here: https://forums.clickstudios.com.au/topic/15217-delayed-copy-button-action-when-upgrading-to-9653/#comment-38254 In a recent build of Passwordstate, a change was made to do a post back to your web server every time you click on a the copy to clipboard button. Previously this was just client side meaning the browser extension copied the data directly out of the browser, rather than retrieving the information from the server. When this post back occurs, we also perform a permission check just like we do on any other page, so these changes may be causing this issue for you. These changes were made with security in mind, to help mitigate against the off chance someone could get access to one of your passwords if you left your computer unlocked and your clipboard hadn't cleared. This new functionality was introduced due to a security audit that we had on our software, which is something we regularly undertake due to the nature of our software. We had some customers experience slow copy to clipboard times after upgrading to a recent build, so we've optimized the copy function in build 9653 to reduce the payload being transferred from the web browser to the Passwordstate web server. We believe this is as much as we can optimize the copy function, without impacting the security of your data. We'd recommend upgrading to the latest build if you are running anything below version 9653. The video below demonstrates copying a password when the Password Grid is set to 10 records, and also 50 records, and on a standard virtual machine running 2 cores with 8 gig ram, the copy function is instant. The post back journey ends when you see the "Clear Clipboard" button in the top right hand corner of your screen. If your performance is any different to the video clip below, perhaps investigate the connection from your browser to your webserver, resources on webserver or rule out any load balancers or proxy servers to troubleshoot the performance. Regards, Support

Issue: You launch a Browser Based Launcher RDP or SSH session, and get a completely black screen with no indication or an error. Fix 1: Go to Administration -> System Settings -> Miscellaneous and check your Base URL. This needs to be the exact URL you use for Passwordstate. Check this base URL starts with HTTPS and not just HTTP. The above information is assuming you have the Browser Based Gateway installed on your Passwordstate web server. If it is installed on a separate server, then the gateway may have issues communicating back to your Passwordstate API. Please log a support ticket with Click Studios to start troubleshooting this scenario. Fix 2: We've recently had several customers report that Sophos AV software was causing the issue. The behaviour they would see is they could launch three or 4 remote sessions, then the 5th one would only show a black screen. All customers reported if they uninstalled Sophos from their workstations this fixed the issue, but a better solution is to put in an exclusion into the Sophos software for the Passwordstate website, or the IP Address that the Passwordstate URL resolves to: Fix 3: A customer has reports that doing Windows Updates, and rebooting the server fixed this issue. Possibly try rebooting your server in the first instance to see if that helps. Regards, Support.

Hello Everyone, Today we have released build 9653. Please note a security issue has been resolved in build 9653 - CVE-2022-3877. Please see our Security Advisories page for more information - https://www.clickstudios.com.au/security/advisories/ For full details, please refer to our changelog here https://www.clickstudios.com.au/passwordstate-changelog.aspx Regards Click Studios

Hi Bard, Please select multiple users and delete as per screenshot below: Regards, Support