Jump to content

support

Administrators
  • Posts

    5,090
  • Joined

  • Last visited

  • Days Won

    318

Posts posted by support

  1. Purpose:

    You need to get automatic email notifications based on some activity in Passwordstate.  This forum post describes how to set up a Scheduled Report to achieve this.

     

    Step 1:

    Open Scheduled Reports from the left hand pane Reports Menu, and then click Add Report

     

    Step 2.

    By default, the report will be sent to you, but you can add another user email address in the CC field if required.  Ensure you tick the Do not send report if it produces no results, and choose the Custom Auditing Report type

    2018-09-25_8-11-52.png

     

    Step 3:

    Choose the scheduled to be any thing you like.  In this example I’ll create it to run every 5 minutes so the user will be email almost immediately after the event has been triggered.  If there's no activity to report, Passwordstate will not email anything to the users.  If it’s not urgent that the user finds out this information, you can choose a different time scale, like daily or weekly for example

    2018-09-25_8-12-01.png

     

    Step 4:

    Choose the Password List or Lists you’d like to monitor, the type of auditing activity that will trigger the report, and the amount of time to query data.  This should match your schedule in Step 3 so data in reports being sent do no overlap

    2018-09-25_8-12-16.png

     

     

    Regards,

    Support

  2. Hi Guys,

     

    Interesting - didn't know that was even in the works.
     

    With PowerShell and our WinAPI, it is the parameter -UseDefaultCredentials which is used to pass the identity of the authenticated "Windows" account across to our API - basically it's impersonation. I'm not sure, but I don't think PowerShell Core can support this, as you're not logged on as a Windows User - unless there's a way to do this in Linux.

    Regards

    Click Studios

  3. Hi Habskilla,

     

    Sorry, the WinAPI (Windows API) can only be called from Windows Machines using PowerShell. With the use of PowerShell, you can execute the script under the identity of an Active Directory account, which then gives you the same level of access as if you were logged into Passwordstate.

    For Linux machines, you will need to use the standard API, which used API Keys for authentication.

    Regards

    Click Studios

  4. Hello,

    Thanks for your request. As a work around, you could run the SQL Query below. Any Password Lists with a TotalPermissions of 0, means there is no Admin on the list.

     

    USE Passwordstate

    SELECT PasswordLists.PasswordListID, PasswordLists.PasswordList, PasswordLists.Description, PasswordLists.TreePath, (SELECT COUNT(PasswordListID) FROM [PasswordListsACL] PSSWD WHERE (PSSWD.PasswordListID = PasswordLists.PasswordListID) AND (PSSWD.Permissions = 'A')) As TotalPermissions
    FROM [PasswordLists] 
    WHERE (PasswordLists.PrivatePasswordList = 0) AND (PasswordLists.Folder <> 1) 
    GROUP BY PasswordLists.PasswordListID, PasswordLists.PasswordList, PasswordLists.Description, PasswordLists.TreePath
    ORDER BY PasswordLists.PasswordList

    Regards

    Click Studios

  5. Hi Folke,

     

    Thanks for the feedback. With these suggestions, can you confirm you're wanting to make changes to existing Password Lists and Folders? We haven't really had much in the way of interest in doing this via the API, whereas the creation via the API is used by many customers.

    Do you also need this just for the initial data migration, or ongoing? We only ask because we have many feature requests we're working through, and it might be some time before we're able to work on it.

    Regards

    Click Studios

  6. Hello Everyone,

    So we can prioritize all the wonderful feature requests we receive from our customers, can you please vote on any feature requests listed in this forum which are important to you.

     

    Simply reply to the thread with a +1 as your response, and this will greatly help us.

    Please also only vote one person per customer.


    Thanks
    Click Studios

  7. Hello,

     

    Yes, you can do something like this, as per the example below in PowerShell. Are you also aware of the GeneratePassword option when updating passwords via the UI as well? This will generate a new password for you, based on the selected Password Generator assigned to the Password List, and then you wouldn't need to change the Expiry Date or Schedule as per below?

     

    With this example below, or if you used the GenerarePassword option, the reset would be picked up within the next minutes and processed.

     

    $NewExpiryDate = (get-date).AddDays(-1).ToString("yyyy-MM-dd")
    $NewSchedule = (get-date).AddMinutes(1).ToString("hh:mm")

    $jsonData = '
    {
    "PasswordID":"57783",
    "ExpiryDate":"' + $NewExpiryDate + '",
    "PasswordResetSchedule":"' + $NewSchedule + '"
    }
    '

    $PasswordstateUrl = 'https://myurl/api/passwords'
    $result = Invoke-Restmethod -Method Put -Uri $PasswordstateUrl -ContentType "application/json" -Body $jsonData -UseDefaultCredentials
    Write-Output $result


    Regards

    Click Studios

  8. 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:

    2018-05-16_8-16-18.png

     

    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:

    2018-05-16_9-30-25.png

     

    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

    2018-05-16_8-16-38.png

     

    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:

    2018-05-16_9-27-52.png

     

    2018-05-16_9-29-10.png

     

     

    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.

     

    2018-05-16_10-24-19.png

    2018-05-16_9-41-43.png

    2018-05-16_10-29-14.png

  9. 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?

     

    browser1.png

    browser2.png

    browser3.png

     

    Regards

    Click Studios

  10. 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

  11. **Edit 27th September 2019**

    We've updated this forum post with some more suggestions, including how to turn on verbose logging and a link to some known error codes.

     

    **Edit 6th January 2020**

    The Gateway installation process is now much simpler than what the video at the bottom of this thread shows.  Please see the Install documentation which describes how to use this new and improved install method:  https://www.clickstudios.com.au/downloads/version9/Passwordstate_Remote_Session_Launcher_Gateway_Install_Guide.pdf

     

     

    The Browser Based Remote Session Launcher that was introduced in Build 8275 requires some installation and configuration to be applied to your Passwordstate web server, but if you find you cannot launch session for any reason, please run through these troubleshooting steps below to resolve the problem:

     

    Issue 1:

    Do you see the Passwordstate-Gateway Service running on your web server?  If not then please follow the documentation under https://www.clickstudios.com.au/downloads/version9/Passwordstate_Remote_Session_Launcher_Gateway_Install_Guide.pdf to set up this feature as a once off process

     

    Issue 2:

    The Passwordstate-Gateway service is running but connections won't launch, you should be presented with a page of troubleshooting steps.  Try clicking the "Test SSL Certificate" link on this page and see what results that gives you.  If you get results saying your certificate is not secure, take the necessary steps to ensure your browser trusts your Passwordstate certificate.  This could be installing the certificate into the Trusted Certificate Authorities on your desktop though Internet Explorer, or adding an exception in Firefox as an example.

    2018-03-20_10-12-03.png

     

    Issue 3:

    If you receive a Web Proxy Gateway error like the screenshot above in Issue 2, this might be caused by a firewall on your web server blocking the connection.  To fix this, log into your Passwordstate web server (assuming this is where you installed the gateway) and run the following command in elevated Command Prompt to create a firewall rule:

     

    netsh.exe advfirewall firewall add rule name="Passwordstate-Gateway" dir=in action=allow protocol=TCP localport=7273

     

    Also consider that it may not be your Web Server firewall causing this issue, but it could be another firewall.  For example, if your DNS is hosted externally to your network, then port 7273 must be open on your company firewall and forwarding all traffic on to where you have your gateway installed.

     

    To test that ports are open, run this Powershell test from your desktop where you access Passwordstate from, to the Passwordstate web server, assuming this is where you installed the gateway.  You'll need to change the name of the web server in this test:

     

    Test-NetConnection webserver01.contoso.com -Port 7273

     

     

    Issue 4:

    If you receive a Web Proxy error like the screenshot above in Issue #2, this may be caused by incorrect syntax in your gateway.conf file.  Please ensure the syntax of this section of the gateway.conf file is in the same format as the below screenshot

    2018-10-02_11-07-02.png

     

    Issue 5:

    Can you successfully start the Passwordstate-Gateway service on your web server?  If not, please try these suggestions:

     

    Possible Fix Suggestion 1:

    Check the name of the C:\inetpub\Passwordstate\hosts\gateway\Passwordstate.pfx file is correct. This file must be called 'Passwordstate.pfx' for the service to work correctly

     

    Possible Fix Suggestion 2:

    Is OpenJDK installed on your web server?  If not please run the Gateway installer again, as this automatically downloads and installs Java for you: https://www.clickstudios.com.au/downloads/version9/Passwordstate_Remote_Session_Launcher_Gateway_Install_Guide.pdf

     

    Possible Fix Suggestion 3:

    Did you configure the SSL Certificate for the gateway, and put the encrypted password for this certificate in the gateway.conf file?  If not please refer to https://www.clickstudios.com.au/community/index.php?/topic/2971-how-to-encrypt-the-certificate-password-for-use-with-the-browser-based-gateway/2.png

     

     

    Possible Fix Suggestion 4:

    Is the default port of 7273 is in use by something else?  To test this, run a command prompt on your web server, and run the following command:

     

    netstat -ano | findstr :7273

     

    You should get a blank result back from this command if the port is free.  If something else is using the port, try changing the listening port in the C:\inetpub\Passwordstate\hosts\gateway\gateway.conf file to something else under 10000, save and restart the service

     

    Possible Fix Suggestion 5:

    Check the password that you set when exporting the certificate is the same password that you have encrypted and applied to your C:\inetpub\Passwordstate\hosts\gateway\gateway.conf file.  One way to test this is to export the certificate again from IIS, and set a new password.  Update the password in the Gateway.conf file and see if the service starts then

     

    Possible Fix Suggestion 6:

    In the Gateway.conf file, update SSL to false, and save the file.  Try restarting the service again now, and if it starts, this confirms that the certificate is the issue. And you should try running through the export process again by following this forum post: https://www.clickstudios.com.au/community/index.php?/topic/2971-how-to-encrypt-the-certificate-password-for-use-with-the-browser-based-gateway/

     

     

    2018-10-02_11-09-14.png

     

    **Note** 

    The SSL value in the gateway.conf file needs to be set to true in order to establish successful connections.  This test of changing it to false is purely to establish if there is something wrong with the certificate.  You should set this back to true after you have finished troubleshooting your issue.

     

     

    Possible Fix Suggestion 7:

    Possibly the recording path that is set in the Gateway.conf file does not exist or is incorrect.  Try changing the recording path back to the default location which is shown in the screenshot below, and then try starting the service again

     

    2018-10-02_11-13-42.png

     

    Issue 6:
    RDP into Server 2008 and Server 2008 R2 is not working, but Server 2012 and above is working okay.

    If you run into this issue, it's because your server's are not patched with the TLS1.2 and TLS1.2 updates from Microsoft. Please download and installed the appropriate patch below:

     

    Server 2008 - https://support.microsoft.com/en-us/help/4074621/add-rds-support-for-tls-1-1-and-tls-1-2-in-windows-server-2008-sp2
    Server 2008 R2 - https://support.microsoft.com/en-au/help/3080079/update-to-add-rds-support-for-tls-1-1-and-tls-1-2-in-windows-7-or-wind

     

    Issue 7:

    You can establish some connection to some machines with the Browser Based Launcher, but others seem to hang and do not make a connection.  Try one of these suggestions to help troubleshoot this kind of scenario:

     

    Possible Fix Suggestion 1:

    Try doing an open port test when logged in to your Passwordstate web server, to the remote host? Does this return True or False?  This Powershell example would be is me connecting to my remote Windows host: Test-NetConnection devpc1 -Port 3389. If you are having issues with SSH connections, the default port you should be testing for is 22.

     

    Possible Fix Suggestion 2:

    Possible you will get an error code in returned to you in the Error Console which will help diagnose the issue.  See this forum post for a list of Error Codes: https://www.clickstudios.com.au/community/index.php?/topic/2853-error-codes-for-the-browser-based-remote-session-launcher/

     

    Possible Fix Suggestion 3:

    You could temporarily enable verbose logging for your connections, and then refer to the logs to see if this can help diagnose the issue.  See this forum post on how to enable verbose logging of connections: https://www.clickstudios.com.au/community/index.php?/topic/2852-enabling-verbose-logging-for-the-browser-based-remote-session-launcher/

     

     

     

     

     

     

    Installation Video of installing the Gateway can be found below, which outlines all steps to set this up on your web server:

     

     

    We hope this helps and please log a support call with support@clickstudios.com.au if you are still having difficulty getting the Browser Based Remote Session Launcher to work correctly.

     

    Regards,

    Support.

     

×
×
  • Create New...