support

Hello HeDish, Can you confirm if you believe you are seeing the same issue because your web server time is different to your database server time? If so, can you let us know what build number you are using, and there should have been a fix for this in the release below? Regards Click Studios

Hi Fabian, Below will be the change - top one is V8, and bottom one is V9. So what you are saying with button names is incorrect. We receive an enourmous amount of support calls where customers to not realise the 'Ignore' button will add the URL to the 'Ignored URL' list. So we need to change this, because it does not seem obvious to customers. Do you have any other suggestions - keeping in mind we can only use single words, because of dialog realestate?

For anyone else reading this forum post, we figured out what the issue was. On the old web server, the customer had the URL Rewrite module installed for IIS, and had a rule configured in their web.config file. On the new web server this module was not installed in IIS, which was causing the issue. Regards Click Studios

Hello kvnpoa, I think there may be a technical issue with your browser extensions communicating with the API in Passwordstate, as you should not be logged out of the extension like this. Have you enabled any options on the screen Administration -> Browser Extensions Settings, to log yourself out of the extension? Or do you use any Load Balancers or Reverse Proxies, which may be inteferring with this? Regards Click Studios

FYI Guys - in version 9 we are changing the wording of wording of the buttons to Never and Later, so it is more obvious as to what you are doing. If a site is in the Ignored URL list, the extension icon will also turn blue, to make it more visible that it's an ignored URL. Regards Click Studios

Hello Ukasz, This error indicates you've made a mistake in the web.config file, and possibly one of the tags is not complete properly. Can you compare the web.config file to your original one, to see where the issue is? If you cannot figure it out, please contact us via the following page https://www.clickstudios.com.au/support.aspx and provide a copy of your file - we should be able to spot the issue for you. Regards Click Studios

Hi Josep, Unfortunately this is a bug in the latest release (Build 8989). The only working around before we provide a fix, is to first authenticate to Passwordstate, and then open your permalink. Sorry for the inconvenience, and we will email you once the next release is available. Regards Click Studios

Hi Fabian, Can we just check with you - with your Laptop, do you have Passwordstate installed on there, or are you just accessing Passwordstate from there? 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

Hi Jason, You should be able to use the report type below for this. Regards Click Studios

Hi Fabian, I expect that is just a feature if IIS that is giving you that, and not specifically our software. We'd need to try and setup the same scenario to see if there's anything we're able to do about that. Regards Click Studios

Hi Stefan, By default you cannot nest Password Lists beneath other Password Lists - you can only nest Password Lists beneath Folders. There is an option to allow this which can be enabled, but that option is being deprecated in version 9, as it causes confusion like you are seeing. So if you are not using Folders, then you must apply permissions to every single Password List you see in the Passwords Navigation Tree. I hope this clarifies. **Edit** there is a bulk permissions feature to quickly add permissions to multiple lists at once, found under Admin

Hello Rathinger, Upon further investigation with Steve a while back, this feature by Microsoft for signing scripts with certificates is only relevant if you are executing the script off of the file system - we do not do this, instead we read from the database and execute in memory. So we tested this against a machine that had “set-executionpolicy allsigned” set, with Invoke-Command, and it executed fine without signing the script. If you want to replicate this behaviour yourself manually, you can try this: Run “set-executionpolicy allsigned” on your machine

Hi Rankinc, Thanks for your forum post about this as we were unaware the opacity looked like this. We've noticed it's the same in Edge too, so we've logged a call with the developer of this Gateway, and will report back here when we have more information. In case you weren't aware, we've purchased the gateway from another company and integrated it with our software. They are always very good at providing advice or making changes for us if needed. Regards, Support.

Hi Rathinger, If the icon turns red for any reason, the user will need to authenticate back to Passwordstate to configure the extension again. If they have MFA enabled on their Passwordstate login, then this will require them to use that MFA in order to configure the extension. Regards, Support

Hi Rathinger, You'll need to set your base URL to use HTTPS, and then it should start working. You currently have it set to http. For the second question, can you turn off the option to sync the email address with AD, under Administration -> System Settings -> Active Directory: Regards, Support

Hey Fabian, In addition to our inactivity timeout we have, IIS also has a timeout for inactive sessions, which is why your session is ending when your computer is turned off. Unfortunately we cannot end the session in Azure if your laptop is turned off, as our software needs to redirect to that URL in order to end the Azure session. I hope this calrifies. Regards Click Studios

Hi Stefan We have a couple of different permission models in our software. The standard model is where you set permissions on the Password Lists, and those permissions will be sent up to any Folder. The second model is called the Propagating permissions model, where you set permissions on the top level folder, and those permissions filter down to all nested Folders and Password Lists. Can you take a look at this video which explains this in more detail, and hopefully this helps? https://www.youtube.com/watch?v=QBJE_xD185U I think you'll need

Hi Rathinger, Unfortunately I don't think those two errors are related. The browser extensions use the Passwordstate URL that you type into the Browser to authenticate, and don't reference the Base URL at all. Are you possibly blocking any cookies at all in your browser? Do you use a Load Balancer or a Proxy in front of your Passwordstate website at all? Regards, Support

Hi Emad, Yes you you have changed your authentication from one of the One Time Passwords options, to SAML, then SAML will be used to authenticate. I hope I've understood your question properly, but please let me know if I haven't. If you need to, please let me know where in Passwordstate you set SAML, ie in system settings only or maybe in user preferences, or User account policy etc. Regards, Support

Hello Rathinger, You can use our One-Time Password authentication option with Microsoft Authenticator - we use it ourselves Regards Click Studios

Okay thanks - please also send your modified import script as well. Thanks very much.

Hello Rathinger, No, that is not the default behaviour - you should stayed logged in, after restarting your computer of browser. Can you see if someone has changed the default settings on the screen below? If they haven't, then you may be having issues with your API in Passwordstate, and we will need to ask some more questions to try and figure out this cause. Regards Click Studios

Hi Paul, There should be nothing specific needed for Passwordstate for this OS upgrade, as long as your Server 2012R2 install has the following - which it should if you're using version 8 of our software - Microsoft .NET framework 4.5 or above, PowerShell 4.0 or above, Microsoft SQL Server 2012 Native Client. I'd also install .NET Framework 4.7.2 or higher, as version 9 will require this when released - eatly next year. Regards Click Studios