Hello all, I am attempting to use the 5.1 NM SDK via Perl to automate some processes against a cluster mode 8.2 vServer. Based on the SDK documentation for the "NaServer::set_style" method my options for authentication against the filer are LOGIN, HOSTS, or CERTIFICATE. Since this is cluster mode and there is no longer a /etc/hosts.equiv file that means all I can use are LOGIN and CERTIFICATE. If I choose LOGIN I can access all of the functions of the API and everything works perfectly, however I don't really want to have to embed a username and password inside of a script.
I followed the article below to get CERTIFICATE authentication setup. I can tell that the CERTIFICATE authentication is working because I can use the API 'system-get-version' object to retrieve the version and other attributes from the vServer. However if I attempt to use any of the volume related APIs such as 'volume-get-iter' or 'volume-clone-get' I receive a failed results status from the NaServer::invoke_elem method with a reason of 'not authorized for that command'. It appears that there may only be a limited set of API functionality when using CERTIFICATE authentication over LOGIN.
Has anyone had success using CERTIFICATE authetication against an 8.2 cluster mode vServer? any insight would be appreciated! thanks!
You can access all APIs and have no limit on access if you use CBA as the "admin" user.
Basically while creating the certificate give the common-name as : admin
Then using "security login create" command create a user with username "admin" , application as "ontapi" and authmethod as "cert".
This should make it work.
I have also updated the article at : https://communities.netapp.com/community/interfaces_and_tools/developer/blog/2013/07/30/using-sdk-with-certificate-based-authentication-cba
Thanks for pointing this out.
Hope I helped.
Please let me know.
Thank you very much for the reply, this pointed me in the right direction.......I had originally created my certificate/vServer login with a common name unique to our environment. Then I recreated the certificate/vServer login with a common name of 'admin' but I still had the same error message as before. So I recreated the certificate/vServer login again with a common name of 'vsadmin' an then everything was working correctly, I had full API functionality,
I think you should be able to use a custom role that contains whatever access you like but in my experience it is the name of the user and the common name in the certificate (both should be the same) that were critical. Like you I initially created a user account name that made sense to me, like 'automation' and then created a certificate with common name of 'automation'. The CBA seemed work but with very limited functionality. It wasn't until I used the username of 'vsadmin' that I had complete success. My 'vsadmin' user is assigned the 'vsadmin' role, but I just tested changing the role the 'vsadmin-readonly' and the CBA still works but obviously with read only permissions. So I would try using either 'admin' or 'vsdamin' as your username and certificate common name and assign the user your custom role and I think you should be good.......good luck!