Node management permissions needed when using Powershell to set node to "unmanaged"

Hi,

we use an special orion account to set nodes to "unmanged" by powershell script in our automated server maintenance jobs.

Permissions for this account should be limited as much as possible. It should only have the permission to set nodes to "Unmanaged".

Doing the web-request with this URL: https://$($hostname):17778/SolarWinds/InformationService/v3/Json/Invoke/Orion.Nodes/Unmanage with a post body like this: ["N:1996","06/24/2019 09:00:29","06/24/2019 09:02:28","false"]  works great.

But only with both permissions “Allow Node Management RightsANDAllow Account to Unmanage Objects”. Without node management rights we get the error  "Access to Orion.Nodes.Unmanage verb denied.".

When using the same account in the Web UI for putting nodes to unmanaged mode, it's possible without node management rights.

Why is it different in SDK?

Regards,

Hermann

Parents Reply Children
  • It's a local Orion account, not from AD. We've installed this Version(s): Orion Platform 2019.2, IPAM 4.9.0, NCM 8.0, NPM 12.5, NTA 4.6.0, UDT 3.4.0, SAM 6.9.0, NetPath 1.1.5

  • do you mind sharing your API call here? I've used Unmanage a ton, but my service account for API calls does have elevated permissions. I'd like to try and emulate on our side for you so you can know if it's a bug to be logged with support.

    CC: tdanner​ or dan jagnow​; they might know off the top of their heads if this is a known limitation as well

  • I have confirmed that the API should not require node management rights.  The request to change that behavior is being tracked as internal issue CORE-12986.

  • to clarify, meaning that there's an internal issue tracking this bug because it shouldn't require node management rights, but it currently does requires those rights in the present state? or am I reading that wrong?

  • You are reading that correctly.  The rights required to use the API need to be adjusted so they match the rights required to perform the equivalent action from the website.  The website is working as intended.  The API is not.

  • Hi Zack,

    here is the script part we use. Should run in your env if you edit variables in first 4 lines.

    $orionserver = "netmon.rsint.net"

    $NodeID = "2852"

    $username = "NodeUnmanage"

    $SecurePassword = ConvertTo-SecureString -AsPlainText -Force -String 'xxxxxx your password xxxxxxxxxxxxx'

    $cred = New-Object -typename System.Management.Automation.PSCredential -argumentlist $username, $Securepassword

    $now = (Get-Date).ToUniversalTime()

    $url = "https://$($orionserver):17778/SolarWinds/InformationService/v3/Json/Invoke/Orion.Nodes/Unmanage"

    $json = "[`"N:$NodeID`",`"$($now.AddSeconds(1))`",`"$($now.AddMinutes(10))`",`"false`"]"

    # Since the certificate in Orion for SWIS is self-signed we'll need this to ignore it.

        add-type @"

        using System.Net;

        using System.Security.Cryptography.X509Certificates;

        public class TrustAllCertsPolicy : ICertificatePolicy {

            public bool CheckValidationResult(

                ServicePoint srvPoint, X509Certificate certificate,

                WebRequest request, int certificateProblem) {

                return true;

            }

        }

    "@

    [System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy

    Invoke-WebRequest -Uri $url -Credential $cred -Method Post -Body $json -ContentType application/json

  • Hi dan,

    thank you. Would be very important to fix that, because the password needs to be stored in the script and is quite public then. Node management rights for that user account are pretty critical then.

  • A bit offtopic as you mentioned it earlier. The password can also be stored in a encrypted password file. If you like to change it and don’t want to keep the password in plain text let me know.

    cheers

  • Interesting. However, who is able to decrypt the password file? I have to put the script in a public place, but how can I manage to give the "permission" to decrypt the password file?

  • I assume you let those scripts run via task scheduler. You would create the password file with the user that runs those scripts.

    it is not 100% secure but at least no plaintext passwords.

    It can only be decrypted in "normal ways" by the User that created the Passwordfile, so unfortunately there is no way to "give permission" to someone else.

    example:

    Run a Powershell in the User context that executes the script

    run the following command in the powershell

    $credential = Get-Credential

    $credential.Password | ConvertFrom-SecureString | Set-Content c:encrypted_password.txt

    you will now have a file in the User's root directory (the one that ran the script)

    Copy that to where you want it to be stored

    in order to use the password in the script:

    $password = Get-Content c:encrypted_password.txt | ConvertTo-SecureString

    $credential = New-Object System.Management.Automation.PsCredential($username, $password)

    cheers aus Franken