Jump to content

Pavel Belyj

Members
  • Content Count

    16
  • Joined

  • Last visited

Posts posted by Pavel Belyj


  1. I'm anyone else is reading this thread, Pavel has been helping us a lot to try and identify what's causing this issue. We believe it may be caused by Russian language settings on his Passwordstate web server, so we're going to try something new in the next build to see if we can resolve it.

     

    Regards

    Click Studios

     

    For Passwordstate (v. 7033 and below) deploy on Windows Server with Russian language settings for the correct operation of Chrome Extension should be:

     

    For the Russian copy of Windows Server (where deploy Passwordstate) language settings should be:

    6443918.jpg

    6248116.jpg

     

    For the English copy of Windows Server with Russian regional settings (where deploy Passwordstate) language settings should be:

    6429582.png

    6230708.png


  2. Hi Pavel,

     

    To fix this, you will need to do the following with the script:

     

    • Just after the line $group = [ADSI]"WinNT://$HostName/Administrators", insert this and then save the script

              if (-not $group.Path)

              { $group = [ADSI]"WinNT://$HostName/ÐдминиÑтраторы" }
    • Now go to the screen Administration -> Hosts & Password Resets, and click on the 'Restore Discovery Scripts' button

    On occasion though, we will update this script when we release new builds of Passwordstate - if we need to fix any bugs. We will be doing this for the next release to fix a bug for another customer. So any time you perform an upgrade of Passwordstate, you will need to check the changelog, or the script itself, to see if we have overwritten your change above. If so, just update the script again with the detail above.

     

    Regards

    Click Studios

     
    Oh yeah, you're right!
    Thank you!

  3.  

    Hi!
    In Russified copies of Windows7(8) local user groups have Russian names.
    ie, No group "Administrators", there is a group "ÐдминиÑтраторы".
    How can I fix the script task "Local Admin Accounts Discovery Job" ?

     

     
    (default) C:\inetpub\Passwordstate\setup\scripts\Get-LocalAdminAccounts.ps1
    line#20: $group = [ADSI]"WinNT://$HostName/Administrators" -> $group = [ADSI]"WinNT://$HostName/ÐдминиÑтраторы"
     
    However, if use this approach local administrators of the English copies Windows Server will not be found!

  4. Hi Pavel,

     

    Thanks for the screenshot. This has really got us a bit confused, as we're not getting any other reports for this. Can you do one more thing for us? Can you have a look a the following article, and email us a copy of the data in the UserAccounts table - http://www.clickstudios.com.au/documentation/query-data.html. You can email to support @ clickstudios.com.au - obviously without the spaces in-between.

     

    Thanks

    Click Studios

     

    Hi support,

     

    Information that you have requested, were sent


  5. Hi Pavel,

     

    I think we will need to do some testing outside of Passwordstate and Chrome. Can you do the following for us:

    • Download Fiddler from http://www.telerik.com/fiddler and install it on your desktop
    • Click on the Composer tab and (screenshot 1 below):
      • Select POST
      • Enter the correct URL for your environment i.e. https://<yoururl>/api/browser/authenticate
      • Specify the Content-Type: application/json 
      • In the Request Body, specify your UserName, your API Key and the Build Number for the extension - if you haven't done any upgrades for version 7, then it would be 7000. Or it could be 7019 or 7033
      • Now hit the Execute button, and then click on the Result to see the authentication key (second screenshot below). If you don't get a result of 200, then some settings above must be wrong
    • Now that you have the auth_key, do the same again, but this time:

     

    If everything's successful, this should return a list of Password Lists you have access to, which are configured to use the URL field.

     

    Let us know how you go.

     

    "https://password2:9119/api/browser/authenticate" - OK!

    but

    "https://password2:9119/api/browser/getpasswordlists" - ERROR!

     

    see pictures:https://onedrive.live.com/?cid=F78FC9FE826ED4D3&id=F78FC9FE826ED4D3%2110309


  6. Hi Pavel,

     

    Thanks for the data. That 'auth_key' is invalid, means there is an issue authenticating your API key to Passwordstate. Can you try the following for me:

     

    • In Passwordstate, go to the screen Preferences -> API Keys Tab, create a new 'General API Key', and then click on the 'Save' button
    • Now in the Chrome extension, click on the icon and then the 'Preferences' menu, enter the new API Key and ensure all other details are correct. Then hit the Save button
    • Now clear your cache in Chrome, and then restart Chrome

    Can you let us know if this helps at all?

     

    Thanks

    Click Studios

     

    Thanks for the tips!

    However, they have not been successful :(

    Browser Extension successfully login, but the functions "getpasvordlists", "getwebsites" and "generatepassword" returns the  401 ({"error": "auth_key is invalid."}).


  7. Hi Pavel,

     

    I don't suppose you have any other Chrome Extensions installed which could interfere with this?

     

    I might be quicker if you contact us via our support page, and then we can do a remote desktop session with you to see if we can spot what the issue is. Contact us here - http://www.clickstudios.com.au/support.aspx, and hit the 'Generate Support Ticket' button.

     

    Regards

    Click Studios

     

    In the Google Chrome is not installed other extensions.

    Sorry I can not give you remote access to our test virtual lab.

     

    I can provide data from Google Chrome Developer Tools:

     

    POST https://password2:9119/api/browser/getwebsites 401 ({"error":"auth_key is invalid."}) jquery-1.11.1.min.js:4

    send jquery-1.11.1.min.js:4

    m.extend.ajax jquery-1.11.1.min.js:4

    get_websites_for_user background.js:275

    update_data background.js:116

    Remote Address:192.168.233.101:9119
    Request Method:POST
    Status Code:401 {"error":"auth_key is invalid."}
    Request Headers
    POST /api/browser/getwebsites HTTP/1.1
    Host: password2:9119
    Connection: keep-alive
    Content-Length: 57
    Accept: application/json, text/javascript, */*; q=0.01
    Origin: chrome-extension://deebhghkicdgoliiennajdghfolpjaei
    User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Accept-Encoding: gzip,deflate
    Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
    Cookie: ASP.NET_SessionId=hd4l1tur0tf3siczc3gr5c3k
    Form Date
    auth_key=555E5458585F6550450E706D0E644A5C430E080D01040900
    Response Headers
    HTTP/1.1 401 {"error":"auth_key is invalid."}
    Cache-Control: no-cache
    Pragma: no-cache
    Content-Length: 32
    Content-Type: text/plain; charset=utf-8
    Expires: -1
    Server: Microsoft-IIS/8.5
    X-AspNet-Version: 4.0.30319
    X-Powered-By: ASP.NET
    X-UA-Compatible: IE=edge
    Access-Control-Allow-Origin: *
    Date: Mon, 10 Nov 2014 14:06:04 GMT

  8. I upgrade the Passwordstate with version 6 to 7.

    Installed Chrome extension. (Chrome ver.: 38.0.2125.111 m)

    I have created API Key on your 'Preferences' page within Passwordstate.

    I configuring extension for use.

    I filled in all the required fields in my password.

     

    ...and Auto-Fill Web Site Logins not works

     


    browser form fields

    UserName Field Name: user

    Password Field Name: passwd


     

    see pictures below:


    post-269-0-76316100-1415094202_thumb.png

    post-269-0-20059900-1415094232_thumb.png

    post-269-0-04434900-1415094254_thumb.png


     

    This issue is fixed in Passwordstate 7.0 Beta 4 - Build 7059!


  9. Thank you! and Sorry for my English.

    But this method is not suitable for us.

    There are users (IT users) who are administrators for password list A.

    There are users (Security users) who are administrators for password list B.

    Users (IT users) have read-only rights for password list B.

    Users (Security users) have read-only rights for password list A.

    Proposed option in this case will not help.

    Under the action password list A and users (Security users) do not need to be notified.

    Users (Security users) should not have to be notified for password list A.

    and

    Users (IT users) should not have to be notified for password list B.

    It would be nice when only administrators receive notification.

    Only one option would prevent problems from alerting.


  10. Passwordstate V6.3 (Build 6308)

    Error while delete individual password permission:

    1. Password list record - Actions - View Individual Password Permissions

    2. Individual password permissions - Actions - Remove Access

    An Error Has Occurred

    Please note the following error has occurred within the Passwordstate site. We apologize for the inconvenience.

    Debug Information

    Error: Conversion from type 'DBNull' to type 'String' is not valid.

    Stack Trace: at Microsoft.VisualBasic.CompilerServices.Conversions.ToString(Object Value) at cs_lib.RemovePasswordAccess(String PasswordACLID, Int32 PasswordID, String Title, Int32 PasswordListID, String PasswordList, String UserID, String SecurityGroupID)


  11. You used for storage character data type such as varchar.

    The data in your tables are stored in non-Unicode.

    To display characters properly in this case is very important value of the property сollations.

    Data that is moved between non-Unicode columns must be converted from the source code page to the destination code page.

    The default value of collation is Latin1_General_CI_AS. (Microsoft SQL Server 2012 SP1 (Express Edition) was deployed on Windows Server 2012 R2 (English edition))

    For the correct display of Russian letters must choose Cyrillic_General_CI_AS collation in the SQL Server.

    If you will used for storing character data type such as nvarchar (Unicode Support), then problems with the display of the characters (non-English) will not be.

    http://technet.microsoft.com/en-us/library/ms143726.aspx


  12. Good day!

    I have one little problem when working with Passwordstate V6.2 (Build 6231).

    Problem is displaying "???" instead of Russian letters in the names of password folders, or names of password list.

    Passwordstate V6.2 (Build 6231) and Microsoft SQL Server 2012 SP1 (Express Edition) was deployed on Windows Server 2012 R2 (English edition).

    Default Locale (Date Format) is Russian.

×