Hey tdanner,We have been noticing a 403 error when we try to run a Curl Command with a AD Account, but if we use a local Orion account it passes. Is that a known limitation with the API or could I be missing a setting?Thanks!
The REST endpoint accepts AD accounts using HTTP Basic authentication. It does not support NTLM/Kerberos on that port.
So We tried again with Basic Authentication but it still isn't working, I'm hoping maybe this will help?
Local account works fine:
C:\Users\zbg6fg>curl <ORIONSERVER>:17778/SolarWinds/InformationService/v3/Json/Query?query=SELECT+IPAddress+FROM+Orion.Nodes -k -v -u <LocalAccountUSERNAME>
Enter host password for user '<LocalAccountUSERNAME>':
* Trying 10.253.110.150...
* TCP_NODELAY set
* Connected to <ORIONSERVER>(10.253.110.150) port 17778 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=SolarWinds-Orion
* start date: Sep 20 22:53:46 2015 GMT
* expire date: Dec 31 23:59:59 2039 GMT
* issuer: CN=SolarWinds-Orion
* SSL certificate verify result: self signed certificate (18), continuing anyway.
* Server auth using Basic with user 'APITest'
> GET /SolarWinds/InformationService/v3/Json/Query?query=SELECT+IPAddress+FROM+Orion.Nodes HTTP/1.1
> Host: <ORIONSERVER>:17778
> Authorization: Basic QVBJVGVzdDpUZXN0QVBJ
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length: 542
< Content-Type: application/json
< Server: Microsoft-HTTPAPI/2.0
< Date: Tue, 09 Oct 2018 22:40:07 GMT
<
{"results":[{"IPAddress":"10.222.0.150"},{"IPAddress":"10.251.86.51"},{"IPAddress":"10.253.110.150"},{"IPAddress":"10.253.110.151"},{"IPAddress":"10.50.255.10"}
,{"IPAddress":"10.50.32.44"},{"IPAddress":"10.50.32.67"},{"IPAddress":"10.50.36.10"},{"IPAddress":"172.16.59.12"},{"IPAddress":"172.21.108.10"},{"IPAddress":"17
"},{"IPAddress":"172.21.78.91"},{"IPAddress":"172.21.81.10"}]}* Connection #0 to host hawkeye.ad.onsemi.com left intact
AD account blocked:
C:\Users\zbg6fg>curl https://<ORIONSERVER>:17778/SolarWinds/InformationService/v3/Json/Query?query=SELECT+IPAddress+FROM+Orion.Nodes -k -v -u <DomainUser>
Enter host password for user '<DomainUser>':
* Connected to <ORIONSERVER> (10.253.110.150) port 17778 (#0)
* Server auth using Basic with user '<DomainUser>'
> Authorization: Basic b25zZW1pXHpiZzZmZzp[password redacted]
< HTTP/1.1 403 Forbidden
< Content-Length: 0
< Date: Tue, 09 Oct 2018 22:42:27 GMT
* Connection #0 to host <ORIONSERVER> left intact
The next place to look would be in the SWISv3 log file on the Orion server: C:\ProgramData\SolarWinds\InformationService\v3.0\Orion.InformationService.log. Reproduce the error again and check that log for any details.
I've seen the same issue. Basic Auth works with local accounts, but not AD accounts (the client gets a 403). In the SWIS log I see this:
ERROR SolarWinds.Data.Providers.Orion.OrionAccountValidator - (null) (null) Failed to validate username and password for user 'domain\user'.
System.DirectoryServices.Protocols.DirectoryOperationException: The server cannot handle directory requests.
I tried sAM, UPN and just the username and all failed with the same error.
In another post you mentioned the possiblity of adding Kerberos/Negotiate. Is that on the road map for the JSON api? That would be great!
I had the same issue, but I was busy, (and have changed jobs ). In the end I had to create a local account to get it to work again.
I'm going to suggest that simplifying authentication for API access might be a good idea...
We've been using Python scripts for a couple of years now, and always used local accounts for the basic auth. We believed that authenticating via AD credentials simply would not work and is not even supported. However, recently some developer here at our company informed me he could successfully use his AD credentials in a Python script to perform API queries. I tried it myself and what do you know, it works!! However, it only works against one of our SolarWinds deployments. We have 4 different Prod instances and a test env. Only one of the Prod instances allows this, I get a 403 error on all other instances.
Can someone explain how this works, and how I can make it work on the other instances? Someone told me he saw one or more online threads that mention some "setting", but not specific to what that setting actually is.
Need help!! This would be awesome to have it working in all our instances.
I would be very interested if you get that answer. We've been unable to find a versatile solution to this still.
As tdanner suggested, you should try reading the the SWIS log file on the Orion server right after a failed request from one if the instances where Windows Authentication is not working:
C:\ProgramData\SolarWinds\InformationService\v3.0\Orion.InformationService.log
You can test the connection to SWIS with a very simple PowerShell script:
$OrionServer = '127.0.0.1'
$swisWindowsAuth = Connect-Swis -Hostname $OrionServer -Trusted
Get-SwisData -SwisConnection $swisWindowsAuth -Query 'SELECT TOP 5 NodeID, Caption FROM Orion.Nodes'
This thread has some additional details that might be helpful to you:
http request was forbidden with client authentication scheme 'Basic'
You can also try the following PowerShell script (adapted from the thread listed above), substituting the correct domain, user name, and password. This doesn't involve Orion at all, but it can help you determine whether it's possible to validate the credentials from the server in question:
Add-Type -AssemblyName System.DirectoryServices.AccountManagement
$pc = New-Object System.DirectoryServices.AccountManagement.PrincipalContext @("Domain", "MYDOMAIN")
$pc
$pc.ValidateCredentials("MYUSERNAME", "MYPASSWORD")
It could also be relevant to know whether multifactor authentication is enabled.
You are correct, however you are using the Get-SwisData commandlet, We have no problem using the commandlets. The problem is using a straight curl command (of course the ps equivalent of Invoke-WebRequest)
Just some Background info...For my issue, we were looking to build a web app for our operations team to unmanage nodes without needing access to the Manage Nodes Page, which requires admin rights. Also, we have a standard to not unmanage/mute for more than 90 days, and the web ui has no way to limit that. Our home-grown solution would. This app is to be build in NodeJS, so the curl command is needed, instead of the commandlet.
We are currently experiencing the same issue. Am i correct that the only way to solve it is to use local account?
No other slution in 2020?
Hello,
No other way in 2020?
