support

Thanks for letting us know Mike.

Hi Mike, We've been doing some more testing today, with versions of 5.12.35 and 5.10.27, and we cannot seem to reproduce this anymore - which is very odd. Below is my screenshots of the password record we're using, and could you test again for us?

Hi Tobbe, Would you be able to contact us via the following page and provide a sample XML file we can test with - https://www.clickstudios.com.au/support.aspx? And can you confirm you are following these instructions for the import - https://www.clickstudios.com.au/blog/import-passwords-keepass-passwordstate/? Thanks very much. Regards Click Studios

If you need to import all of your data from KeePass into Passwordstate, this is the preferred process due to the below Powershell script keeping the correct format of your KeePass database. We'd like to thank one of our customers Fabian Näf from Switzerland for writing this script for us. He did a great job and it's helped out many of our customers. This import process will create a Folder with the same name as the XML file you export from KeePass, and it will then replicate the KeePass structure beneath this. For customers not familiar with Passwordstate, the equivalent of a "Group" in KeePass is a "Password List" in Passwordstate. We also have the concept of "Folders" which allow you to logically group Password Lists together. If you follow the process below, it should create a Folder with the same name as the XML file you export from KeePass, and it will then replicate the KeePass group structure beneath this. Process Start: In Passwordstate, identify and note down your System Wide API key from Administration-> System Settings -> API and you will find it under “Anonymous API Settings & Key”. Ensure you save this page after you generate the new key. Create a Password List Template under the Passwords Menu -> Password List Templates. On this template please set the following options and then save the template: Disable the option to prevent the saving of password records if they are found to be a “Bad Password” (screenshot 1 below) Uncheck the option so the Password field is not required, and enable the URL field (screenshot 2 below) Identify and note down the TemplateID by toggling the column visibility (screenshot 3 below) In KeePass, open your database and export the contents to a XML file. This can be executed from File -> Export -> KeePass XML (2.x) Download the script from: https://www.clickstudios.com.au/downloads/import-keepass-xml.zip Extract this zip file and open with Powershell ISE or the straight Powershell shell, if you prefer You will be prompted to answer 5 pieces of information: The username of an existing Passwordstate user you wish to give Admin rights to all Passwords imported during this process. Generally you would just enter your own Passwordstate UserID here as you can modify permissions later and and example format for this is halox\lsand Your Passwordstate URL Your System Wide API key The FolderID you wish to create your KeePass structure under. Enter '0' to create this in the root of Passwords Home, otherwise find the Folder ID of any Folder you like and use this when running the script Your PasswordList Template ID It will ask you to browse to your Exported XML file That’s it, the script will now run through and automatically read all of the information out of the XML file, and import it into Passwordstate. From here, there are a few other things you might want to consider doing after the script has run successfully: You may want to rearrange your folder structure. Ie possibly you might want to create some new folders for each of your teams, and then drag and drop existing Password Lists/Folders inside of them Once you are happy with your Folder structure, you should start applying permissions to either Password Lists or Folders using the following video as a guide: https://www.youtube.com/watch?v=QBJE_xD185U Best practices are to use Security Groups to apply permissions, instead of individual users, if possible Screenshot 1: Screenshot 2: Screenshot 3: Regards, Support

Hi Tobbe, Unfortunately we do not have Unicode support in Passwordstate at this stage - it's something we'd like to work on, but it's a large body of work to achieve. Regards Click Studios

Thanks for letting us know

Hi Jan, User have Admin rights to their Private Password Lists, so they can do this from the List Administrator's Actions dropdown list just beneath the Passwords grid. Regards Click Studios

Hi SeanIT, Possibly our Permalinks could help with this - you can have permalinks for password records, Password Lists, Password Folders, Host Folders and Host records. Below is a screenshot of where you can find the Permalink for a password record. Regards Click Studios

Great news, thanks for letting us know.

Hi Everyone, We've been made aware that two recent Windows Updates (KB4530689 on Windows Server 2016 and KB4533013 on Windows Server 2019), have caused an infinite authentication loop with SAML authentication - with any SAML provider. **EDIT we also think KB4533011 is the patch on Server 2012R2, but have not tested this at this point in time**) We believe we've identified the change in behavior these Windows Updates have caused, and are currently working on a fix. In the interim, the two possible workarounds are: Uninstall these Windows Update and reboot your web server Login with your Emergency Access login account, by appending /emergency to your URL, and choose another authentication option. If you cannot remember your emergency access password, please follow this article and log a support call with us https://www.clickstudios.com.au/community/index.php?/topic/1887-recover-emergency-access-password/ We have now released Build 8844 which resolves this issue. Please use one of the following suggested upgrade methods outlined in the following document - https://www.clickstudios.com.au/downloads/version8/Upgrade_Instructions.pdf Regards Click Studios

Hey Sarge, I think 8760: regards, Support

Below is a guide from Click Studios on how to Move Passwordstate to Azure. Please refer to Official Microsoft documentation if this guide isn't comprehensive enough. If you intend to move to the cloud, please ensure you keep your current on premise version running, and only shut that down once you have confirmed that you can successfully access your new instance in Azure. The first thing you’ll need to do is determine which kind of database you’ll be using in Azure. You can either install SQL on an Azure virtual Windows Server (just as you would on an On-Premise server), and move your database to it following this document: https://www.clickstudios.com.au/documentation/move-new-database-server.aspx. If you prefer to use an Azure SQL Database, the latest build of SQL Server Management Studio Tools (SMSS) can help with this migration from your On-Prem database to the Azure SQL database. First you should create an empty Azure SQL database and then in SMSS you can use this option to push data to this empty database: After migrating your data up to the SQL Azure database, you will need to run these SQL commands when connected to your Azure SQL database, using SMSS. This will create the "Passwordstate_User" account in the database and assign it the appropriate permissions. Azure does not allow for the USE statement, so we need to right click Master Database and select New Query. Execute the following script: CREATE LOGIN passwordstate_user WITH password='Welcome01' GO CREATE USER passwordstate_user FOR LOGIN passwordstate_user WITH DEFAULT_SCHEMA=[dbo] GO Next right click your Passwordstate database, select New Query and run this script: CREATE USER passwordstate_user FOR LOGIN passwordstate_user WITH DEFAULT_SCHEMA=[dbo] GO EXEC sp_addrolemember 'db_owner', 'passwordstate_user'; GO Once you database is moved, you can then use this document to move your Passwordstate install to your Azure Windows server: https://www.clickstudios.com.au/documentation/move-new-web-server.aspx Please note you’ll need to have an external DNS entry which directs all internet traffic to your Azure web server, and you’ll also need to open a port on your Azure web server firewall to all access for all users. The port that needs to be open is the port you set in your IIS Bindings, but generally 443 is the best port to use. We hope this helps, Support.

Hey Rene, Thanks for your post and we think this might be able to be prevented by using our propagating permissions model. Here is a video which shows a bit more about this: https://www.youtube.com/watch?v=QBJE_xD185U Here's an email that we send to customers occasionally, which may help, happy to work with you on this to make sure you can get something working for your business: Setting up the structure of the navigation tree is difficult to advise for, as every business is different, but below I've given an example of how you could build yours assuming you have different departments, like “IT Department” or “HR Department”. The top level Folder is set to Manual Permissions (blue padlock), and you would give everyone in the IT Department view access to it. Then each folder nested beneath it is for each team in the department, and these permissions are set to propagate down (green arrow on the folder) and only that team should have access to it. This just means the Linux team will only see "IT Department -> Linux Team", and the Service Desk will only see "IT Department -> Service Desk" etc. You could use this example below and possibly duplicate it for each department in your business, HR, Finance, Marketing etc. Permissions: Always use Security Groups if possible. In the above example for the IT Department structure, you could get away with having 4 Security Groups: · IT Department – Add all users to this from the department and give this group View access to the top level IT Department folder · Linux Team – Apply this group to only the Linux Folder · Service Desk – Apply this group to only the Service Desk Folder · Windows Team – Apply this group to only the Windows Folder Possibly you could have 2 Security Groups per Team, which gives different permissions: · Linux Team Read Only · Linux Team Modify · Service Desk Read Only · Service Desk Modify · Windows Team Read Only · Windows Team Modify Setting up permissions like this means all you have to do is add a new user to the relevant AD Security Group. This will sync to Passwordstate automatically and give users appropriate permissions easily. Also, Adding a Private Password List, or a Shared Password List inside a folder that is propagating permissions down from the top level will not change the permissions. Another tip to help, consider setting this System Setting option under Administration -> System Settings -> Password List Options to allow user with Modify rights the ability to Add Password Lists: You could also consider locking down the ability to create folders completely, so to keep your folder structure standard. This can be done under Administration -> Feature Access-> Menu Access. I hope that's enough to get you started, but please let me know if you have any questions at all about any of this? Regards, Support

Hi Sarge, You could possibly run report #36 which will return all passwords that are set up for resets, and it should give you the host it is active on. Reporting documentation is at the bottom of the API documentation you are looking at. I hope this helps? Regards, Support

Do you see it saying "Backing Up Database" when performing a manual backup? Could you possibly follow this forum post to provide some informaiton about your Passwordstate web server, and send the resulting output to suppotr@clickstudios.com.au? https://www.clickstudios.com.au/community/index.php?/topic/2518-passwordstate-support-information-script/ Regards, Support

Hi OB999, That's interesting, do you get any kind of errors when clicking the Test Permissions button on the Backups and Settings page? You may need to grant the account you have set for your backups access to your SQL Server Services, as per this video: https://www.youtube.com/watch?v=4iCvCYLwSL4 Does this help at all? Regards, Support

Hi Jan, If you are using our Browser extensions to autofill web page logins, then this should do this for you automatically. Unfortunately we do not have auto-filling of physically installed applications in our software. Regards, Support

Hi Sus, When installing it on a separate site, it will completely disregard that built in Application, so it's safe to leave it as is. Regards, Support

We are exploring this option in Passwordstate 9. We can't promise anything yet, but just wanted to let you know we are listening to you and we'll do our best to make this happen. Having said that, our initial designs are the App will need to pull information from your Passwordstate API, so the end users will still need to enter a URL upon initial launch of the App. We don't see a way around this unfortunately. We are hoping to store all data offline in the App/local encrypted database too. Regards, Support

Hello Pongsatorn, What we found with this is that all sessions on IIS no longer existing when returning from the SAML provider, and they previously did - so we needed to query the database a second time and set the session variables. So we're not exactly sure what Microsoft did to cause this, but it did kill your session in IIS - possibly killing/clearing the ASP.NET session cookies as well. I hope this helps. Regards Click Studios

Hi Mike, I was able to replicate this. I will need to submit this to our browser extension developers to take a look at, as I don't believe it should be updating the field IDs in this manner. I'll get back to you as soon as I have more information on this. Regards, Support.

Excellent PaulCA, glad that helped. One thing I forgot to mention is that by default, there is a setting on the Password List where you will be discovering these accounts into to say reset the Password after 90 days. You should change this to 30 days in your scenario: I hope this helps:) Regards, Support

Hi Sus, Unfortunately at this stage the Global Admin Address book needs to be updated manually in the UI, or if you want to automate this you could use our API. If you look under Help -> Web API Documentation, there is a section about adding/deleting and maintaining contacts using a script. Potentially you could write a script to read any new users that are added to active directory, and then use our API POST commands to add that user into the global address book. For the issue where the Self Destruct message cannot be found, having the High Availability node set up will definitely explain this. I'd recommend installing the Self Destruct Site separately to any of your two Passwordstate servers, by following this video: https://www.youtube.com/watch?v=BikrIJCy1lg This way, you will have only one Self Destruct site, and both all Self Destruct messages will be hosted here. I hope this helps! Regards, Support.

Hi Steve, That's correct - the feature is only available to users under the Passwords tab. If you would like a feature request for this, could you please post it under the Feature Requests section of our forum? Thanks very much. Regards Click Studios

HI Craig, Sorry, but we have not made any progress on this request, due to the lack of interest from other customers. We would love to work on each individual requests for all customers, but unfortunately it's just not practical for us. If this request does get some interest in the future, we will definitely look into it for you - we hope you understand. Regards Click Studios