Jump to content

support

Administrators
  • Posts

    5,076
  • Joined

  • Last visited

  • Days Won

    317

Everything posted by support

  1. Thanks Mark - we're definitely going to be working on this, and are documenting the new features we want next week. It will take a while to achieve though, as all browser extensions need to be updated - unfortunately there's not a lot of standards between all the browsers. Regards Click Studios
  2. When browsing to your Passwordstate website, you may see a couple of different types of errors which are stopping you from accessing the website. This post will help you resolve these issues. First Issue: When first installing Passwordstate, by default the URL it chooses during the install will be the name of your web server, with a port number of 9119. These values can be changed but this post will assume you have left the default values during the install. If you enter the URL without appending the port you will see this message: The correct way to append the port is to enter it like this, and if you have the correct URL and Port your site should then load successfully: To check your URL and Port Number, open IIS on your web server, and go to Bindings. In the example below, the exact URL you should enter into your browser should be https://win2k16installs:9119 To make an easier URL to type in and remember, you can set the Port in IIS as 443, as this is the standard Port that HTTPS traffic communicates on. If you do not append a port to your URL, your web browser is smart enough to know that your site is configured with 443. If you change the port, you should restart the website in IIS and then try to access the site again. Here's some screenshots to show how this works: If you wanted to change the URL to something more friendly, like https://passwordstate, please see this forum post which will guide you through the process: https://www.clickstudios.com.au/community/index.php?/topic/1465-changing-the-passwordstate-url/ To conclude this post: For basic quick access to your Passwordstate website, you should set your bindings to be the DNS name of your web server, and if you have set a port for the site to anything else other than 443, then you should append that number to your URL in your browser. Hope this helps and if you still have issues, please contact Click Studios on support@clickstudios.com.au Regards, Support.
  3. Hi Guys, We are documenting the next round of features for the browser extensions, and we will include this. Darly B, I was posting this information as a work around until we can develop the features you're requesting. Regards Click Studios
  4. Hey Greg and Daryl B, We're looking into you feature request for you, but can you confirm if you have the following settings for us: You only specify the Base URL field on the password record - screenshot 1 below On the browser form fields tab, are the login field names specified? If using our extension to save the logins, then hopefully it detected them okay - second screenshot below And in the 3rd screenshot below, this setting will not attempt to form fill any fields in the fields on the 'Browser Form Fields' tab are empty These seems to work for us, and will not form fill fields once inside your web application, but the only exception to this would be if the fields names inside the application are named exactly the same as the login screen - I hope that makes sense? Regards Click Studios
  5. Hi Stuart, Thanks for your suggestion - we really appreciate it. We do have many feature requests that we're currently working our way through at the moment, but if we receive interest from the community on this request, then we will look at prioritising it for you. Regards Click Studios
  6. Thanks for your request Daryl. We'll let everyone know once we've found the time to work on this, and thanks for your patience till then. Regards Click Studios
  7. Thanks for your request Fabian - we appreciate it. Regards Click Studios
  8. Thanks very much Philipp for your suggestion - we will look into it in a future release, and report back here when complete. Regards Click Studios
  9. Thanks for the vote Greg. We'll consider this request when we next work on feature development for our extensions. Regards Click Studios
  10. Hi Frank, Thanks for your suggestion - we appreciate it. If there are duplicate accounts for a sight, the extension icon should turn yellow for you, and the you can click on it to select which account you want to use to login. Regards Click Studios
  11. Hi Alexey, No specific reason - I guess because we had a KB Article section in there, and the Security Admin manual maps to each of the menu in the Admin area. Maybe we should put in both, and probably under the Backups and Upgrades section in the Security Admins manual. Regards Click Studios
  12. Hi Guys, Under the Help Menu, in User Manual, we have various Disaster Recovery processes covered under the KB Article section - this might help as well. Regards Click Studios
  13. It's odd that the order of the installs can break things, but at at least it's a relatively easy fix
  14. Hi Geoff, Thanks for your request and we'll see if we can come up with something for this. The main design issue I think we'll have is that we don't want one popup window on top of another i.e. Add Host screen on top of Add Password screen. Possibly we could just add the Host if not found based on what you type into the textbox, but there may be certain fields that need changing for the Host i.e. Operating System. We'll have a think for what's possible here. Regards Click Studios
  15. Hello Achim, Thanks for your feature request and interest in our software. Unfortunately we do not have any language translation at this time. It is something we would like to work on, but it’s an incredible amount of work to change all pages in Passwordstate, in addition to the translation files themselves – and we rarely get requests for this. We do have many customers throughout Europe in different languages using our software, so we do hope you can still make use of our software without the language translation. Regards Click Studios
  16. Issue: We've had a few reports of customers who have not been able to sync AD Security Groups, or possibly not able to add users into the system from Active Directory. Symptoms: Some symptoms you may see is when adding in a AD Security Group, it will not enumerate the members. Or possibly you might be presented with a Error page in Passwordstate saying it cannot query Active Directory. Possible Cause: By default, Passwordstate only requires an account that has "Domain User" privileges in AD to be able to sync objects, however if you have hardened Active Directory to minimize the visibility of containers for certain users, you may need to elevate the permissions for your Privileged Account. How to Test: As a temporary test, add your Passwordstate Privileged Account to the "Domain Administrators" security group in Active Directory. If this resolves the issue, then this indicates it's a permission issue. How to Fix: Unfortunately every AD environment that has been hardened can be different, so it's difficult to say exactly where the issue lies. Normally when companies harden AD they may remove the ability for the "Authenticated Users" on certain containers to hide them, but some applications built with standard .NET code can have issues with this, including some of Microsoft's. We would suggest you check permissions for each container starting with Users and Computers, and confirm whether or not the Authenticated Users has read access, as per below screenshot: Next, you should check any other container that you have computers or user accounts stored in for the same permissions above, and this will include and nested containers, as the problem may be caused at any level. Finally check the top level domain and then depending on the results, you can do one of a few things: Restore the default AD permissions to allow Authenticated users to have read access to all containers where you have users or computers, and also ensure the permissions filter down to all nested objects - We realize this may not be possible. Give your Privileged Account Read access on all containers, and ensure permissions filter down to all nested objects Elevate the permissions of your Privileged Account to one of the built in AD Security Groups. Suggestions are: Account Operators, Administrators, Domain Administrators or Pre-Windows 2000 Compatible Access More Information: You may possibly run into the same sort of issues in Passwordstate, when attempting to let Passwordstate reset a password for an Account in AD. For most accounts in a domain, the privileged account Passwordstate uses should only need to be a member of “Account Operators” built in security group to be able to reset the passwords. However, this won’t allow the account to reset passwords for higher privileged accounts like Domain Administrators, or Enterprise Administrators. To reset passwords for accounts like these, the privileged account must also be a member of one of the Administrator Groups, either “Administrators” or “Domain Administrators”. This is by design from Microsoft, because if you can reset a domain Administrator password, then you effectively can use that account to perform domain admin tasks, so why not just make it a member of the Domain Admins in the first place? There are ways to set granular password reset permissions on account attributes, which will allow an account with less privileges to reset a domain admin password. We would not like to provide advice on this though as you can imagine it could be different for every domain. So summary, your privileged account should be a member of "Account Operators" group for all normal password resets, or “Administrators” to reset passwords for any Administrator type account. To mitigate against the risk of having these high privileges for your account, you can configure your privileged account to reset its own password on a regular basis in Passwordstate. Just link it to a password record from within the Privileged account screen, and set it to reset as often as you like. If you still find you cannot perform sync's/ resets, please contact Click Studios on support@clickstudios.com.au and if we have any more current information about this, we will let you know. Regards, Support.
  17. Purpose: This post outlines the process you need to follow, to grant someone access to the Remote Session Launcher, without them having the need to know the password. An example could be you have a contractor coming on site, and you want them to connect to machines and perform work, but you do knot want them knowing the password they are using to connect. If you are not familiar with how to set up the Remote Session Launcher, please see this in depth Forum Post - https://www.clickstudios.com.au/community/index.php?/topic/2110-how-to-set-up-the-remote-session-launcher-passwordstate-8/ 1. Under the Passwords tab, add a new Password Record that has an account that has permissions to connect into machines on your network. The following example is an Active Directory account which can connect to any Windows Server or Desktop. **Note, you do not grant the contractor permissions to see or use this Password Record: 2. Under Hosts tab -> Hosts Home, create a new Remote Session Credential, and link it to the existing Password Record you just created: 3. Grant your Contractor access to the remote session Credential you have just created in step 2 above: 4. Under the Hosts tab, grant the user access to the Folder of your choice, which has the machines added into it: 5. The user will now be able to choose a Host of their choice, and click the Auto Launch button. This will use the Remote Session Credential to establish a connection to the remote host, and the contractor will not have access to the password that they have connected in with: Regards, Support Click Studios
  18. Hi Craig, The following two documents will help with the move: https://www.clickstudios.com.au/documentation/move-new-database-server.html https://www.clickstudios.com.au/documentation/move-new-web-server.html Regards Click Studios
  19. If you have run into any issues with your normal Passwordstate accounts, and cannot log in, you can use an Emergency Access account to gain access back to the Administration area. This will allow you to fix the issue and restore Passwordstate back to a working environment. To log in with your emergency access password, you'll need to append /emergency to your Passwordstate URL, and enter the Emergency Password which you set during your initial install. An example of an Emergency Access URL is https://passwordstate.clickstudios.com.au/emergency. If you have forgotten your Emergency password, Click Studios can help you recover it, but you'll need to provide us some information. Please send this information to support@clickstudios.com.au requesting assistance to recover the password. **Note** If we do not have you listed as a contact, then we will need to get approval from one of our contacts, or your line manager to help you recover this password. Please CC in your Passwordstate Administrators and/or your Manager in your email as a form of authorization. 1. Provide a copy of your web.config file, which is located in your Passwordstate installation directory – default location is C:\inetpub\passwordstate on your web server. Note, if your web.config file is encrypted, you'll need to first decrypt it before sending through. How do you know if it's decrypted? Please see here: https://forums.clickstudios.com.au/topic/2699-encrypting-and-decrypting-the-webconfig-file/ 2. Using SQL Management Studio Tools, connect to your Passwordstate database server and run the following query: USE Passwordstate SELECT EA_Password, Secret3, Secret4 FROM SystemSettings Copy the output of this query and email it to Click Studios Once we have received your information, we will email you back your Emergency Access Password. We then recommend changing it once you have fixed your system, under Administration -> Emergency Access. Regards, Click Studios Support
  20. Purpose: This post will guide you through the process of installing IIS on your web server. Applies to: Windows Server 2008, Server 2012, Server 2016 How to I do this? Log into your web server as an Administrator, and launch the Server Manager utility by entering servermanager in the 'Run' prompt Click Add roles and features Choose Role-based or feature-based installation and click Next Choose your web server from the Server Pool and click Next Select Web Server (IIS) Click Add Features and then click Next Click Next Click Next Select the following Role Services and click Next: Common HTTP Features Static Content Default Document HTTP Errors Application Development ASP.NET (or ASP.NET 4.5 on Server 2012 and Windows 8) .NET Extensibility (or .NET Extensibility 4.5 on Server 2012 and Windows 8) ISAPI Extensions ISAPI Filters Security Windows Authentication Request Filtering Performance Static Content Compression Click Install Click Close
  21. Step 1: On your web server, open your c:\inetpub\passwordstate\web.config file. Take note of the username and password inside the connection string: Step 2: Open SQL Management Studio Tools, and enter your database server name, choose "SQL Server Authentication" and enter in the username and password you found in the web.config file If you get an error, then either the passwordstate_user account does not have db_owner rights to your database, or the password is incorrect. To fix this, connect to your database server using another account that has permissions, and confirm passwordstate_user has the correct permissions, and possibly set the password in SQL to match what is in your web.config file.
  22. Step 1: Ensure you have prerequisites set up for your web server and hosts, as per this forum post (Once off process) Step 2: Add new Password Record configured as follows: Screen 1: Ensure you configure the below 5 options correctly and enter in the password for the account. If you configure an Expiry Date it will automatically change the password in Passwordstate and on the Host when that date is reached. Screen 2: Ensure you select the appropriate Privileged Account and the Reset Windows Password reset script. Also confirm the Password Reset Schedule is enabled if you want the password to automatically change when the Expiry Date occurs Screen 3: Confirm the Validate Password for Windows Account validation script is selected
  23. To enable Passwordstate to reset passwords for accounts on remote hosts in your environment, you must ensure you have the following prerequisites set up: Web server and remote host requirements - https://www.clickstudios.com.au/downloads/version9/Passwordstate_Privileged_Account_Management_Manual.pdf In the Passwordstate user interface: Hosts need to be added in under the Hosts tab -> Hosts Home -> View All Hosts Records screen Some systems require a Privileged Account to perform the password reset on the remote host. To determine if you need to set up a Privileged Account, check Section 7 of this guide: https://www.clickstudios.com.au/downloads/version9/Passwordstate_Privileged_Account_Management_Manual.pdf A Password List that is configured for Password Resets (Screenshot below of this setting when creating or editing a Password List) Quick Information About Privileged Accounts: After creating a privileged account, for security reasons only the person who created it is granted access to use it. If you find you create a Password Record, but cannot see the Privileged Account that you thought was already in the system, go back into the Administration -> Privileged Account screen and confirm you have access to it (any any other user in Passwordstate that you need) Screenshot below shows where this can be configured:
  24. If you're new to Passwordstate, this video should help you install it for the first time:
×
×
  • Create New...