Inedo Community Forums Forums
    • Recent
    • Tags
    • Popular
    • Login

    Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

    If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

    Otter GetCredentialProperty Password

    Scheduled Pinned Locked Moved Support
    otter
    8 Posts 2 Posters 11 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • ? This user is from outside of this forum
      Guest
      last edited by

      When I use this function to get a stored credential:

      Log-Debug $GetCredentialProperty(DSSOtterAzure,Password);

      It prints out: DEBUG: System.Security.SecureString

      I assume that means it contains a secure string (and it's not just not a string containing the words "System.Security.SecureString" ) but how can I pass this to a powershell script (using pscall) for use in a credentials object?

      If I try and pass it as a secure string parameter it complains that it's the wrong type:
      Cannot convert the "System.Security.SecureString" value of type "System.String" to type "System.Security.SecureString".

      If I pass it as a string and then convert it to a secure string in the script it says the credentials are wrong :(

      Thanks!

      1 Reply Last reply Reply Quote 0
      • ? This user is from outside of this forum
        Guest
        last edited by

        It prints out: DEBUG: System.Security.SecureString

        This is a bug, we wil lfix it in the next maintenace release.

        how can I pass this to a powershell script (using pscall) for use in a credentials object

        We will add a function like, $ToPsCredential(), so that when you use it in a PSCall statement, it will be passed in as a secure string.

        If I pass it as a string and then convert it to a secure string in the script it says the credentials are wrong :(

        If it's just outputing "System.Security.SecureString" then that might be it... but if that's not the case, when you call that same script (that converts string to secure) from the command-line, does it exhibit the same behavior? Can you log the incoming password and secure string results inside the powershell script to see where the problem might be?

        1 Reply Last reply Reply Quote 0
        • ? This user is from outside of this forum
          Guest
          last edited by

          Thanks for the reply, I'll await the bug fix and new function.

          1 Reply Last reply Reply Quote 0
          • ? This user is from outside of this forum
            Guest
            last edited by

            Is this function ($ToPsCredential()) already avaliable? Or will it be avaliable in near future?

            I know I can use $CredentialProperty() and $PSCredential() to extract username and password from Resource Credentials and then create PSCredential object but I'm looking for a more secure way for doing this. I don't want to allow encrypted properties to be accessed in plans using $CredentialProperty() function.

            Or is there any other way to pass credentials to DSC resource using Ensure-DscResource?

            1 Reply Last reply Reply Quote 0
            • jraschJ Offline
              jrasch inedo-engineer
              last edited by

              @Adam - I have filed https://github.com/Inedo/inedox-windows/issues/70 to update the existing function to support referencing UsernamePassword credentials so you don't need to use $CredentialProperty

              1 Reply Last reply Reply Quote 0
              • ? This user is from outside of this forum
                Guest
                last edited by

                Great news, thank you.

                1 Reply Last reply Reply Quote 0
                • jraschJ Offline
                  jrasch inedo-engineer
                  last edited by

                  There are 2 ways to go about this:

                  1. Allow $PsCredentials() to support credential names as an argument

                  This is easiest, but would still require the "allow $CredentialProperty usage" option because you could always just write out the password in PowerShell regardless:

                   $credentials = Get-Credential
                   [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR(($credentials.Password))) | Write-Host
                  
                  1. Create a new PowerShellCredentials type

                  While the same "exploit" would still be available, at least it would be limited to PowerShell, e.g. you couldn't just Log-Information $CredentialProperty(secret, Password);

                  This though means we're just duplicating what UserNamePassword credentials already do, and it could cause confusion as to which one to use.

                  If you have any other feedback on this, we are all ears!

                  1 Reply Last reply Reply Quote 0
                  • ? This user is from outside of this forum
                    Guest
                    last edited by

                    Maybe some kind of checkbox in existing UserNamePassword would be a good solution? For example, a checkbox that clearly indicates that these credentials can only be used in PowerShell?

                    1 Reply Last reply Reply Quote 0

                    Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                    Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                    With your input, this post could be even better 💗

                    Register Login
                    • 1 / 1
                    • First post
                      Last post
                    Inedo Website Home • Support Home • Code of Conduct • Forums Guide • Documentation