Leaderboard

Not sure what Microsoft did to cause this in the Dec security update as well but the missing asp.net session cookie may be related to the upcoming changes to samesite cookie https://support.microsoft.com/en-au/help/4522904/potential-disruption-to-customer-websites-in-latest-chrome https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/

Thanks for the quick reply. I will take a closer look at it and test it and get back to you.

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

Oddly enough it is working now - both the zip and bak files are present. Over the weekend the scheduled backups ran correctly and a test backup just now resulted in both files being created in the backup folder. I'll keep an eye on it to ensure both files are being consistently created. Thanks for your assistance!

Hi, do you have plans for creating an app for passwordstate which has more features than the mobile website? It would be great if a real app would exist with the possibility to create new passwords and edit them. Another awesome feature would be the offline availability of passwords. Kind regards Achim

Hi Support, Thank you:)

if a user is offline... say on a plane and has a need for a password to access something on their pc... an app would be the correct way to go... Web is only as good as your internet access.. if the app just downloaded and ecnrypted the pwd that user has access to it would reduce the risk.

Hello Everybody, i recently upgraded to the latest PState build and want to test the option where a single Password record can be linked to multiple Web Site URLs. I changed the password template by adding multiple generic URL fields, added the URLs in the respective fields within the AD User credential, saved the changes and when I click on the generic URL fields, there is no match happening. Is there some documentation or examples on how this works? Thanks and Cheers!

Hello, With this new feature, you do not use Generic Fields for this, instead you use the menu you see below in my screenshot. We hope this helps. Regards Click Studios

Thanks, and I can see the issue now - I just tested this also: You have your Invoke-RestMethod inside the json object - although you probably have moved this out by now And the GenericField1 and Description fields do not have a double quote before the single quote for your PowerShell variables i.e. should be "GenericField1":"'+$ServerName+'", instead of "GenericField1":'+$ServerName+'", I know it's hard to see in this forum, but cut and paste the text above and you will see what I mean. Regards Click Studios