Solved

Unauthorized for Nutanix REST API. check username and password

  • 1 August 2019
  • 6 replies
  • 290 views

Badge +1
I am trying to connect Zenoss to Nutanix Prism cluster and have provided the monitoring guys a user name and pw along with cluster IP. They are getting errors trying to connect, the error is in title of this post.. unauthorized for Nutanix REST API. check username and password

So I then provided the monitoring guys the nutanix account and pw and it still spits out the same error.

Please advise. I have to be missing something here.
icon

Best answer by theGman 8 August 2019, 20:22

I resolved this issue by upgrading to the newer version per a recent advisory. I am now at 5.10.6. I don't assume that there was a bug for which the new version contained a resolution, the release notes don't indicate any issue, so what I believe is that we had some other problems in AOS that was simply put back to normal after the upgrade.
View original

6 replies

Userlevel 1
Badge +1
Not sure if this will help, but I am finishing up a powershell script using API calls, since the necessary powershell cmdlets don't exist. Here is a code snippet that works for me:

code:
$Header = @{"Authorization" = "Basic "+[System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($username+":"+$password ))}

foreach ($Cluster in $Clusters) {
Connect-NutanixCluster -Server $cluster -UserName $username -Password $secpassword -AcceptInvalidSSLCerts -ForcedConnection | Out-Null
$pdlist = Get-NTNXProtectionDomain | Where {$_.Active -eq $true}

foreach ($pd in $pdlist) {
$URL = "https://"+$Cluster+":9440/PrismGateway/services/rest/v1/protection_domains/"+$pd.name+"/schedules"
try { $output = Invoke-RestMethod -Method Get -Uri $URL -Headers $Header -UseBasicParsing } catch { $output = '' }


They secpassword to the cmdlet is a securestring object, but the password in the REST header is plaintext.

I suspect there might ber a clue in the header info, or perhaps the URL. It took me a while to find the "PrismGateway/services/rest/v1" part of the URL.

FYI, I got code from http://myvirtualcloud.net/how-to-establish-powershell-connection-to-nutanix-and-execute-your-1st-query/
Badge +1
Thanks, I'm not trying to code anything, I'm trying to connect an out of the box 3rd party tool developed for monitoring Nutanix infrastructure in partnership with Nutanix.. something as simply as entering the username and pw is failing, and the error message would have one believe this is a rights issue, I tried both the new local account I created as well as the nutanix account, neither account would allow me to connect to prism.

The documentation for the Nutanix Zenpack for Zenoss simply states enter the username, pw and IP to connect.. and also something about exposing v1 and v2 APis... so far my experiences with this product are less than desirable and I'm trying to remain positive..
Userlevel 1
Badge +1
The account I use for this and for our Nagios checks is a local Prism Element account. I don't know if a Prism Central account would work. Also, I think the local account needs to be a Viewer role.

Also note, I also do Nagios checks via SNMP. Is the monitoring tool using SNMP? That is a separate user account in the SNMP settings (there is a user tab). I think SNMP v3 is the one that needs user/pass, v1 and v2 use community strings. My config has a username, an authkey and a privkey, so I am using v3. I think the command also require the security type (AES, SHA, etc.) https://portal.nutanix.com/#/page/kbs/details?targetId=kA0600000008bAECAY
Badge +1
Hi bbeavis - that for this, I was wondering about this but the reality is the Zenoss Zenpack for Nutanix is not polling the devices, it is connecting to the APIs, which is why the error is popping up about not being authorized for the APIs.

One thing strikes me, the very first bit of instructions for connecting Zenoss to Nutanix is "you must expose the v1 and v2 APIs" .. I don't see anything in Nutanix documentation that points to any configurations that would need to be made to "expose the APIs"

And I have tried both local account I created and the nutanix account, but both accounts bring the same error back.

I am now beginning to believe this is some other communication error that is being mis-interpreted. However, there is no firewall blocking the traffic between the devices. We were able to make a sucessful connection to Prism Central but we aren't ready to go live with it yet so we are first connecting to Prism E. Also, connecting to the cluster IP provides redundancy that Prism Central doesn't offer, so I prefer to use Prism E as the connection point to monitor our nutanix clusters and keep prism central for other mgmt usage.

How about the http proxy and whitelist? we have the proxy configured in prism, do I need to while list the IPs of the Zenoss collectors that query the system? I haven't tried this yet and won't be able to until the cluster is healthy, apparently there is a support call in progress by a fellow engineer so I can't test anything yet.
Userlevel 1
Badge +1
Unfortunately, I don't use a proxy. In terms of exposing the API, I've done nothing special. It appears that v1-v3 are open on my system, but I think the API URL is different per version.

code:
/PrismGateway/services/rest/v1/
/PrismGateway/services/rest/v2.0/
/api/nutanix/v3/


You will probably get an authentication error, but that will show the PE is listening on the api urls.

so try from a browser,
code:
https://:9440/PrismGateway/services/rest/v1/vms
https://:9440/PrismGateway/services/rest/v2.0/vms
https://:9440/api/nutanix/v3/vms


If you get a 404 or 500 error, then something deeper should be looked into (I would think). Ideally, if you can do this from the monitoring system (wget or curl if linux) then that might help pinpoint where to look. If you want a successful result, you need to inject user/pass in the header of the request, like in the code example.
Badge +1
I resolved this issue by upgrading to the newer version per a recent advisory. I am now at 5.10.6. I don't assume that there was a bug for which the new version contained a resolution, the release notes don't indicate any issue, so what I believe is that we had some other problems in AOS that was simply put back to normal after the upgrade.

Reply