SAM credential - use only password not username

Hi All.

Working on a requirement to run a powershell script monitor against a web site that uses a Bearer Token (similar to an oauth token) for authentication rather than a username/password.

I can make this work by adding the token in plain text to the script (component monitor) in the Header > Authentication section.  But you know plain text credentials in scripts not a good best practice.

A coworker mentioned that you can set up a SAM credential with a dummy username and the token for password.  Then in the component monitor use that SAM credential with some kind of setting/switch/parameter to tell the component monitor use only the password not the username. 

I'm guessing the parameter needed is some kind of $CREDENTIAL variable, maybe with an array designator to choose only one element.  However, still researching to determine the exact settings needed.

Let me know if anyone in the community has used script parameters to use only the password from a SAM credential.

Thanks much.

  • Having worked on this a while today...  Solarwinds documentation says there are two macros that represent various parts of the SAM credential used in script monitors - ${USER} and ${PASSWORD}.

    Working with this and trying to replace the loooooooong token in the header >> authorization part of the script monitor I have no luck with authenticating to my web site.

    Digging deeper and using some diagnostic write-host messages I find that the ${USER} variable expands into my dummy user name, but the ${PASSWORD} variable does not.  Used as a script argument I get literally "${PASSWORD}"; used in the body of the script I get nothing.  Blank. 

    I tried replacing the password in the SAM credential with something simple, like 'password123' just in case my long token contains some character that the monitor can't handle.  Results are the same: password variable does not expand in my script monitor.

    I saw a thread from a couple years ago where another community member was unable to get anything from the ${PASSWORD} macro in a script monitor - similar results to my experience.  I'm using SW version 2023.x of pretty recent vintage.  Wondering if the ${PASSWORD} macro was somehow removed in a recent product update.

    Please let me know if anyone has had any luck using the ${PASSWORD} macro in script monitors, especially PowerShell script monitors.

    Thanks.

  • Jbiggley had a response in this thread:  Passing ${CREDENTIAL} in a PowerShell without using -Credential - Forum - Server & Application Monitor (SAM) - THWACK (solarwinds.com), which I believe would accomplish what you are looking for.  It takes the "Credential for Monitoring" variable (${Credential}) then decrypts the password.  So in theory someone could still potentially hijack the password, but at least you wouldn't be storing the password as plain text within the monitor itself.  My recommendation would be the backend account tied to the oauth token to have very limited access.

    Simply supply the code below in the top of your script, and $password would be your unecrypted password/api key from the credential set.

    $c = Get-Credential 
    
    Function SecureStringToString($value)
    {
        [System.IntPtr] $bstr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($value);
        try
        {
            [System.Runtime.InteropServices.Marshal]::PtrToStringBSTR($bstr);
        }
        finally
        {
            [System.Runtime.InteropServices.Marshal]::FreeBSTR($bstr);
        }
    }
    
    [string] $username = $c.Username
    [string] $password = SecureStringToString $c.Password
    $securepass = $password | ConvertTo-SecureString -AsPlainText -Force

  • Thank you! Reading through the thread it sounds like this will provide the needed result.

    One question.  I assume then...

    1. I will add ${CREDENTIAL} as a script argument in the component monitor.
    2. the '$c = Get-Credential' as the first line of the component script is smart enough to know that the credential was passed from ${CREDENTIAL}.  I don't have to worry about assigning the $arg[0] to a separate variable. 

    Please let me know if either of these assumptions are not correct, or if more clarification is needed.  Thanks for your help.

  • With some effort and troubleshooting got this working.

    Using Get-Credential something else was needed to make this work.  Assign a variable to the ${creds} macro with the -credential switch, as below:

    $b = ${creds}
    $c = Get-Credential -Credential $b 
    Once ${creds} was assigned to $c the function provided above successfully parses out the username (not used) and the password in plain text.   
    With the bearer token represented in the $password variable I can replace the loooooong-and-insecure plain text token with that variable in the http header:
    $header = @{
        "Authorization"="Bearer $password"
    This configuration allows successful authentication to the target web site while obscuring the credential.  
    ----------
    Note on use case:  accessing a Red Hat Openshift Thanos endpoint ("Thanos" - part of the monitoring configuration for OCP*) from Solarwinds SAM via a Powershell script monitor using a Bearer Token for authentication.  In order to obfuscate the credential, placing the token in a SAM credential with a dummy account name and the token for password.
    ----------
    Additional note on the Solarwinds script macro for credential.  Solarwinds seems to support both ${CREDENTIAL} and ${creds} to represent the SAM credential applied to a script monitor.  Using ${CREDENTIAL} my script returned error about <account name from the SAM credential> not recognized as a command.  Using ${creds} the error does not appear.  I don't know the difference between these two macros but ${creds} seems to work better for this application.  See the below link for more details:
    ----------
    Thanks much for your assistance.  Anyone in the community feel free to question or comment.
    ----------
    *OCP - Openshift Container Platform
  • You should be able to use:

    $c = Get-Credential ${Credential}

    inside of the script itself instead of setting credential into the argument.