#Mutual authentication with OTV 9.12

1 messages · Page 1 of 1 (latest)

marsh vortex
#

Hi all,
can someone explain to me how this mutual-authentication stuff works with ONTAP Tools for vSphere 9.12?
As mentioned here (https://docs.netapp.com/us-en/ontap-tools-vmware-vsphere/configure/task_add_storage_systems.html) it says: "From ONTAP tools 9.12 release onwards all ONTAP storage systems communication happens through certificate based authentication."

So I updated from OTV 9.10 to 9.12. And then checked if I have additional lines in the security login show for my OTV user. But I still only had the two original ones with "authentication method" password.
After some shenanigans in OTV (modifing the cluster, removing it completely, readding it, ...) I now have the situation that OTV actually added its own cert to ONTAP (check with security certificate show -type client-ca).
I also have four lines for my OTV user ( I needed to manually add the "cert" ones, so that must be a bug):

User/Group                 Authentication                 Acct   Authentication
Name           Application Method        Role Name        Locked Method
-------------- ----------- ------------- ---------------- ------ --------------
ontaptools     http        cert          ONTAPToolsforVMwarevSphereVSC_Discovery_Create_Modify_Destroy - none
ontaptools     http        password      ONTAPToolsforVMwarevSphereVSC_Discovery_Create_Modify_Destroy no none
ontaptools     ontapi      cert          ONTAPToolsforVMwarevSphereVSC_Discovery_Create_Modify_Destroy - none
ontaptools     ontapi      password      ONTAPToolsforVMwarevSphereVSC_Discovery_Create_Modify_Destroy no none
#

Anyways, it works. So far so good.

But I was curious why the "password" authentication methods where still there. So I deleted them. And surprise-surprise, now OTV tells me "Error occurred while fetching storage system privileges: Authentication failure" in the GUI.

So it looks like even though the documentation says "all ONTAP storage systems communication happens through certificate based authentication" that's not really the case. I mean OTV actually needs the certs on both sides (and they need to be valid non-expired certs) and it needs the "cert" authentication methods for your OTV user.
But actually it will (also) use the password method...

#

I don't really see the improvement here. I thought with mutual-authentication you can finally get rid of passwords for your applications integrating in ONTAP. So to reduce the risk if these credentials get stolen (maybe from the OTV somehow).

#

Does my ONTAP-system maybe need to be at least on 9.12.1? 🧐
Currently it's on 9.11.1P6

fresh mirage
#

What I'm seeing says "Invoke ONTAP API to create user where username should match with the certificate's common-name. In order to keep the username unique vcguid will be appended along with OTV-id "

#

do you have a user like that in your cluster?

#

it may only be for new installs..

#

if you "modify" a storage system, it should have an option to "generate a new client certificate for ontap", which should re-do all this..

marsh vortex
# fresh mirage do you have a user like that in your cluster?

yes, that exists (there are two certs because there are two SCV VMs in different vCenters):

cl3::*> security login show -vserver cl3 -user-or-group-name ontaptools

Vserver: cl3
                                                                 Second
User/Group                 Authentication                 Acct   Authentication
Name           Application Method        Role Name        Locked Method
-------------- ----------- ------------- ---------------- ------ --------------
ontaptools     http        cert          ONTAPToolsforVMwarevSphereVSC_Discovery_Create_Modify_Destroy - none
ontaptools     http        password      ONTAPToolsforVMwarevSphereVSC_Discovery_Create_Modify_Destroy no none
ontaptools     ontapi      cert          ONTAPToolsforVMwarevSphereVSC_Discovery_Create_Modify_Destroy - none
ontaptools     ontapi      password      ONTAPToolsforVMwarevSphereVSC_Discovery_Create_Modify_Destroy no none
4 entries were displayed.

cl3::*> security certificate show -vserver cl3 -type client-ca -common-name ontaptools
Vserver    Serial Number   Certificate Name                       Type
---------- --------------- -------------------------------------- ------------
cl3        36B19AE07F0BB831 ontaptools_36B19AE07F0BB831           client-ca
    Certificate Authority: ontaptools
          Expiration Date: Thu Apr 18 17:35:17 2024

cl3        61DCA872162F19C1 ontaptools                            client-ca
    Certificate Authority: ontaptools
          Expiration Date: Thu Apr 18 15:15:32 2024

2 entries were displayed.
#

SCV created the certs without issues. The problem in one vCenter was that it did not create the security login show lines with "authentication method" cert
But that's only I minor bug I currently don't really care about.

My issue is that I can't delete the lines with "authentication method" password because then SCV will not work anymore...
As mentioned I don't understand how mutual authentication using certificates has any use if I still need to retain the passwords... which could get stolen and reused on any other client for malicious purposes.

fresh mirage
#

Certainly doesn’t seem an optimal implementation if so does it?