WFA 3 authentication

[JTVNETAPP]

WFA 3.0

ONTAP 8.2 ClusterMode

I am just starting to test WFA 3.0, and am trying to figure out authentication.  I can get the basics working, e.g. assigning an AD group to a role, and have users of that AD group successfully login to WFA, and get the assigned role.   The authentication part I am working on is the execution of WFA operations.

I am interested in having commands executed on the controller/cluster as the person who is logged into WFA. The WFA documentation suggests this is possible; From the OnCommand Workflow Automation 3.0 Installation and Setup Guide, page 24:

With credentials
WFA tries to establish a connection using HTTPS and then tries using HTTP. You can also use Microsoft Active Directory LDAP authentication to connect to arrays without defining credentials in WFA. To use Active Directory LDAP, you must configure the array to perform authentication with the same Active Directory LDAP server.

So in theory if an account on the controller (ONTAP 8.2.x cluster-mode) is setup as nsswitch, the WFA logged in credentials should pass to the controller. Is that correct?

I run into a snag however when looking to create a cluster account as nsswitch. The 8.2 SysAdmin Guide, page 139 says:

Cluster user accounts cannot use nsswitch as an authentication method.

I am not certain if that is just a ONTAP 8.2 limitation, and is perhaps lifted in 8.3?

My goal is to have have WFA use the credentials of the user logged into WFA to execute the workflow, without having to maintain a separate user database on both WFA and the cluster? (i.e. if possible I don't want to have to create accounts on the cluster, and matching accounts within WFA).

Ultimately I would love it if WFA could authenticate to a Vserver (aka VSM) and use a Vserver account.   We have Vserver admins, and appropriate roles with a defined set of commands permitted setup for those persons. Vserver admins currently ssh to the vserver management address and use the CLI to perform tasks. My desire is to have WFA use those same accounts.  Can WFA do that?

[sinhaa]

So in theory if an account on the controller (ONTAP 8.2.x cluster-mode) is setup as nsswitch, the WFA logged in credentials should pass to the controller. Is that correct?

-----

No, I'm afraid it’s not. I'll try to expalin in as simple terms as I can. The credentials of a WFA user who logs in remain within WFA in its DB if it’s a local user. For Domain user the success of authentication is done by AD server and if passed the WFA user is logged in with the appropriate role assigned to his Group. So WFA doesn't get to know what are the user credentials.

No matter who has logged into WFA, if a WFA command tried to connect to a ONTAP Cluster or an external server like a mysql DB or a remote Windows host, the credentials available to the WFA Server service NA_WFA_SRV i.e. the Login account with which the WFA Server service  was started with will be used. By default NA_WFA_SRV starts with LocalSystem account i.e.  with no credentials. This can be changed to be started with another User account by editing the Service Properties providing the correct credentials. But again, the connection attempt to an external system like ONTAP will now use these new credentials and NOT dynamically use the credentials of any user who logged into WFA. 

So this is not happening. Application level credentials can't be use in System level authentications.

All ONTAP Clustered DOT and not just 8.2 doesn't provide nsswitch or Domain authentication methods. The only passwordless login possible on cDOT is cetificate based authentication. I can help you on this if you want to know more.

@ My goal is to have have WFA use the credentials of the user logged into WFA to execute the workflow, without having to maintain a separate user database on both WFA and the cluster? (i.e. if possible I don't want to have to create accounts on the cluster, and matching accounts within WFA).

-----

Sorry, but this is just NOT possible.

 sinhaa

[JTVNETAPP]

Thank you for the reply Sinhaa.

So it sounds like the only way to have workflows executed is to have an account, which has appropriate cluster level permissions, statically defined in the "Execution -> Credentials", is that correct?

So all workflows, by all users of that WFA instance, are performed as that same cluster account.

This is a bit of a limitation in a distributed administration environment.

For example, we have Vserver1, and a distributed admin team to support Vserver1. That team should (and by existing roles and vserver admin accounts can) only perform actions on the objects (volumes, quotas, export-policies, etc), within that Vserver1, they can not be able to touch Vserver2. Then Vserver2, and it's admin team, should only be able to affect Vserver2, and not Vserver1.

How do others make this work in a distributed administration environment?

Have a separate WFA instance for each different administration team, with each WFA configured to use a separate account with rights limited to the appropriate vserver?

Thanks for your input,

Jeff

[sinhaa]

@

So it sounds like the only way to have workflows executed is to have an account, which has appropriate cluster level permissions, statically defined in the "Execution -> Credentials", is that correct?

So all workflows, by all users of that WFA instance, are performed as that same cluster account.

--------

Well, yeah. Curently one cluster IP saved in Execution->Credentials can only have 1 set of username/password which as you said will always be used to connect to the cluster in workflow executions irrespective of who is the WFA logged in user.

As an alternative, you don't save the cluster credentials in Execution-> Credentials, but have your commands designed such that Username/Passwd are to be provided at the execuition time. WFA3.0 provides Password as User Input feature. The workflow executor can provide the username/password and this will be used to Connect to the cluster.  But I don't know if any  of the WFA certified i.e. available-with-product  commands use this method to connect to the cluster. You  would need to modify the commands to use this method. Look for the WFA developer's guide on how to do this.

sinhaa

[geringer]

I have a workaround for the distributed admin problem.  I created a command to determine if the WFA userid matches a user id with vsadmin rights on the vServer that the workflow is running against.  This command returns normally if the user is a vsadmin, but throws an error (which aborts the workflow) if the user does not have vsadmin rights.  If you make this the first command in your workflow it provides the access control thatyou are looking for.  The .dar file is attached.

Mike

[JTVNETAPP]

Hi Mike,
Thank you for creating and sharing this!

I am new to WFA, so this is a great help.
After learning about WFA authentication, I was kinda pessimistic about being able to use WFA in our distributed admin environment, but this gives it a lease on life.

thanks again.