2017-08-22 05:36 AM - edited 2017-09-04 02:27 AM
We have OCUM 7.1 with integrated (linked with cert) OCPM, by policy it is not allowed to use the default admin role for the service account which will gather the Filers.
So we need to create a seperate role with the required permissions and add the user to this role.
Does anyone know if there is a howto ?? (i found one for DFM 7-Mode but not for OCUM cDOT) or can advise howto do this ?
Solved! SEE THE SOLUTION
2017-09-01 04:30 AM
hopefully this would help
2017-09-01 05:02 AM
no not really because i did not find the detailed requirements for creating a sep. OCUM User role on Netapp cDOT.
- on DFM there was a documentation howto create a least privileged User for DFM....
Guide says only admin role
2017-09-01 07:29 AM - edited 2017-09-01 10:01 AM
* CORRECTION/UPDATE * - I just grabbed what I think is the lates RBAC/privs file and it doesn't look like it'll work - no version # for OCUM appears in the tool. I pinged dbkelly to see if I'm just missing something...
The RBAC tool (discussed here):
Has a template/profile for OCUM. We used that in our shop and it seemed to work out pretty well. Haven't run into any errors/problems so far with the resulting account.
Hope that helps,
2017-09-04 02:10 AM
installed the tool, but it failed on selecting the product OnCommand Unified Manager Select the version (no version selctable)
We are using ONTAP 9.0P2 with OCUM 7.1
If i check the ontapPrivs.xml, i only see the 7 Mode Version DFM
<product id="dfm" label="OnCommand Unified Manager" description="OnCommand Unified Manager (DFM)">
<dfm id="dfm51" label="DFM 5.1">
and i did not the ONTAP 9
2017-09-05 04:54 AM
Yes - I have a question into the product team as to what version of the privs.xml file has OCUM 7.x included. I know we had a working version at one point but not sure why it's not working now (and/or if I'm just completely mis-remembering it).
Will post an update as soon as I hear back.
2017-09-07 01:47 PM
Upfront warning - this user setup below is not approved by NetApp support and they won't take any responsibility for failed polling, missing data, alarms not triggering/catching issues, etc. I don't expect any issues with this configuration but wanted to be as clear on this as possible.
I've had success using a limited role with OCUM/OPM 7.1 using the commands below:
security login role create -vserver <cluster_vserver> -role ocum_readonly_role -cmddirname DEFAULT -access readonly security login role create -vserver <cluster_vserver> -role ocum_readonly_role -cmddirname "cluster application-record" -access all security login role create -vserver <cluster_vserver> -role ocum_readonly_role -cmddirname "metrocluster modify" -access all security login role create -vserver <cluster_vserver> -role ocum_readonly_role -cmddirname "metrocluster show" -access all vserver services web access create -vserver <cluster_vserver> -name spi -role ocum_readonly_role security login create -vserver <cluster_vserver> -user ocum_readonly -application ontapi -authmethod password -role ocum_readonly_role security login create -vserver <cluster_vserver> -user ocum_readonly -application http -authmethod password -role ocum_readonly_role
Here's the rationale for the commands above.
- A limited role is setup with access to the 'cluster application-record' command tree. This is where ONTAP tracks what OCUM/OPM/WFA instances are managing the cluster.
- OCUM also demands access to the 'metrocluster' command tree and polling fails without this access.
- A SPI role is created to allow OCUM/OPM to pull performance files.
- A login is created with http/ontapi access. All connectivity should be through API calls for most metrics, or HTTP calls to the SPI interface to pull performance data.
2017-09-11 06:16 AM
Good morning - thanks a bunch for posting that role/account listing. I had some time this morning so I tried setting up an account that way and applying it to the cluster data sources section on our COOP/non-prod cluster. Anyway, after I updated the credentials on this particular cluster I got a "cluster login failed" status inside OCUM 7.2 - then no polling would occur and the cluster was unreachable. I gave it a bit just to see if the polling cycle would pick it back up, but no dice.
I went ahead and added a ssh privilege to the role and verified the acct/pswd work via an interactive shell (i.e. just making sure I didn't fat-finger anything) but OCUM must be trying some method/whatever that isn't supported in the role as you've specified. Any ideas what might be missing and/or where I'd look to see what the specific problem was?
2017-09-11 06:32 AM - edited 2017-09-11 06:33 AM
this solution looks fine until now, the first tests are successful, we will check the Metrocluster at next and then we will see if we still get some issues.
many thanks for now