ONTAP 9.4 Intergation with OCUM and WFA using services account(AD RBAC ROLE) instead of admin

[Hariprasad]

Team

While integrating OCUM 9.4 and WFA 4.2 with cDOT 9.4 the common practrice is to use admin account on OCUM.The security policies we have limits admin account and needs logging enabled for every admin related activities.

Can some one tell exact permission needed to create a role/service user account(should not be part of Admin role) with least permission on ONTAP and use that account to integrate with OCUM/WFA.

Note :All provisions is through WFA and storage admin only can login to console to troubleshoot.

[niels]

Hi Hariprasat,

I see two options here in case you are not allowed to use the adminm account directly.

1) create a new user, which can be AD integrated, and assign it admin privileges. That limits the use of the local admin account, but obviously still allows full admin access. This is fully supported though.

2) you create a role. Unfortunately there is no official documentation on what capabilities that role requires. Full admin access is the only officially supported setup - see 1) above. Nonetheless there are people with similar requirements as you who have tried to figure that out - look here:

https://community.netapp.com/t5/Data-Infrastructure-Management-Software-Discussions/how-to-create-separate-least-priveledged-role-for-OCUM-Service-Acc...

Again - this is people trying things. Not officially supported. I don't know about latest OCUM. After you created the role with the capabilities listed there, you might need to check ONTAP logs in case that service user is denied certain tasks and you might need to add those capabilities to the OCUM role.

Kind regards, Niels

---------------------

If this post helped you, help others by accepting as solution or give kudos.

[Hariprasad]

Thanks Niels

I am looking at second option and as you said there is no Documentation of what permissions needed .

I looked into the Link others posted but my understanding with their requirement is alerting and monitoring but where as I need integration with WFA (Provisioning) which needs more permissions to create volumes/shares etc..

Hari

[niels]

True. WFA will need different capabilities than OCUM.

But the capabilities required by WFA will match what you want it to do. So as an example if you want WFA to create and alter volumes, but not destroy them, you need to create a role with the respective privildges. I doubt there will bre a one-size-fits-all-solution to this - that would be full admin privilidge as in #1.

But generally it should be easier to figure out what capabilities you need as the WFA user is not monitoring on some interval, but acting on a prticular task at a particular time. So whenever you initiate a workflow and it fails, check the ONTAP logs which capability is missing.

Yes - that is tedious. But as I tend to say "secure is never easy, and easy is never secure".

Kind regards, Niels

[Hariprasad]

Hi Niels

I tried putting up the roles required for OCUM Integration with WFA and still not tested through.

Can you please review and let me know if this needs any amendements.

I am under impression this line is not needed if we restrict console access with OCUM WEB UI

security login create -vserver cluster1 -username OCUMadmin -role OCUM -application console -authmethod password

Hari

[niels]

Just to be sure - you are plaiing to use the role OCUM and the user OCUMadmin for both

a) having Unified manager monitor the clusters, and

b) having WFA execute workflow-based tasks?

If so, you may want to split into two seperate roles. Have a very limited user for use by Unified Manager, and have another user for WFA for actual execution of tasks.

OCUM should not require the console application as it should use API calls only, meaning http and/or ontapi. The console is the physical console port or SP access. I doubt that you would need that for either WFA or OCUM.

Kind regards, Niels

[Hariprasad · Accepted solution]

Thanks Niels

I havent implemented yet but this sould work and with bit of trial errors we should be able to Implement looking at error logs.

May be its good idea if we add this as built in RBAC role in feature.

Hari