Yes--this can be done using Symmetrix Access Control Lists (SYMACLs), you can find information about implementing it in the Solutions Enabler Array Management Product Guide here:
For SYMACLs you would grant them BCV rights for Clone or Mirror and/or SNAP rights to the set of devices for TF/Snap. Check page 170 for more info on using TF with SYMACLs.
You definitely need to use SYMACLs no matter what, as SYMAUTH does not have the granularity to restrict like you want. If you want to not only prevent specific hosts from controlling the Symmetrix but also certain users you need to add on SYMAUTH. But keep in mind SYMAUTH should not be enabled without very careful planning as enabling it can block everyone if not done properly. SYMACL on the other hand does not block everyone by default when turned on. Both must be done with care, but SYMAUTH is more disruptive when enabled at first.
The biggest thing to remember to understand about ACLs is the default "Unknown" ACL. This ACL allows any host that has not been configured with a ACL to have a certain level of default access to all of the devices. This is designed to "do-no-harm" when initially enabling SYMACL.
So if the unknown host ACL is kept and you restrict access to installing Solutions Enabler it will suffice to prevent accidents. But if someone becomes malicious and gets a hold of SE and installs it on an "unknown" server they will have control you may not want them to. So best practice is to look for all hosts that need access to the array, configure ACLs for all of them depending on their needs and then delete the unknown group. Once that group is deleted any new host with SE installed on it will be entirely prevented access until an admin configured ACLs for it.
Based on the document i think we will be implementing host based acl on the aix servers where tf/clone scripts are to be run. the other servers do not have symcli installed nor have the access for installation file.
the service processor also part of unknown group. and we tried to add it in admin group. it is added but still it is not able to list all acl etc. it still shows as it is part of unknown group. not sure how to resolve that
Well, I would suggest that EMC personnel to dial in the box and add it from there using SYMMWINN. It is hard for me to believe that it is member of AdminGrp while symcli displays it as a member of UnkwnGrp.
codyhosterman
286 Posts
0
November 19th, 2013 12:00
Yes--this can be done using Symmetrix Access Control Lists (SYMACLs), you can find information about implementing it in the Solutions Enabler Array Management Product Guide here:
https://support.emc.com/docu46983_Solutions_Enabler_Symmetrix_Array_Management_CLI__7.6_Product_Guide.pdf?language=en_US
Note that it requires EMC PS/Support to enable it at first, then the rest can be configured by the end user.
dynamox
9 Legend
•
20.4K Posts
1
November 19th, 2013 12:00
Symacl and symauth
apethe
34 Posts
0
November 19th, 2013 12:00
What role should i assign if i want them only to be able to run timefinder commands and nothing else.
Also, do i use access groups or access lists.
codyhosterman
286 Posts
0
November 19th, 2013 12:00
For SYMACLs you would grant them BCV rights for Clone or Mirror and/or SNAP rights to the set of devices for TF/Snap. Check page 170 for more info on using TF with SYMACLs.
You definitely need to use SYMACLs no matter what, as SYMAUTH does not have the granularity to restrict like you want. If you want to not only prevent specific hosts from controlling the Symmetrix but also certain users you need to add on SYMAUTH. But keep in mind SYMAUTH should not be enabled without very careful planning as enabling it can block everyone if not done properly. SYMACL on the other hand does not block everyone by default when turned on. Both must be done with care, but SYMAUTH is more disruptive when enabled at first.
codyhosterman
286 Posts
1
November 19th, 2013 13:00
Should be fine.
The biggest thing to remember to understand about ACLs is the default "Unknown" ACL. This ACL allows any host that has not been configured with a ACL to have a certain level of default access to all of the devices. This is designed to "do-no-harm" when initially enabling SYMACL.
So if the unknown host ACL is kept and you restrict access to installing Solutions Enabler it will suffice to prevent accidents. But if someone becomes malicious and gets a hold of SE and installs it on an "unknown" server they will have control you may not want them to. So best practice is to look for all hosts that need access to the array, configure ACLs for all of them depending on their needs and then delete the unknown group. Once that group is deleted any new host with SE installed on it will be entirely prevented access until an admin configured ACLs for it.
apethe
34 Posts
0
November 19th, 2013 13:00
Based on the document i think we will be implementing host based acl on the aix servers where tf/clone scripts are to be run. the other servers do not have symcli installed nor have the access for installation file.
Do you see any flaws with this implementation?
CPrem
1 Rookie
•
32 Posts
0
July 2nd, 2014 07:00
the service processor also part of unknown group. and we tried to add it in admin group. it is added but still it is not able to list all acl etc. it still shows as it is part of unknown group. not sure how to resolve that
M_Salem
213 Posts
0
July 2nd, 2014 12:00
Well, I would suggest that EMC personnel to dial in the box and add it from there using SYMMWINN. It is hard for me to believe that it is member of AdminGrp while symcli displays it as a member of UnkwnGrp.
Hope that helps
Mohammed Salem