support

Hi Rob, I do not believe this will work if all you're doing is closing the tab - sorry, but this is outside of our control unfortunately. Regards Click Studios

Hi Rob, I think the issue is your Step 5 above. I asked what happens if you close your browser, not close your tab. The only way to kill your sessions in IIS is to log out of Passwordstate, or close your browser altogether. Just closing the tab will not do this. Regards Click Studios

Hello, Thanks for your request. We did try getting this to work some time ago, but were not successful, but we will give it another go and see what we can do. Regards Click Studios

Hello, Sorry you're having some issues. If you have uploaded a logo of the exact same name, then yes this would be the issue. I've attached the default logo for you, and you will need to save this into the folder C:\inetpub\Passwordstate\images\logos Regards Click Studios

Hello Constantin, As we don't have the sort of feature you need, we recommend not configuring a Password Lists with Authentication options which users cannot use. In the unlikely event somebody did this, Security Administrators can always turn it off/change it via the screen Administration -> Password Lists. For authentication into Passwordstate, all we can suggest for now is multiple User Account Policies - this will enforce it for you. If possible, and we certainly understand if it's not, but consolidating the number of 2FA methods you use may help as well - we find most of our customers try to do this as it does simplify things, and reduces your support costs. Regards Click Studios

Hi, Thanks for the feedback, but we think this approach would be problematic. We auto-populate a lot of the Authentication fields on users Preferences screen, even if they are not using those Authentication options i.e. SecurID Username is populated for all accounts. Do you know users can chose their own Authentication Method on their Preferences screen? I think this might be a better option for you, as you then would not need to worry about all those User Account Policies. Regards Click Studios

Hi Constantin, Thanks for the clarification, and no that is not possible sorry. I'm not sure if we would consider this as a feature request sorry, unless we had many customers interested in it - an no-one has expressed an interest before. Technically we're not sure how this would event work - would we just randomly present a 2FA option to the user - what is they don't use SecurID, as an example. Regards Click Studios

Hi Constantin, With the user of User Account Policies, found under the Administration menu, you can have different authentication options for different sets of users. Can you investigate this, and let us know if this is what you need. Regards Click Studios

Hi Chris, Thanks for your help, and patience, in trying to troubleshoot this, and we can confirm we see the same thing if the Password List is for a Remote Site Location. So we'll look into getting this fixed for the next release, and test all other methods as well to make sure there are no other issues. Thanks again. Regards Click Studios

Yes, that would work

Thanks Sarge. Per page CSS would require us to update all 492 pages in Passwordstate, so this is unlikely to happen sorry - unless we have a lot of customers who also need this level of customization for all pages in Passwordstate. Regards Click Studios

Actually, maybe for the login screens we could change the name of the css from BaseColor to LoginScreenBaseColor, and then you can have different css for these screens as well. Also, did you know you can now also use a background image on all logins screens - this would negate the custom css on these screens if you would prefer to use that. Regards Click Studios

I've just done some quick testing in the main site, and this should be possible with us adding one line of code into one of our classes. So if you were to include your own css file called /App_Themes/custom.css, then this would apply to all pages in the core product. You will need to include the '!important' rule on all your css attributes so they take precedence over ours, but it seems to work nicely. If we add this in though, it would be one css file for the whole site - so if you were to change the base color, it would change for all pages, just not the login screens. Trying to provide custom css for each individual page would be a considerable amount of work. The Self Destruct and Reset Portal would be the same concept with this custom.css file. Because you add this file yourself, no upgrades will touch this. Regards Click Studios

Thanks Sarge

Hi Sarge, Thanks for your request. Could you provide an example of the CSS code you are modifying here? When you refer to "Currently the base colour", are you referring to the Self Destruct or Password Reset Portal still, or the logins screens in Passwordstate? Thanks Click Studios

Hi Rob, If you close your Browser, and not just the tab, does that make any difference? Thanks Click Studios

Hi Chris, I've sent an email regarding this, and it does not have anything to do with a 3 digit PasswordListID - we need to keep investigating. Regards Click Studios

Hello, Could you please refer to our API Documentation under the help menu - there are more parameters required when creating Password Lists. e.g. where to place it in the Navigation Tree, what permissions to apply, what settings for the Password List, etc. Regards Click Studios

Hi Chris, We've emailed you a script we tested with which works - can you let us know how it goes for you? Regards Click Studios

Hello, You would need to modify this directly in the database then - you can set the Managed field to 1. We can't guarantee this will work flawlessly though, as it will not preselect any Reset or Validation scripts for you. Give it a try, and let us know if you run into any issues. Regards Click Studios

Hi Chris, I've had a quick look, and I am a bit confused about your script sorry - it's quite a bit to consume. A couple things I have noticed, and I don't know if this is the issue or not, or just my lack of understanding. You script has functions embedded inside other functions - normally we don't do this, but not sure if this is the cause When adding the password records, you reference $record.list, which I believe is meant to be the PasswordListID - it's best to name the variables properly, do avoid any confusion if your other team members need to use the script. If this variable is meant to be referencing the 'list' column in your sample spreadsheet, then this column is entirely blank In your sample csv file, you also have an account name called 'Misc.', but in your AccountTypes csv lookup file, it's called 'Misc. Account' I hope this helps a little. Regards Click Studios

Hi Chris, To help us fast track this, can you let us know at what line number in your script it's actually failing? Thanks very much. Regards Click Studios

Hi Chris, Sorry for the delay - we did have a quick look, but it is a very large script and will take some time to analyse. Maybe upload the entire script to the forum also, and someone from the community might be able to test it also. Regards Click Studios

Thanks Christian

and sorry, we forgot to post back here...