locked
ConvertTo-SecureString and AD Computer password changes RRS feed

  • Question

  • Hello all,

    I got a strange behavior. I'm using converto-securestring since a while on my scripts for securing tierce passwords. Today on a specific computer, all my securestrings are broken. I have the following error message: 

    convertTo-Securestring : Key not valid for use in specified state.

    The problem is that the context didn't change at all. It is the same computer and the same user used for running those scripts.

    However, I just noticed that the password of the computer changed two days ago on AD. It seems to be related. My computer is a 2012 R2.

    My scripts were running under 2008 R2 before and I never had this problem before. We just migrated a couple of weeks ago.


    www.alexwinner.com

    Monday, September 25, 2017 12:41 PM

All replies

  • Not enough information and not the right information.

    What script are you talking about?  What is the error? 


    \_(ツ)_/

    Monday, September 25, 2017 7:23 PM
  • There is nothing special about the script. 

    lets take an example. you store a password in a TXT file like this:

    ConvertTo-SecureString '' -AsPlainText -Force | ConvertFrom-SecureString | set-content E:\passwd.txt

    For use it, each time I'm running the following command:

    [System.Runtime.InteropServices.Marshal]::SecureStringToCoTaskMemUnicode($(gc E:\passwd.txt |convertTo-Securestring))


    On the same computer, one day I was able to convert the string to a secure string. The day after it's not anymore working.

    I got the following error: convertTo-Securestring : Key not valid for use in specified state.


    www.alexwinner.com

    Tuesday, September 26, 2017 9:36 AM
  • Hi,
     
    Based on my research, I'd like to explain that ConvertTo-SecureString cmdlet might use current user's password to generate an encryption key by default, the encryption key is then used to encrypt the intended string. And if the password has been changed, the encrypted password might not be decrypted because the encrypted key has been changed.

    And According to your situation, I recommend that you could have a try to custom the encryption key to avoid this issue.

    For more information, please refer the following article:
    Password Encryption & Decryption
    http://www.travisgan.com/2015/06/powershell-password-encryption.html
    Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    If you need further help, please feel free to let us know.

    Best Regards,
    Albert Ling

    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, September 26, 2017 9:54 AM
  • Interesting but the User's password had not been changed.

    www.alexwinner.com

    Tuesday, September 26, 2017 11:10 AM
  • Read this link:

    https://www.pdq.com/blog/secure-password-with-powershell-encrypting-credentials-part-2/

    ".. when you use ConvertTo-SecureString and ConvertFrom-SecureString without a Key or SecureKey, Powershell will use Windows Data Protection API (DPAPI) to encrypt/decrypt your strings. This means that it will only work for the same user on the same computer."  ..

    Tuesday, September 26, 2017 12:04 PM
  • As I said before:

    • The problem is that the context didn't change at all. It is the same computer and the same user used for running those scripts.

    So it is not the problem.


    www.alexwinner.com

    Tuesday, September 26, 2017 12:19 PM
  • Secure strings are not encrypted against a users password.  They are encrypted to the users ID.  A user cannot create a secure string and share it with other users or decrypt it from a different account.  It is specific to that user.

    Perhaps you should tell us why you think you need to do this.


    \_(ツ)_/

    Tuesday, September 26, 2017 6:35 PM
  • Read this link:

    https://www.pdq.com/blog/secure-password-with-powershell-encrypting-credentials-part-2/

    ".. when you use ConvertTo-SecureString and ConvertFrom-SecureString without a Key or SecureKey, Powershell will use Windows Data Protection API (DPAPI) to encrypt/decrypt your strings. This means that it will only work for the same user on the same computer."  ..

    In a domain it is encrypted to the users certificate and is always usable from the user account on any machine.  In a workgroup or standalone it is tied to the machine.


    \_(ツ)_/

    Tuesday, September 26, 2017 7:16 PM
  • I repeat that my securestring became unreadable wihtout changing anything. The securestring was generated on the same computer, same user account... That's the point.



    www.alexwinner.com

    Wednesday, September 27, 2017 8:41 AM
  • Hi,

    Based on your situation, this is not a normal behavior, I would suggest you open up a case with Microsoft Technical Support to see if they could get more information regarding this problem: https://www.microsoft.com/en-us/worldwide.aspx.

    Thanks for your understanding and cooperation.

    Best Regards,
    Albert Ling

    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, September 29, 2017 8:27 AM
  • the problem is related to the fact that the user account was using a temp profile...

    www.alexwinner.com

    Monday, October 16, 2017 3:00 PM
  • Hi,

    Good to hear that you have solved this issue by yourself. In addition, thanks for sharing your solution in the forum as it would be helpful to anyone who encounters similar issues.

    If there is anything else we can do for you, please feel free to post in the forum.

    Best Regards,
    Albert Ling

    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, October 17, 2017 8:59 AM