Accediendo mediante ssh a una NetApp vamos a crear un rol, un grupo de usuarios y un usuario.
Debemos saber la contraseña de root para poder acceder. Además necesitaremos un cliente ssh para realizar la conexión, en esta ocasión hemos usado OpenSSH
Abrimos una consola de línea de comandos en Windows y ejecutaremos ssh introduciendo como parámetros el nombre de usuario (root) y el servidor destino (NetApp)
Nos solicitará la contraseña de acceso, una vez introducida correctamente estaremos conectados a nuestra NetApp en modo línea de comando y mediante una conexión segura (Secure Shell – ssh).
El esquema de creación sería el siguiente:
Una o varias características pueden pertenecer a una o varias capacidades que a su vez pueden pertenecer a uno o muchos roles. Un grupo o usuario puede tener ninguno, uno o varios roles y un usuario puede pertenecer a uno, varios o ningún grupo.
Crearemos un rol con únicamente la capacidad de inicio de sesión mediante telnet. Existen seis capacidades/permisos padres que se pueden otorgar a los roles, que son: login-*, cli-*, api-*, security-*, compliance-* y filerview-readonly.
Para ver la descripción de las capacidades según la documentación Data ONTAP 7.3 Commands: Manual Page Reference for 7-Mode, Volume 1 pinchar aquí.
El siguiente paso es crear un grupo de usuarios donde asociaremos el rol creado anteriormente.
Finalmente crearemos un usuario que pertenecerá al grupo anteriormente creado.
Para mejorar la seguridad hemos pensado que vamos a deshabilitar el puerto telnet y que solo sea posible acceder mediante ssh.
Comprobamos los accesos que posee el rol.
Debemos modificar nuestro rol para permitir acceso vía ssh.
Mediante este comando modificamos el rol añadiendo el permiso por acceso shh e intrínsecamente eliminamos el acceso por telnet.
Si deseamos añadir más permisos el comando sería. Ojo!!! Sin espacio entre las capacidades.
Comprobamos que nuestro usuario tiene acceso a la NetApp vía ssh.
There ares ix categories of capabilities: login-*, cli-*, api-*, security-*, compliance-* and filerview-readonly.
The ‘*’ character is used similar to a wildcard, with a couple of restrictions: It must be used at the end
of the capability. It must be used alone or in conjunction with one of the categories. If used with cli-, It
must be used with the full name of the CLI command.
The login-* category includes logging in via login_telnet, login-console, login-rsh, login-ssh,
login_snmp, login-ndmp, login-sp and login-http-admin.
The cli-* category includes all of the commands that can be run after a user is logged in with telnet,
console, rsh, or ssh. The format for this is cli-<command>* , which means allow all the commands and
subcommands. (cli-<command> just means the command and NO subcommands.) The capability for a
specific command, like exportfs, would have the following syntax: cli-exportfs* This means allow
command line accesses to the exportfs command and all of it’s subcommands. cli-export* may look
valid but is NOT allowed.
The api-* typei ncludes all of the Ontap API calls. These commands are only available via
login-httpadmin, so in general, any api-* command must also include this login. The format for this is
api-<ontap-api-command> which means allow a specific command/subcommand. Here, it is possible
to list only subcommands, like api-system-get-info or a command and it’s subcommands, like
api-systemget-* , or even api-system-*
The security-* type currently only has a few elements:
security-passwd-change-others which is used specifically to control if a user can change another
user’s password without knowing their previous password. By default, only root and members of the
Administrators group have this capability.
security-priv-advanced which is necessary to run advanced commands that are not used for normal
administration. Please talk to a Network Appliance representative before using advanced commands. By
default, only root and members of the Administrators group have this capability.
security-api-vfiler Normally a client will send ONTAP APIs directly to a vfiler if it wishes the API to
be executed on the vfiler. The security-apivfiler capability is necessary to send ONTAP APIs to the
physical filer which are to be forwarded to a vfiler for execution. By default, only root and members of
the Administrators group have this capability.
security-load-lclgroups which is necessary to run the useradmin domainuser load command. This
command changes all group membership. By default, only root and members of the Administrators
group have this capability.
security-complete-user-control which is used to allow an admin to add, modify, and delete users,
groups and roles with more capabilities than himself. These users typically only have access to the
cli-useradmin* and associated commands, though they can give themselves greater permissions. By
default, only root and members of the Administrators group have this capability.
The compliance-* categoryp rovides compliance capabilities to users in the "Compliance
Administrators" group when issuing snaplock commands. This category may not be added to other
groups in the system, nor can it be removed from the list of capabilities given to Compliance
Administrators. Currenttlhye, only privilege associated in this category is
compliance-privileged-delete. A user can be added to the "Compliance Administrators" group only if
the system has "telnet.distinct.enable" option set to "on".
The filerview-readonly capability allows users to access unmodifiable entities within FilerView GUI.
If the user has the filerview-readonly capability then FilerView GUI only shows the menus that have the
read-only bit set, which means that filer objects cannot be modified but could be browsed and queried.
No hay comentarios:
Publicar un comentario