#401 unauthorized Ontapi

1 messages · Page 1 of 1 (latest)

forest fog
#

I was wondering if anyone could offer advice on what could be causing this 401 error I'm getting when trying to authenticate with the Ontapi .

This is the error message:

Failed to create backend: problem initializing storage driver ‘ontap-nas’: error initializing ontap-nas driver: could not create Data ONTAP API client: error creating ONTAP API client: error reading SVM details: response code 401 (Unauthorized): incorrect or missing credentials :

Logs from the CLI:

------------------------ --------------- -------------- -------------- -------
Tue Aug 29 16:15:45 2023 server123    vsadmin        10.21.132.8    Error
  Input  : Login Attempt
  Message: Authentication failed.
Tue Aug 29 16:15:45 2023 server123    vsadmin        10.21.132.8    Error
  Input  : POST /servlets/netapp.servlets.admin.XMLrequest_filer HTTP/1.1
  Message: 401 Unauthorized
  • The credentials are definitely correct
  • The account is not locked
  • The machine connecting to ONTAP is in the correct IP range stated in the export policy
  • The network interface service-policy has management-https and management-ssh included (added this from a support guide)
  • We are initiating the connection from Trident
  • The storage driver is ontap-nas

I appreciate a 401 error is a bit vague, please let me know if I can clarify anything.

grizzled zealot
#

sounds like a wrong password for the vsadmin user... can you connect via SSH to the mgmt IP using the same login/password?

slim crown
#

What OnTap version?
Is TRIDENT making the same shift with ONTAP to accomidate for the move from ZAPI to rest?

forest fog
#

I'm not able to SSH to mgmt IP but I think that's correct because this vsadmin account is tied to the SVM rather than at a cluster level. We're running 9.11.1P4, this is a new setup so TRIDENT is configured to work with rest as far as I'm aware.

I've noticed one interesting thing, I tried this command using my own cluster admin credentials:

curl -X POST -Lk https://<mgmtIP>/servlets/netapp.servlets.admin.XMLrequest_filer --user <username> -d "<netapp><system-get-version/></netapp>"

This gave the following error:

<html><head>
<title>401 Unauthorized</title>
</head><body>
<h1>Unauthorized</h1>
<p>This server could not verify that you
are authorized to access the document
requested.  Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
</body></html>

However, when i tried the same API call on another ONTAP cluster we have, I could authenticate without issues.

<!DOCTYPE netapp SYSTEM 'file:/etc/netapp_gx.dtd'>
<netapp version='1.211' xmlns='http://www.netapp.com/filer/admin'>
<results status="passed"><build-timestamp>1666870668</build-timestamp><is-clustered>true</is-clustered><version>NetApp Release 9.11.1P4: Fri Oct 28 12:49:14 UTC 2022</version><version-tuple><system-version-tuple><generation>9</generation><major>11</major><minor>1</minor></system-version-tuple></version-tuple></results></netapp>```

So I think the issue is on a cluster level now, rather than SVM/TRIDENT... Any ideas what I could check in regards to this? 

I checked the network routes which seem ok.
hot sky
#

What does

security login show -vserver server123

Look like?

forest fog
# 
User/Group                 Authentication                 Acct   Authentication
Name           Application Method        Role Name        Locked Method
-------------- ----------- ------------- ---------------- ------ --------------
vsadmin        http        password      vsadmin          no     none
vsadmin        ontapi      password      vsadmin          no     none
vsadmin        ssh         password      vsadmin          no     none
3 entries were displayed.
hot sky
#

And maybe…
security login role show-rest
?

When using a user account in the svm, typically you will use a LIF address associated with the vserver.
When asked to ssh with the vsadmin account, you should use something from the vserver, not the cluster. It won’t be allowed

When I’ve seen trident in play, the json file defined:
management ip (cluster)
Data lif (vserver)
Svm name
Aggregate name
Username (at the cluster, not vserver)
User-password

That’s just a bit. There were other details that would be there.

forest fog
#

its a big list but this is what we have. We made a new observation today too - making a cluster level account which has admin priviledges worked. We would prefer to use an account scoped to this particular SVM though rather than a Cluster account which has complete access over all SVMs.

I'm looking through the list i posted above seeing if granting more permissions helps

📎 message.txt
hot sky
#

If you can definitely figure what is really needed, you can create a custom role.

Realize though, using trident requires some cluster level commands. If I recall, creating and destroying volumes are done at the cluster with vserver scope

forest fog
#

Thanks for the advice, I'm experimenting more. I'll update here if we find the culprit 👍

grizzled zealot
hot sky
#

You can’t for trident. That’s why I suspect there was an issue.

#

Trident logs into the cluster and performs calls at the cluster (creating and deleting volumes)

forest fog
#

We managed to figure it out! I was authenticating using the SVM account with the Cluster MGMT LIF not the SVM MGMT LIF (which I just created) It seems silly now but I have a much better understanding of the ONTAP networking setup after all this troubleshooting.

Thanks everyone who helped me in this thread, I have learned a lot and hope to contribute to helping others in the future as I learn more about ONTAP 😄

grizzled zealot
hot sky
#

Excellent! I guess that may have been added at some point? I don’t use it. I’ve only helped out here and there. I have the json file from one customer and it clearly uses (it at least used to) use the cluster admin. The vserver, and data lifs were provided also