Guía de configuración de seguridad de EMC Celerra · Seguridad de capa de transporte (TLS): protocolo sucesor de SSL para la autenticación y encriptación de comunicaciones generales

1 de 90

ContenidoIntroducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Requisitos del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Precauciones y advertencias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Opciones de la interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Terminología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4Información relacionada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Conceptos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Consideraciones de planificación para la identificación y autenticación de usuarios administrativos . . . . . . . . . . . . . . . . . . .16Consideraciones de planificación para usar un servidor de directorios externo para identificación y autenticación de usuarios administrativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19Consideraciones de planificación para el acceso administrativo basado en funciones. . . . . . . . . . . . . . . . . . . . . . . . . .21Consideraciones de planificación para la seguridad de las contraseñas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25Consideraciones de planificación para la Infraestructura de claves públicas (PKI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

Configuración del uso de un servidor de directorios externo para identificación y autenticación de usuarios administrativos . . . . . .29Configuración de la política de contraseñas . . . . . . . . . . . . . . . . . . . . . .32

Definición interactiva de la política de contraseñas . . . . . . . . . . . .32Definición de políticas de contraseñas específicas . . . . . . . . . . . . .33Configuración del período de vencimiento de las contraseñas. . . .33

Configuración del tiempo de espera de las sesiones . . . . . . . . . . . . . . .34Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34Modificación del valor de tiempo de espera de las sesiones. . . . . .34

Personalización de un banner de inicio de sesión. . . . . . . . . . . . . . . . . .36Creación de un mensaje del día (MOTD) . . . . . . . . . . . . . . . . . . . . . . . . . .37Protección de tokens de sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38Configuración de la encriptación y la autenticación de redes mediante el protocolo SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

Uso de HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Uso de SSL con LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Cambio del protocolo SSL predeterminado. . . . . . . . . . . . . . . . . . . .40Cambio de la serie de cifrado de SSL predeterminada. . . . . . . . . . .40Requisitos posteriores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Guía de configuración de seguridad de EMC Celerra

P/N 300-008-085Rev A02

Versión 5.6Octubre de 2008

Guía de configuración de seguridad de EMC CelerraVersión 5.6 2 de 90

Configuración de PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Creación del certificado proporcionado por la persona . . . . . . . . . 42Obtención de certificados de CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Uso de la Control Station como CA . . . . . . . . . . . . . . . . . . . . . . . . . . 42Generación de un conjunto de claves y de la solicitud de certificado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Envío de la solicitud de certificado a la CA. . . . . . . . . . . . . . . . . . . . 46Importación de un certificado firmado por la CA . . . . . . . . . . . . . . . 47Enumeración de los certificados disponibles en la CA . . . . . . . . . . 49Obtención de un certificado de CA . . . . . . . . . . . . . . . . . . . . . . . . . . 49Importación de un certificado de CA . . . . . . . . . . . . . . . . . . . . . . . . . 52Generación de un nuevo certificado de CA para la Control Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Visualización del certificado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Distribución del certificado de CA de la Control Station . . . . . . . . . 55

Administración de la PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Visualización de las propiedades del certificado y el conjunto de claves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Búsqueda de conjuntos de claves vencidos. . . . . . . . . . . . . . . . . . . 57Eliminación de conjuntos de claves. . . . . . . . . . . . . . . . . . . . . . . . . . 57Visualización de propiedades de un certificado de CA . . . . . . . . . . 58Búsqueda de certificados de CA vencidos . . . . . . . . . . . . . . . . . . . . 58Eliminación de certificados de CA . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Resolución de problemas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Dónde obtener ayuda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60EMC E-Lab Interoperability Navigator . . . . . . . . . . . . . . . . . . . . . . . . 60Resolución de problemas de la conexión de Control Station a un servidor de directorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Resolución de problemas de las cuentas de usuario administrativo locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Resolución de problemas de cuentas de usuario administrativo asignadas por dominio . . . . . . . . . . . . . . . . . . . . . . . 63Resolución de problemas de importaciones de certificados . . . . . 63Mensajes de error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Programas de capacitación para clientes . . . . . . . . . . . . . . . . . . . . . 65

Apéndice A: Series de cifrado de SSL soportadas . . . . . . . . . . . . . . . . . 66Apéndice B: Comprensión de la configuración del servidor de directorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Usuarios y equipos de Active Directory . . . . . . . . . . . . . . . . . . . . . . 68Ldap Admin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

3 de 90Versión 5.6Guía de configuración de seguridad de EMC Celerra

IntroducciónEMC® Celerra® Network Server implementa diversas funciones de seguridad para controlar el acceso de usuarios y el acceso a redes, monitorear el acceso y el uso del sistema, y soportar la transmisión de datos encriptados. Estas funciones de seguridad se implementan en la Control Station y los Data Movers. En este documento, se explica por qué, cuándo y cómo deben utilizarse estas funciones de seguridad. Es importante contar con conocimientos básicos sobre estas funciones para comprender mejor la seguridad de Celerra. "Conceptos" en la página 7 proporciona más detalles.

Este documento forma parte de la documentación de Celerra Network Server y está destinado a los administradores responsables de la configuración general y del funcionamiento de Celerra.

Requisitos del sistemaLa Tabla 1 en la página 3 describe las configuraciones de almacenamiento, red, hardware y software de Celerra Network Server necesarias para utilizar las funciones de seguridad según se describe en este documento.

Precauciones y advertencias Si tiene dudas respecto de esta información, póngase en contacto con un representante del Servicio al Cliente de EMC para obtener ayuda.

Si no modifica las contraseñas predeterminadas durante la instalación, debe cambiarlas lo antes posible.

Opciones de la interfaz de usuarioCelerra Network Server ofrece flexibilidad para administración de networked storage basado en su entorno de soporte y sus preferencias de interfaz. En este documento, se describe cómo configurar y administrar las funciones de seguridad mediante la interfaz de línea de comandos (CLI). Además, puede realizar muchas de estas tareas con Celerra Manager.

Para obtener información adicional acerca de la administración de Celerra, consulte:

◆ Learning about EMC Celerra en el EMC Celerra Network Server Documentation CD

◆ Ayuda en línea de Celerra Manager

Installing EMC Celerra Management Applications incluye instrucciones para iniciar Celerra Manager.

Tabla 1 Requisitos del sistema de seguridad

Software Celerra Network Server versión 5.6.

Hardware No tiene requisitos de hardware específicos.

Red No tiene requisitos de red específicos.

Almacenamiento No tiene requisitos de almacenamiento específicos.

../../mergedprojects/Concepts/Celerra_Product_Line.htm

../../../wwhelp/wwhimpl/java/html/wwhelp.htm

../../../wwhelp/wwhimpl/java/html/wwhelp.htm

../InstallationManagement/index.htm

Guía de configuración de seguridad de EMC Celerra4 de 90 Versión 5.6

TerminologíaEl EMC Celerra Glossary proporciona una lista completa de terminología de Celerra.

API de XML: interfaz para administrar y monitorear de manera remota un Celerra Network Server. La interfaz usa mensajes con formato XML y es independiente de cualquier lenguaje de programación. Autenticación: proceso para verificar la identidad de un usuario que intenta acceder a un recurso u objeto, por ejemplo, un archivo o un directorio.

Autoridad de certificación (CA): tercero de confianza que firma digitalmente certificados de claves públicas.

Certificado de la autoridad de certificación: asociación firmada digitalmente entre una identidad (una Autoridad de certificación) y una clave pública que utilizará el host para verificar las firmas digitales en los Certificados de claves públicas.

Certificado digital: ID electrónico emitido por una autoridad de certificación que establece las credenciales de un usuario. Incluye la identidad del usuario (un nombre de host), un número de serie, fechas de vencimiento, una copia de la clave pública del titular del certificado (utilizada para encriptación de mensajes y firmas digitales) y una firma digital de la autoridad que emite el certificado de modo que un destinatario pueda verificar la validez del certificado.

Control Station: componente de hardware y software de Celerra Network Server que administra el sistema y proporciona una interfaz de usuario administrativo a todos los componentes de Celerra.

Data Mover: en un Celerra Network Server, un componente del gabinete que ejecuta su propio sistema operativo que recupera archivos desde un dispositivo de almacenamiento y permite que estén disponibles para un cliente de la red.

Directorio basado en LDAP: servidor de directorios que proporciona acceso mediante LDAP. OpenLDAP o iPlanet (también conocido como Sun Java System Directory Server y Sun ONE Directory Server) son ejemplos de servidores de directorios basados en LDAP.

Entrada de control de acceso (ACE): en un entorno de Microsoft Windows, un elemento de una lista de control de acceso (ACL). Este elemento define los derechos de acceso a un archivo para un usuario o grupo.

File systems comunes de Internet (CIFS): protocolo de uso compartido de archivos basado en Microsoft Server Message Block (SMB). Permite a los usuarios compartir file systems mediante Internet e intranets.

Infraestructura de claves públicas (PKI): medio de administración de claves públicas y certificados de claves públicas asociados para utilizar en criptografía de claves públicas.

Interfaz de línea de comandos (CLI): interfaz para ingresar comandos por medio de la Control Station para realizar tareas que incluyen la administración y configuración de la base de datos y los Data Movers, y el monitoreo de estadísticas de los componentes del gabinete de Celerra.

Kerberos: mecanismo de autenticación, integridad de datos y encriptación de privacidad de datos utilizado para codificar información de autenticación. Kerberos coexiste con NTLM (servicios Netlogon) y, mediante criptografía de clave secreta, proporciona autenticación para aplicaciones cliente/servidor.

../../mergedprojects/Glossary/index.htm


Lista de control de acceso (ACL): lista de entradas de control de acceso (ACEs) que proporciona información sobre los usuarios y los grupos que pueden acceder a un objeto.

Network File System (NFS): file system distribuido que proporciona acceso transparente a file systems remotos. NFS permite a todos los sistemas de red compartir una única copia de un directorio.

OpenLDAP: implementación de fuente abierta de un servicio de directorios basado en LDAP.

Persona: medio de proporcionar una identidad para un Data Mover como servidor o cliente por medio de una clave privada y certificado de clave pública asociado. Cada persona puede mantener hasta dos conjuntos de claves (vigente y futuro), de modo de habilitar la generación de nuevas claves y certificados antes del vencimiento del certificado vigente.

Política de acceso: política que define los métodos de control de acceso (permisos NFS o ACL de Windows) que se exigen cuando un usuario accede a un archivo en un sistema Celerra, en un entorno configurado para ofrecer acceso multiprotocolo a algunos file systems. La política de acceso se configura con el comando server_mount y también determina las acciones que puede realizar un usuario en relación con un archivo o directorio.

Protocolo de transferencia de hipertexto (HTTP): protocolo de comunicaciones que se utiliza para la conexión con servidores en Internet.

Protocolo ligero de acceso a directorio (LDAP): protocolo de acceso a la información estándar de la industria que se ejecuta directamente mediante TCP/IP. Es el protocolo de acceso primario para Active Directory y para los servidores de directorio basados en LDAP. La versión 3 de LDAP se define mediante un conjunto de documentos estándar propuestos en Internet Engineering Task Force (IETF) RFC 2251.

Protocolo seguro de transferencia de hipertexto (HTTPS): HTTP por medio de SSL. Todo el tráfico de red entre el cliente y el sistema de servidores está encriptado. Además, es posible verificar las identidades del servidor y del cliente. Por lo general, las identidades del servidor se verifican, no así las identidades del cliente.

Protocolo simple de administración de redes (SNMP): método utilizado para comunicar información de administración entre las estaciones de administración de redes y los agentes en los elementos de red.

Secure Socket Layer (SSL): protocolo de seguridad que proporciona encriptación y autenticación. Encripta datos y proporciona autenticación de mensajes y servidores. También soporta autenticación de clientes, si el servidor así lo requiere.

Seguridad de capa de transporte (TLS): protocolo sucesor de SSL para la autenticación y encriptación de comunicaciones generales por medio de redes TCP/IP. La versión 1 de TLS es prácticamente idéntica a la versión 3 de SSL.

Servidor de directorios: servidor que almacena y organiza información sobre los recursos y usuarios de la red de un equipo y que permite a los administradores de red administrar el acceso de los usuarios a los recursos. X.500 es el servicio de directorios abierto más conocido. Los servicios de directorio de propietarios incluyen Active Directory de Microsoft.

X.509: estándar de uso frecuente para definir certificados digitales.


Información relacionada Para obtener información específica relacionada con las características y funcionalidades que se describen en este documento, consulte:

◆ Manual de referencia de comandos de EMC Celerra Network Server

◆ Páginas de los manuales en línea de Celerra

◆ EMC Celerra Network Server Parameters Guide

◆ Installing EMC Celerra Management Applications

◆ Configuring NFS on EMC Celerra

◆ Configuración de NFS en EMC Celerra

◆ Administración de EMC Celerra para un entorno de múltiples protocolos

◆ Configuring EMC Celerra Naming Services

◆ Uso de EMC Celerra FileMover

◆ Configuración de eventos y notificaciones de EMC Celerra

◆ Nota técnica Auditing in the Celerra Control Station

◆ Nota técnica Celerra Network Server on the Enterprise Network

El EMC Celerra Network Server Documentation CD, suministrado con Celerra y también disponible en Powerlink®, proporciona un conjunto completo de publicaciones de clientes de EMC Celerra. Inicie sesión en Powerlink, vaya a Soporte > Documentación Técnica y Asesorías > Documentación de Hardware y Plataformas > Celerra Network Server. En esta página, haga clic en Agregar a Favoritos. La sección Favoritos de la página principal de Powerlink contiene un enlace que lo lleva directamente a esta página.

Para obtener información general sobre LDAP, consulte:

◆ RFC 2307, An Approach for Using LDAP as a Network Information Service.

Para obtener información específica sobre la configuración de LDAP y SSL de Active Directory, consulte:

◆ El artículo de la base de conocimientos de Microsoft Cómo habilitar LDAP sobre SSL con una entidad de certificación de terceros (ID 321051).

Para obtener información específica sobre la configuración de OpenLDAP y SSL, consulte el sitio Web de OpenLDAP (www.openldap.org). Si está utilizando un servidor de directorios basado en LDAP distinto de Active Directory, consulte la documentación del proveedor para obtener información sobre la configuración de LDAP y SSL.

../CommandReference/index.htm

../Parameters/index.htm

../InstallationManagement/index.htm

../ConfWindows/index.htm

../CgNFS/index.htm

../ConfWinMulti/index.htm

../FileMover/index.htm

../EventsandNotifications/index.htm

http://powerlink.emc.com


Conceptos Las sólidas funciones de seguridad del sistema son cada vez más necesarias para cumplir con las nuevas reglamentaciones y garantizar una mayor protección contra ataques al sistema. Celerra implementa varias funciones tanto en la Control Station como en los Data Movers para proteger la infraestructura, controlar el acceso y proteger los datos.

En la Control Station:

◆ Para proteger la infraestructura, Celerra ofrece diversas funciones que se pueden utilizar para ajustar el funcionamiento de la Control Station. La Tabla 2 en la página 8 describe estas funciones.

◆ Para proteger los recursos del sistema contra el acceso no autorizado, Celerra soporta la identificación y la autenticación estricta de usuarios administrativos, el acceso administrativo basado en funciones y las políticas de contraseñas definidas por el cliente. La Tabla 3 en la página 10 describe estas funciones.

◆ Para soportar la transmisión de datos encriptados, Celerra soporta el protocolo de seguridad SSL. La Tabla 4 en la página 12 describe esta función.

En Data Movers:

◆ Para proteger la infraestructura, Celerra ofrece diversas funciones que se pueden utilizar para ajustar el funcionamiento de los Data Movers. La Tabla 5 en la página 13 describe estas funciones.

◆ Para proteger la transmisión de datos encriptados, Celerra soporta el protocolo de seguridad SSL y la administración de certificados de claves públicas para ciertos protocolos. La Tabla 6 en la página 15 describe estas funciones.

Si bien muchas de estas funciones requieren configuración y administración explícitas, se incluyeron otras funciones como cambios básicos del funcionamiento del software. Por ejemplo, con la versión 5.6 de Celerra, se implementaron los siguientes cambios:

◆ Se mejoró la seguridad entre un usuario y Celerra Manager, y entre dos Control Stations al cambiar la checksum utilizada para iniciar el tooken de sesión (cookie) de MD5 a SHA1. SHA1 produce un valor hash de 160 bits, a diferencia de MD5, que produce un valor hash de solo 128 bits.

◆ Se quitaron puertos dinámicos y servicios innecesarios del sistema operativo Linux de la Control Station.

Nota: Muchas de las funciones de seguridad de Celerra se describen en otros documentos de la biblioteca, según se indica en las tablas de visión general. Por lo tanto, este documento incluye procedimientos de configuración detallados únicamente para un subconjunto de funciones de seguridad disponibles.


Tabla 2 Visión general de las funciones de la Control Station utilizadas para proteger la infraestructura (página 1 de 2)

Función Descripción Restricciones Más información

Tiempo de espera de sesión agotado

Celerra agota el tiempo de espera de las sesiones administrativas iniciadas desde las shells de Control Station y Celerra Manager. El tiempo de espera de las sesiones finaliza después de un período de inactividad especificado.

El tiempo de espera de las sesiones se encuentra activado de forma predeterminada.

Para modificar las propiedades de la Control Station, debe iniciar sesión como root.

Para administrar el tiempo de espera de las sesiones shell, use el comando /nas/sbin/ nas_config -sessiontimeout. "Configuración del tiempo de espera de las sesiones" en la página 34 describe cómo configurar esta función.

Para administrar el tiempo de espera de las sesiones de Celerra Manager, seleccione Celerras > [Celerra_name] > Security > Celerra Manager. Puede encontrar una descripción de esta función en la ayuda en línea de Celerra Manager.

Banner de inicio de sesión y mensaje del día (MOTD)

Un banner de inicio de sesión y un mensaje del día (MOTD) permiten al administrador comunicarse con los usuarios administrativos de Celerra.

El mismo banner de inicio de sesión y el MOTD se ven en la interfaz de línea de comandos y en Celerra Manager.


Para configurar el banner y el MOTD mediante Celerra Manager, seleccione Celerras > [Celerra_name] > Control Station Properties. Puede encontrar una descripción de esta función en la ayuda en línea de Celerra Manager.

Para configurar el banner y el MOTD mediante CLI, use un editor de texto para editar los archivos /etc/issue o /etc/motd. "Personalización de un banner de inicio de sesión" en la página 36 y "Creación de un mensaje del día (MOTD)" en la página 37 describen cómo configurar estas funciones.

Administración de servicios de red

En Celerra Manager, se puede ver el estado actual de algunos servicios de red (y los protocolos y puertos de comunicación asociados) de la Control Station. Estos servicios se pueden activar, desactivar y monitorear. Para mejorar la seguridad de Celerra, debe restringir el acceso a Celerra mediante la desactivación de los servicios de red que no se utilizan en el entorno.


Para administrar los servicios de red mediante Celerra Manager, seleccione Celerras > [Celerra_name] > Security > Network Services. Puede encontrar una descripción de esta función en la ayuda en línea de Celerra Manager.


Tokens de sesión (cookies)

Celerra utiliza SHA1 para generar checksums a fin de proteger los tokens de sesión (cookies) que se usan con el objetivo de identificar a los usuarios después de que inician sesión. Para mejorar la seguridad, puede cambiar el valor secreto predeterminado de SHA1 que se emplea para generar las checksums.

Cuando modifica este valor, los tokens de sesión (cookies) existentes pierden validez y los usuarios actuales de Celerra Manager deben iniciar sesión nuevamente.


Para administrar los tokens de sesión (cookies), edite el archivo /nas/http/conf/secret.txt. "Protección de tokens de sesión" en la página 38 describe cómo configurar esta función.

Auditoría Celerra proporciona comandos y archivos de configuración para capturar las actividades de administración iniciadas desde la Control Station, específicamente el acceso a los archivos clave del sistema y a los datos de los usuarios finales.


La nota técnica Auditing in the Celerra Control Station, disponible en EMC Powerlink, proporciona información específica sobre la implementación de la auditoría.

Tabla 2 Visión general de las funciones de la Control Station utilizadas para proteger la infraestructura (página 2 de 2)



Tabla 3 Visión general de las funciones de la Control Station utilizadas para controlar el acceso (página 1 de 2)


Identificación y autenticación de usuarios administrativos

Las cuentas de usuario administrativo únicas permiten una administración más segura de Celerra. Las cuentas de usuario administrativo pueden ser una cuenta de usuario local o una cuenta de usuario local asignada a una cuenta de dominio.

Las cuentas de usuario administrativo asignadas por dominio requieren que Celerra tenga acceso a un servidor de directorios basado en LDAP. Esto puede significar la configuración del acceso a un servidor de directorios Active Directory o a otro, como OpenLDAP o iPlanet.

Los usuarios administrativos pueden administrarse solo mediante Celerra Manager.

Los comandos de Linux disponibles en CLI (useradd, userdel, usermod, groupadd, groupmod y groupdel) no soportan el acceso administrativo basado en funciones de Celerra y no deben utilizarse para administrar las cuentas de usuario y de grupos.

Para crear una nueva cuenta de usuario administrativo, debe ser un usuario root o administrativo con privilegios root o de operador de seguridad.

"Consideraciones de planificación para la identificación y autenticación de usuarios administrativos" en la página 16 describe los conceptos relacionados con esta función.

Para crear y administrar usuarios administrativos con Celerra Manager, seleccione Celerras > [Celerra_name] > Security > Administrators. Puede encontrar una descripción de esta función en la ayuda en línea de Celerra Manager.

"Consideraciones de planificación para usar un servidor de directorios externo para identificación y autenticación de usuarios administrativos" en la página 19 describe cómo Celerra interactúa con el servidor de directorios basado en LDAP, y "Configuración del uso de un servidor de directorios externo para identificación y autenticación de usuarios administrativos" en la página 29 describe cómo configurar esta función.

Acceso administrativo basado en funciones

Esta función permite asignar privilegios adecuados a los usuarios administrativos según sus responsabilidades. Por lo tanto, simplifica la interfaz de Celerra Manager para los usuarios administrativos al limitar las operaciones que pueden efectuar y protege los datos del sistema y del cliente de las operaciones realizadas por usuarios administrativos que no deberían llevarlas a cabo.

Una función define los privilegios (lectura, modificación o control completo) que puede realizar sobre un objeto de Celerra en particular. Celerra ofrece tanto funciones predefinidas como personalizadas.

En Celerra 5.6, no se proporciona soporte para las funciones de usuarios administrativos cuando utilizan CLI.

Para asignar funciones, debe ser un usuario root o administrativo con privilegios root o de operador de seguridad.

"Consideraciones de planificación para el acceso administrativo basado en funciones" en la página 21 describe los conceptos relacionados con esta función.

Para crear y administrar el acceso administrativo basado en funciones con Celerra Manager, seleccione Celerras > [Celerra_name] > Security > Administrators. Puede encontrar una descripción de esta función en la ayuda en línea de Celerra Manager.


Política de calidad de las contraseñas

Una contraseña segura es un elemento importante de una estrategia de seguridad. Celerra impone varios requisitos para garantizar una política de calidad de las contraseñas.

Esta función define los requisitos de complejidad de las contraseñas para todos los usuarios administrativos. Esta función no se aplica a los usuarios asignados por dominio, cuyas contraseñas se rigen por políticas dentro del dominio.

Para definir la política de calidad de las contraseñas, debe iniciar sesión como usuario root.

"Consideraciones de planificación para la seguridad de las contraseñas" en la página 25 describe los elementos de una política de calidad de las contraseñas.

Para definir la política de calidad de las contraseñas, use el comando /nas/sbin/ nas_config -password. "Configuración de la política de contraseñas" en la página 32 describe cómo configurar esta función.

Tabla 3 Visión general de las funciones de la Control Station utilizadas para controlar el acceso (página 2 de 2)



Tabla 4 Visión general de las funciones de la Control Station utilizadas para proteger datos


Certificados SSL (X.509) para Celerra Manager

Celerra Manager utiliza encriptación y autenticación de SSL para proteger la conexión entre el navegador Web del usuario y el servidor Web Apache de Celerra. SSL utiliza certificados digitales, cuya autenticidad está comprobada por una CA, para identificar y autenticar el servidor.

A partir de la versión 5.6, el software Celerra genera automáticamente el certificado de CA y un nuevo certificado Apache firmado por dicho certificado de CA en la instalación del sistema o en la actualización del software si estos certificados aún no existen.

En el caso de Celerra Manager, la Control Station funciona como una CA con propósito limitado, que firma el certificado proporcionado por el servidor Web Apache.

Si cambia el nombre de host de Celerra, deberá generar nuevamente la CA de la Control Station y los certificados Apache. Cuando se genera un nuevo certificado de CA, también se genera un certificado Apache coincidente.

Si solo cambia el nombre de dominio o la dirección IP de Celerra, puede volver a generar únicamente el certificado del servidor Web Apache.

Una vez que vuelve a generar los certificados, los navegadores o los sistemas que utilizaban los certificados anteriores deben instalar los certificados nuevos.


Installing EMC Celerra Management Applications describe cómo configurar esta función.

El white paper de Celerra Uso de Celerra Manager en su entorno de navegación Web: configuración de navegadores y seguridad para mejorar su experiencia, disponible en EMC Powerlink, proporciona información sobre cómo y por qué instalar los certificados.

Encriptación y autenticación de redes mediante LDAP sobre SSL

Celerra soporta la encriptación y la autenticación de SSL en la conexión LDAP entre la Control Station y el servidor de directorios basado en LDAP.

"Consideraciones de planificación para usar un servidor de directorios externo para identificación y autenticación de usuarios administrativos" en la página 19 describe cómo Celerra interactúa con el servidor de directorios basado en LDAP, y "Configuración del uso de un servidor de directorios externo para identificación y autenticación de usuarios administrativos" en la página 29 describe cómo configurar esta función.


Tabla 5 Visión general de las funciones de los Data Movers que se utilizan para proteger la infraestructura (página 1 de 2)


Administración de servicios de red

En Celerra Manager, se puede ver el estado actual de algunos servicios de red (y los protocolos y puertos de comunicación asociados) de los Data Movers. Estos servicios se pueden activar, desactivar y monitorear. Para mejorar la seguridad de Celerra, debe restringir el acceso a Celerra mediante la desactivación de los servicios de red que no se utilizan en el entorno, como el FTP.

Algunos servicios que se ejecutan en los Data Movers deben reiniciarse para que se apliquen los cambios.

Para administrar los servicios de red mediante Celerra Manager, seleccione Celerras > [Celerra_name] > Security > Network Services. Puede encontrar una descripción de esta función en la ayuda en línea de Celerra Manager.

Autenticación Kerberos de CIFS

Dado que Kerberos es ahora el método de autenticación recomendado en entornos Windows, es posible que desee desactivar la autenticación NTLM. (Como opción predeterminada, Celerra permite la autenticación Kerberos y NTLM).

Para establecer el modo de autenticación del servidor CIFS solo en Kerberos, use el comando server_cifs <movername> -add compname=<comp_name>, domain=<full_domain_name>, authentication=kerberos.

La página principal de server_cifs man describe cómo configurar estas opciones. Configuring NFS on EMC Celerra describe el proceso de autenticación.

Configuración de seguridad NFS

Si bien, por lo general, se considera a NSF como un protocolo de uso compartido de archivos vulnerable, se puede lograr que este sea más seguro mediante la siguiente configuración:

• Definir acceso de solo lectura para algunos hosts (o todos).

• Limitar el acceso a la raíz de subredes o sistemas específicos.

Asimismo, si se requiere una autenticación sólida, puede configurar Secure NFS, que utiliza Kerberos.

Configuración de NFS en EMC Celerra describe cómo configurar estas opciones.


Políticas de acceso El conjunto de modos de acceso personalizables de Celerra permite elegir la mejor interacción posible entre el acceso CIFS y NSF para su entorno.

Puede seleccionar la forma de mantenimiento de los atributos y el tipo de interacción entre los usuarios de NFS y CIFS, que incluyen:

• Separado• CIFS dominante• NFS dominante• Igual • Combinado (se utiliza para

alcanzar un alto nivel de sincronización entre los dos protocolos).

Se requiere la política de acceso combinado cuando se utiliza NFSv4.

Administración de EMC Celerra para un entorno de múltiples protocolos describe cómo configurar esta función.

Credenciales estilo Windows (NT) para usuarios UNIX

Celerra permite crear una credencial estilo Windows (NT) común. Por lo tanto, los usuarios tienen las mismas credenciales sin importar el protocolo de acceso a los archivos, lo que proporciona un control de acceso más consistente.

Administración de EMC Celerra para un entorno de múltiples protocolos describe cómo configurar esta función.

Administración de SNMP La cadena de la comunidad de SNMP proporciona la base para la seguridad en SNMP. El nombre predeterminado de la comunidad es el conocido nombre public. Este nombre debe modificarse a fin de impedir el acceso no deseado a Celerra.

Use el comando server_snmp -community para asignar un nuevo valor a una comunidad del agente SNMP del servidor para un Data Mover.

SNMP se utiliza para la comunicación entre la Control Station y el Data Mover, por lo tanto, si se desactiva, puede interferir con algunas funciones. Por ejemplo, el comando server_netstat no funcionará.

Configuración de eventos y notificaciones de EMC Celerra describe cómo configurar esta función.

Tabla 5 Visión general de las funciones de los Data Movers que se utilizan para proteger la infraestructura (página 2 de 2)



Tabla 6 Visión general de las funciones del Data Mover utilizadas para proteger datos


Encriptación y autenticación de redes mediante SSL

Celerra soporta la encriptación y la autenticación de SSL para las conexiones LDAP y HTTP entre Data Movers y varios servicios externos.

Solo se puede configurar y administrar SSL en conexiones de Data Movers mediante CLI.

"Configuración de la encriptación y la autenticación de redes mediante el protocolo SSL" en la página 39 describe cómo configurar los parámetros asociados con esta función.

Configuring EMC Celerra Naming Services y Uso de EMC Celerra FileMover describen cómo configurar y administrar SSL para estas funciones.

Certificados de claves públicas

El entorno de PKI proporciona los sistemas de bases de datos y administración de software necesarios para soportar el uso de certificados digitales para conexiones LDAP y HTTP del Data Mover donde el SSL se encuentra activado.

El entorno de PKI de Celerra soporta solamente los certificados de claves públicas X.509.

"Consideraciones de planificación para la Infraestructura de claves públicas (PKI)" en la página 26 describe los conceptos relacionados con esta función.

"Configuración de PKI" en la página 42 y "Administración de la PKI" en la página 56 describen cómo configurar y administrar esta función mediante CLI.

Para configurar y administrar la PKI con Celerra Manager, seleccione Celerras > [Celerra_name] > Security > Public Key Certificates. Puede encontrar una descripción en la ayuda en línea de Celerra Manager.


Consideraciones de planificación para la identificación y autenticación de usuarios administrativos La creación de usuarios administrativos únicos, cada uno con los privilegios adecuados según sus responsabilidades, simplifica la administración de Celerra mediante la limitación de las operaciones que los usuarios administrativos pueden efectuar y, además, protege los datos del sistema y del cliente de las operaciones realizadas por usuarios administrativos que no deberían llevarlas a cabo.

La función de administrador permite definir:

◆ Usuarios administrativos

◆ Grupos según los cuales se puede organizar usuarios

◆ Funciones que pueden asociarse con grupos

◆ Privilegios que definen funciones para obtener acceso a todos los objetos de Celerra y controlarlos

La función de administradores también ofrece la posibilidad de usar un servidor de directorios externo como catálogo centralizado de cuentas de usuario y simplificar así la administración.

Nota: Los usuarios administrativos pueden acceder al sistema Celerra mediante CLI, Celerra Manager o la API de XML. En Celerra 5.6, la asociación de privilegios específicos con estos usuarios, también denominados funciones, solo se soporta para usuarios administrativos que tengan acceso a Celerra por medio de Celerra Manager y la API de XML y para usuarios administrativos que utilizan comandos CLI específicos. Si un usuario administrativo específico necesita control de acceso basado en funciones, no le proporcione acceso a Celerra mediante CLI.

Nota: Esta función es distinta del soporte de control de acceso de la Control Station existente que se administra con el comando nas_acl.

Usuarios administrativosCelerra proporciona dos cuentas de usuario administrativo predeterminadas: root y nasadmin. Puede crear usuarios administrativos adicionales, cada uno con privilegios adecuados según sus responsabilidades.

Usuarios administrativos predeterminados

Puede usar las cuentas de usuario predeterminadas (root y nasadmin) para iniciar sesión en CLI y Celerra Manager. El usuario root puede acceder a cada objeto y acción de Celerra, y controlarlos. El usuario nasadmin tiene el mismo acceso y control que el usuario root, con algunas excepciones.

Debe ser un usuario root para poder ejecutar algunos comandos u opciones de comandos en CLI. Por lo general, estos comandos requieren experiencia especial, son potencialmente destructivos y solo se utilizan en circunstancias especiales. La Tabla 7 en la página 17 muestra estos comandos.


En Celerra Manager, debe ser usuario root para configurar y modificar algunas funciones. La Tabla 8 en la página 17 muestra estas funciones.

"Consideraciones de planificación para el acceso administrativo basado en funciones" en la página 21 proporciona más información sobre cómo los usuarios root y nasadmin se ven afectados por el control basado en funciones.

Tabla 7 Comandos que solo pueden ejecutar los usuarios root

Directorio Comandos

/nas/bin fs_ckpt fs_timefinder nas_acl nas_cel nas_devicegroup nas_fs nas_server nas_storage nas_volume

/nas/sbin cs_standby nas_ca_certificate nas_config nas_connecthome nas_halt nas_mview nas_rdf server_user

Tabla 8 Funciones de Celerra Manager que solo pueden administrar los usuarios root

Función Con acceso desde

Propiedades de Control Station Celerra Home > Control Station Properties

Tiempo de espera de sesión agotado Security > Celerra Manager

Servicios de red Security > Network Services

Connect Home Support > Connect Home

Comandos CLI (algunos comandos de Celerra y también de Linux)

Comandos CLI

Asistente de configuración de Celerra Asistentes

Contraseña entre Control Stations Replications > Celerra Network Servers


Creación de nuevos usuarios administrativosPuede crear nuevas cuentas de usuarios administrativos mediante la página Administrators > Users > New User en Celerra Manager. La ayuda en línea de Celerra Manager ofrece una explicación detallada de este procedimiento.

Nota: En Celerra 5.6, ya no se pueden crear cuentas de usuario administrativo mediante CLI. Los comandos de Linux anteriormente utilizados en CLI para administrar cuentas de usuario y de grupos (useradd, userdel, usermod, groupadd, groupmod y groupdel) no soportan el acceso administrativo basado en funciones de Celerra y ya no definirán entradas reconocidas por el software Celerra.

Para crear una nueva cuenta de usuario administrativo, debe ser un usuario root o administrativo con privilegios root o de operador de seguridad. "Consideraciones de planificación para el acceso administrativo basado en funciones" en la página 21 describe cómo se asignan y se usan estos privilegios.

Cuentas de usuario locales versus cuentas de usuario asignadas por dominioLas cuentas de usuario administrativo pueden ser una cuenta de usuario local o una cuenta de usuario local asignada a una cuenta de dominio. Una cuenta de usuario asignada por dominio utiliza el nombre de usuario y la contraseña especificados en el servidor de dominio. Este tipo de cuenta de usuario siempre se autentica en el servidor de dominio. Si el servidor de dominio no está disponible, el usuario no puede iniciar sesión.

El mapping de usuarios a cuentas de usuario locales proporciona el mecanismo para verificar que un usuario autenticado por un servidor de directorios externo está autorizado para acceder a Celerra, y que el usuario tiene las credenciales locales necesarias, incluido el UID, para realizar tareas.

Celerra proporciona la posibilidad de crear automáticamente cuentas de usuario locales para usuarios de dominio. Una vez habilitada, la cuenta de usuario local se establece para cualquier usuario asignado por dominio que pueda autenticarse correctamente en el servidor de dominio y que pertenezca a al menos un grupo reconocido por el sistema Celerra. El nombre de la cuenta local de la cuenta del usuario de dominio será el nombre del usuario de dominio seguido del nombre de dominio (por ejemplo, joe.corp). Si el nombre ya existe en el sistema local, se anexará un número al nombre de usuario (por ejemplo, joe1.corp). El número anexado es el siguiente número de la secuencia que no se haya utilizado.

Especificación de acceso a Celerra para el usuario administrativoLos usuarios administrativos pueden acceder al sistema Celerra por medio de la interfaz de línea de comandos (CLI) del shell de Control Station, Celerra Manager o la API de XML.

Nota: La API de XML permite crear su propia GUI u otro tipo de interfaz de administración. Al igual que Celerra Manager y determinados comandos CLI, la API de XML utiliza la interfaz de software de Celerra entre la capa de presentación de la interfaz de usuario Web y el código principal de Control Station, conocida como la capa del dispositivo o APL. En consecuencia, se debe habilitar específicamente el acceso a Celerra por medio de la API de XML.

Cuando crea un nuevo usuario administrativo, debe especificar el tipo de acceso a Celerra que tiene el usuario. De manera predeterminada, un nuevo usuario administrativo no tiene acceso.

Cuando se crea una cuenta de usuario local automáticamente para un usuario asignado por dominio, el nuevo usuario recibe acceso a Celerra Manager y a la API de XML de manera predeterminada.


Consideraciones de planificación para usar un servidor de directorios externo para identificación y autenticación de usuarios administrativosUn servidor de directorios externo puede identificar y autenticar una cuenta de usuario administrativo cuando el usuario inicia sesión en la Celerra Control Station. El servidor de directorios externo proporciona un catálogo centralizado de cuentas de usuario, lo que simplifica la administración.

El servidor de directorios externo puede ser un servidor Active Directory basado en LDAP o un servidor distinto de Active Directory:

◆ Active Directory es un servicio de directorios basado en LDAP que se utiliza en Windows 2000 y Windows Server 2003 que proporciona administración de cuentas de usuario y de grupos, seguridad y recursos distribuidos.

◆ OpenLDAP e iPlanet (también conocido como Sun Java System Directory Server y Sun ONE Directory Server) son servidores de directorios distribuidos basados en LDAP que proporcionan un catálogo central para almacenar y administrar perfiles de identidad, privilegios de acceso e información sobre recursos de redes y aplicaciones.

Comprensión del servidor de directorios Un servidor de directorios basado en LDAP organiza la información en una estructura jerárquica de directorios de acuerdo con las necesidades de una organización en particular. Cada objeto almacenado en el directorio está representado por una entrada de directorio. Una entrada está conformada por uno o varios atributos. Los atributos de una entrada definen exclusivamente a dicha entrada. Las entradas se almacenan de forma jerárquica en el árbol de directorios. Gracias a LDAP, es posible consultar una entrada y solicitar todas las entradas y sus atributos debajo de la entrada solicitada.

Un ejemplo de una estructura de directorios basado en LDAP es el siguiente:dc=mycompany,dc=com ou=people ou=group ou=hosts ou=netgroup

dc= indica componentes del dominio y ou= indica unidades organizacionales compuestas de personas, grupos, hosts y grupos de red. Por lo general, el atributo cn se utiliza para indicar el nombre mediante el cual se conoce una entrada en particular.

La estructura de directorios puede cambiarse. Por ejemplo, la información de los usuarios puede almacenarse en un contenedor denominado usuarios en lugar de personas, y los hosts en un contenedor llamado equipos en vez de hosts. Debe trabajar junto con el administrador del servidor de directorios basado en LDAP para comprender la estructura de directorios de la organización y comprobar que se hayan definido las entradas necesarias.

Configuración del acceso Para configurar el cliente basado en LDAP de la Control Station, debe contar con la siguiente información:

◆ Nombre de dominio: indica la raíz del árbol de directorios LDAP, es decir, en qué lugar del árbol de directorios LDAP se comienza a buscar la información. También se lo conoce como el nombre distinguido de la base.


Por ejemplo, el nombre distinguido de la base para la estructura de directorios basados en LDAP de ejemplo es dc=mycompany,dc=com. Active Directory asume que el tipo de atributo es dc para que el nombre distinguido de la base pueda expresarse simplemente como mycompany.com.

Nota: Celerra soporta solo un único dominio LDAP. No soporta árboles ni bosques. En consecuencia, no se siguen las referencias a otros dominios.

◆ Nombre distinguido de vinculación: indica la identidad utilizada para vincularse con el servicio LDAP, es decir, el usuario o la cuenta que tiene permitido buscar en el directorio LDAP dentro de la base de búsqueda definida.

Por lo general, Active Directory asume un nombre distinguido de vinculación con el formato cn=<acctname>,cn=users,dc=<domain component>,dc=<domain component>.

Nota: El administrador de Active Directory puede crear usuarios en otras ubicaciones dentro de Active Directory, en cuyo caso el path del nombre distinguido de vinculación puede ser distinto.

Un servidor de directorios OpenLDAP acepta distintos formatos de nombre distinguido de vinculación, como cn=<acctname>,uid=<name>,ou=people,dc=<domain component>,dc=<domain component> o uid=<name>,dc=users,dc=<domain component>,dc=<domain component>.

◆ Atributo de nombre y path de búsqueda de usuario: indica la rama de directorio en la que Celerra buscará una instancia del atributo de nombre cuyo valor es el nombre de cuenta del usuario.

Por lo general, Active Directory asume un atributo de nombre y path de búsqueda de usuario con el formato cn=<acctname>,cn=users,dc=<domain component>,dc=<domain component>.

Nota: El administrador de Active Directory puede crear usuarios en otras ubicaciones dentro de Active Directory, en cuyo caso el path de búsqueda de usuario puede ser distinto.

Un servidor de directorios OpenLDAP acepta distintos formatos de nombre distinguido de vinculación, como uid=<name>,ou=people,dc=<domain component>,dc=<domain component> o uid=<name>,dc=users,dc=<domain component>,dc=<domain component>.

◆ Path de búsqueda de grupo, atributo de nombre, y miembro y clase de grupo: indica la rama de directorio en la que Celerra buscará una instancia del atributo cuyo valor sea el nombre de grupo del usuario. El grupo puede especificarse mejor al identificar la clase en la que se almacena el grupo y el atributo de dicha clase.

Active Directory asume un atributo de nombre y un path de búsqueda de grupo de cn=<acctname>,cn=users,dc=<domain component>,dc=<domain component>. En Active Directory, los grupos y los usuarios se almacenan en la misma jerarquía. La clase de grupo se denomina group y el valor de atributo predeterminado es member.


Nota: El administrador de Active Directory puede crear grupos en otras ubicaciones dentro de Active Directory, en cuyo caso el path de búsqueda de grupo puede ser distinto.

En otros servidores de directories, la clase puede ser posixGroup, groupOfNames o groupOfUniqueNames. Si el valor de clase de grupo es groupOfUniqueNames, el valor de atributo predeterminado es uniqueMember. Si el valor de clase de grupo es groupOfNames, el valor de atributo predeterminado es member. Si el valor de clase de grupo es posixGroup, el valor de atributo predeterminado es memberUid.

Conexión al servidor de directorios mediante SSLPara proteger el tráfico LDAP y mejorar la seguridad de las aplicaciones de servidores y de clientes, el servidor de directorios basado en LDAP puede soportar el uso de SSL y, en algunos casos, requerirlo. SSL proporciona capacidades de encriptación y autenticación. Encripta datos en la red y proporciona autenticación de mensajes y servidores. También soporta autenticación de clientes, si el servidor así lo requiere. SSL utiliza certificados digitales, cuya autenticidad está comprobada por una CA.

El cliente LDAP, mediante el cliente SSL subyacente, autentica el certificado que recibe del servidor de directorios basado en LDAP. Para que la comprobación del certificado se realice correctamente, el certificado de CA (para la CA que firmó el certificado del servidor de directorios) debe haberse importado en la Control Station. Además, el asunto del certificado del servidor debe contener el nombre de host o la dirección IP del servidor. De lo contrario, la comprobación del certificado no se llevará a cabo correctamente.

Nota: La implementación de clientes basados en LDAP de la Control Station no soporta la autenticación de clientes basados en SSL.

"Configuración del uso de un servidor de directorios externo para identificación y autenticación de usuarios administrativos" en la página 29 describe cómo configurar esta función.

Consideraciones de planificación para el acceso administrativo basado en funcionesUna cuenta de usuario administrativo siempre se asocia con un grupo primario y se asigna una función a cada grupo. Una función define los privilegios (es decir, las operaciones) que el usuario administrativo puede realizar sobre un objeto de Celerra en particular. A partir de la versión Celerra 5.6, es necesario tener los privilegios adecuados para acceder a todos los objetos de Celerra y controlarlos.

Grupos y funciones Una cuenta de usuario administrativo siempre está asociada con un grupo primario. También puede asociarse con otros grupos, hasta un máximo de 17. Al igual que las cuentas de usuario, los grupos pueden ser un grupo local o un grupo local asignado a un grupo de dominios.


Celerra ofrece tanto grupos predefinidos como personalizados. Los grupos predefinidos no pueden modificarse ni eliminarse. Se asigna a cada grupo una función. Solo se puede asignar una función por vez a un grupo, aunque se puede asociar una función con muchos grupos. Si no se asigna una función a un grupo, el grupo recibe la función predeterminada de operador, que solo tiene privilegios de lectura. La Tabla 9 en la página 22 muestra los grupos predefinidos y sus funciones asociadas.

Un usuario administrativo puede tener múltiples funciones si pertenece a múltiples grupos. En este caso, una unión de estas funciones determina las operaciones que el usuario administrativo puede realizar.

Funciones y privilegiosUna función define los privilegios (las operaciones) que un usuario administrativo puede realizar en un objeto de Celerra en particular. Existen tres niveles de privilegios:

◆ Lectura: permite a un usuario administrativo ver objetos. De manera predeterminada, todos los usuarios administrativos tienen privilegios de lectura en todos los objetos.

◆ Edición: permite a un usuario administrativo realizar cambios en un objeto.

◆ Control completo: permite a un usuario administrativo crear y eliminar objetos, y realizar cambios significativos. De manera predeterminada, todos los usuarios administrativos tienen control completo del objeto de la tarea.

Celerra ofrece tanto funciones predefinidas como personalizadas. Las funciones predefinidas (también identificadas como funciones del sistema) no pueden modificarse. Las funciones personalizadas (también identificadas como funciones de usuario) son funciones definidas por los administradores.

Las funciones predefinidas (y los objetos de Celerra sobre los que estas funciones tienen privilegios de edición o control completo) son:

Tabla 9 Grupos predefinidos y sus funciones asociadas

Nombre del grupo Función asociada

backup backup_operator

fullnas nasadmin

nasadmin operator

network network_admin

opadmin operator

root root

security security_operator

storage storage_admin


Funciones predefinidas Descripción

Objetos para los que la función tiene privilegios de edición

Objetos para los que la función tiene control completo

root función root del sistema Licencias Log Collection & Transfer Network Services

Todos los objetos

Nota: Para tener control completo sobre las propiedades de Control Station y Connect Home, debe haber iniciado sesión como usuario root. Un usuario a quien se le asignaron privilegios root no tiene control completo sobre estos objetos.

nasadmin función de administrador estándar

Licencias Log Collection & Transfer Network Services Replication

Todos los objetos excepto:

Control Station Connect Home Administrative Access (administración de usuarios solamente)

operador de seguridad operador de seguridad con acceso a administrador de funciones y administración de usuarios/grupos

Licencias Administrative Access Certificados de claves públicas

operador de backup función de operador de backup con acceso completo a ckpt y VTLU

n/d Checkpoints VTLU

filemover_application función de la aplicación FileMover

n/d FileMover

administrador de red función de administrador de red

n/d Devices Interfaces NIS DNS Routing

administrador de almacenamiento

función de administración de almacenamiento

n/d Pools Volumes File Systems Quotas Migration FileMover Storage Systems

operator función de operador estándar n/d n/d


Privilegios de usuario predeterminadosLa cuenta de usuario root tiene su membresía de grupo primario en el grupo root asociado con la función root.

Nasadmin de cuenta de usuario tiene su membresía de grupo primario en el grupo nasadmin asociado con la función de operador para acceso de solo lectura. Además, es un miembro del grupo fullnas, asociado con la función nasadmin para acceso de edición y control completo a prácticamente todos los objetos de Celerra.

De manera predeterminada, se asigna un nuevo usuario administrativo al grupo nasadmin, lo que significa que el usuario solo tiene privilegios de lectura.

Nota: En la función de acceso administrativo basada en funciones, el grupo nasadmin se asocia con la función de operador más restrictiva. Puede acceder a los privilegios más amplios anteriormente asociados con la cuenta de usuario nasadmin predeterminada mediante la membresía en el grupo fullnas.

Qué sucede una vez asignadas las funcionesUn usuario administrativo debe tener los privilegios adecuados para acceder a objetos de Celerra y controlarlos.

Uso de Celerra Manager

Si un usuario administrativo utiliza Celerra Manager para acceder al sistema Celerra y ese usuario no está autorizado para realizar una determinada función, esa función estará atenuada y no disponible. Esto puede suceder en menús, botones y campos.

Uso de CLI

Nota: En Celerra 5.6, la mayoría de los comandos CLI no soportan privilegios o funciones. Por lo tanto, no puede limitar los privilegios de un usuario administrativo que utiliza CLI. En consecuencia, los usuarios administrativos que usan CLI continúan teniendo al menos todos los privilegios asociados con la función nasadmin. Si desea crear usuarios administrativos con funciones más limitadas que nasadmin, debe permitir a estos usuarios el acceso a Celerra solo mediante Celerra Manager.

En la versión 5.6, los privilegios y las funciones se implementan solo para cuatro comandos CLI:

◆ nas_ckpt_schedule

◆ nas_copy

◆ nas_replicate

◆ nas_task

Para ejecutar algunas de las opciones de estos comandos o todas ellas, se le debe asignar al usuario administrativo una función que proporcione privilegios de control completo sobre el objeto Replication. Las descripciones de comandos individuales proporcionan información detallada sobre los privilegios que se necesitan para ejecutar varias opciones.


Consideraciones de planificación para la seguridad de las contraseñasUna contraseña segura es un elemento importante de una estrategia de seguridad.

Política de calidad de las contraseñasA fin de garantizar que todos los usuarios administrativos locales escojan contraseñas lo suficientemente seguras, puede definir una política de calidad de las contraseñas que imponga cierta complejidad para las contraseñas definidas por los usuarios. Esta función no se aplica a los usuarios asignados por dominio, cuyas contraseñas se rigen por políticas dentro del dominio.

La política de contraseñas predeterminada de Celerra incluye los siguientes requisitos:

◆ Una longitud mínima de contraseña de ocho caracteres.

◆ Un máximo de tres intentos para definir una nueva contraseña de valor aceptable antes de que el comando falle.

◆ Un mínimo de tres caracteres que no se encontraban en la contraseña anterior.

◆ Un mínimo de un numeral en la contraseña nueva.

Nota: Actualmente, no hay ningún requisito de usar caracteres especiales (por ejemplo, !, @, #, $, %, &, ^ y *) o caracteres en mayúsculas y minúsculas en la contraseña.

Celerra además soporta un período de vencimiento de la contraseña predeterminado de 120 días.

"Configuración de la política de contraseñas" en la página 32 describe cómo configurar esta función.

Nota: Los cambios efectuados en la política de calidad de las contraseñas solo se aplican a las contraseñas definidas después de la revisión de la política.

Cambio de las contraseñas predeterminadasCelerra proporciona dos cuentas de usuario administrativo predeterminadas: root y nasadmin. A ambas cuentas se les asigna la contraseña nasadmin de forma predeterminada. El procedimiento de instalación del software Celerra permite especificar una contraseña distinta, pero no se requiere una contraseña nueva.

!PRECAUCIÓN!Si no modifica las contraseñas predeterminadas durante la instalación, debe cambiarlas lo antes posible.

Las contraseñas se eligen y se modifican por medio de la página User Properties en Celerra Manager. La ayuda en línea de Celerra Manager ofrece una explicación detallada de este procedimiento.

Nota: Puede acceder a la página User Properties desde la ficha Security > Administrators > Users o desde el campo User Name de la ficha Control Station Properties.

Los usuarios administrativos y los usuarios root con privilegios de operador de seguridad no están obligados a elegir contraseñas que cumplan con la política de contraseñas. Además, cuando se crea una nueva cuenta de usuario, los usuarios


administrativos y los usuarios root con privilegios de operador de seguridad pueden asignar cualquier contraseña al usuario.

Sin embargo, si el usuario posteriormente cambia su contraseña, esta nueva contraseña estará sujeta a la política de contraseñas existente. Una vez establecida la política de contraseñas, si intenta definir una contraseña que no cumple con los requisitos especificados, recibirá un error que indica que la contraseña es incorrecta.

Consideraciones de planificación para la Infraestructura de claves públicas (PKI)La Infraestructura de claves públicas de Celerra proporciona sistemas de bases de datos y administración de software para soportar el uso de certificados digitales para conexiones HTTP y LDAP de Data Movers en las que se encuentra activado SSL. Los certificados, cuya autenticidad es verificada por una Autoridad de certificación (CA), son utilizados por el protocolo SSL para identificar uno o ambos extremos de una conexión, lo que brinda mayor seguridad entre clientes y servidores.

Nota: El entorno PKI de Celerra soporta el estándar de certificados X.509. Los certificados se codifican mediante Distinguished Encoding Rules (DER) y se pueden codificar, además, en el formato Privacy Enhanced Mail (PEM) para facilitar su distribución mediante sistemas de correo electrónico.

PersonasLas personas se utilizan para proporcionar una identidad para un Data Mover cuando el Data Mover actúa como servidor o cliente. Cuando se negocia una conexión segura con un cliente (por ejemplo, el software de migración y políticas externas que se utilizado con FileMover), la persona proporciona una clave privada y un certificado al Data Mover (que actúa como servidor). Este certificado proporciona el mecanismo para que el cliente pueda identificar y autenticar el servidor. Cuando se negocia una conexión segura con un servidor (por ejemplo, un servidor de directorios externo basado en LDAP) configurado para requerir autenticación de clientes, la persona proporciona la clave privada y el certificado al Data Mover (que actúa como cliente). Este certificado proporciona el mecanismo para que el servidor pueda identificar y autenticar el cliente.

Como opción predeterminada, cada Data Mover se encuentra configurado con una sola persona, denominada predeterminada. Para crear el certificado que la persona proporciona al Data Mover, primero debe generar el conjunto de claves privadas/públicas de la persona. Luego, debe solicitar un certificado firmado emitido por una CA. Las solicitudes de certificados se generan únicamente en formato Privacy Enhanced Mail (PEM).

Nota: Actualmente, solo se permite una persona en cada Data Mover. Celerra no soporta un mecanismo para crear personas adicionales.

Si utiliza Celerra Control Station como CA, la Control Station recibe automáticamente la solicitud de certificado, genera y firma el certificado y lo devuelve al Data Mover. La Control Station puede firmar certificados para todos los Data Movers del gabinete. No se puede utilizar para firmar certificados para hosts externos. "Uso de la Control Station como CA" en la página 42 describe las tareas necesarias para usar una Control Station como CA.

Si utiliza una CA externa, debe enviar manualmente la solicitud de certificado. La solicitud para firmar la clave pública se genera con el conjunto de claves


privadas/públicas. Muestre las propiedades de la persona para verificar su contenido. Obtenga una copia de la solicitud de certificado y luego envíe la solicitud a la CA por medio del sitio Web o el correo electrónico de la empresa.

Cuando la CA devuelva un certificado firmado, debe importarlo al Data Mover. Para importar el certificado firmado, puede proporcionar un path e importar un archivo, o cortar y pegar el texto asociado. El archivo puede tener formato Distinguished Encoding Rules (DER) o PEM. Solo es posible cortar y pegar texto en formato PEM.

Cada persona puede estar asociada a un máximo de dos conjuntos de claves y certificados (actual y siguiente) para permitir generar claves y certificados nuevos antes del vencimiento del certificado actual. Cuando se importa el certificado siguiente (que ya tiene validez), el certificado y su conjunto de claves asociadas se convierten inmediatamente en el conjunto de claves y el certificado actuales.

Debido a que el certificado siguiente normalmente se genera cuando es necesario, por lo general, no se visualiza un certificado siguiente asociado con una persona. No obstante, un certificado siguiente puede encontrase en espera si existe una diferencia de tiempo entre el Data Mover y la CA (o la Control Station si está funcionando como CA). Por ejemplo, una CA puede preparar un certificado con antelación asignándolo a una fecha de inicio futura. Las empresas que se fusionan pueden configurar dicho certificado para que esté vigente en la fecha de fusión oficial.

El certificado siguiente se convierte en el certificado actual (y se eliminan la clave y el certificado actuales) cuando el certificado entra en vigencia (por tiempo de Data Mover) y se produce una de las siguientes condiciones:

◆ Se envía una consulta a la persona (ya sea por medio de CLI o de Celerra Manager).

◆ La función de un Data Mover (por ejemplo, SSL) solicita la clave y el certificado de la persona.

Una vez vencido el certificado, cualquier intento por usar el certificado ocasiona una falla, por lo general, una pérdida de la conexión o una falla al intentar volver a conectarse. Una vez que está disponible un nuevo certificado, la PKI elimina el certificado anterior y proporciona el nuevo certificado cuando se solicita. Sin embargo, si no obtuvo un certificado nuevo antes del vencimiento del certificado actual, se producirá un error en la solicitud de certificado. La PKI no proporcionará un certificado vencido para una persona.

No existe ningún modo automatizado para verificar los certificados de claves públicas vencidos. Debe verificar manualmente los certificados vencidos. Para ello, enumere las personas y examine las fechas de vencimiento de los certificados asociados. Luego, puede proceder según las prácticas de negocios de su organización.

"Creación del certificado proporcionado por la persona" en la página 42 describe el procedimiento para crear el certificado y el conjunto de claves que la persona suministra a los Data Movers cuando Celerra se configura como servidor o cliente.

Certificados de la Autoridad de certificación (CA)Cuando una aplicación cliente basada en Celerra requiere una conexión de red con un servidor (por ejemplo, la conexión de FileMover con su almacenamiento secundario), el servidor suministra un certificado como parte de la negociación para garantizar una conexión segura. Celerra confirma la identidad del servidor mediante la validación del certificado. Para ello, verifica la firma del certificado del servidor con la clave pública del certificado de CA.


La obtención de los certificados de CA requeridos es una tarea manual. Por lo general, antes de la operación concreta, debe identificar la CA adecuada. Luego, debe verificar la lista de certificados de CA disponibles en el sistema Celerra. Si se requiere un certificado de CA nuevo y se está utilizando una CA externa, puede obtener el certificado de CA del sitio Web de la empresa o de la persona responsable de la seguridad. Si la CA es local (interna o de nivel empresarial), obtenga el certificado de CA de la persona que administra la CA.

Para que Celerra conozca el certificado de CA, debe importarlo. Puede proporcionar un path e importar un archivo, o cortar y pegar el texto. Un archivo puede tener formato DER o PEM. Solo es posible cortar y pegar texto en formato PEM.

"Obtención de certificados de CA" en la página 42 describe el procedimiento para obtener el certificado que se utiliza para confirmar la identidad de un servidor.

Uso de la Control Station como CAEl software Celerra genera automáticamente un certificado y un conjunto de claves para la Control Station al instalar o actualizar el software. La Control Station utiliza este certificado y este conjunto de claves para firmar solicitudes de certificados de Data Movers. Sin embargo, para que la Control Station funcione correctamente como CA y para que un Data Mover la reconozca como tal, se deben llevar a cabo diversas tareas de configuración:

◆ Distribuya el certificado de CA de la Control Station a los clientes de la red. Para que un cliente de red valide un certificado que haya enviado un Data Mover firmado por la Control Station, el cliente necesita la clave pública del certificado de CA para verificar la firma del certificado del Data Mover.

◆ Importe el certificado de CA (con los certificados de CA de las CAs externas).

Solo es posible obtener una copia del certificado de la Control Station mediante el comando nas_ca_certificate de CLI como se describe en "Uso de la Control Station como CA" en la página 42.

Si el certificado y el conjunto de claves de la Control Station están comprometidos, puede volver a generarlos. Esta tarea solo puede llevarse a cabo mediante el comando CLI nas_ca_certificate. Después de volver a generar el certificado y el conjunto de claves de la Control Station, debe volver a generar una nueva solicitud de certificado y conjunto de claves, y luego importar el certificado firmado para cualquier persona cuyo certificado haya firmado la Control Station.

Nota: La Control Station continúa generando un conjunto de claves separado para la conexión basada en SSL entre el servidor Web Apache de Celerra (en nombre de Celerra Manager) y el navegador Web de un usuario. Sin embargo, la Control Station ahora emplea el conjunto de claves de CA para firmar el certificado del servidor Web Apache, lo que implica que el certificado ya no se firma automáticamente. Installing EMC Celerra Management Applications describe la manera de administrar certificados para Celerra Manager.


Configuración del uso de un servidor de directorios externo para identificación y autenticación de usuarios administrativosEl uso de un servidor de directorios externo proporciona un catálogo centralizado de cuentas de usuario administrativo, lo que simplifica la administración. "Consideraciones de planificación para usar un servidor de directorios externo para identificación y autenticación de usuarios administrativos" en la página 19 ofrece una descripción general.

Antes de iniciar sesión como usuario administrativo, debe llevar a cabo varias tareas de configuración preliminares.

Paso Acción

1. Determine el servidor de directorios basado en LDAP con el que se comunicará Celerra.

Nota: Por lo general, la empresa en la que se utiliza Celerra ya utiliza un servidor de directorios basado en LDAP para almacenar credenciales de usuario. En este caso, consulte con Active Directory o con el administrador del servidor de directorios basado en LDAP para obtener información sobre la conexión. De lo contrario, deberá estudiar el servidor Active Directory disponible u otro servidor de directorios basado en LDAP y descubrir la información de conexión necesaria. Existen varias herramientas disponibles para administrar los servicios de directorio basados en LDAP. "Apéndice B: Comprensión de la configuración del servidor de directorios" en la página 68 proporciona información sobre estas herramientas.

2. Obtenga la siguiente información:

a. El nombre distinguido de la base de la raíz del árbol de directorios LDAP, es decir, el lugar donde el árbol de directorios LDAP comenzará a buscar información. El nombre distinguido de la base puede expresarse como un nombre de dominio completamente calificado o en el formato X.509 con el atributo dc=. Por ejemplo, si el nombre de dominio completamente calificado es mycompany.com, el nombre distinguido de la base se expresa como dc=mycompany,dc=com.

b. Nombre de host o dirección IP del servidor de directorios basado en LDAP.c. Dirección IP o nombre de host de un servidor de directorios basado en LDAP

de backup.


3. Solicítele al administrador del servidor de directorios que agregue un nombre de cuenta o usuario que identifique a Celerra en la estructura de directorios del servidor basado en LDAP. O bien si tiene permisos para crear cuentas de grupo y usuarios en Active Directory o en otro servidor de directorios basado en LDAP, agregue este nombre de cuenta o usuario usted mismo.

Esta cuenta debe ser una cuenta de usuario restringida (por ejemplo, una cuenta de Invitado de dominio) con privilegios de lectura/búsqueda para el directorio.

Nota: Existen varias herramientas disponibles para administrar los servicios de directorio basados en LDAP. "Apéndice B: Comprensión de la configuración del servidor de directorios" en la página 68 proporciona información sobre estas herramientas.

Esta entrada identifica a Celerra como el usuario o la cuenta que se vinculará con el servicio de directorios, es decir, el usuario o la cuenta que tiene permitido buscar en el directorio LDAP dentro de la base de búsqueda definida. Esta entrada también es conocida como nombre distinguido de vinculación.

Por ejemplo, cuando se usa Active Directory, el nombre distinguido de vinculación puede definirse como cn=<acctname>,cn=users,dc=<domain component>,dc=<domain component> y cuando se utiliza un servidor de directorios OpenLDAP, como uid=<name>,dc=users,dc=<domain component>,dc=<domain component> o cn=<acctname>,uid=<name>,ou=people,dc=<domain component>,dc=<domain component>.

4. Asegúrese de que los usuarios administrativos (y sus grupos asociados) que iniciarán sesión en la Control Station estén definidos en el servidor de directorios basado en LDAP y determine los paths en los que Celerra buscará una instancia del atributo de nombre cuyo valor sea el nombre de grupo o usuario.

Si las cuentas de grupo y usuario aún no existen, solicítele al administrador del servidor de directorios que las agregue. O bien si tiene permisos para crear cuentas de grupo y usuarios en Active Directory o en otro servidor de directorios basado en LDAP, agregue estas cuentas usted mismo.

Nota: Existen varias herramientas disponibles para administrar los servicios de directorio basados en LDAP. "Apéndice B: Comprensión de la configuración del servidor de directorios" en la página 68 proporciona información sobre estas herramientas.

Por ejemplo, si los usuarios y los grupos se almacenan en una unidad organizacional con usuarios de nombres comunes, el path de búsqueda será cn=users,dc=<domain component>,dc=<domain component>.

5. Si la conexión LDAP utiliza SSL, obtenga el certificado público de la CA que firma el certificado del servidor SSL del servidor de directorios basado en LDAP. Celerra utiliza este certificado de CA para verificar el certificado recibido del servidor LDAP. El certificado debe estar codificado en el formato Base64.

Si el servidor de directorios basado en LDAP utiliza un CA externo, obtenga el certificado de CA en el sitio Web de la empresa de CA. Si el servidor de directorios basado en LDAP utiliza un CA interno o si los certificados tienen firma propia, solicítele el certificado de CA al administrador del servidor de directorios basado en LDAP.

Si no activará SSL, no necesitará un certificado de CA.

Paso Acción


6. Con la información que ha recopilado, inicie sesión en Celerra Manager y utilice la ficha Administrators > Domain Settings para configurar la Control Station de modo que pueda acceder al servidor de directorios basado en LDAP.

Nota: Si selecciona el campo Enable automatic domain user mapping en la ficha Domain Settings, Celerra crea automáticamente una cuenta de usuario local asignada al usuario de dominio. De manera alternativa, puede crear un usuario administrativo asignado a un usuario de dominio y asociarlo con un grupo asignado por dominio.

En la ayuda en línea de Celerra Manager, se puede obtener una descripción de estas tareas.

Paso Acción


Configuración de la política de contraseñasEsta función permite que el administrador root de Celerra defina los requisitos de complejidad de las contraseñas para todos los usuarios administrativos. "Consideraciones de planificación para la seguridad de las contraseñas" en la página 25 proporciona una descripción general.

Nota: Esta función no se aplica a los usuarios administrativos asignados por dominio, cuyas contraseñas se rigen por políticas dentro del dominio.

Nota: Debe ser usuario root para ejecutar el comando /nas/sbin/nas_config.

Definición interactiva de la política de contraseñas

Acción

Para iniciar un script que solicite definiciones de la política de contraseñas, use la siguiente sintaxis de comandos: # /nas/sbin/nas_config -password

Salida

Minimum length for a new password (Between 6 and 15): [8] Number of attempts to allow before failing: [3] Number of new characters (not in the old password): [3] Number of digits that must be in the new password: [1] Number of special characters that must be in a new password: [0] Number of lower case characters that must be in password: [0] Number of upper case characters that must be in password: [0]

Notas

El valor actual definido para cada campo figura entre corchetes. Los valores predeterminados originales para cada campo son los siguientes:

• longitud: mínimo ocho caracteres; rango de 6 a 15.• intentos: tres intentos como máximo.• nuevos caracteres: mínimo tres caracteres.• dígitos: mínimo un dígito.• caracteres especiales, en minúsculas y mayúsculas: 0

Para cambiar el valor de cada campo, escriba el nuevo valor cuando se lo solicite.


Definición de políticas de contraseñas específicas

Configuración del período de vencimiento de las contraseñasEl archivo /etc/login.defs contiene el parámetro utilizado para establecer el vencimiento de las contraseñas.

Acción

Para establecer definiciones de políticas de contraseñas específicas, use la siguiente sintaxis de comandos: # /nas/sbin/nas_config -password [-min <6..15>] [-retries <max_allowed>] [-newchars <min_num>] [-digits <min_num>] [-spechars <min_num>] [-lcase <min_num>] [-ucase <min_num>]

donde<6..15> = longitud mínima de la contraseña nueva. La longitud predeterminada es ocho caracteres. La longitud debe ser un valor de 6 a 15 caracteres. <max_allowed> = cantidad de intentos que puede realizar un usuario para definir una nueva contraseña aceptable antes de que el comando falle. El valor predeterminado es 3 intentos.<min_num> = cantidad mínima de caracteres que debe contener la nueva contraseña que no estaban incluidos en la contraseña anterior. El valor predeterminado es 3 caracteres.<min_num> = cantidad mínima de dígitos que debe contener la contraseña nueva. El valor predeterminado es 1 dígito.<min_num> = cantidad mínima de caracteres especiales (por ejemplo, !, @, #, $, %, &, ^ y *) que deben incluirse en la contraseña nueva. El valor predeterminado es 0.<min_num> = cantidad mínima de caracteres en minúsculas que debe contener la nueva contraseña. El valor predeterminado es 0.<min_num> = cantidad mínima de caracteres en mayúsculas que debe contener la nueva contraseña. El valor predeterminado es 0.

Ejemplo:

Para establecer la longitud mínima de la contraseña nueva en 10 caracteres, escriba:# /nas/sbin/nas_config -password -min 10

Salida

#

Paso Acción

1. Inicie sesión en CLI con su nombre de usuario y contraseña. Debe contar con privilegios de usuario root para acceder al archivo /etc/login.def.

2. Cambie el valor del parámetro pass_max_days en el archivo /etc/login.def mediante vi u otro editor de texto.

Nota: El período de vencimiento predeterminado es 120 días.


Configuración del tiempo de espera de las sesionesCelerra agota el tiempo de espera de las sesiones iniciadas desde las shells de Control Station y Celerra Manager:

◆ Para administrar el tiempo de espera de las sesiones de Celerra Manager, seleccione Celerras > [Celerra_name] > Security > Celerra Manager. Puede encontrar información más detallada en la ayuda en línea de Celerra Manager.

◆ Puede cambiar el valor predeterminado del tiempo de espera de las sesiones de la Control Station mediante el comando /nas/sbin/nas_config -sessiontimeout.

Nota: Debe ser usuario root para ejecutar el comando /nas/sbin/nas_config.

Requisitos previosLa Control Station soporta tres shells:

◆ bash

◆ ksh

◆ tcsh

Cada shell soporta una función de tiempo de espera de las sesiones. La opción de tiempo de espera de las sesiones de Control Station establece el valor de tiempo de espera de las sesiones en todo el sistema, actualiza automáticamente los valores apropiados en /etc/environment para las shells bash y ksh, y en la variable de cierre de sesión automático en /etc/csh.cshrc para la shell tcsh.

Una vez que se estableció el valor, se verán afectadas las shells que se crearon recientemente (pero no las shells que ya se encuentran en ejecución).

Nota: Es posible cambiar el valor de tiempo de espera de las sesiones para los usuarios administrativos. Para hacerlo, configure la variable pertinente en el archivo de configuración de shells del usuario (por ejemplo, ~/.bashrc). Los valores no se restringen si edita el archivo de configuración directamente.

Modificación del valor de tiempo de espera de las sesionesEl valor predeterminado de tiempo de espera de las sesiones para las sesiones shell de la Control Station es 60 minutos. Se define como tiempo de inactividad al tiempo que transcurre desde que aparece el indicador shell principal y no se ha realizado ninguna acción. Por lo tanto, la espera de una solicitud de un comando durante un período indeterminado no se ve afectada por el valor de tiempo de espera de las sesiones.


Desactivación del tiempo de espera de las sesiones

Acción

Para cambiar el valor de tiempo de espera de las sesiones, utilice la siguiente sintaxis de comandos:# /nas/sbin/nas_config -sessiontimeout <minutes>

donde:<minutes> = cantidad de minutos de tiempo de espera de la sesión (de 5 a 240)

Ejemplo:

Para cambiar el valor de tiempo de espera de las sesiones a 200 minutos, escriba:# /nas/sbin/nas_config -sessiontimeout 200

Salida

#

Acción

Para desactivar el tiempo de espera de las sesiones, utilice la siguiente sintaxis de comandos: # /nas/sbin/nas_config -sessiontimeout 0

o# /nas/sbin/nas_config -sessiontimeout off

Salida

#


Personalización de un banner de inicio de sesiónEl archivo /etc/issue contiene un mensaje de banner de inicio de sesión o identificación del sistema, que aparece antes de la solicitud de inicio de sesión. Se puede utilizar un banner de inicio de sesión para distintos objetivos de información, pero, por lo general, se lo utiliza para advertir a los usuarios acerca del uso no autorizado o no adecuado del sistema.

Nota: También es posible personalizar el banner de inicio de sesión por medio de la ficha Celerra Manager Control Station Properties. Debe contar con privilegios de usuario root para acceder al campo Login Banner.

Paso Acción

1. Inicie sesión en CLI con su nombre de usuario y contraseña. Debe contar con privilegios de usuario root para obtener acceso al archivo /etc/issue.

2. Edite el archivo /etc/issue mediante vi u otro editor de texto.

EMC sugiere que se agregue un retorno de carro adicional al final del mensaje del banner.

Utilice espacios, tabulaciones y retornos de carro para darle formato al mensaje. En general, debe limitar el tamaño del mensaje para que no ocupe más de una pantalla.

Nota: Debido a que el banner de inicio de sesión aparece con la solicitud de inicio de sesión, no incluya información confidencial en el mensaje del banner.

3. Inicie sesión en CLI o en Celerra Manager para ver el banner de inicio de sesión y comprobar los cambios.


Creación de un mensaje del día (MOTD) El archivo de mensaje del día, /etc/motd, aparece después de que un usuario inicia sesión correctamente. Puede utilizarse para distintos objetivos de información, pero resulta particularmente útil para enviar mensajes que afectan a todos los usuarios. El mensaje puede contener información sobre actualizaciones del servidor o una alerta acerca de un apagado inminente del sistema. Como opción predeterminada, este archivo está vacío.

Nota: También puede personalizar el MOTD mediante la ficha Celerra Manager Control Station Properties. Debe contar con privilegios de usuario root para acceder al campo Message of the Day.

Paso Acción

1. Inicie sesión en CLI con su nombre de usuario y contraseña. Debe contar con privilegios de usuario root para obtener acceso al archivo /etc/motd.

2. Edite el archivo /etc/motd mediante vi u otro editor de texto.

EMC sugiere que se agregue un retorno de carro adicional al final del mensaje del banner.

Utilice espacios, tabulaciones y retornos de carro para darle formato al mensaje. En general, debe limitar el tamaño del mensaje para que no ocupe más de una pantalla.

3. Inicie sesión en CLI o en Celerra Manager para ver el MOTD y comprobar los cambios.


Protección de tokens de sesiónLa conexión entre un usuario y Celerra Manager, y entre dos Celerras utiliza SHA1 para generar checksums con el objetivo de proteger los tokens de sesión (cookies) que identifican a los usuarios después de que inician sesión. El valor secreto de SHA1 que se usa para generar las checksums se establece al azar durante la instalación. Sin embargo, para optimizar la seguridad, puede cambiar el valor secreto de SHA1 predeterminado.

Paso Acción

1. Inicie sesión en CLI con su nombre de usuario y contraseña. Debe contar con privilegios de usuario root para acceder al archivo /nas/http/conf/secret.txt.

2. Edite el archivo /nas/http/conf/secret.txt mediante vi u otro editor de texto.

Reemplace la frase predeterminada por un nuevo valor y guarde el archivo.

Cuando modifica este valor, los tokens de sesión existentes pierden validez y los usuarios actuales de Celerra Manager deben iniciar sesión nuevamente.


Configuración de la encriptación y la autenticación de redes mediante el protocolo SSLSecure Socket Layer (SSL) es un protocolo de nivel de sesión utilizado para encriptar las transmisiones de red en Internet. Encripta datos y proporciona autenticación de mensajes y servidores. También soporta autenticación de clientes, si el servidor así lo requiere. SSL es independiente de los protocolos de nivel superior. Por lo tanto, puede encapsular los protocolos de nivel de aplicaciones, como HTTP y LDAP:

◆ El Protocolo de transferencia de hipertexto (HTTP) es un protocolo rápido, sin estado y orientado a objetos que se utiliza en la Web. Permite que los servidores y los clientes Web negocien e interactúen. Lamentablemente cuenta con muy pocas funciones de seguridad. HTTPS (seguro) es una variante de HTTP que utiliza un servidor habilitado por SSL.

◆ El Protocolo Ligero de Acceso a Directorio (LDAP) es un protocolo de acceso estándar de la industria que se ejecuta directamente mediante TCP/IP. Es el protocolo de acceso primario para Active Directory y otros servidores de directorios, como Sun Java System Directory Server (iPlanet) y OpenLDAP.

Celerra soporta SSL para las conexiones LDAP y HTTP del Data Mover.

Uso de HTTPSPuede activar SSL en conexiones HTTP del Data Mover mediante el comando server_http. Actualmente, la función FileMover de Celerra utiliza las funciones de encriptación y autenticación de HTTPS y SSL. Uso de EMC Celerra FileMover describe cómo configurar SSL con HTTP para que lo utilice FileMover. Las claves y los certificados que se utilizan con SSL se administran mediante PKI. PKI se encuentra disponible mediante CLI y Celerra Manager. "Consideraciones de planificación para la Infraestructura de claves públicas (PKI)" en la página 26 proporciona una visión general de la función PKI. "Configuración de PKI" en la página 42 y "Administración de la PKI" en la página 56 describe cómo configurar y administrar PKI mediante CLI.

Uso de SSL con LDAPPuede activar SSL en conexiones LDAP del Data Mover mediante el comando server_ldap. Actualmente, el soporte de servicios de nombre de Celerra para OpenLDAP, iPlanet y Active Directory usa las funciones de encriptación y autenticación de LDAP y SSL. Configuring EMC Celerra Naming Services describe cómo configurar SSL con LDAP para que lo utilicen los servidores de directorios basados en LDAP iPlanet y OpenLDAP. Las claves y los certificados que se utilizan con SSL se administran mediante PKI. PKI se encuentra disponible mediante CLI y Celerra Manager. "Consideraciones de planificación para la Infraestructura de claves públicas (PKI)" en la página 26 proporciona una visión general de la función PKI. "Configuración de PKI" en la página 42 y "Administración de la PKI" en la página 56 describe cómo configurar y administrar PKI mediante CLI.


Cambio del protocolo SSL predeterminadoCelerra soporta las siguientes versiones del protocolo SSL:

◆ SSLv3

◆ TLSv1

Cambio de la serie de cifrado de SSL predeterminadaUna serie de cifrado define un conjunto de tecnologías para proteger las comunicaciones SSL:

◆ Algoritmo de intercambio de claves (cómo se utiliza la clave secreta para encriptar los datos que se comunican del cliente al servidor). Ejemplos: RSA Key o Diffie-Hellman (DH).

◆ Método de autenticación (de qué manera los hosts pueden autenticar la identidad de los hosts remotos). Ejemplos: certificado RSA, certificado DSS o sin autenticación.

◆ Cifrado de encriptación (cómo encriptar datos). Ejemplos: AES (256 ó 128 bits), RC4 (128 ó 56 bits), 3DES (168 bits), DES (56 ó 40 bits) o encriptación nula.

◆ Algoritmo hash (garantía de datos al proporcionar una forma de determinar si se modificaron los datos). Ejemplos: SHA-1 o MD5

La serie de cifrados soportados combina todos estos elementos. El "Apéndice A: Series de cifrado de SSL soportadas" en la página 66 muestra las series de cifrado de SSL que soporta Celerra.

Acción

Para cambiar el protocolo SSL predeterminado, utilice la siguiente sintaxis de comandos:$ server_param <movername> -facility ssl -modify protocol -value <new_value>

donde:<movername> = nombre del Data Mover<new_value> = 0 (tanto SSLv3 como TLSv1), 1 (solo SSLv3) o 2 (solo TLSv1)

Nota: El valor predeterminado es 0.

Los nombres de parámetros y funcionalidades distinguen mayúsculas y minúsculas.

Ejemplos:

Para cambiar el protocolo SSL predeterminado por SSLv3 solo, escriba:$ server_param server_2 -facility ssl -modify protocol -value 1

Para cambiar el protocolo SSL predeterminado por TLSv1 solo, escriba:$ server_param server_2 -facility ssl -modify protocol -value 2

Salida

server_2 : done


Requisitos posterioresDespués de cambiar los valores de parámetros SSL, debe reiniciar el Data Mover para que se aplique el cambio de la serie de cifrado y el protocolo SSL.

Acción

Para cambiar la serie de cifrado de SSL predeterminada, utilice la siguiente sintaxis de comandos:$ server_param <movername> -facility ssl -modify cipher -value <new_value>

donde:<movername> = nombre especificado.<new_value> = cadena que especifica el nuevo valor de cifrado. Si el valor incluye caracteres especiales (por ejemplo, punto y coma, espacios o signos de exclamación), estos deben estar entre comillas.

Nota: El valor de la serie de cifrado predeterminado es ALL:!ADH:!SSLv2:@STRENGTH, lo que significa que Celerra soporta todos los cifrados salvo SSLv2, Anonymous Diffie-Hellman y NULL ciphers, ordenados por su “fortaleza”, es decir, por el tamaño de la clave de encriptación.

Los nombres de parámetros y funcionalidades distinguen mayúsculas y minúsculas.

Ejemplo:

Para cambiar la serie de cifrado SSL predeterminada por un cifrado seguro (principalmente AES128 y AES256) que utilizará cada conexión SSL nueva, escriba:$ server_param server_2 -facility ssl -modify cipher -value ‘HIGH:@STRENGTH’

Salida

server_2 : done


Configuración de PKI"Consideraciones de planificación para la Infraestructura de claves públicas (PKI)" en la página 26 proporciona una descripción general de esta función.

Creación del certificado proporcionado por la personaEl procedimiento de creación del certificado que proporciona la persona al Data Mover varía levemente según si la Autoridad de certificación (CA) que firma el certificado es una CA externa o la Celerra Control Station:

1. "Generación de un conjunto de claves y de la solicitud de certificado" en la página 43

2. "Envío de la solicitud de certificado a la CA" en la página 46 (no se requiere si utiliza la Control Station)

3. "Importación de un certificado firmado por la CA" en la página 47 (no se requiere si utiliza la Control Station)

Obtención de certificados de CA El procedimiento de obtención del certificado de CA que se utiliza para confirmar la identidad de un servidor comprende las siguientes tareas:

1. "Enumeración de los certificados disponibles en la CA" en la página 49

2. "Obtención de un certificado de CA" en la página 49

3. "Importación de un certificado de CA" en la página 52

Uso de la Control Station como CA El procedimiento para utilizar la Control Station como CA comprende las siguientes tareas:

1. "Generación de un nuevo certificado de CA para la Control Station" en la página 52

2. "Visualización del certificado" en la página 53

3. "Distribución del certificado de CA de la Control Station" en la página 55

Nota: La Control Station continúa generando un conjunto de claves separado para la conexión basada en SSL entre el servidor Web Apache de Celerra (en nombre de Celerra Manager) y el navegador Web de un usuario. Sin embargo, la Control Station ahora emplea el conjunto de claves de CA para firmar el certificado del servidor Web Apache, lo que implica que el certificado ya no se firma automáticamente. Installing EMC Celerra Management Applications describe la manera de administrar certificados para Celerra Manager.


Generación de un conjunto de claves y de la solicitud de certificadoPara crear el certificado que la persona proporciona al Data Mover, primero debe generar el conjunto de claves privadas/públicas de la persona con una solicitud para que una CA firme el certificado. La CA puede ser una CA externa o la Control Station.

Creación de un certificado firmado por una CA externa

Acción

Para generar un conjunto de claves y solicitar que una CA externa firme el certificado, utilice la siguiente sintaxis de comandos:$ server_certificate <movername> -persona -generate {<persona_name> | id=<persona_id>} -key_size <bits> {-cn | -common_name} <common_name>

donde:<movername> = nombre del Data Mover físico con el que está asociada la persona.

<persona_name> = nombre de la persona.

<persona_id> = ID de la persona. El ID se genera cuando se crea la persona. Puede determinar el ID mediante el comando -persona -list.

<bits> = tamaño de la clave, 2048 ó 4096 bits.

<common_name> = nombre utilizado con frecuencia, por lo general, un nombre de host que describe el Data Mover con el que está asociada la persona. Si el nombre incluye caracteres especiales (por ejemplo, punto y coma, espacios o signos de exclamación), estos deben estar entre comillas.

Nota: Las solicitudes de certificados se generan solamente en formato PEM.

Ejemplo:

Para generar un conjunto de claves y solicitar que una CA externa firme el certificado, escriba:

$ server_certificate server_2 -persona -generate default -key_size 4096 -cn ‘name;1.2.3.4’

Salida

server_2 : Starting key generation. This could take a long time ... done


Creación de un certificado firmado por la Control Station Si está usando la Celerra Control Station para firmar el certificado, debe especificar la cantidad de meses durante los cuales es válido el certificado.

Creación de un certificado que especifica información detallada sobre la personaCuando genera la solicitud de certificado y el conjunto de claves privadas/públicas de la persona, puede especificar información detallada acerca del Data Mover. Por lo general, esta información incluye detalles, como la organización que usa el Data

Acción

Para generar un conjunto de claves y solicitar que la Control Station firme el certificado, utilice la siguiente sintaxis de comandos:$ server_certificate <movername> -persona -generate {<persona_name> | id=<persona_id>} -key_size <bits> -cs_sign_duration <# of months> {-cn | -common_name} <common_name>





<# of months> = cantidad de meses durante los cuales el certificado es válido.



Ejemplo:

Para generar un conjunto de claves y solicitar que la Control Station firme el certificado, escriba:

$ server_certificate server_2 -persona -generate default -key_size 4096 -cs_sign_duration 13 -cn ‘name;1.2.3.4’

Salida



Mover y el lugar donde está ubicado. Además, tiene la opción de guardar la solicitud de certificado en un archivo específico.

Acción

Para generar un conjunto de claves y solicitar que una CA externa firme el certificado, además de especificar información detallada acerca del Data Mover y guardar la solicitud de certificado en un archivo específico, utilice la siguiente sintaxis de comandos:$ server_certificate <movername> -persona -generate {<persona_name> | id=<persona_id>} -key_size <bits> {-cn | -common_name} <common_name> -ou <org_unit> -organization <organization> -location <location> -state <state> -country <country> -filename <output_path>






<org_unit> = nombre de la unidad organizacional. Si el nombre incluye caracteres especiales (por ejemplo, punto y coma, espacios o signos de exclamación), estos deben estar entre comillas.

<organization> = nombre de la organización.

<location> = ubicación física de la organización.

<state> = estado en el que se encuentra la organización.

<country> = país en el que se encuentra la organización.

<output_path> = nombre y path donde se escribe la solicitud generada.

Nota: Los argumentos -ou, -organization, -location, -state y -country son opcionales.

Nota: El argumento -filename solo es válido si una CA externa firma el certificado.


Ejemplo:

Para generar un conjunto de claves y solicitar que una CA externa firme el certificado, además de especificar información detallada acerca del Data Mover y guardar la solicitud de certificado en un archivo específico, escriba:

$ server_certificate server_2 -persona -generate default -key_size 4096 -cn ‘name;1.2.3.4’ -ou ‘my.org;my dept’ -organization EMC -location Hopkinton -state MA -country US -filename /tmp/server_2.1.request.pem

Salida



Envío de la solicitud de certificado a la CA

Nota: Esta tarea no es necesaria si está utilizando la Control Station para firmar el certificado. La Control Station recibe automáticamente la solicitud de certificado.

Si está utilizando una CA externa para firmar el certificado, automáticamente se genera una solicitud para firmar la clave pública junto con el conjunto de claves privadas/públicas. Luego, debe enviar la solicitud de certificado a la CA.

Paso Acción

1. Visualice las propiedades de la persona para comprobar el contenido de la solicitud de certificado mediante la siguiente sintaxis de comandos:$ server_certificate <movername> -persona -info {-all | <persona_name> | id=<persona_id>}



<persona_id> = ID de la persona. El ID se genera cuando se crea la persona.

Ejemplo:

Para ver las propiedades de la persona predeterminada, incluida la solicitud de certificado, escriba:$ server_certificate server_2 -persona -info default

Salida:

server_2 : id=1 name=default next state=Request Pending next certificate: request subject = CN=name;CN=1.2.3.4 request: -----BEGIN CERTIFICATE REQUEST----- MIIB6TCCAVICAQYwDQYJKoZIhvcNAQEEBQAwWzELMAkGA1UEBhMCQVUxEzARBgNV BAgTClF1ZWVuc2xhbmQxGjAYBgNVBAoTEUNyeXB0U29mdCBQdHkgTHRkMRswGQYD VQQDExJUZXN0IENBICgxMDI0IGJpdCkwHhcNMDAxMDE2MjIzMTAzWhcNMDMwMTE0 MjIzMTAzWjBjMQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDEaMBgG A1UEChMRQ3J5cHRTb2Z0IFB0eSBMdGQxIzAhBgNVBAMTGlNlcnZlciB0ZXN0IGNl cnQgKDUxMiBiaXQpMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJ+zw4Qnlf8SMVIP Fe9GEcStgOY2Ww/dgNdhjeD8ckUJNP5VZkVDTGiXav6ooKXfX3j/7tdkuD8Ey2// Kv7+ue0CAwEAATANBgkqhkiG9w0BAQQFAAOBgQCT0grFQeZaqYb5EYfk20XixZV4 GmyAbXMftG1Eo7qGiMhYzRwGNWxEYojf5PZkYZXvSqZ/ZXHXa4g59jK/rJNnaVGM k+xIX8mxQvlV0n5O9PIha5BX5teZnkHKgL8aKKLKW1BK7YTngsfSzzaeame5iKfz itAE+OjGF+PFKbwX8Q== -----END CERTIFICATE REQUEST-----

2. Si aún no lo ha hecho, guarde la solicitud de certificado en un archivo (por ejemplo, server_2.1.request.pem).

3. Envíe el archivo .pem a la CA por medio del correo electrónico o el sitio Web de la empresa.


Importación de un certificado firmado por la CA

Nota: Esta tarea no es necesaria si está utilizando la Control Station para firmar el certificado. La Control Station proporciona automáticamente el certificado firmado al Data Mover.

Puede importar un certificado firmado cuando el próximo certificado firmado asociado con la persona está disponible para la descarga. No bien se importa el certificado, se convierte en el certificado actual (siempre y cuando la fecha sea válida).

Paso Acción

1. Obtenga el certificado firmado (por ejemplo, cert.pem) de la CA.

2. Consulte todos los Data Movers para determinar qué personas están esperando un certificado firmado:$ server_certificate ALL -persona -list

Salida:

server_2 : id=1 name=default next state=Request Pending request subject = CN=name;CN=1.2.3.4 server_3 :id=1 name=default next state=Request Pending request subject = CN=test;CN=5.6.7.8

3. Para determinar a qué persona debe importarse el certificado, asocie el asunto del certificado con el valor del campo Request Subject para aquellas personas cuyo Next State sea Request Pending.

4. Importe el certificado firmado a la persona que lo está esperando mediante la siguiente sintaxis de comandos:$ server_certificate <movername> -persona -import {<persona_name> | id=<persona_id>}




Nota: El certificado firmado puede tener formato DER o PEM. Solo puede pegar texto en formato PEM en la línea de comandos. Si especifica -filename y proporciona un path, puede importar un certificado firmado por la CA en formato DER o PEM.

Ejemplo:

Para importar el certificado firmado, escriba:

$ server_certificate server_2 -persona -import default

Salida:

server_2 : Please paste certificate data. Enter a carriage return and on the new line type ‘end of file’ or ‘eof’ followed by another carriage return.

Nota: Después de pegar correctamente el texto del certificado, se muestra el indicador del sistema.


5. Compruebe que el certificado se haya importado correctamente mediante la siguiente sintaxis de comandos:$ server_certificate <movername> -persona -info {-all | <persona_name> | id=<persona_id>}




Ejemplo:

Para comprobar si el certificado de la persona predeterminada se importó correctamente, escriba:$ server_certificate server_2 -persona -info default

Salida:

server_2id=1 name=default next state=Not Available Current Certificate: id = 1 subject = CN=name;CN=1.2.3.4 issuer = O=Celerra Certificate Authority;CN=eng173100 start date = 20070606183824Z end date = 20070706183824Z serial number = 05 signature alg. = sha1WithRSAEncryption public key alg. = rsaEncryption public key size = 4096 version = 3

Nota: Por lo general, después de que se importa un certificado, se convierte de inmediato en el certificado y conjunto de claves actual, y el campo Next State figura como Not Available. Si el certificado importado no es válido (por ejemplo, si su registro de fecha y hora está varios minutos adelantado que el del Data Mover), el certificado y el conjunto de claves importados conservan el siguiente certificado y conjunto de claves, y el campo Next State figura como Available hasta el momento en el que el certificado y el conjunto de claves sean válidos.

Paso Acción


Enumeración de los certificados disponibles en la CA

Obtención de un certificado de CASi requiere un nuevo certificado de CA y se está utilizando una CA externa, puede obtener el certificado de CA del sitio Web de la empresa o, posiblemente, de la persona responsable de la seguridad de la empresa. Si la CA es la Control Station (interna o de nivel empresarial), puede obtener el certificado de CA de la persona que administra la CA. De forma alternativa, puede ver el texto del certificado de CA mediante el comando nas_ca_certificate -display.

Acción

Para ver todos los certificados de CA disponibles, escriba:$ server_certificate ALL -ca_certificate -list

Salida

server_2 : id=1subject=C=ZA;ST=Western Cape;L=Cape Town;O=Thawte Consulting cc;OU=Certificissuer=C=ZA;ST=Western Cape;L=Cape Town;O=Thawte Consulting cc;OU=Certificaexpire=20201231235959Z

id=2subject=C=US;O=America Online Inc.;CN=America Online Root Certification Autissuer=C=US;O=America Online Inc.;CN=America Online Root Certification Authexpire=20371119204300Z

id=3subject=C=US;ST=Massachusetts;L=Westboro;O=EMC;OU=IS;OU=Terms of use at wwwissuer=O=VeriSign Trust Network;OU=VeriSign, Inc.;OU=VeriSign Internationalexpire=20080620235959Z

id=4subject=C=US;O=VeriSign,Inc.;OU=Class 3 Public Primary Certification Authorissuer=C=US;O=VeriSign, Inc.;OU=Class 3 Public Primary Certification Authorexpire=20280801235959Z

Acción

Para ver el certificado de CA de la Control Station, escriba:$ /nas/sbin/nas_ca_certificate -display

Nota: El texto del certificado aparece en la pantalla de la terminal. De forma alternativa, puede redirigirlo a un archivo. El texto del certificado aparece entre BEGIN CERTIFICATE y END CERTIFICATE.


Salida

Certificate: Data: Version: 3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: sha1WithRSAEncryption Issuer: O=Celerra Certificate Authority, CN=eng173100 Validity Not Before: Mar 23 21:07:40 2007 GMT Not After: Mar 21 21:07:40 2012 GMT Subject: O=Celerra Certificate Authority, CN=eng173100 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:da:b2:37:86:05:a3:73:d5:9a:04:ba:db:05:97: d2:12:fe:1a:79:06:19:eb:c7:2c:c2:51:93:7f:7a: 93:59:37:63:1e:53:b3:8d:d2:7f:f0:e3:49:42:22: f4:26:9b:b4:e4:a6:40:6d:8d:e7:ea:07:8e:ca:b7: 7e:88:71:9d:11:27:5a:e3:57:16:03:a7:ee:19:25: 07:d9:42:17:b4:eb:e6:97:61:13:54:62:03:ec:93: b7:e6:f1:7f:21:f0:71:2d:c4:8a:8f:20:d1:ab:5a: 6a:6c:f1:f6:2f:26:8c:39:32:93:93:67:bb:03:a7: 22:29:00:11:e0:a1:12:4b:02:79:fb:0f:fc:54:90: 30:65:cd:ea:e6:84:cc:91:fe:21:9c:c1:91:f3:17: 1e:44:7b:6f:23:e9:17:63:88:92:ea:80:a5:ca:38: 9a:b3:f8:08:cb:32:16:56:8b:c4:f7:54:ef:75:db: 36:7e:cf:ef:75:44:11:69:bf:7c:06:97:d1:87:ff: 5f:22:b5:ad:c3:94:a5:f8:a7:69:21:60:5a:04:5e: 00:15:04:77:47:03:ec:c5:7a:a2:bf:32:0e:4d:d8: dc:44:fa:26:39:16:84:a7:1f:11:ef:a3:37:39:a6: 35:b1:e9:a8:aa:a8:4a:72:8a:b8:c4:bf:04:70:12: b3:31 Exponent: 65537 (0x10001)


Salida

X509v3 extensions: X509v3 Subject Key Identifier: 35:06:F2:FE:CC:21:4B:92:DA:74:C9:47:CE:BB:37:21:5E:04:E2:E6 X509v3 Authority Key Identifier: keyid:35:06:F2:FE:CC:21:4B:92:DA:74:C9:47:CE:BB:37:21:5E:04:E2:E6 DirName:/O=Celerra Certificate Authority/CN=eng173100 serial:00X509v3 Basic Constraints: CA:TRUE X509v3 Subject Alternative Name: DNS:eng173100 Signature Algorithm: sha1WithRSAEncryption 09:c3:13:26:16:be:44:56:82:5d:0e:63:07:19:28:f3:6a:c4: f3:bf:93:25:85:c3:55:48:4e:07:84:1d:ea:18:cf:8b:b8:2d: 54:13:25:2f:c9:75:c1:28:39:88:91:04:df:47:2c:c0:8f:a4: ba:a6:cd:aa:59:8a:33:7d:55:29:aa:23:59:ab:be:1d:57:f6: 20:e7:2b:68:98:f2:5d:ed:58:31:d5:62:85:5d:6a:3f:6d:2b: 2d:f3:41:be:97:3f:cf:05:8b:7e:f5:d7:e8:7c:66:b2:ea:ed: 58:d4:f0:1c:91:d8:80:af:3c:ff:14:b6:e7:51:73:bb:64:84: 26:95:67:c6:60:32:67:c1:f7:66:f4:79:b5:5d:32:33:3c:00: 8c:75:7d:02:06:d3:1a:4e:18:0b:86:78:24:37:18:20:31:61: 59:dd:78:1f:88:f8:38:a0:f4:25:2e:c8:85:4f:ce:8a:88:f4: 4f:12:7e:ee:84:52:b4:91:fe:ff:07:6c:32:ca:41:d0:a6:c0: 9d:8f:cc:e8:74:ee:ab:f3:a5:b9:ad:bb:d7:79:67:89:34:52: b4:6b:39:db:83:27:43:84:c3:c3:ca:cd:b2:0c:1d:f5:20:de: 7a:dc:f0:1f:fc:70:5b:71:bf:e3:14:31:4c:7e:eb:b5:11:9c: 96:bf:fe:6f-----BEGIN CERTIFICATE-----MIIDoDCCAoigAwIBAgIBAzANBgkqhkiG9w0BAQUFADA8MSYwJAYDVQQKEx1DZWxlcnJhIENlcnRpZmljYXRlIEF1dGhvcml0eTESMBAGA1UEAxMJZW5nMTczMTAwMB4XDTA3MDMyMzIxMDc0MFoXDTEyMDMyMTIxMDc0MFowPDEmMCQGA1UEChMdQ2VsZXJyYSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxEjAQBgNVBAMTCWVuZzE3MzEwMDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANqyN4YFo3PVmgS62wWX0hL+GnkGGevHLMJRk396k1k3Yx5Ts43Sf/DjSUIi9CabtOSmQG2N5+oHjsq3fohxnREnWuNXFgOn7hklB9lCF7Tr5pdhE1RiA+yTt+bxfyHwcS3Eio8g0ataamzx9i8mjDkyk5NnuwOnIikAEeChEksCefsP/FSQMGXN6uaEzJH+IZzBkfMXHkR7byPpF2OIkuqApco4mrP4CMsyFlaLxPdU73XbNn7P73VEEWm/fAaX0Yf/XyK1rcOUpfinaSFgWgReABUEd0cD7MV6or8yDk3Y3ET6JjkWhKcfEe+jNzmmNbHpqKqoSnKKuMS/BHASszECAwEAAaOBrDCBqTAdBgNVHQ4EFgQUNQby/swhS5LadMlHzrs3IV4E4uYwZAYDVR0jBF0wW4AUNQby/swhS5LadMlHzrs3IV4E4uahQKQ+MDwxJjAkBgNVBAoTHUNlbGVycmEgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRIwEAYDVQQDEwllbmcxNzMxMDCCAQAwDAYDVR0TBAUwAwEB/zAUBgNVHREEDTALggllbmcxNzMxMDAwDQYJKoZIhvcNAQEFBQADggEBAAnDEyYWvkRWgl0OYwcZKPNqxPO/kyWFw1VITgeEHeoYz4u4LVQTJS/JdcEoOYiRBN9HLMCPpLqmzapZijN9VSmqI1mrvh1X9iDnK2iY8l3tWDHVYoVdaj9tKy3zQb6XP88Fi3711+h8ZrLq7VjU8ByR2ICvPP8UtudRc7tkhCaVZ8ZgMmfB92b0ebVdMjM8AIx1fQIG0xpOGAuGeCQ3GCAxYVndeB+I+Dig9CUuyIVPzoqI9E8Sfu6EUrSR/v8HbDLKQdCmwJ2PzOh07qvzpbmtu9d5Z4k0UrRrOduDJ0OEw8PKzbIMHfUg3nrc8B/8cFtxv+MUMUx+67URnJa//m8=-----END CERTIFICATE-----


Importación de un certificado de CAPara que los Data Movers reconozcan el certificado de CA, debe importarlo. Puede proporcionar un path e importar un archivo, o cortar y pegar el texto.

Generación de un nuevo certificado de CA para la Control Station

Nota: Esta tarea se requiere solo si el conjunto de claves de CA se ve comprometido o si el certificado de CA vence. El certificado de CA de la Control Station se genera durante la instalación o la actualización del software Celerra 5.6.

Para ejecutar este comando, debe ser usuario root.

Acción

Para importar un certificado de CA, utilice la siguiente sintaxis de comandos:$ server_certificate <movername> -ca_certificate -import [-filename <path>]

donde:<movername> = nombre del Data Mover físico con el que está asociado el certificado de CA.

<path> = ubicación del archivo que se importará.

Nota: El certificado de CA puede tener formato DER o PEM. Solo puede pegar texto en formato PEM en la línea de comandos. Si especifica -filename y proporciona un path, puede importar un certificado de CA en formato DER o PEM.

Ejemplo:

Para importar un certificado de CA, escriba:$ server_certificate server_2 -ca_certificate -import

Salida

server_2 : Please paste certificate data. Enter a carriage return and on the new line type ‘end of file’ or ‘eof’ followed by another carriage return.

Nota

Después de pegar correctamente el texto del certificado, se muestra el indicador del sistema.

Acción

Para generar un nuevo certificado y conjunto de claves para la Control Station, escriba:# /nas/sbin/nas_ca_certificate -generate

Nota: De forma predeterminada, este certificado es válido durante cinco años desde la fecha de generación y el nombre del certificado es el nombre de host de la Control Station.


Visualización del certificadoVea el texto del certificado de CA de la Control Station y cópielo para distribuirlo a los clientes de la red.

Salida

New keys and certificate were successfully generated.

Acción

Para ver el certificado de CA de la Control Station, escriba:$ /nas/sbin/nas_ca_certificate -display

Nota: El texto del certificado aparece en la pantalla de la terminal. De forma alternativa, puede redirigirlo a un archivo.

Salida

Certificate: Data: Version: 3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: sha1WithRSAEncryption Issuer: O=Celerra Certificate Authority, CN=eng173100 Validity Not Before: Mar 23 21:07:40 2007 GMT Not After: Mar 21 21:07:40 2012 GMT Subject: O=Celerra Certificate Authority, CN=eng173100 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:da:b2:37:86:05:a3:73:d5:9a:04:ba:db:05:97: d2:12:fe:1a:79:06:19:eb:c7:2c:c2:51:93:7f:7a: 93:59:37:63:1e:53:b3:8d:d2:7f:f0:e3:49:42:22: f4:26:9b:b4:e4:a6:40:6d:8d:e7:ea:07:8e:ca:b7: 7e:88:71:9d:11:27:5a:e3:57:16:03:a7:ee:19:25: 07:d9:42:17:b4:eb:e6:97:61:13:54:62:03:ec:93: b7:e6:f1:7f:21:f0:71:2d:c4:8a:8f:20:d1:ab:5a: 6a:6c:f1:f6:2f:26:8c:39:32:93:93:67:bb:03:a7: 22:29:00:11:e0:a1:12:4b:02:79:fb:0f:fc:54:90: 30:65:cd:ea:e6:84:cc:91:fe:21:9c:c1:91:f3:17: 1e:44:7b:6f:23:e9:17:63:88:92:ea:80:a5:ca:38: 9a:b3:f8:08:cb:32:16:56:8b:c4:f7:54:ef:75:db: 36:7e:cf:ef:75:44:11:69:bf:7c:06:97:d1:87:ff: 5f:22:b5:ad:c3:94:a5:f8:a7:69:21:60:5a:04:5e: 00:15:04:77:47:03:ec:c5:7a:a2:bf:32:0e:4d:d8: dc:44:fa:26:39:16:84:a7:1f:11:ef:a3:37:39:a6: 35:b1:e9:a8:aa:a8:4a:72:8a:b8:c4:bf:04:70:12: b3:31 Exponent: 65537 (0x10001)


Salida

X509v3 extensions: X509v3 Subject Key Identifier: 35:06:F2:FE:CC:21:4B:92:DA:74:C9:47:CE:BB:37:21:5E:04:E2:E6 X509v3 Authority Key Identifier: keyid:35:06:F2:FE:CC:21:4B:92:DA:74:C9:47:CE:BB:37:21:5E:04:E2:E6 DirName:/O=Celerra Certificate Authority/CN=eng173100 serial:00X509v3 Basic Constraints: CA:TRUE X509v3 Subject Alternative Name: DNS:eng173100 Signature Algorithm: sha1WithRSAEncryption 09:c3:13:26:16:be:44:56:82:5d:0e:63:07:19:28:f3:6a:c4: f3:bf:93:25:85:c3:55:48:4e:07:84:1d:ea:18:cf:8b:b8:2d: 54:13:25:2f:c9:75:c1:28:39:88:91:04:df:47:2c:c0:8f:a4: ba:a6:cd:aa:59:8a:33:7d:55:29:aa:23:59:ab:be:1d:57:f6: 20:e7:2b:68:98:f2:5d:ed:58:31:d5:62:85:5d:6a:3f:6d:2b: 2d:f3:41:be:97:3f:cf:05:8b:7e:f5:d7:e8:7c:66:b2:ea:ed: 58:d4:f0:1c:91:d8:80:af:3c:ff:14:b6:e7:51:73:bb:64:84: 26:95:67:c6:60:32:67:c1:f7:66:f4:79:b5:5d:32:33:3c:00: 8c:75:7d:02:06:d3:1a:4e:18:0b:86:78:24:37:18:20:31:61: 59:dd:78:1f:88:f8:38:a0:f4:25:2e:c8:85:4f:ce:8a:88:f4: 4f:12:7e:ee:84:52:b4:91:fe:ff:07:6c:32:ca:41:d0:a6:c0: 9d:8f:cc:e8:74:ee:ab:f3:a5:b9:ad:bb:d7:79:67:89:34:52: b4:6b:39:db:83:27:43:84:c3:c3:ca:cd:b2:0c:1d:f5:20:de: 7a:dc:f0:1f:fc:70:5b:71:bf:e3:14:31:4c:7e:eb:b5:11:9c: 96:bf:fe:6f-----BEGIN CERTIFICATE-----MIIDoDCCAoigAwIBAgIBAzANBgkqhkiG9w0BAQUFADA8MSYwJAYDVQQKEx1DZWxlcnJhIENlcnRpZmljYXRlIEF1dGhvcml0eTESMBAGA1UEAxMJZW5nMTczMTAwMB4XDTA3MDMyMzIxMDc0MFoXDTEyMDMyMTIxMDc0MFowPDEmMCQGA1UEChMdQ2VsZXJyYSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxEjAQBgNVBAMTCWVuZzE3MzEwMDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANqyN4YFo3PVmgS62wWX0hL+GnkGGevHLMJRk396k1k3Yx5Ts43Sf/DjSUIi9CabtOSmQG2N5+oHjsq3fohxnREnWuNXFgOn7hklB9lCF7Tr5pdhE1RiA+yTt+bxfyHwcS3Eio8g0ataamzx9i8mjDkyk5NnuwOnIikAEeChEksCefsP/FSQMGXN6uaEzJH+IZzBkfMXHkR7byPpF2OIkuqApco4mrP4CMsyFlaLxPdU73XbNn7P73VEEWm/fAaX0Yf/XyK1rcOUpfinaSFgWgReABUEd0cD7MV6or8yDk3Y3ET6JjkWhKcfEe+jNzmmNbHpqKqoSnKKuMS/BHASszECAwEAAaOBrDCBqTAdBgNVHQ4EFgQUNQby/swhS5LadMlHzrs3IV4E4uYwZAYDVR0jBF0wW4AUNQby/swhS5LadMlHzrs3IV4E4uahQKQ+MDwxJjAkBgNVBAoTHUNlbGVycmEgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRIwEAYDVQQDEwllbmcxNzMxMDCCAQAwDAYDVR0TBAUwAwEB/zAUBgNVHREEDTALggllbmcxNzMxMDAwDQYJKoZIhvcNAQEFBQADggEBAAnDEyYWvkRWgl0OYwcZKPNqxPO/kyWFw1VITgeEHeoYz4u4LVQTJS/JdcEoOYiRBN9HLMCPpLqmzapZijN9VSmqI1mrvh1X9iDnK2iY8l3tWDHVYoVdaj9tKy3zQb6XP88Fi3711+h8ZrLq7VjU8ByR2ICvPP8UtudRc7tkhCaVZ8ZgMmfB92b0ebVdMjM8AIx1fQIG0xpOGAuGeCQ3GCAxYVndeB+I+Dig9CUuyIVPzoqI9E8Sfu6EUrSR/v8HbDLKQdCmwJ2PzOh07qvzpbmtu9d5Z4k0UrRrOduDJ0OEw8PKzbIMHfUg3nrc8B/8cFtxv+MUMUx+67URnJa//m8=-----END CERTIFICATE-----


Distribución del certificado de CA de la Control StationEl certificado de CA de la Control Station debe estar disponible, de modo que los clientes de red puedan importarlo y utilizarlo a fin de reconocer los certificados que envían los Data Movers firmados por esta Control Station.

Paso Acción

1. Guarde el certificado de CA de la Control Station en un archivo (por ejemplo, cs_ca_cert.crt).

2. Ponga a disposición de los clientes de red este archivo .crt por medio del mecanismo apropiado (FTP o correo electrónico).

3. Vuelva a generar una nueva solicitud de certificado y conjunto de claves, e importe un certificado firmado para las personas cuyos certificados están firmados por la Control Station. "Creación del certificado proporcionado por la persona" en la página 42 describe este procedimiento.

4. Si un Data Mover es cliente de otro Data Mover, importe el nuevo certificado de CA en el Data Mover apropiado. "Obtención de certificados de CA" en la página 42 describe este procedimiento.


Administración de la PKI"Consideraciones de planificación para la Infraestructura de claves públicas (PKI)" en la página 26 proporciona una descripción general de esta función.

Las tareas para administrar los certificados y los conjuntos de claves de personas son las siguientes:

◆ "Visualización de las propiedades del certificado y el conjunto de claves" en la página 56

◆ "Búsqueda de conjuntos de claves vencidos" en la página 57

◆ "Eliminación de conjuntos de claves" en la página 57

Las tareas para administrar el certificado de CA son las siguientes:

◆ "Visualización de propiedades de un certificado de CA" en la página 58

◆ "Búsqueda de certificados de CA vencidos" en la página 58

◆ "Eliminación de certificados de CA" en la página 59

Visualización de las propiedades del certificado y el conjunto de claves

Acción

Para ver las propiedades de un certificado y un conjunto de claves, utilice la siguiente sintaxis de comandos:$ server_certificate <movername> -persona -info {-all | <persona_name> | id=<persona_id>}




Ejemplo:

Para ver el certificado y el conjunto de claves de la persona denominada default, escriba:$ server_certificate server_2 -persona -info default

Salida

server_2 : id=1 name=default next state=Not Available CURRENT CERTIFICATE: id = 1 subject = CN=test;CN=1.2.3.4 issuer = O=Celerra Certificate Authority;CN=eng173100 start date = 20070606183824Z end date = 20070706183824Z serial number = 05 signature alg. = sha1WithRSAEncryption public key alg. = rsaEncryption public key size = 4096 version = 3


Búsqueda de conjuntos de claves vencidosNo existe ningún modo automatizado para verificar los certificados y los conjuntos de claves públicas vencidos. Para verificar los certificados vencidos, debe enumerar las personas y revisar las fechas de vencimiento de los certificados asociados con cada persona.

Eliminación de conjuntos de clavesDebe eliminar los conjuntos de claves cuando venzan, cuando ya no se necesite el servicio o cuando no se cumplirá con la solicitud de certificado. Puede borrar el certificado y el conjunto de claves actuales de una persona, el certificado y el conjunto de claves siguientes, o ambos.

Acción

Para enumerar todos los certificados y conjuntos de claves que se encuentran disponibles, escriba:$ server_certificate ALL -persona -list

Salida

server_2 : id=1 name=default next state=Request Pending request subject=CN=name;CN=1.2.3.4server_3 : id=1 name=default next state=Not Available CURRENT CERTIFICATE: id=1 subject=CN=test;CN=1.2.3.4 expire=20070608183824Z issuer=O=Celerra Certificate Authority;CN=eng173100

Nota

La fecha de vencimiento del certificado actual figura en el campo Expire. 20070608183824Z equivale a viernes, 8 de junio de 2007, 18:38:24 GMT.

Acción

Para eliminar un conjunto de claves y el certificado asociado, utilice la siguiente sintaxis de comandos:$ server_certificate <movername> -persona -clear {<persona_name> | id=<persona_id>} {-next | -current | -both}

donde:<movername> = nombre asignado al Data Mover físico con el que está asociada la persona.



Ejemplo:

Para borrar el certificado y el conjunto de claves actuales y siguientes de la persona en server_2, escriba:$ server_certificate server_2 -persona -clear default -both


Visualización de propiedades de un certificado de CA

Búsqueda de certificados de CA vencidosNo existe ningún modo automatizado para verificar los certificados de CA vencidos. Para verificar los certificados vencidos, debe enumerar los certificados de CA y revisar las fechas de vencimiento.

Salida

server_2 : done

Acción

Para ver las propiedades de un certificado de CA, utilice la siguiente sintaxis de comandos:$ server_certificate <movername> -ca_certificate -info {-all | <certificate_id>}


<certificate_id> = ID del certificado.

Nota: Use la opción -all para ver las propiedades de todos los certificados de CA disponibles para el Data Mover.

Ejemplo:

Para ver las propiedades del certificado de CA identificado por el ID de certificado 2, escriba:$ server_certificate server_2 -ca_certificate -info 2

Salida

server_2 :id=2subject = C=US;O=VeriSign, Inc.;OU=Class 3 Public Primary Certification Authorityissuer = C=US;O=VeriSign, Inc.;OU=Class 3 Public Primary Certification Authoritystart = 19960129000000Zexpire = 20280801235959Zsignature alg. = md2WithRSAEncryptionpublic key alg. = rsaEncryptionpublic key size = 2048 bitsserial number = 70ba e41d 10d9 2934 b638 ca7b 03cc babfversion = 1

Acción

Para enumerar todos los certificados de CA que se encuentran disponibles, escriba:$ server_certificate ALL -ca_certificate -list


Eliminación de certificados de CADebe eliminar un certificado de CA cuando haya vencido, se vea comprometido o ya no sea necesario para autenticar un servidor.

Salida

server_2 :id=1subject=O=Celerra Certificate Authority;CN=sorentoissuer=O=Celerra Certificate Authority;CN=sorentoexpire=20120318032639Zid=2subject=C=US;O=VeriSign, Inc.;OU=Class 3 Public Primary Certification Authorissuer=C=US;O=VeriSign, Inc.;OU=Class 3 Public Primary Certification Authorexpire=20280801235959Z

server_3 :id=1subject=O=Celerra Certificate Authority;CN=zeus-csissuer=O=Celerra Certificate Authority;CN=zeus-csexpire=20120606181215Z

Nota

La fecha de vencimiento del certificado figura en el campo Expire. 20120318032639Z equivale a 18 de marzo de 2012, 03:26:39 GMT.

Acción

Para eliminar un certificado de CA, utilice la siguiente sintaxis de comandos:$ server_certificate <movername> -ca_certificate -delete {-all | <certificate_id>}


<certificate_id> = ID del certificado. Puede determinar el ID mediante el comando -ca_certificate -list.

Nota: Use la opción -all para eliminar todos los certificados de CA disponibles para el Data Mover.

Ejemplo:

Para eliminar el certificado de CA en server_2 identificado por su número de ID, escriba:$ server_certificate server_2 -ca_certificate -delete 1

Salida

server_2 : done


Resolución de problemas Como parte de su esfuerzo continuo por mejorar y optimizar el performance y las capacidades de sus líneas de productos, EMC lanza periódicamente nuevas versiones de las herramientas de hardware y software Celerra. En consecuencia, es posible que algunas de las funciones que se describen en este documento no se soporten en todas las revisiones de las herramientas de hardware y software que se encuentran en uso actualmente. Para obtener la información más reciente acerca de las funciones de cada producto, consulte las notas de la versión del producto correspondiente.

Si un producto no funciona correctamente o de la manera que se describe en este documento, póngase en contacto con su representante de EMC.

Dónde obtener ayudaPara obtener información sobre licencias, productos y servicio de EMC, consulte:

Información de productos: para ver documentación, notas de la versión, actualizaciones de software o para obtener información sobre productos, licencias y servicios de EMC, visite el sitio Web de EMC Powerlink (registro obligatorio) en la dirección:

http://Powerlink.EMC.com

Soporte técnico: para obtener soporte técnico, visite Servicio al Cliente de EMC en Powerlink. Inicie sesión en el sitio Web de EMC Powerlink, vaya a Soporte > Solicitar Soporte. Para abrir una solicitud de servicio por medio de Powerlink, debe contar con un acuerdo de soporte válido. Comuníquese con un representante del Servicio al Cliente de EMC para obtener detalles sobre cómo obtener un acuerdo de soporte válido o para formular preguntas sobre su cuenta.

Nota: No solicite un representante de soporte específico a menos que ya le haya asignado uno para su problema específico del sistema.

EMC Problem Resolution Roadmap for Celerra contiene información adicional sobre el uso de Powerlink y la resolución de problemas.

EMC E-Lab Interoperability NavigatorEMC E-LabTM Interoperability Navigator es una aplicación basada en Web en la que se pueden hacer búsquedas que brinda acceso a matrices de soporte de interoperabilidad de EMC. Está disponible en http://Powerlink.EMC.com. Después de iniciar sesión en Powerlink, vaya a Soporte > Información de Interoperabilidad y de Ciclo de Vida de Productos > E-Lab Interoperability Navigator.

Resolución de problemas de la conexión de Control Station a un servidor de directoriosPrueba de la conexión de Control Station a un servidor de directoriosPuede comprobar el correcto funcionamiento de la conexión de la Control Station con un servidor de directorios basado en LDAP si selecciona Test en la ficha Administrators > Domain Settings. Si especificó un servidor de directorios primario y de backup, ambas conexiones se prueban al mismo tiempo.

http://Powerlink.EMC.com


../ProblemResolutionRoadmap/index.htm




Si se puede acceder a al menos un servidor de directorios de forma correcta, la autenticación del usuario administrativo se realiza sin inconvenientes incluso si la conexión con el otro servidor de directorios no se puede establecer. No obstante, la función de prueba continuará informando una falla hasta que pueda conectarse correctamente con los servidores de directorios especificados.

La falla indica que la configuración de vinculación de dominio, las direcciones o los paths de búsqueda son incorrectos, o que uno o ambos servidores no están disponibles La función Test solo garantiza que la Control Station pueda conectarse (vincularse) con el servidor de directorios. No pone a prueba la localización de grupos y usuarios.

Nota: Un servidor de directorios de backup debe soportar la misma configuración de dominio que el servidor de directorios primario.

Creación de la cuenta de usuario que se vincula con el servicio de directoriosEMC recomienda que la cuenta de usuario que se utiliza como vínculo al servicio de directorios tenga las mayores restricciones posibles (por ejemplo, una cuenta cuyo grupo primario sea de invitados de dominio). Si la cuenta de usuario no puede vincularse con el servicio de directorios, compruebe lo siguiente:

1. Compruebe que la Asignación de derechos de usuario de GPO no incluya invitados en la lista de usuarios a los que se les denegó el acceso al controlador de dominios de la red.

2. En estos entornos, en los que los invitados no pueden conectarse a los controladores de dominio, el grupo primario de la cuenta de usuario posiblemente necesite ser de usuarios de dominio y no de invitados de dominio.

3. Si los problemas de acceso persisten, se debe utilizar una cuenta de usuario con más privilegios.

Asegúrese de que la cuenta seleccionada tenga privilegios de lectura/búsqueda para el directorio.

Configuración de la sesión SSLPara crear correctamente la sesión SSL, se deben haber realizado correctamente las siguientes tareas de configuración:

◆ El certificado cargado en Control Station debe ser el certificado público de CA que firmó el certificado de servidor SSL del servidor de directorios basado en LDAP. Control Station utiliza este certificado de CA para verificar el certificado recibido del servidor LDAP.

◆ El nombre de host del servidor de directorios basado en LDAP (especificado en los campos Primary y Backup de la página Administrators > Domain Settings) y el nombre común proporcionado en el certificado del servidor de directorios deben coincidir. El valor que especifique depende del formato del asunto en el certificado del servidor de directorios; por lo común, el asunto se indica por su nombre de host, aunque puede ser la dirección IP.


Resolución de problemas de las cuentas de usuario administrativo localesHabilitación de una cuenta deshabilitada mediante el cambio de contraseñaCelerra Manager, al igual que el sistema operativo Linux, habilita una cuenta de usuario administrativo local previamente deshabilitada si se cambia su contraseña. La cuenta no puede habilitarse realizando otro tipo de cambio.

Uso de cuentas de usuario localesCelerra proporciona la posibilidad de crear cuentas de usuario administrativo estrictamente locales además de cuentas de usuario administrativo locales asignadas por dominio.

Debe utilizar una cuenta de usuario local para iniciar sesión directamente en un Celerra específico. Este tipo de cuenta de usuario local es relevante solo para el Celerra en el que se creó y se utiliza para administrarlo.

Las cuentas de usuario locales creadas para usuarios de dominio proporcionan el mecanismo para verificar que un usuario autenticado por un servidor de directorios externo esté autorizado para acceder a Celerra Network Server y que tenga las credenciales locales necesarias, incluido el UID, para realizar tareas. Debe utilizar una cuenta de dominio para acceder y administrar de forma remota múltiples Celerras, y evitar así la necesidad de configurar cuentas de usuario individuales en cada Celerra que administra.

Importante: No utilice el nombre local de una cuenta asignada por dominio para iniciar sesión en Celerra.

Limpieza de cuentas de usuario locales desactualizadasEn determinadas circunstancias, es posible que necesite eliminar manualmente cuentas de usuario locales desactualizadas de Celerra. Este problema solo se da cuando los nombres de usuario son exactamente iguales. Por ejemplo, el usuario Jennifer Smith tiene una cuenta de usuario local asignada por dominio denominada JSmith. Más adelante, Jennifer adopta su nombre de casada y su cuenta de usuario en el servidor de directorios cambia a JBrown, lo que genera una nueva cuenta de usuario local asignada por dominio. No obstante, cuando se crea un nuevo usuario, Joshua Smith, en el servidor de directorios con el nombre de usuario JSmith y se asigna a Celerra, se asigna a este usuario la cuenta de usuario local existente JSmith y recibe los privilegios anteriormente asignados a Jennifer.

EMC recomienda que, en el servidor de directorios, se evite volver a utilizar nombres de usuarios para diferentes usuarios físicos. Si no puede evitarse el uso duplicado, para evitar la posible situación problemática descrita anteriormente, debe utilizar Celerra Manager para realizar una de las siguientes acciones:

◆ En el caso en el que el nombre de usuario del directorio del administrador de Celerra se cambie, modifique manualmente el nombre de usuario local y el nombre de usuario de dominio en la cuenta de usuario local asignada por dominio.

◆ En el caso en el que la cuenta del administrador de Celerra se quite del servidor de directorios, elimine manualmente la cuenta de usuario local asignada por dominio y el directorio principal.


Comprensión de cómo se crean los nombres de cuenta de usuario localCuando se asigna automáticamente una cuenta de usuario local desde un usuario de dominio, Celerra le asigna un nombre en función del nombre del servidor de directorios del usuario y del nombre de dominio. Si el nombre de usuario incluye espacios, se quitarán.

Resolución de problemas de cuentas de usuario administrativo asignadas por dominioCuando un usuario administrativo asignado por dominio inicia sesión en Control Station, el nombre de dominio proporcionado debe coincidir con el nombre de dominio o el nombre de dominio completamente calificado conocido para Celerra, es decir, el nombre de dominio definido en la ficha Domain Settings de Celerra Manager. De lo contrario, el usuario no podrá iniciar sesión.

Los formatos de inicio de sesión de usuario asignado por dominio soportados son:

◆ <domain name>\<user> (por ejemplo, mycompany\anne)

◆ <fully-qualified domain name>\<user> (por ejemplo, mycompany.com\anne)

◆ <user>@<domain name> (por ejemplo, anne@mycompany)

◆ <user>@<fully-qualified domain name> (por ejemplo, [email protected])

Nota: Los usuarios solamente pueden iniciar sesión con un dominio. En consecuencia, mycompany y mycompany.com son tratados como el mismo dominio.

Resolución de problemas de importaciones de certificadosLos certificados se utilizan por los Data Movers y Control Station para identificar uno o ambos extremos de una conexión habilitada por SSL. El Data Mover puede importar certificados codificados utilizando el formato de Distinguished Encoding Rules (DER), también conocido como X.509 con codificación binaria o el formato Privacy Enhanced Mail (PEM), también conocido como X.509 con codificación Base64. Control Station puede importar certificados codificados utilizando el formato PEM.

Un archivo de certificado en el formato DER está compuesto por datos binarios. El formato PEM utiliza la codificación Base64 para transformar texto binario en texto ASCII, traduciendo cada 6 bits a un carácter ASCII específico y enviando el texto del certificado (hasta 64 caracteres) en las líneas BEGIN CERTIFICATE y END CERTIFICATE. Según el origen del archivo de certificado, el certificado con codificación PEM puede estar precedido por otro texto que menciona el contenido del certificado. La traducción de texto binario en texto evita que los datos sean modificados en tránsito entre sistemas, por ejemplo, por medio de correo electrónico.

Importación de un certificado en el Data MoverIntento de importación de un certificado vencido

Si recibe un error al importar un certificado, verifique que no hayan vencido la fecha y hora de validez del certificado. No es posible importar un certificado vencido al Data Mover.


Importación de un certificado con codificación DER

Si recibe un error al importar un certificado con codificación DER a un Data Mover, compruebe lo siguiente:

◆ Verifique que el certificado sea válido con una herramienta como OpenSSL o Microsoft Certificate Server. Para utilizar estas herramientas, el archivo debe tener una extensión válida, como .der, .cer o .crt.

◆ Si el certificado no es válido, es decir, si la herramienta informa un error, es posible que el archivo de certificado esté dañado y deba reemplazarse por una copia no dañada.

◆ Si el certificado es válido, utilice la herramienta para exportar el certificado en formato PEM, verifique que el certificado con codificación PEM sea válido e importe la versión PEM del certificado.

Importación de un certificado con codificación PEM

Si recibe un error al importar un certificado con codificación PEM a un Data Mover, compruebe lo siguiente:

◆ Verifique que el formato PEM del archivo de certificado sea correcto.

◆ Verifique que el certificado sea válido con una herramienta como OpenSSL o Microsoft Certificate Server. Si el certificado no es válido, es decir, si la herramienta informa un error, es posible que el archivo de certificado esté dañado y deba reemplazarse por una copia no dañada.

Importación de un certificado en una Control StationControl Station no devuelve un error si se carga un certificado vencido. No obstante, Control Station no utilizará un certificado desactualizado para verificar el certificado recibido del servidor de directorios basado en LDAP.

Puede determinar la fecha de vencimiento del certificado actualmente instalado visualizando las propiedades del certificado en el campo SSL Certificate.

Mensajes de error A partir de la versión 5.6, todos los mensajes de estado, alertas y nuevos eventos proporcionan información detallada y acciones recomendadas para ayudarlo a resolver problemas.

Para ver información detallada de los mensajes, utilice alguno de los siguientes métodos:

◆ Celerra Manager:

• Haga clic con el botón secundario sobre un mensaje de estado, alerta o evento, y seleccione ver Event Details, Alert Details o Status Details.

◆ Celerra CLI:

• Utilice el comando nas_message -info <message_id> para recuperar información detallada sobre un error específico.

◆ EMC Celerra Network Server Error Messages Guide:

• Utilice esta guía para hallar información sobre mensajes que se encuentren en formato de mensaje de una versión anterior.

../ErrorMsgs/index.htm

../ErrorMsgs/index.htm


◆ Powerlink:

• Utilice el texto de la descripción breve del mensaje de error para realizar búsquedas en la Knowledgebase, en Powerlink. Inicie sesión en Powerlink y haga clic en Soporte > Búsqueda en la Knowledgebase> Buscar todo.

Programas de capacitación para clientesLos programas de capacitación para clientes de EMC están diseñados para ayudarlo a aprender la manera en que interoperan los productos de almacenamiento de EMC y se integran en del entorno para maximizar toda la inversión en infraestructura. Los programas de capacitación para clientes de EMC incluyen capacitación en línea y práctica en los laboratorios de última generación, que se encuentran distribuidos en todo el mundo para brindar gran comodidad. Los programas de capacitación para clientes de EMC son desarrollados e impartidos por expertos de EMC. Para obtener más información sobre los programas y registrarse, inicie sesión en Powerlink, nuestro sitio Web para clientes y partners, y seleccione el menú Capacitación.




Apéndice A: Series de cifrado de SSL soportadasLa Tabla 10 en la página 66 muestra las series de cifrado que soporta Celerra. Las siguientes listas les asignan a las series de cifrado SSL o TLS nombres de la especificación relevante y sus equivalentes de OpenSSL. Cabe destacar que varios nombres de las series de cifrado no incluyen la autenticación empleada, por ejemplo, DES-CBC3-SHA. En estos casos, se utiliza la autenticación RSA.

Se aplican las siguientes restricciones:

◆ Las series de cifrado ADH y los cifrados NULL se encuentran desactivados de forma predeterminada (porque no permiten la autenticación).

◆ Celerra no acepta algunas series de cifrado, debido al tamaño del certificado (si el certificado presentado por el Data Mover tiene una clave de 2048 bits, se rechazan los cifrados con claves más pequeñas).

Tabla 10 Series de cifrado de SSL soportadas (página 1 de 2)

Protocolo Nombre de la especificación Nombre de OpenSSL

Series de cifrado SSL v3.0

SSL_RSA_WITH_NULL_MD5 NULL-MD5

SSL_RSA_WITH_NULL_SHA NULL-SHA

SSL_RSA_WITH_DES_CBC_SHA DES-CBC-SHA

SSL_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA

SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-RSA-DES-CBC-SHA

SSL_DHE_RSA_WITH_DES_CBC_SHA EDH-RSA-DES-CBC-SHA

SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA EDH-RSA-DES-CBC3-SHA

SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 EXP-ADH-RC4-MD5

SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA EXP-ADH-DES-CBC-SHA

SSL_DH_anon_WITH_DES_CBC_SHA ADH-DES-CBC-SHA


Series de cifrado TLS v1.0

TLS_RSA_WITH_NULL_MD5 NULL-MD5

TLS_RSA_WITH_NULL_SHA NULL-SHA

TLS_RSA_EXPORT_WITH_RC4_40_MD5 EXP-RC4-MD5

TLS_RSA_WITH_RC4_128_MD5 RC4-MD5

TLS_RSA_WITH_RC4_128_SHA RC4-SHA

TLS_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-DES-CBC-SHA

TLS_DH_anon_WITH_RC4_128_MD5 ADH-RC4-MD5

TLS_DH_anon_WITH_3DES_EDE_CBC_SHA ADH-DES-CBC3-SHA

Series de cifrado AES de RFC3268, con ampliación de TLS v1.0

TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA

TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA

TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE-RSA-AES128-SHA

TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE-RSA-AES256-SHA

TLS_DH_anon_WITH_AES_128_CBC_SHA ADH-AES128-SHA

TLS_DH_anon_WITH_AES_256_CBC_SHA ADH-AES256-SHA

Exportación adicional 1024 y otras series de cifrado

Nota: Estos cifrados pueden utilizarse además en SSL v3.

TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA EXP1024-DES-CBC-SHA

TLS_RSA_EXPORT1024_WITH_RC4_56_SHA EXP1024-RC4-SHA

Series de cifrado SSL v2.0

SSL_CK_DES_64_CBC_WITH_MD5 DES-CBC-MD5

SSL_CK_DES_192_EDE3_CBC_WITH_MD5 DES-CBC3-MD5

Tabla 10 Series de cifrado de SSL soportadas (página 2 de 2)

Protocolo Nombre de la especificación Nombre de OpenSSL


Apéndice B: Comprensión de la configuración del servidor de directoriosEste apéndice proporciona información sobre las herramientas que puede utilizar para comprender mejor la estructura de la información de su organización en el servidor de directorios basado en LDAP y sugerencias sobre cómo interpretar esta información. Debe saber dónde se encuentran los usuarios y los grupos. Use esta información para configurar el servidor de directorios como se detalla en "Configuración del uso de un servidor de directorios externo para identificación y autenticación de usuarios administrativos" en la página 29 y para configurar la conexión entre el servidor de directorios y el cliente basado en LDAP de la Control Station. Para hacerlo, vaya a la ficha Administrators > Domain Settings de Celerra Manager.

Hay varias herramientas disponibles para administrar los servicios de directorios basados en LDAP, entre ellas, se encuentran:

◆ "Usuarios y equipos de Active Directory" en la página 68

◆ "Ldap Admin" en la página 76

Usuarios y equipos de Active Directory Las cuentas de usuario y de grupo de Active Directory pueden administrarse con el snap-in MMC de Extensiones de usuarios y computadoras de Active Directory (ADUC). Este snap-in se instala automáticamente en cada controlador de dominio de Windows. Puede acceder a esta herramienta desde Control Panel (Panel de control) > Administrative Tools (Herramientas administrativas) > Active Directory Users & Computers (Usuarios y equipos de Active Directory).

La Tabla 11 en la página 68 incluye la información que necesita para conectarse correctamente a Active Directory.

Tabla 11 Información necesaria para conectarse a un servidor de directorios Active Directory

Información de conexión necesaria Sus valores

Nombre de dominio completamente calificado (también conocido como nombre distinguido de la base)

Dirección IP o nombre de host del servidor de directorios/controlador de dominio principal

Dirección IP o nombre de host del servidor de directorios/controlador de dominio secundario

Nombre de cuenta (también conocido como nombre distinguido de vinculación)


Paso Acción

1. Abra ADUC y (si es necesario) conéctese con el dominio. Haga clic con el botón secundario en el nombre de dominio y, a continuación, seleccione Find (Buscar) en el menú.


2. Identifique al usuario de dominio que será el usuario administrativo de Celerra. Para buscar el perfil del usuario, escriba el nombre del usuario en el campo Find (Buscar) y haga clic en Find Now (Buscar ahora).

Paso Acción


3. Agregue el path X.500 a la información de usuario que se muestra al seleccionar View (Ver) > Choose Columns (Elegir columnas).

4. Seleccione X500 Distinguished Name (Nombre distinguido de X500) en el campo Columns available (Columnas disponibles) y haga clic en Add (Agregar).

Paso Acción


5. La ventana Buscar muestra el nombre distinguido de X.500 del usuario administrativo. El nombre distinguido de X.500 contiene el nombre del usuario (CN=Joe Muggs) y el path al contenedor en el que se encuentra el usuario en la estructura de directorios: CN=Users,DC=derbycity,DC=local. Registre el path.

Paso Acción


6. Asegúrese de que todos los demás usuarios administrativos de Celerra usen el mismo path. Para esto:

• Repita la opción Buscar para todas las cuentas de usuarios administrativos de Celerra

o

• Desplácese hasta el área de directorios en ADUC y busque todas las cuentas de usuarios administrativos de Celerra.

7. Repita los pasos 1 a 6 para buscar el path del contenedor en la estructura de directorios donde se encuentran los grupos.

Si los paths del usuario y del grupo son CN=Users,DC=<domain component>,DC=<domain component>[, DC=<domain component>…] (por ejemplo, CN=Users,DC=derbycity,DC=local), puede usar la opción de Active Directory predeterminada de la ficha Configuración del dominio. Esta opción asume que los usuarios y los grupos se encuentran en el contenedor predeterminado (CN=Users), por lo tanto, no debe especificar el path de búsqueda de los usuarios o los grupos.

Paso Acción


8. Es posible que los usuarios no estén en el contenedor predeterminado (CN=Users). Tal vez estén ubicados en otros contenedores o unidades organizacionales dentro del directorio, por ejemplo, en el directorio de usuarios de Celerra. En este caso, debe usar la opción Custom Active Directory (Active Directory personalizado) de la ficha Domain Settings (Configuración del dominio) y escribir manualmente los paths de búsqueda.

9. Es posible que los grupos no estén en el contenedor predeterminado (CN=Users). No es necesario que estos estén ubicados con los usuarios. Pueden estar dentro de otros contenedores o unidades organizacionales dentro del directorio.

Paso Acción


10. La búsqueda de grupos y usuarios LDAP comienza con el path especificado y continúa con el contenedor y todos los contenedores que se encuentran incluidos. Si los grupos y los usuarios administrativos de Celerra no se encuentran dentro del mismo contenedor o unidad organizacional, debe utilizar la convergencia (partes comunes) de los paths colectivos al especificar los paths de búsqueda de los usuarios y los grupos. En algunos casos, deben ser la raíz del dominio. Por ejemplo, supongamos que los usuarios administrativos de Celerra están almacenados en las dos ubicaciones siguientes de Active Directory:

Path 1: CN=Users,DC=derbycity,DC=local.

Path 2: OU=Celerra Users,OU=EMC Celerra,DC=derbycity,DC=local

Para que Celerra pueda encontrar todos los usuarios administrativos, se debe utilizar la convergencia de los dos paths como path de búsqueda, es decir, la raíz del dominio DC=derbycity,DC=local.

Escriba este valor en el campo User Search Path (Ruta de búsqueda del usuario), en la ficha Domain Settings (Configuración del dominio).

11. Use la ventana Buscar nuevamente para determinar el path completo de X.500 de la cuenta que utilizará para conectar Celerra Control Station con el directorio. En este caso, no debe quitar el nombre de usuario del path, porque está especificando el path a una cuenta individual.

Si utiliza la opción Default Active Directory (Active Directory predeterminado) de la ficha Domain Settings (Configuración del dominio), escriba solo el nombre de la cuenta, por ejemplo Celerra LDAP Binding, en el campo Account Name (Nombre de cuenta). No debe proporcionar la sintaxis de X.500, porque el software Celerra construye el path completo de X.500.

Si utiliza la opción Custom Active Directory (Active Directory predeterminado) en la ficha Domain Settings (Configuración del dominio), escriba el path completo de X.500 en el campo Distinguished Name (Nombre distinguido).

Paso Acción


Ldap AdminA diferencia de Active Directory, otros servidores de directorios basados en LDAP no se suministran con una interfaz de administración GUI. En estos casos, puede utilizar una herramienta, como Ldap Admin, para especificar los paths de búsqueda adecuados en los servidores LDAP. La herramienta gratuita Ldap Admin (un administrador LDAP de Windows disponible en ldapadmin.sourceforge.net) permite explorar, buscar, modificar, crear y eliminar objetos en un servidor LDAP. La funcionalidad Copy-to-clipboard de Ldap Admin resulta especialmente útil para transferir fácilmente los valores en la ficha Domain Settings (Configuración del dominio) de Celerra Manager.

La Tabla 12 en la página 76 incluye la información que necesita para conectarse correctamente con un servidor Active Directory personalizado u otro servidor de directorios basado en LDAP, como OpenLDAP.

Tabla 12 Información que se necesita para conectarse con un servidor Active Directory personalizado u otro servidor de directorios basado en LDAP

Información de conexión necesaria Sus valores

Nombre de dominio completamente calificado (también conocido como nombre distinguido de la base)

Dirección IP o nombre de host del servidor de directorios principal

Dirección IP o nombre de host del servidor de directorios secundario

Nombre distinguido (también conocido como nombre distinguido de vinculación)

Path de búsqueda del usuario

Atributo de nombre del usuario

Path de búsqueda del grupo

Atributo de nombre del grupo

Clase de grupo

Miembro del grupo


Paso Acción

1. Inicie Ldap Admin y cree una conexión nueva. Haga clic en Test connection (Probar conexión) para comprobar la conexión.


2. Abra la conexión con el servidor LDAP, haga clic con el botón secundario en el nombre de dominio y, a continuación, seleccione Search (Buscar) en el menú.

Paso Acción


3. Identifique al usuario LDAP que será el usuario administrativo de Celerra. Para buscar el perfil del usuario, escriba el nombre del usuario en el campo Name (Nombre) y haga clic en Start (Inicio).

Paso Acción


4. Haga clic con el botón secundario en el usuario apropiado de la lista de resultados y, a continuación, seleccione Go to (Ir a) en el menú. Utilizará este usuario para determinar los paths de búsqueda de los usuarios y los grupos. Cierre la ventana Search (Buscar).

Paso Acción


5. En la ventana principal de Ldap Admin, la barra de estado contiene el nombre distinguido (DN) de la carpeta en la que se encuentra el usuario. Muchos servidores LDAP siguen la convención detallada en RFC2307 y colocan a los usuarios en un contenedor denominado People.

Paso Acción


6. Haga clic con el botón secundario en la carpeta y, a continuación, seleccione Copy dn to clipboard (Copiar al portapapeles) en el menú.

7. En la ficha Domain Settings (Configuración del dominio), seleccione la opción Other Directory Servers (Otros servidores de directorio). Pegue el valor de nombre distinguido en el campo User Search Path (Ruta de búsqueda del usuario).

Paso Acción


8. Asegúrese de que todos los demás usuarios administrativos de Celerra usen el mismo path. Para esto:

• Repita la función Search para todas las cuentas de usuarios administrativos de Celerra.

o

• Desplácese hasta el área de directorios en Ldap Admin y busque todas las cuentas de usuarios administrativos de Celerra.

Paso Acción


9. Repita los pasos 2 a 8 para buscar un nombre de grupo a fin de encontrar el path del contenedor en la estructura de directorios donde se encuentran los grupos. Cuando busque por nombre de grupo, debe utilizar la búsqueda avanzada y proporcionar un filtro de búsqueda con el formato cn=<group name>. Una vez que la búsqueda esté completa, haga clic con el botón secundario en el grupo correspondiente de la lista de resultados y, a continuación, seleccione Go to (Ir a) en el menú.

10. La búsqueda de grupos y usuarios LDAP comienza con el path especificado y continúa con el contenedor y todos los contenedores que se encuentran incluidos. Si los grupos y los usuarios administrativos de Celerra no se encuentran dentro del mismo contenedor o unidad organizacional, debe utilizar la convergencia (partes comunes) de los paths colectivos al especificar los paths de búsqueda de los usuarios y los grupos. En algunos casos, deben ser la raíz del dominio. Por ejemplo, supongamos que los usuarios administrativos de Celerra están almacenados en las dos ubicaciones siguientes de LDAP:

Path 1: OU=People,DC=openldap-eng,DC=local

Path 2: OU=Celerra Users,OU=EMC Celerra, DC=openldap-eng,DC=local

Para que Celerra pueda encontrar todos los usuarios administrativos de Celerra, se debe utilizar la convergencia de los dos paths como path de búsqueda, es decir, la raíz del dominio DC=openldap-eng,DC=local.

Paso Acción


11. Utilice la ventana Search para buscar la cuenta de usuario que utilizará para conectar Celerra Control Station con el directorio. Haga clic con el botón secundario en el nombre de la cuenta y, a continuación, seleccione Copy dn to clipboard (Copiar al portapapeles). Pegue el valor de nombre distinguido en el campo Distinguished Name (Nombre distinguido) de la ficha Domain Settings (Configuración del dominio), por ejemplo, uid=celerra,ou=People.

Paso Acción



Índice

Aacceso administrativo basado en funciones 10

creación 22predeterminado 24

administración de servicios de red 8, 13administración de SNMP 14auditoría 9autenticación Kerberos de CIFS 13

Bbanner de inicio de sesión 8

personalización 36

Ccertificados de CA

distribución 55eliminación 59generación 52importación 27, 52lista 49, 58obtención 27, 42, 49visualización 53visualización de propiedades 58

certificados de claves públicas 15borrado 57certificados de CA 27creación 42envío de la solicitud de certificado a la CA 46generación de un conjunto de claves y de la solicitud de

certificado 43importación de un certificado firmado por la CA 47lista 57personas 26visualización 56

certificados, claves públicascomprobación del certificado 21configuración de seguridad NFS 13contraseñas

cambio del valor predeterminado 25configuración del vencimiento 33definición de políticas específicas 33definición de políticas mediante un script 32política de calidad 11, 25

Control Stationacceso administrativo basado en funciones 10administración de servicios de red 8auditoría 9banner de inicio de sesión 8cambios en el sistema operativo Linux 7certificados SSL (X.509) 12configuración del uso del servidor de directorios 29identificación y autenticación de usuarios

administrativos 10MOTD 8política de calidad de las contraseñas 11

seguridad 3, 7seguridad para controlar el acceso 10seguridad para la infraestructura 8seguridad para proteger datos 12tiempo de espera de sesión agotado 8uso como CA 42uso del servidor de directorios basado en LDAP 10

cookie 7, 9credenciales estilo Windows 14

DData Mover

administración de servicios de red 13administración de SNMP 14autenticación Kerberos de CIFS 13certificados SSL (X.509) 15configuración de seguridad NFS 13credenciales estilo Windows para usuarios UNIX 14PKI 15políticas de acceso 14seguridad 3, 7seguridad para proteger datos 15seguridad para proteger la infraestructura 13

Iidentificación y autenticación de usuarios administrativos 10

planificación 16soporte de interfaces 16

Infraestructura de claves públicas, consulte PKI

Mmensaje del día 8

creación 37MOTD 8

Oopciones de la interfaz de usuario 3

Ppersonas

entrega de un certificado 42generación de un conjunto de claves 26importación de un certificado 26solicitud de un certificado firmado 26

PKI 39políticas de acceso 14privilegios administrativos 10, 16

Rresolución de problemas 60

conexión de Control Station con el servidor de directorios 60

configuración de la sesión SSL 61creación de cuenta de vinculación 61cuentas de usuario administrativo asignadas

por dominio 63

88 de 90 Guía de configuración de seguridad de EMC CelerraVersión 5.6

cuentas de usuario administrativo locales 62

SSecure Socket Layer, consulte SSLservidor de directorios basado en LDAP

herramientas 68resolución de problemas 60, 61uso para identificación y autenticación de usuarios

administrativos 10, 29SHA1 7, 9soporte de checksum 7, 9SSL 21

cambio de la serie de cifrado 40cambio de versión del protocolo 40resolución de problemas 61series de cifrado soportadas 66uso de certificados con Celerra Manager 12uso de certificados con HTTP 15, 39uso de certificados con LDAP 15, 39uso de certificados para la conexión entre la Control

Station y el servidor de directorios basado en LDAP 12

Ttiempo de espera de sesión agotado 8

configuración 34desactivación 35modificación 35

tokens de sesión 7, 9modificación del valor secreto de SHA1 38

Uusuarios administrativos

acceso a Celerra 18creación 18creación de funciones 22creación de grupos 21identificación y autenticación mediante un servidor de

directorios 19locales versus asignados por dominio 18predeterminados 16resolución de problemas 62, 63


Notas

Acerca de este documentoComo parte de su esfuerzo continuo por mejorar y optimizar el performance y las capacidades de la línea de productos Celerra Network Server, EMC lanza periódicamente nuevas versiones de las herramientas de hardware y software Celerra. En consecuencia, es posible que algunas de las funciones que se describen en este documento no se soporten en todas las versiones de las herramientas de hardware y software Celerra que se encuentran en uso actualmente. Para obtener la información más reciente acerca de las funciones de cada producto, consulte las notas de la versión del producto correspondiente. Si su sistema Celerra no cuenta con alguna de las funciones que se describen en este documento, póngase en contacto con su representante de Servicio al Cliente de EMC para obtener una actualización de hardware o software.

Comentarios y sugerencias acerca de la documentaciónSus sugerencias nos ayudarán mejorar la exactitud, organización y calidad general de la documentación para usuarios. Envíe un mensaje de correo electrónico a [email protected] para darnos su opinión acerca de este documento.

Copyright © 1998-2008 EMC Corporation. Todos los derechos reservados.

EMC considera que la información de esta publicación es precisa en el momento de su publicación. La información está sujeta a cambios sin previo aviso.

LA INFORMACIÓN DE ESTA PUBLICACIÓN SE PROPORCIONA "TAL CUAL". EMC CORPORATION NO SE HACE RESPONSABLE NI OFRECE GARANTÍA DE NINGÚN TIPO CON RESPECTO A LA INFORMACIÓN DE ESTA PUBLICACIÓN Y, ESPECÍFICAMENTE, RENUNCIA A TODA GARANTÍA IMPLÍCITA DE COMERCIABILIDAD O CAPACIDAD PARA UN PROPÓSITO DETERMINADO.

El uso, la copia y la distribución de cualquier software de EMC descrito en esta publicación requieren una licencia de software correspondiente.

Para obtener una lista actualizada de nombres de productos de EMC, consulte las marcas comerciales de EMC Corporation en argentina.emc.com.

Todas las otras marcas comerciales incluidas en este documento pertenecen a sus respectivos propietarios.

Versión 5.6 90 de 90

Documents

Guía de configuración de seguridad de EMC Celerra · Seguridad de capa de transporte (TLS): protocolo sucesor de SSL para la autenticación y encriptación de comunicaciones generales