Prevent system admins from running SE commands

Vince, as promised, a brand new thread for your question

I've heard of 2 options.... well, actually 3:
1) be careful which licenses to install on that particular SE (sym..something..licenses.dat)
2) install SE on a dedicated host and build some sort of shell to issue only those specific commands to a particular user
3) SymACL: you can grant rights to a specific host to only issue certain commands to specific symdevs.

For example (case 3):
Host XY has STD devs 20, 21, 22, BCVs 30, 31, 32
You only need to be able to perform BCV commands
You grant timefinder rights to the host XY and install only the Timefinder license (plus the base license)
You can now issue symbcv or symmir commands against ONLY symdevs 20, 21, 22, 30, 31 and 32. No other symdev can be touched !

I think that the main "countermeasure" against a "not so expert" system administrator issuing the wrong command against a DMX is not to give them administrator's password

AFAIK as long as you are administrator (or root) you can issue commands. BUT you can choose to filter commands at two different layers ..

1) use symacl and allow MSCS hosts to issue RDF commands against their own devices

2) use symauth and map users to "roles", allowing (or disallowing) them to run some or all symcli commands

I never ever had the chance to try either the first or the last one .. So it's all my speculation

My 2 cents .. create a brand new user (sanadministrator) and grand "full power" only to this user (via symauth command). But don't forget to restrict every other user ..

Enjoy !!

Vince I'll split this thread .. we are going OT .. and it's better to give your question the right exposure. Please suggest a name for this brand new thread

Both functions can be combined, so let's say you have user A which can only monitor and user B with admin rights in symauth. If symacl is implemented as well B will on a certain host only be able to issue commands allowed to that host by symacl, user A can monitor things allowed by symacl, user C can do nothing (no entry in symauth database). Good thing is you can put in users from AD in DOMAIN\User format and do not need to to this for every system connected to the box.
Be aware that you should have an entry for an admin user before you set symauth to enforce, you could lock yourself out of the system
symacl has to be switched on by the CE on the service processor and requires careful planning! Also it adds a level of complexity to provisioning process: Devices have not only to be properly mapped and masked but also be configured in the correct access pool. Can be quite an overhead.

Cheers
Frank

i am waiting for additional granularity for symacl ..so i can restrict timefinder operations to establish/split but not restore.

Indeed, so do I
I have an RFE (Request for Enhancement) filed about 2 months ago with exactly that remark. I wonder if EMC will do something with this.

SymACL does just that. Ask your account manager to get a presentation of this product.