administración de emc celerra para un entorno de … · administración de emc celerra para un...

1 de 80

ContenidoIntroducción al entorno Celerra de múltiples protocolos . . . . . . . . . . . . .3

Documentación de múltiples protocolos y Windows . . . . . . . . . . . . .3Terminología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Conceptos del entorno Celerra de múltiples protocolos. . . . . . . . . . . . . .6Requerimientos del sistema para un entorno Celerra de múltiples protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

E-Lab Interoperability Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13Opciones de interfaz de usuario para el entorno Celerra de múltiples protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14Guía para la administración de Celerra en un entorno de múltiples protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15Consideraciones de interoperabilidad. . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Uso de convenciones de nombres de archivos NFS y CIFS . . . . . .16Resolución de conflictos de nombres de archivos . . . . . . . . . . . . . .16Uso de enlaces simbólicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17Enlace de file systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Selección de una política de control de acceso . . . . . . . . . . . . . . . . . . . .25Uso de MIXED y MIXED_COMPAT. . . . . . . . . . . . . . . . . . . . . . . . . . . .27Reglas de herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Backups y restores de objetos de file systems. . . . . . . . . . . . . . . . .31Configuración de una política de control de acceso. . . . . . . . . . . . .32Migración a MIXED y MIXED_COMPAT. . . . . . . . . . . . . . . . . . . . . . . .32Restablecimiento de MIXED y MIXED_COMPAT . . . . . . . . . . . . . . . .35

Generación de una credencial de Windows NT . . . . . . . . . . . . . . . . . . . .36Procesamiento de una credencial de Windows NT. . . . . . . . . . . . . .36Acceso a un dominio confiable mediante Windows 2000 . . . . . . . .37Configuración del dominio predeterminado de Windows . . . . . . . .38Definición de memoria caché para credenciales de Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38Configuración del vencimiento del registro de fecha y hora . . . . . .39Generación de credenciales de Windows NT . . . . . . . . . . . . . . . . . .39Inclusión de grupos UNIX en una credencial de Windows NT . . . . .40

Uso exclusivo de permisos UNIX para control de acceso. . . . . . . . . . . .41Configuración de política de bloqueo de archivos. . . . . . . . . . . . . . . . . .42

Montaje del file system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43Visualización y configuración de permisos UNIX desde un cliente Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

Administración de EMC Celerra para unentorno de múltiples protocolos

P/N 300-008-087Rev A02

Versión 5.6Octubre de 2008

Administración de EMC Celerra para un entorno de múltiples protocolosVersión 5.6 2 de 80

Consideraciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45Activación de capacidades especiales para la administración de ACLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

Configuración y administración de soporte de DFS . . . . . . . . . . . . . . . .47Activación y desactivación de soporte de DFS . . . . . . . . . . . . . . . . .52

Uso de wide links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53Pasos del proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Establecimiento de wide links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

Visualización y configuración de ACLs de Windows desde un cliente UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

Recuperación de emcgetsd y emcsetsd. . . . . . . . . . . . . . . . . . . . . . .61Visualización de ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Modificación de ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

Resolución de problemas del entorno Celerrade múltiples protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68

Dónde obtener ayuda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68Construcción de mensajes de error de server_log . . . . . . . . . . . . . .68Códigos de error Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69Códigos de estado NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69Problemas y limitaciones conocidos . . . . . . . . . . . . . . . . . . . . . . . . .70

Mensajes de error del entorno de múltiples protocolos de Celerra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73Información relacionada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74

Programas de capacitación para clientes . . . . . . . . . . . . . . . . . . . . .74Índice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77

3 de 80Versión 5.6Administración de EMC Celerra para un entorno de múltiples protocolos

Introducción al entorno Celerra de múltiples protocolosEn un entorno UNIX, se utiliza el protocolo Network File System (NFS) para acceder a los file systems. En un entorno Windows, se utiliza el protocolo Common Internet File System (CIFS) para acceder a los file systems. EMC® Celerra® Network Server soporta un entorno NFS y CIFS combinado mediante la provisión de capacidades de acceso a múltiples protocolos, como políticas de control de acceso y mecanismos de bloqueo que permiten que a los usuarios de UNIX y Windows compartir los mismos file systems.Este documento forma parte de la documentación de Celerra Network Server y está dirigido a los administradores de sistemas responsables de la implementación del Celerra Network Server en su entorno combinado Windows y UNIX.

Documentación de múltiples protocolos y WindowsLos siguientes documentos de Celerra Network Server explican cómo configurar y administrar Celerra en un entorno Windows y en un entorno de múltiples protocolos:◆ Configuring and Managing CIFS on EMC Celerra explica cómo configurar una

configuración básica CIFS en Celerra Network Server mediante la interfaz de línea de comandos (CLI). Este entorno inicial también se puede configurar mediante Celerra Manager.

◆ Configuring and Managing CIFS on EMC Celerra contiene procedimientos avanzados que se podrían requerir después de la configuración inicial de CIFS en Celerra Network Server e instrucciones para modificar y administrar Celerra en un entorno Windows.

◆ Configuring NFS on EMC Celerra explica cómo configurar y administrar NFS (versiones 2, 3 y 4) en Celerra Network Server.

TerminologíaEsta sección define términos importantes para comprender las capacidades de Administración de EMC Celerra para un entorno de múltiples protocolos en Celerra Network Server. El EMC Celerra Glossary proporciona una lista completa de terminología de Celerra. Active Directory (AD): servicio de directorio avanzado que se incluye con Windows 2000 y Windows Server 2003. Almacena información de los objetos en una red y permite que dicha información esté disponible para los usuarios y los administradores de la red mediante un protocolo como LDAP.Autenticación: proceso para verificar la identidad de un usuario que intente obtener acceder a un recurso, objeto o servicio, por ejemplo, un archivo o un directorio. Common Internet File System (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.

../ConfWindows/index.htm

../ManCIFS/index.htm

../CgNFS/index.htm

../ConfWinMulti/index.htm

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

Administración de EMC Celerra para un entorno de múltiples protocolos4 de 80 Versión 5.6

Controlador de dominio: servidor que autentica los inicios de sesión y mantiene la política de seguridad y la base de datos maestra de la cuenta de seguridad para un dominio de Windows. Los controladores de dominio administran el acceso delos usuarios a la red, incluidos el inicio de sesión, la autenticación y el acceso al directorio y a los recursos compartidos. Consulte además dominio de Windows 2000 o Windows Server 2003 y dominio de Windows NT.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. También se denomina blade. A veces al Data Mover se lo denomina internamente ‘DART’, ya que DART es el software que se ejecuta en la plataforma.Data Mover virtual (VDM): función del software Celerra que permite a los usuarios la separación administrativa de servidores CIFS, la replicación de entornos CIFS y la transferencia de servidores CIFS de un Data Mover a otro.Domain Name System (DNS): Software de resolución de nombres que permite alos usuarios ubicar computadoras en una red UNIX o red TCP/IP por el nombre de dominio. El servidor DNS mantiene una base de datos de los nombres de dominio, los nombre de host y sus direcciones de IP correspondientes, y los servicios que prestan estos hosts. Consulte ntxmap.Dominio: agrupación lógica de servidores de Microsoft Windows y de otras computadoras que comparten seguridad común e información de cuentas de usuarios. Todos los recursos como las computadoras y los usuarios son números de dominio y poseen una cuenta en el dominio que los identifica como exclusivos. El administrador de dominio crea una cuenta de usuario para cada usuario del dominio y los usuarios inician sesión en el dominio una vez. Los usuarios no inician sesión en cada servidor individual.Dominio de Windows 2000 o Windows Server 2003: dominio de Microsoft Windows controlado y administrado por Microsoft Windows 2000 o por Windows Server 2003 mediante Active Directory para administrar todos los recursos del sistema. Emplea DNS para resolución de nombres. Dominio de Windows NT: dominio de Microsoft Windows controlado y administrado por un servidor de Microsoft Windows NT mediante una base de datos SAM para administrar las cuentas de usuarios y grupos, y un namespace de NetBIOS. En un dominio de Windows NT, existen un controlador de dominio primario (PDC) con una copia de lectura/escritura de SAM y, posiblemente, varios controladores de dominio de backup (BDCs) con copias de solo lectura de SAM.File system: método para catalogar y administrar los archivos y los directorios en un sistema de almacenamiento.ID de usuario (UID): identificador numérico que corresponde a un usuario específico.Identificador de grupo (GID): identificador numérico asignado a un grupo específico de usuarios.Identificador de seguridad (SID): identificador exclusivo que define a un usuario o a un grupo en un entorno Microsoft Windows. Cada usuario o grupo posee su propio SID.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 poseen accesoa un objeto.


Microsoft Distributed File System (DFS): servicio de Windows 2000 y Windows Server 2003 basado en software residente en servidores de red y en clientes que enlaza de manera transparente las carpetas compartidas en los diferentes file servers en un solo namespace.Network Basic Input/Output System (NetBIOS): Interfaz y protocolo de programación de red desarrollado para computadoras personales IBM.Nombre de recurso compartido: nombre otorgado a un file system o a un recurso de un file system disponible desde un servidor CIFS específico para usuarios CIFS. Es posible contar con múltiples recursos compartidos con el mismo nombre, compartidos desde servidores CIFS diferentes.Nombre NetBIOS: nombre reconocido por WINS, que asigna el nombre a una dirección IP. Objetos de Política de Grupo (GPO): en Windows 2000 o Windows Server 2003,los administradores pueden utilizar la política de grupo para definir las opciones de configuración para los grupo de usuarios y computadoras. Los objetos de políticas de grupo de Windows pueden controlar elementos como la configuración local, de dominio y de seguridad de red. 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.Server Message Block (SMB): protocolo subyacente utilizado por el protocolo CISS, mejorado para uso en Internet para solicitud de servicios de comunicación, archivos e impresiones desde un servidor por medio de la red. El protocolo CIFS emplea SMB para brindar seguridad en el acceso y la transferencia de archivos para varios tipos de hosts de red, como LANs, intranets e Internet.Servicio de CIFS: el proceso del servidor CIFS que se ejecuta en el Data Mover que presenta recursos compartidos en una red y en computadoras basadas en Microsoft Windows.Servidor CIFS: servidor lógico que utiliza el protocolo CIFS para la transferenciade archivos. Un Data Mover puede albergar muchas instancias de un servidor CIFS. Cada instancia se denomina servidor CIFS.Servidor CIFS predeterminado: el servidor CIFS que se crea al agregar un servidor CIFS sin especificar ninguna interfaz (con la opción interfaces= del comando server_cifs -add). El servidor CIFS predeterminado utiliza todas las interfacesno asignadas a otros servidores CIFS en el Data Mover.


Conceptos del entorno Celerra de múltiples protocolosCada usuario de Celerra Network Server, ya sea un usuario de Windows o de UNIX, debe ser identificado por un identificador de grupo (GID) y un identificador de usuario (UID) numérico exclusivo. Sin embargo, Windows no utiliza IDs numéricos para identificar usuarios. En lugar de esto, emplea cadenas llamadas identificadores de seguridad (SIDs).

Resolución del IDs de usuarios CIFSAntes de configurar el servicio de uso compartido de archivos de Windows (denominado CIFS) en Celerra Network Server, se debe seleccionar un método de mapping de SIDs de Windows para UIDs y GIDs. El método empleado dependerá de la existencia de un entorno solo de Windows o UNIX, o de un entorno Windows de múltiples protocolos. Dichos métodos incluyen:◆ Active Directory◆ Directorio LDAP◆ Archivos locales◆ Network Information Service (NIS)◆ Usermapper (interno o externo)EMC recomienda la utilización de Usermapper interno en entornos que sean solamente de Windows. El Usermapper interno también puede utilizarse en entornos de múltiples protocolos en los que los usuarios posean solamente cuentas de usuario de Windows.Configuración de mapping de usuario EMC Celerra proporciona una lista de las herramientas y los métodos que pueden utilizarse para asignar usuarios de Windowsa UIDs y GIDs estilo UNIX, y las herramientas que se pueden utilizar para migrar usuarios desde un entorno de protocolo único a un entorno de múltiples protocolos.

Seguridad de los objetos de los file systemsEn un entorno de múltiples protocolos, Celerra Network Server emplea sus políticas de seguridad para administrar el control de acceso de sus file systems.

Modelo de seguridad de UNIXLos derechos de acceso de UNIX se conocen como bits de modo de un objeto de file system. Se representan mediante una cadena de bits en la cual cada bit representa un modo o un privilegio de acceso otorgado al usuario que posee el archivo, al grupo asociado con el objeto del file system y a todos los demás usuarios.Los bits de modo UNIX se representan como tres conjuntos triples de permisos rwx (read, write, execute) concatenados para cada categoría de usuario (User, Group, Other), como se muestra en el siguiente directorio de file system:

lrwxrwxrwx 1 kcb ing 10 Dic 9 13:42 xyz.doc -> xyz.html-rw-r--r-- 1 kcb ing 1862 Ene 2 14:32 abc.htmldrwxr-xr-x 2 kcb ing 5096 Mar 9 11:30 programa

Usuario

Grupo

Otros

CNS-000537

../InternalUsermapper/index.htm


En el ejemplo anterior:◆ El primer caracter de cada línea indica el tipo de archivo, que puede ser “d” para

un directorio, 1 para un enlace simbólico o guión (-) para un archivo regular.

◆ Los siguientes nueve caracteres de cada línea corresponden a los conjuntos de permisos read/write o execute para el usuario, para el grupo o para otros.

◆ kcb corresponde al usuario y eng, al grupo.

◆ xyz.doc es un enlace simbólico que cualquier persona usar para recuperar el archivo xyz.html.

◆ abc.html es un archivo regular que cualquier persona puede leer, pero solo el usuario kcb puede escribirlo.

◆ schedule es un directorio que cualquier persona puede buscar y leer, pero solo el usuario kcb puede insertar y borrar archivos en él.

Modelo de seguridad de WindowsGracias a los diversos permisos de acceso y a las opciones Allow (Permitir) o Deny (Denegar), el modelo de seguridad de Windows ofrece una estructura de seguridad más flexible que el modelo de UNIX, como se muestra en la Figura 1 en la página 7.

Figura 1 Ejemplo de permisos de acceso de Windows


El acceso a un objeto del file system se concede o se deniega mediante un descriptor de seguridad (SD). Un SD contiene información acerca de:◆ El propietario del objeto, que es el creador del objeto del file system y tiene el

privilegio de modificar permisos en dicho objeto, como Owner SID y Primary Group SID.

◆ Lista de control de acceso (ACL): Incluye información acerca del propietario del objeto, ACL discrecional (DACL) que describe los permisos de acceso, y ACL del sistema (SACL) que describe el criterio de información de auditorías. Para el DACL, cada derecho de acceso se define en la entrada de control de acceso (ACE), que de manera explícita concede o deniega acciones específicas para un objeto de file system. Cada cuenta de grupo y de usuario especificada posee un ACE en la ACL que representa los privilegios concedidos o denegados. Celerra Network Server soporta ACLs en los niveles de archivos, directoriosy recursos compartidos.

Credenciales de usuario y control de accesoSe genera una credencial de usuario de Windows que se almacena en la memoria caché cuando un usuario se conecta por primera vez a Celerra Network Server por medio del protocolo CIFS. La credencial contiene el SID del usuario y todos los SIDs de los grupos a los que pertenece el usuario. Cuando se utiliza una autenticación regular de UNIX (AUTH_SYS), se envía la credencial de usuario de UNIX con la solicitud de protocolo Remote Procedure Calling (RPC). Dicha credencial está compuesta por un UID y hasta 16 GIDs a los que pertenece el usuario. En un entorno NFS seguro, la credencial de usuario de UNIX se genera durante la autenticación Kerberos y está compuesta por el UID del usuario y los GIDs de todos los grupos a los cuales pertenece el usuario. Cuando el usuario solicita acceso a un objeto de file system, Celerra Network Server compara las credenciales del usuario con los permisos de ese objeto de file system.Para un usuario de FTP que provee un dominio y un nombre de usuario, Celerra Network Server se contacta con el controlador del dominio para efectuar una verificación y luego genera una credencial de Windows. Para un usuario FTP que provee un nombre de usuario no calificado, Celerra Network Server genera una credencial estilo UNIX que se basa en la información de contraseña local y en los archivos de grupo, en NIS o en el servicio de directorios LDAP.

Políticas de control de acceso de CelerraEn un entorno de múltiples protocolos, Celerra Network Server debe decidir qué conjunto de atributos de permisos utilizar en un archivo o en un directorio para determinar el acceso de usuario que se concede a un objeto de file system. Este proceso se denomina autorización de usuario y se controla por medio de la política de control de acceso del file system.Cuando se monta un file system con el comando server_mount, puede especificarse una de las políticas de control de acceso que se explican en la Tabla 1 en la página 9.Como opción predeterminada, cuando se crea un file system por primera vez mediante el uso de la Control Station, no existe una ACL en la raíz de dicho file system. El propietario UNIX es el usuario root y es el único que posee acceso de escritura a este file system. El sistema Celerra configura de manera automática los permisos de ACL como FULL CONTROL for EVERYONE en el directorio raíz del recurso compartido de CIFS del file system una vez que se establece la primera conexión con este recurso compartido.


Las políticas de control de acceso se aplican solo cuando la autenticación de usuarios del Data Mover se encuentra configurada con la opción predeterminada recomendada, NT. Esta opción se configura mediante la opción -add security del comando server_cifs.

Tabla 1 Políticas de control de acceso de Celerra (página 1 de 2)

Política de control de acceso Descripción

NATIVE (opción predeterminada)

• El acceso a un archivo o a un directorio por medio de un FTP autenticado con NFS o UNIX se concede solamente si los permisos UNIX del archivo o directorio lo permiten.

• El acceso por medio de un FTP autenticado con CIFS o Windows se concede solamente si los permisos Windows del archivo o directorio lo permiten.

• Los permisos ACL y UNIX se mantienen para cada archivo y para cada directorio.

• Una modificación en los permisos de un objeto de file system en NFS no afecta los permisos en CIFS y una modificación en los permisos de un objeto del file system en CIFS no afecta los permisos en NFS.

NT • El acceso a un archivo o a un directorio por medio de un FTP autenticado con NFS o UNIX se concede solamente si los permisos UNIX y Windows lo permiten.

• El acceso por medio de un FTP autenticado con CIFS o Windows se concede solamente si los permisos Windows lo permiten (los permisos UNIX no tienen efecto).



UNIX • El acceso a un archivo o a un directorio por medio de un FTP autenticado con NFS o UNIX se concede solamente si los permisos UNIX lo permiten (los permisos de Windows no tienen efecto).

• El acceso por medio de un FTP autenticado con CIFS o Windows se concede solamente si los permisos UNIX y Windows del archivo o directorio lo permiten.



SECURE • Proporciona el mayor nivel de seguridad para CIFS y NFS. • El acceso a un archivo o a un directorio por medio de NFS, FTP o CIFS

se concede solamente si los permisos UNIX del archivo o directorio lo permiten.




Nota: No establezca una raíz de DFS en un objeto del file system con una política de control de acceso de UNIX o SECURE, ya que ninguno de los componentes del enlace de DFS se crea con derechos UNIX.

La configuración del parámetro cifs acl.unixCheckAcl=0 altera el comportamiento de la política de acceso al file system UNIX para que solo se utilicen los bits de modo UNIX de los directorios y los archivos para determinar el acceso de los usuarios a los archivos, independientemente del protocolo que usen para acceder al file system. El file system igualmente almacenará la ACL configurada, pero no aplicará los derechos de acceso del usuario.

Nota: Si utiliza este parámetro, también podría considerar configurar el bit 1 del parámetro del servidor cifs acl.extacl en ‘2’. Esto expone los bits de modo UNIX de los directoriosy archivos como ACEs adicionales en las ACLs de los directorios y archivos.

MIXED • El acceso a un archivo o a un directorio por medio de NFS, FTP o CIFS lo determina siempre la ACL.


• Las ACLs para archivos y directorios se crean a partir del último protocolo que haya configurado o modificado los permisos. Por ejemplo, si un cliente NFS configura o modifica permisos en un archivo o en un directorio, se vuelve a generar la ACL basada en los bits de modo UNIX. Si un cliente CIFS configura o modifica permisos en un archivo o en un directorio, la ACL se genera basada en los permisos estándar de Windows.

• En todos los casos, la ACL determina el acceso a los archivos y a los directorios sin importar si el cliente utiliza un protocolo NFS, CIFS o FTP.

• Los permisos de ACL son más granulares que los bits de modo UNIX; en consecuencia, no todos los permisos que se configuran en una ACL se podrán traducir a bits de modo UNIX. En algunos casos, es posible que los bits de modo muestren más permisos que los que posee un usuario realmente. Consulte "Uso de MIXED y MIXED_COMPAT" en la página 27 para obtener una descripción detallada.

MIXED_COMPAT • El acceso a un archivo o a un directorio por medio de NFS, FTP o CIFS lo determina el último protocolo (NFS o CIFS) que haya configurado o modificado los permisos.


• Si los permisos de un archivo o directorio se configuran o se modifican desde un cliente CIFS, el acceso lo determinará la ACL (EXPLICIT ACL). Los bits de modo UNIX se generan basados en la ACL, pero no se utilizan para el control de acceso.

• Si los permisos de un archivo o directorio se configuran o se modifican desde un cliente UNIX, los bits de modo UNIX determinan el acceso. Igualmente se crea una ACL, pero no se utiliza para el control de acceso.

• Los permisos de ACL son más granulares que los bits de modo UNIX; en consecuencia, no todos los permisos que se configuran en una ACL se podrán traducir a bits de modo UNIX. En algunos casos, es posible que los bits de modo muestren más permisos que los que posee un usuario realmente. Consulte "Uso de MIXED y MIXED_COMPAT" en la página 27 para obtener más información.

Tabla 1 Políticas de control de acceso de Celerra (página 2 de 2)

Política de control de acceso Descripción


Credencial estilo Windows para usuarios UNIX En un entorno de múltiples protocolos, algunos usuarios o todos los usuarios tendrán identidades de usuario UNIX y Windows y podrán usar cualquiera de las dos identidades para acceder a los datos almacenados por el sistema Celerra. La característica de credencial de Windows NT permite a Celerra Network Server tomar en cuenta las membresías de grupo de un usuario Windows en el momento de controlar una ACL para el acceso mediante NFS. Cuando un usuario UNIX inicia una solicitud de un objeto de un file system, Celerra Network Server asigna el UID de UNIX al SID de Windows y, a continuación, fusiona los grupos UNIX y Windows del usuario para generar una credencial de Windows NT. La credencial de Windows NT es muy similar a una credencial de Windows, excepto por el hecho de que no contiene grupos locales porque un usuario UNIX no puede recuperar dichos grupos desde la computadora local. Una vez generada la credencial de Windows NT, se amplía la credencial UNIX proporcionada en la solicitud NFS RPC para control de acceso de NFS.La credencial de Windows NT proporciona lo siguiente:◆ Permisos consistentes en un objeto de file system independientes del protocolo

de acceso.

◆ Caché para almacenamiento de credenciales de Windows NT, con menos tiempo de procesamiento de control de acceso.

◆ Administración de acceso a los datos mediante ACLs, independientementedel protocolo que emplee el cliente.

◆ Mejora la limitación de credenciales de UNIX de 16 grupos por usuario que imponen las versiones 2 y 3 de NFS.

El uso de la característica de credenciales de Windows NT en un entorno de múltiples protocolos puede resultar muy conveniente, ya que toma en cuentalas membresías de grupos de Windows al controlar una ACL mediante NFS.

Uso del Data Mover como servidor DFSMicrosoft Distributed File System (DFS) permite a los administradores agrupar carpetas compartidas en diferentes servidores dentro de un namespace de DFS lógico. Un namespace de DFS es una vista virtual de estas carpetas compartidas que se muestran en una estructura de árbol de directorios. Mediante el uso de DFS, los administradores pueden elegir qué carpetas compartidas mostrar en el namespace, asignar nombres a dichas carpetas y diseñar la jerarquía del árbol en el que aparecen las carpetas. Los usuarios pueden navegar en el namespace sin necesidad de conocer los nombres de los servidores ni la cantidad exacta de carpetas compartidas que albergan los datos.Cada estructura de árbol de DFS posee un destino raíz que es el servidor host que ejecuta el servicio DFS y alberga el namespace. Una raíz de DFS contiene enlaces que hacen referencia a las carpetas compartidas (un recurso compartido en sí y los directorios contenido en él) de la red. Estas carpetas se denominan destinos DFS.

Servidores raíz de DFSMicrosoft ofrece dos tipos de servidores raíz de DFS: el servidor raíz de DFS de dominio y el servidor raíz de DFS independiente. El servidor de DFS de dominio


almacena la jerarquía de DFS en el Active Directory. El servidor raíz de DFS independiente almacena la jerarquía de DFS en una ubicación local. Celerra Network Server ofrece la misma funcionalidad que un servidor raíz de DFS independiente Windows 2000 o Windows Server 2003.Para obtener una descripción detallada de DFS, visite el sitio Web de Microsoften http://www.microsoft.com

Wide linksLa función de wide links de Celerra Network Server utiliza la funcionalidad de Microsoft DFS para resolver los enlaces simbólicos absolutos de UNIX para los clientes Windows. Para esto, se crea una raíz de DFS en un recurso compartidode CIFS y luego se establece un enlace en la raíz de DFS que asigna el punto de montaje UNIX al servidor Windows:\share\path. Este mapping se realiza con la herramienta MMC DFS. Resulta difícil para un cliente Windows abrir un path a un objeto del file system cuando el path contiene un enlace simbólico absoluto. El cliente Windows le solicita al servidor que realice una función en un objeto del file system basado en un path determinado. A diferencia de Windows, los clientes UNIX emplean un path de destino asociado a su punto de montaje. Dicho path puede conducir a un objeto de file system en un servidor remoto.

EjemploUn cliente UNIX posee los siguientes dos file systems montados:server1:/ufs1 montado en /firstserver2:/ufs2 montado en /secondEn el ufs1, hay un enlace de directorio simbólico absoluto a /second/home. El cliente UNIX puede acceder a este enlace de manera sencilla desde ufs1. Sin embargo, dado que este path existe solo en el cliente UNIX y no en el servidor local, el cliente Windows no puede seguir este path. Mediante el uso de wide links, los clientes Windows pueden seguir un enlace simbólico absoluto para acceder a archivos desde el mismo directorio que los clientes UNIX. Para esto, el sistema Celerra emplea la funcionalidad raíz de DFS del Data Mover. La traducción de wide links facilita la creación y el mantenimiento de un único namespace de file system de múltiples protocolos que abarca varios file serversy reduce la carga asociada con la consistencia que se debe mantener entre las definiciones de estructuras de namespace de NFS y CIFS (por ejemplo, tabla de montaje automático NFS y DFS). "Uso de wide links" en la página 53 proporciona información más detallada.

http://www.microsoft.com


Requerimientos del sistema para un entorno Celerra de múltiples protocolos Para obtener información acerca de los requerimientos del sistema, consulte:◆ Configuring and Managing CIFS on EMC Celerra para requerimientos de

acceso de CIFS.

◆ Configuring NFS on EMC Celerra para requerimientos de acceso de NFS.

◆ "E-Lab Interoperability Navigator" en la página 13 para obtener un listado de los clientes NFS y CIFS soportados.

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. Se encuentra disponible en el sitio Web de EMC Powerlink® en http://Powerlink.EMC.com. Inicie sesión en Powerlink y haga clic en Soporte > Información de Interoperabilidad y de Ciclo de Vida de Productos > E-Lab Interoperability Navigator.


../CgNFS/index.htm

http://powerlink.emc.com


Opciones de interfaz de usuario para el entorno Celerra de múltiples protocolosCelerra Network Server ofrece flexibilidad para administración de networked storage basado en su entorno de soporte y sus preferencias de interfaz. Este documento describe cómo configurar Celerra Network Server en un entorno de múltiples protocolos mediante la interfaz de línea de comandos (CLI). También podrá realizar algunas de estas tareas mediante las aplicaciones de administración de Celerra:◆ Celerra Manager: Basic Edition

◆ Celerra Manager: Advanced Edition

◆ Snap-ins de Microsoft Management Console (MMC)

◆ Extensiones de usuarios y computadoras de Active Directory (ADUC)

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

◆ El sistema de ayuda en línea de la aplicación incluido en el EMC Celerra Network Server Documentation CD

El documento Installing EMC Celerra Management Applications incluye instrucciones para iniciar Celerra Manager y para instalar los snap-ins de MMC y las extensiones de ADUC.

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

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

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

../InstallationManagement/index.htm



Guía para la administración de Celerra en un entorno de múltiples protocolosLas tareas que se requieren para administrar Celerra en un entorno de múltiples protocolos son las siguientes:◆ "Consideraciones de interoperabilidad" en la página 16

◆ "Selección de una política de control de acceso" en la página 25

◆ "Generación de una credencial de Windows NT" en la página 36

◆ "Uso exclusivo de permisos UNIX para control de acceso" en la página 41

◆ "Configuración de política de bloqueo de archivos" en la página 42

◆ "Visualización y configuración de permisos UNIX desde un cliente Windows" en la página 45

◆ "Configuración y administración de soporte de DFS" en la página 47

◆ "Uso de wide links" en la página 53

◆ "Visualización y configuración de ACLs de Windows desde un cliente UNIX" en la página 61


Consideraciones de interoperabilidadAunque el uso compartido de archivos de múltiples protocolos suele ser transparente para los usuarios finales, existen consideraciones especiales que se deben tener en cuenta para el soporte de un entorno de múltiples protocolos.Esta sección describe:◆ "Uso de convenciones de nombres de archivos NFS y CIFS" en la página 16◆ "Resolución de conflictos de nombres de archivos" en la página 16◆ "Uso de enlaces simbólicos" en la página 17◆ "Enlace de file systems" en la página 20

Uso de convenciones de nombres de archivos NFS y CIFS La Tabla 2 en la página 16 explica las diferencias que existen entre los protocolos NFS y CISS en cuanto a las convenciones de nombres de archivos.

Resolución de conflictos de nombres de archivosDebido a las diferencias en las convenciones de nombres de archivos, es posible que los archivos creados por un usuario NFS eventualmente presenten conflictos para un usuario CIFS. Esto ocurre cuando un usuario NFS crea archivos en un solo directorio con nombres que únicamente presentan diferencias en el uso de mayúsculas y minúsculas.Para resolver los conflictos de nombres, Celerra Network Server diferencia el nombre del archivo CIFS anexando un identificador numérico. Por ejemplo:◆ Un archivo NFS, Aaa, en un directorio NFS y CIFS se muestra a los usuarios

CIFS como Aaa.

◆ Un segundo archivo NFS, aAA, en el mismo directorio es exclusivo para los usuarios NFS, pero se muestra a los usuarios CIFS como aAA~1.

◆ Un tercer archivo NFS, aAa, es exclusivo para los usuarios NFS, pero se mostrará a los usuarios CIFS como aAa~2.

Tabla 2 convenciones de nombres de archivos NFS y CIFS

Nombres de NFS Nombres de CIFS

Distinguen entre mayúsculas y minúsculas. No distinguen entre mayúsculas y minúsculas, pero las preservan.

Permiten que un directorio contenga archivos con nombres iguales, pero con diferencias en el uso de mayúsculas y minúsculas.

No permiten que un directorio contenga dos archivos con un mismo nombre y diferencias en el uso de mayúsculas y minúsculas, e identifican dichos nombres como nombres duplicados.

Nota

Al crear nombres UID y GID para clientes Windows, los nombres de Windows (nombres de grupos globales, nombres de dominio y nombres de usuario) deben escribirse en minúsculas en NIS, en los archivos con contraseña y en los archivos UNIX de grupo. Deberá ser cuidadoso al realizar mapping explícito de usuarios y grupos; Celerra Network Server no reconoce nombres como Windows.


Uso de enlaces simbólicosLos enlaces simbólicos son nodos especiales creados por los clientes UNIX que hacen referencia a otro nodo (un archivo o directorio denominado nodo de destino). El nodo destino se define en un nodo de enlace simbólico como un nombre de path. Normalmente, los enlaces simbólicos de NFS no son pertinentes para los clientes Windows, ya que el cliente debe resolver (seguir) el enlace simbólico a su destino. Sin embargo, en ciertas circunstancias, Celerra Network Server resuelve enlaces simbólicos para clientes Windows con el objeto de que dichos clientes puedan acceder a los mismos archivos y directorios como clientes UNIX mediante un enlace simbólico.

Nota: Para asegurarse que se haya hecho backup de los enlaces simbólicos al utilizar herramientas de backup basadas en Windows (como NTbackup), configure el bit 3 del parámetro cifs acl.extacl. "Visualización y configuración de ACLs de Windows desde un cliente UNIX" en la página 61 explica el parámetro cifs acl.extacl.

Si Celerra Data Mover puede acceder al destino en nombre del usuario CIFS, el usuario visualiza el destino del enlace simbólico y no enlace mismo, y desconoce que ha seguido un enlace simbólico. Si el destino es inaccesible, el usuario visualiza el enlace simbólico como un archivo pero no puede acceder a dicho archivo.Como opción predeterminada, Celerra Network Server resuelve los enlaces simbólicos para clientes Windows únicamente si el destino:◆ No contiene un path absoluto (nombre de path completo). En otras palabras, el

path de destino no comienza con una barra diagonal (/).

◆ No asocia el directorio que contiene el enlace simbólico con el directorio principal (no cuenta con un nombre de path al que pueda hacer referencia de manera ascendente por medio del componente ‘..’).

Ejemplos de enlaces simbólicos válidos y no válidosEl Data Mover puede seguir un enlace simbólico que haga referencia a dir2/dir3 en nombre de los clientes Windows, ya que el destino depende del directorio en el que reside el enlace mismo. A menos que se configure el parámetro oculto followabsolute, los clientes Windows no podrán seguir un enlace simbólico que haga referencia a /dir1/dir2/dir3. Esto se debe a que el destino depende de la raíz del file system y, por lo tanto, no puede resolverse.

!PRECAUCIÓN!Cuando un Data Mover resuelve enlaces simbólicos en nombre de los clientes CIFS, dichos clientes no pueden establecer una distinción entre el enlace simbólico en sí y el destino del enlace simbólico. Por lo tanto, si un enlace simbólico hace referencia a un directorio y un usuario Windows intenta eliminar el enlace simbólico, se eliminan el enlace y el contenido del directorio al que hace referencia el enlace


!PRECAUCIÓN!No utilice las aplicaciones de Microsoft Office en archivos representados por enlaces simbólicos. Cuando se actualiza un archivo, Microsoft Office crea el archivo actualizado en el directorio que contiene el enlace simbólico y no en el directorio de destino del enlace simbólico.

!PRECAUCIÓN!Cuando no se puede acceder al destino, no se puede eliminar el enlace simbólico mediante un cliente Windows. Durante el proceso de eliminación, Microsoft Explorer intenta abrir el archivo (que no se puede localizar) y se produce un error.

El Data Mover no puede seguir un enlace simbólico que haga referencia a ../file en nombre de los clientes Windows a menos que se configure el parámetro shadow followdotdot. Aun así, el enlace puede traducirse solamente si el destino se encuentra dentro del mismo recurso compartido que el enlace mismo.

Cambio del comportamiento predeterminado del enlace simbólicoLos siguientes parámetros del sistema modifican el comportamiento predeterminado de los enlaces simbólicos:shadow followdotdot: si se soportan enlaces simbólicos con paths destino que hagan referencia a directorios principales, cambie el parámetro followdotdot oculto. Aunque cambie el parámetro, igualmente es necesario ubicar el nodo destino en el mismo espacio compartido (no es posible hacer referencia a una ubicación fuera del recurso compartido) a menos que se active el parámetro shadow followabsolutpath. "Cambio del parámetro shadow followdotdot" en la página 18 proporciona información más detallada.shadow followabsolutpath: si se deben soportar los enlaces simbólicos que utilicen paths absolutos como destino, cambie el parámetro followabsolutpath. "Activación de enlaces simbólicos con paths absolutos" en la página 20 proporciona información más detallada.Cuando se activa el parámetro shadow followabsolutpath para seguir paths absolutos, el Data Mover el interpreta destino. El Data Mover solo puede resolver paths que dependan del file system raíz en el Data Mover. Si se trata de un Data Mover virtual, este path debe ser la raíz del VDM (por ejemplo, /mountpoint/directory); de lo contrario, el cliente Windows no podrá acceder al destino.

Con NFS, los clientes leen un path destino del enlace simbólico y tratan de acceder al destino por medio de una búsqueda local en el cliente. Los clientes NFS solo pueden acceder a los destinos con paths absolutos si los clientes poseen el mismo punto de montaje que el Data Mover.Cambio del parámetro shadow followdotdotComo opción predeterminada, el Data Mover no sigue en nombre de los clientes Windows enlaces simbólicos que contengan pathnames que hagan referencia ascendente a directorios principales. Si se altera el parámetro shadow followdotdot, el Data Mover sigue en nombre de los clientes Windows los enlaces simbólicos que contengan el componente ‘..’.


!PRECAUCIÓN!La activación del parámetro shadow followdotdot apuntada a que el Data Mover siga los enlaces simbólicos de manera ascendente en nombre de los clientes Windows podría crear loops infinitos en el namespace que se presenta a los clientes Windows. Las aplicaciones que realizan búsquedas del namespace corren el riesgo de bloquearse en un loop infinito.

Acción

Para permitir que el Data Mover siga en nombre de los clientes Windows los enlaces simbólicos con el componente ‘..’ en los pathnames de destino, use la siguiente sintaxis de comandos:$ server_param <movername> -facility shadow -modify followdotdot -value 1

donde:<movername> = nombre del Data MoverEjemplo:$ server_param server_2 -facility shadow -modify followdotdot -value 1

Salida

server_2 : done


Activación de enlaces simbólicos con paths absolutosComo opción predeterminada, el Data Mover no sigue en nombre de los clientes Windows enlaces simbólicos que contengan paths absolutos (pathnames completos). Si se altera el parámetro shadow followabsolutpath, el Data Mover no seguirá enlaces simbólicos que contengan pathnames completos.

Nota: Si se configura el Bit 1, se crea un problema de seguridad potencial para el acceso NFS, ya que el cliente NFS puede crear un enlace simbólico absoluto para cualquier ubicación del Data Mover. Si no se configura el Bit 1, solo se seguirán los enlacesque posea el la raíz (uid 0).

Enlace de file systemsMediante el uso de enlaces simbólicos, los clientes CIFS pueden tener acceso a file systems múltiples en un Data Mover desde un único recurso compartido. Esto le brinda la apariencia de un gran namespace cuando en realidad está compuesto por file systems individuales que se enlazan mediante enlaces simbólicos. Una vez activado el parámetro shadow followabsolutpath, es posible crear un único recurso compartido CIFS que brinde acceso a file systems múltiples en un Data Mover. "Activación de enlaces simbólicos con paths absolutos" en la página 20 proporciona información más detallada.

Acción

Para permitir que el Data Mover siga en nombre de los clientes Windows los enlaces simbólicos cuando el destino sea un path absoluto, use la siguiente sintaxis de comandos:$ server_param <movername> -facility shadow -modify followabsolutpath -value <new_value>

donde:<movername> = nombre del Data Mover<new_value> = lista de bits Bit 0: 0 = no permite enlaces simbólicos que contengan un path absoluto 1= permite seguir enlaces simbólicos que contengan un path absoluto Bit 1: 0 = permite seguir solo enlaces simbólicos absolutos que pertenezcan a la raíz (UID 0) 1= permite seguir cualquier enlace simbólico absolutoEjemplo:$ server_param server_2 -facility shadow -modify followabsolutpath -value 1

Salida

server_2 : done


Para enlazar file systems mediante un enlace simbólico:

Acceso a enlaces simbólicos por medio de clientes CIFS El siguiente ejemplo muestra los pasos que se requieren para montar dos file systems, crear un recurso compartido en el file system de nivel superior y, luego, enlazar el segundo file system al recurso compartido mediante un enlace simbólico:

Nota: Es posible realizar los siguientes pasos únicamente mediante el uso de la Control Station y de un cliente NFS.

Paso Acción

1. Active el shadow followabsolutpath. Como opción predeterminada, este parámetro nose activa en el Data Mover. "Cambio del comportamiento predeterminado del enlace simbólico" en la página 18 proporciona información más detallada.

2. Monte los file systems.

3. Cree un recurso compartido en el file system de nivel superior (el que posee enlaces simbólicos).

4. Monte el file system de nivel superior en un cliente NFS.

5. Cree un enlace simbólico al file system en el directorio en el que se accederá al enlace.

Paso Acción

1. Configure el parámetro shadow followabsolutpath en 1 (activar).

2. Monte los dos file systems, ufs1 y ufs2:$ server_mount server_2server_2 :root_fs_2 on / uxfs,perm,rwroot_fs_common on /.etc_common uxfs,perm,roufs1 on /ufs1 uxfs,perm,rwufs2 on /ufs2 uxfs,perm,rw

3. Cree un recurso compartido para ufs1 (file system de nivel superior):$ server_export server_2server_2 :export "/ufs1" share "ufs1" "/ufs1" netbios=NS700-JB1 maxusr=4294967295 umask=22

4. Monte el file system de nivel superior, ufs1, en un cliente NFS:# mount 192.168.101.238:/ufs1 /ufs1# montaje192.168.101.238:/ufs1 on /ufs1 type nfs (rw,addr=192.168.101.238)


En el paso anterior, el comando ln -s /ufs2 fslink2 enlaza fslink2 al path /ufs2 dela misma manera que al Data Mover. Los clientes CIFS que accedan al recurso compartido ufs1 podrán visualizar fslink2 como uno de sus directorios, como se muestra en la Figura 2 en la página 22.

Figura 2 Ejemplo de enlace simbólico

Acceso a enlaces simbólicos por medio de clientes NFS Los clientes NFS no pueden acceder al enlace fslink2 porque no conocen este path en el Data Mover, el cual se muestra a continuación:

# ls -ltotal 8lrwxrwxrwx 1 root root 5 Jun 10 13:20 fslink2 -> /ufs2drwxr-xr-x 2 root root 8192 Jun 9 12:14 lost+found# cd fslink2bash: cd: fslink2: No such file or directory

Para que los clientes NFS tengan acceso a enlaces simbólicos, se deben realizar los pasos adicionales de exportar el file system, crear y montar el directorio, y, finalmente, montar el file system a dicho directorio.

5. El enlace simbólico sigue el path absoluto en relación al Data Mover. Este path es un path absoluto que depende del file system raíz en el Data Mover.

Nota: Debe contar con privilegios de usuario root para crear un enlace simbólico.

Cree un enlace simbólico al segundo file system, ufs2, en el directorio en el que se accederá al enlace (en este ejemplo, /ufs1).# ln -s /ufs2 fslink2# ls -ltotal 8lrwxrwxrwx 1 root root 5 Jun 10 2004 fslink2 -> /ufs2drwxr-xr-x 2 root root 8192 Jun 9 12:14 lost+found

Nota: Los puntos de comprobación de un file system enlazado no aparecerán debajo del file system de nivel superior (en este ejemplo, usf1). Para visualizar estos puntos de comprobación, deberá ubicarse en el directorio correspondiente al file system enlazado.

Paso Acción


El siguiente ejemplo muestra los pasos que se requieren para exportar /ufs2 en el Data Mover, crear y montar el directorio /ufs2 en el cliente NFS y, finalmente, montar el ufs2 a dicho directorio:

Limitaciones de enlace de archivosLas limitaciones de enlace de archivos son las siguientes:◆ Cuando un usuario sigue un enlace desde el file system de nivel superior

a un file system subordinado, se aplica la política de control de acceso del file system de nivel superior al file system subordinado.

◆ El tamaño del file system de nivel superior (desde el cual se conecta el usuario) no refleja el tamaño de los file systems subordinados.

◆ Las cuotas siempre se informan por cada file system. Si existen usuarios, grupos o árboles en file systems subordinados, cada file system se informa de manera individual.

◆ Si se configuran las solicitudes de notificación en el sistema de nivel superior con el bit WatchTree, las modificaciones de los file systems subordinados no generarán notificaciones.

◆ Algunas solicitudes arrojan el pathname completo de los archivos abiertos. Si un archivo abierto se encuentra en un file system al que se accede por medio de un enlace simbólico, es posible que el path que arroje no sea el path esperado.

◆ Al recorrer file systems mediante enlaces simbólicos, es posible que el comando cd .. no arroje el directorio que contiene el enlace simbólico (desde Microsoft Windows Explorer, esto no constituye un problema).

Paso Acción

1. Exporte el file system en el Data Mover:# server_export server_2 -o anon=0 /ufs2server_2 : done

2. Cree el directorio y monte el file system en el cliente NFS:# mkdir /ufs2# mount 192.168.101.238:/ufs2 /ufs2# cd /ufs1# ls -ltotal 8lrwxrwxrwx 1 root root 5 Jun 10 13:20 fslink2 -> /ufs2drwxr-xr-x 2 root root 8192 Jun 9 12:14 lost+found

3. Una vez que se crea el directorio /ufs2 en el cliente NFS y se monta el file system en dicho directorio, el cliente puede seguir el enlace simbólico que se presenta a continuación:# cd fslink2# ls -ltotal 32drwxr-xr-x 2 root root 8192 Jun 9 12:15 lost+found-rw-r--r-- 1 32769 32771 24064 Jun 10 09:52 test1.doc


◆ Al realizar restores de archivos desde backups en file systems enlazados, siempre se deben realizar restores de los enlaces simbólicos en primer lugar; de lo contrario, el restore completo se realiza en el file system de nivel superior.

◆ Si un file system subordinado no se monta en un Data Mover, los clientes CIFS verán el enlace simbólico como un directorio. Este directorio es el file system raíz del Data Mover.


Selección de una política de control de acceso La Figura 3 en la página 25 ayuda a decidir qué política de control de acceso es más apropiada para el entorno.

Figura 3 Árbol de toma de decisiones para políticas de control de acceso

Nota: Se denomina sincronización automática a la traducción de bits de modo UNIX en ACLs cuando se configuran los permisos de un cliente NFS y, en sentido opuesto, hace alusión a la traducción de ACLs en bits de modo UNIX en los objetos del file system cuando se configuran permisos de un cliente CIFS. "Sincronización automática" en la página 27 explica la manera en que ocurre esto en Celerra Network Server.

Inicio

SEGURO

UNIX NT ¿Es el sistema

operativo predominante?

¿Se requiere

sincronización automática de

permisos Windows y UNIX o NFSv4?

Igualmente Windows

y UNIX

Sí

No

Sí

MIXTO O

MIXTO_COMPATNATIVO

CNS-000542

¿Se requiere

seguridad entre los

protocolos?

Windows UNIX

¿Es un file system de protocolos múltiples?

Sí

No

No


La Tabla 3 en la página 26 muestra la manera en que interactúan las políticas de acceso de Celerra con los clientes CIFS y NFS para controlar los permisos de un objeto de file system en un entorno de múltiples protocolos.

Tabla 3 Control de permisos en un entorno de múltiples protocolos.

Política de control de acceso

Atributos de permisos Clientes CIFS Clientes NFS

¿Las modificaciones efectuadas en un conjunto de permisos se reflejan en otro conjunto de permisos?

NATIVE (opción predeterminada)

Dos atributos de permisos: ACLy bits de modo UNIX.

Se controla la ACL.Se controlan los derechos UNIX.

No

UNIX Se controlan los derechos UNIXy la ACL.

NT Se controla la ACL.Se controlan los derechos UNIX y la ACL.SECURE Se controlan los

derechos UNIX y la ACL.

MIXED Debido a la sincronización automática, se aplica un conjunto de atributos de permisos independientemente del protocolo.

Se controla la ACL. Si no existe una ACL, se crea una basada en los bits de modo UNIX. El acceso también lo determina la ACL.Los clientes NFSv4 pueden administrar la ACL.

Sí

Una modificación en la ACL vuelve a generar los bits de modo UNIX, pero no se controlan los derechos UNIX.

Una modificación en los bits de modo UNIX vuelve a generar los permisos de ACL, pero no se controlan los derechos UNIX.

MIXED_COMPAT Debido a la sincronización automática, se aplica un conjunto de atributos de permisos independientemente del protocolo.

Si un cliente CIFS configuró o modificó por última vez los permisos de un archivo o directorio, se controlala ACL y se vuelven a generar los derechos UNIX, pero no se controlan. Si un cliente NFS configuró o modificó por última vez los permisos de un archivo o directorio, se controlan los derechos UNIX y se vuelve a generar la ACL, pero no se controla. Los clientes NFSv4 pueden administrarla ACL.

Si un cliente NFS configuró o modificó por última vez los permisos de un archivo o directorio, se controlan los derechos UNIX y se vuelve a generar la ACL, pero no se controla.Si un cliente CIFS configuró o modificó por última vez los permisos de un archivo o directorio, se controlala ACL y se vuelven a generar los derechos UNIX, pero no se controlan. Los clientes NFSv4 pueden administrarla ACL.


Nota: Al acceder a las ACLs desde un cliente Windows, estas se controlan solo siel método de autenticación de usuario CIFS se configura en el modo predeterminado recomendado, NT. Esto se configura mediante la opción -add security del comando server_cifs.Todas las solicitudes de acceso que se controlan con los permisos UNIX pueden forzarse mediante la modificación del parámetro cifs acl.checkacl. "Uso exclusivo de permisos UNIX para control de acceso" en la página 41 proporciona información más detallada.

Uso de MIXED y MIXED_COMPAT UNIX y Windows administran el control de acceso de modos muy diferentes,lo que dificultan la configuración de los mismos parámetros de seguridad para un objeto de file system en un entorno de múltiples protocolos. La política MIXEDy MIXED_COMPAT de Celerra sincroniza los permisos UNIX y Windows de la manera más similar posible mediante un algoritmo que traduce los derechos UNIX en entradas de ACL y, asimismo, las entradas ACL en derechos UNIX. Las políticas MIXED y MIXED_COMPAT difieren en la manera en que traducen un grupo UNIX en una ACE y en la manera en que ejecutan el control de acceso. Como se explica en el siguiente ejemplo, la política MIXED siempre realiza el control de acceso con una ACL, independientemente del protocolo que se emplee para acceder a un objeto del file system. La política MIXED_COMPAT utiliza los permisos de protocolo que hayan configurado o modificado los permisos por última vez en un objeto del file system.

Ejemplo de MIXEDSe asignan los bits de modo de rwxrw-r- al archivo FileX. Si se modifica la ACL del archivo FileX de manera tal que se conceda acceso de lectura, escritura y ejecución del archivo a user1, que no es el propietario del archivo, la ACL muestra que el propietario del archivo tiene acceso de lectura, escritura y ejecución del archivo FileX. Los miembros del grupo propietario poseen acceso de lectura y escritura, otros tienen acceso de lectura y user1 tiene acceso de lectura, escritura y ejecución. Sin embargo, los bits de modo UNIX muestran rwxr-xrwx, lo que significa que al menos un usuario que no es el propietario del archivo tiene acceso de lectura, escritura y ejecución. Aunque parezca que todos los demás usuarios cuentan con acceso completo al archivo FileX, únicamente user1 dispone de acceso completo, ya que es el único acceso de control es la ACL, no los bits de modo UNIX.

Sincronización automáticaCuando se activan las políticas MIXED y MIXED_COMPAT para un objeto del file system, se sincronizan automáticamente la ACL y los bits de modo UNIX. Los cambios en una ACL generan modificaciones en los bits de modo y los cambios en los bits de modo regeneran la ACL.


La Tabla 4 en la página 28 explica la manera en que la política de control de acceso MIXED traduce las ACLs y los bits de modo UNIX durante la sincronización.

La Tabla 5 en la página 28 explica la manera en que la política de control de acceso MIXED_COMPAT traduce las ACLs de Windows y los bits de modo UNIX durante la sincronización automática.

Mapping de permisos de ACL a bits de modo UNIX La Tabla 6 en la página 29 muestra la manera en que las políticas de acceso MIXED y MIXED_COMPAT asignan los permisos de archivos y directorios de ACL a los derechos de archivos y directorios UNIX.

Tabla 4 Política de control de acceso MIXED

Traducción de bits de modo UNIX en ACLs Traducción de ACLs en bits de modo UNIX

Crea entradas de ACL para File Owner, Groupy Everyone basadas en los bits de modo de Owner, Group y Other.

Traduce la opción ACL Allow, pero no la opción ACL Deny.

Configura los permisos Delete o Change y aplica la opción Take Ownership para el Owner pero no para Everyone ni para otros grupos.

Genera los bits de modo de Owner a partirde la entrada Owner, la ACE del archivoo el directorio, y la ACE Everyone.

Tabla 5 Política de control de acceso MIXED_COMPAT

Traducción de bits de modo UNIX en ACLs Traducción de ACLs en bits de modo UNIX

Crea solo dos entradas en la ACL: Ownery Everyone.

Traduce la opción ACL Allow, pero no la opción ACL Deny.

Crea una ACE Everyone a partir de los bitsde modo de Group, ya que los grupos no se traducen con esta política.

Genera las ACEs None, Owner y Granteden los bits de modo de Group y Other.

Ignora los bits de modo de Other y no los utiliza para generar la ACL.

Configura los permisos Delete o Change y aplica la opción Take Ownership para el File Owner pero no para el grupo Everyone.


Nota: Para MIXED y MIXED_COMPAT, asegúrese de que esté configurado el grupo predeterminado de Windows, ya que Celerra Network Server usa este grupo para decidir qué grupo primario UNIX le asignará al objeto del file system creado mediante CIFS.

Nota: Cuando se utiliza Celerra como servidor NFSv4, algunos clientes NFSv4 pueden colocar un signo más en la salida ls -l cuando el objeto del file system cuente con una ACL. Ejemplo: rwxrw-r +

Mapping de bits de modo UNIX a permisos de ACLLa Tabla 7 en la página 29 muestra la manera en que las políticas de control de acceso MIXED y MIXED_COMPAT asignan los bits de modo UNIX a los permisos de ACL.

Tabla 6 Traducción de permisos de archivos y directorios de ACL a derechos UNIX

Permisos de archivos Permisos de directorios

R W X R W X

Traverse Folder/Execute File X X

Read Data X

Read Attributes X X X

Read Extended Attributes X X

Write Data X

Append Data X

Write Attributes X X

Write Extended Attributes X X

Delete X X

Read Permissions X

List Folders X

Create Files X

Create Folders X

Delete Subfolders and Files X

Tabla 7 Traducción de derechos UNIX a una ACL (página 1 de 2)

R W X

Traverse Folder/Execute File X

List Folder X X


Reglas de herenciaLa Tabla 8 en la página 30 explica las reglas de herencia para las políticas de acceso NATIVE, UNIX, NT y SECURE.

Read Data X

Read Attributes X

Read Extended Attributes X

Create Files/Write Data X

Create Folders/Append Data X

Write Attributes X

Write Extended Attributes X

Delete Subfolders and Files X

Delete

Read Permissions X X X

Change Permissions

Take Ownership

Tabla 8 Reglas de herencia de NATIVE, UNIX, NT y SECURE

Protocolo Reglas

CIFS Cuando un cliente CIFS crea un objeto de file system:• Se hereda la ACL del directorio principal (si la hubiere).• El conjunto umask determina los bits de modo UNIX del recurso

compartido. La umask del recurso compartido se configura mediante la opción umask del comando server_export.

NFS Cuando un cliente NFS crea un objeto de file system:• Se hereda la ACL del directorio principal (si la hubiere).• La umask del usuario determina los bits de modo UNIX.

Nota: Los clientes NFS v4 pueden configurar los bits de modo o la ACL, o ambos, en el momento en que crean el archivo o el directorio; dicha configuración prevalecerá sobre la herencia y la umask.

Tabla 7 Traducción de derechos UNIX a una ACL (página 2 de 2)

R W X


La Tabla 9 en la página 31 explica las reglas de herencia para las políticas de control de acceso MIXED y MIXED_COMPAT.

Backups y restores de objetos de file systemsLas herramientas de backup de file systems guardan las ACLs y los derechos UNIX con sus respectivos atributos, y realizan restores de ellos. Para los backups de Network Data Management Protocol (NDMP) y los backups de red CIFS, solo se realizan backups y restores de los permisos de ACLs, que determinan los derechos UNIX. Para un backup de NFS, solo se realizan backups y restores de los derechos UNIX, que determinan los permisos de ACLs. En consecuencia, es posible que las ACEs más complejas de las ACLs se pierdan durante un backup de NFS.Use NDMP para realizar backups y restores de file systems de múltiples protocolos, ya que los backups de red realizados mediante NFS o CIFS solo capturan un conjunto de metadatos de un file system de múltiples protocolos.

Nota: El valor umask se especifica como un valor octal y se determina mediante operaciones XOR con los permisos de 644 para archivos y 755 para directorios. Los valores comunes incluyen 002, que brinda acceso completo al usuario, al propietario o al grupo (y capacidad de búsqueda en directorios) y acceso de lectura a otros, o 022 (opción predeterminada), que brinda acceso total al usuario o al propietario y permisos de lectura (y capacidad de búsqueda en directorios), pero no de escritura, al grupo o a otros. Para cambiar el valor umask predeterminado, use el parámetro share.default.umask.

Tabla 9 Reglas de herencia MIXED y MIXED_COMPAT

Protocolo Reglas

CIFS • Cuando un cliente CIFS crea un objeto de file system, si se encuentra configurado el indicador de herencia y el directorio principal del objeto cuenta con una ACL, el objeto del file system heredará la ACL y se crearán permisos de bits de modo UNIX basados en la traducción de ACL.

• Si el directorio principal no cuenta con una ACL, los permisos UNIX se configuran en función del valor umask* y se genera una ACL basada en dichos valores.

NFS • Los bits de modo UNIX se basan en el valor umask.1• Se crea una ACL a partir de los bits de modo UNIX.

Nota: Los clientes NFS v4 pueden configurar los bits de modo o la ACL en el momento en que crean el archivo o el directorio; dicha configuración prevalecerá sobre la herencia y la umask.

1El valor umask se especifica como un valor octal y se determina mediante operaciones XOR con los permisos predeterminados de 644 para archivos y 755 para directorios.

Tabla 8 Reglas de herencia de NATIVE, UNIX, NT y SECURE

Protocolo Reglas


Configuración de una política de control de accesoSi el file system actualmente cuenta con una política de control de acceso de NATIVE, NT, UNIX o SECURE y se vuelve a montar con MIXED o MIXED_COMPAT, realice una "Migración a MIXED y MIXED_COMPAT" en la página 32 después de completar la ejecución de este comando.

Nota: Siempre controle las políticas activas de control de acceso antes de ejecutar este comando.

Migración a MIXED y MIXED_COMPATCon las políticas de acceso NATIVE, NT, UNIX y SECURE, Celerra Network Server puede almacenar permisos UNIX y Windows para cada archivo y cada directorio de un file system. Con estas políticas, una modificación realizada en un conjunto de permisos no afecta el otro conjunto. En consecuencia resultado, es improbable que los permisos Windows y UNIX sean consistentes entre sí. Cuando se vuelve a montar un file system con MIXED o MIXED_COMPAT con una política de control de acceso original de NATIVE, NT, UNIX o SECURE, es posible que sus archivos y directorios existentes aún tengan permisos no sincronizados.El comando nas_fs -translate permite que el file system sincronice los permisosUNIX y Windows de cada archivo y directorio del file system, como se explica en "Mapping de permisos de ACL a bits de modo UNIX" en la página 28 y en "Mapping de bits de modo UNIX a permisos de ACL" en la página 29.

Acción

Para configurar la política de control de acceso para un file system, utilice la siguiente sintaxis de comandos:$ server_mount <movername> -o accesspolicy=NT|UNIX|SECURE|NATIVE|MIXED|MIXED_COMPAT <fs_name> <mount_point>

donde:<movername> = nombre del Data Mover o VDM<fs_name> = nombre del file system que se monta<mount_point> = nombre del punto de montajeUn <mount_point> debe comenzar con una barra diagonal (/).Ejemplo:Para configurar la política de control de acceso en NT para el file system ufs1 en server_2, escriba:$ server_mount server_2 -o accesspolicy=NT ufs1 /ufs1

Salida

server_2 : done


!PRECAUCIÓN!Es posible que la migración a MIXED o a MIXED_COMPAT cambie los derechos existentes en algunos objetos del file system. Ejecute la función de traducción únicamente si el entorno de múltiples protocolos requiere la sincronización automática de los bits de modo UNIX y las entradas de ACL, o si emplea NFSv4para acceder a los datos.

La Tabla 10 en la página 33 explica la manera en que se traducen los permisos Windows y UNIX a MIXED o MIXED_COMPAT mediante NT, UNIX, NATIVE o SECURE como política de origen. La política de origen le indica a Celerra cuál es el conjunto de atributos de permisos (ACL o bits de modo) desde el que deben derivarse los permisos al migrar a MIXED o MIXED_COMPAT. No necesariamente establece una asociación con la política empleada anteriormente por el objeto del file system. La política de origen se especifica en la opción -from del comando nas_fs -translate. Por ejemplo, si se especifica UNIX para la opción -from, se vuelven a generar todas las ACLs a partir de los bits de modo.

Antes de realizar la sincronizaciónDado que no es posible deshacer el proceso de sincronización, primero realice un backup del file system. Siempre compruebe la política de control de acceso configurada en el file system antes y después de ejecutar el comando de traducción. El file system se debe montar como MIXED o MIXED_COMPAT antes de ejecutar este comando. De lo contrario, se rechaza el comando. El file system que se traducirá debe ser un objeto del file system UXFS montado como lectura/escritura.

Tabla 10 Migración a MIXED o MIXED_COMPAT

Políticade origen Acción de sincronización

NATIVE y NT Si el objeto del file system cuenta con una ACL, los derechos UNIX se derivan de la ACL, como se muestra en la Tabla 6 en la página 29. Si un objeto no cuenta con una ACL, la ACL se genera a partir de los bits de modo, que no presentan modificaciones.

UNIX Todas las ACLs se vuelven a generar a partir de los bits de modo. El control de acceso no se cambia para los usuarios UNIX. Dado que el modelo de seguridad de UNIX no es tan flexible como el modelo de seguridad de Windows, es posible que se pierda información de ACL durante la migración.

SECURE Se comprueban y se almacenan las ACLs y los bits de modo. Se fusionan los bits de modo con la ACL mediante la adición de tres ACEs: OWNER, GROUP y OTHER, en caso de que no existan. Si existe alguna de estas ACEs, se fusiona con los derechos UNIX correspondientes.


Ejecución de la sincronizaciónDespués de volver a montar un objeto de file system a MIXED o MIXED_COMPAT, ejecute el comando nas_fs -translate para sincronizar los permisos UNIX y Windows en un file system. La migración se realiza desde:

◆ NT, NATIVE, UNIX o SECURE a MIXED o MIXED_COMPAT

◆ MIXED a MIXED_COMPAT

◆ MIXED_COMPAT a MIXED

Nota: La política de control de acceso que se especifica en la opción -from le indica a Celerra qué permisos (UNIX o Windows) utilizar como política maestra durante la traducción, como se explica en la Tabla 10 en la página 33.

Acción

Para sincronizar los permisos UNIX y Windows en un file system, utilice la siguiente sintaxisde comandos:$ nas_fs -traduce <fs_name> -access_policy start -to {MIXED} -from {NT|NATIVE|UNIX|SECURE}

donde:<fs_name> = nombre del file systemEjemplo:Para sincronizar los permisos UNIX y Windows para ufs1 en server_2 y volver a generar las ACLs basadas en bits de modo UNIX, escriba:$ nas_fs -translate ufs1 access_policy start -to MIXED -from UNIX

Salida

server_2 : done


Comprobación del estado de traducción

Restablecimiento de MIXED y MIXED_COMPATEs posible restablecer en NT, NATIVE, UNIX o SECURE la política de control de acceso MIXED o MIXED_COMPAT de un objeto de file system; para eso, se debe volver a montar el objeto del file system con la política de acceso deseada. No se producen modificaciones en los permisos de las ACLs ni en los bis de modo UNIX, a menos que se aplique la nueva política derechos de acceso y que las ACLs y los bits de modo se vuelvan independientes con la primera modificación..

Acción

Para configurar el estado de traducción de un file system, utilice la siguiente sintaxis de comandos:$ nas_fs -translate <fs_name> -access_policy status

donde:<fs_name> = nombre del file system traducidoEjemplo:Para comprobar el estado de traducción de ufs1, escriba:$ nas_fs -translate ufs1 -a status

Salida Notas

status=In progress percent_inode_scanned=681097154093: ADMIN: 4: Command succeeded: acl database=/ufs1 convertAccessPolicy status

• Si se produjo un error en la traducción, compruebe si el file system se montó como MIXED o como MIXED_COMPAT.

• Si la traducción no se completa debido a una falla del sistema, vuelva a ejecutar el comando.

Acción

Para restablecer la política de control de acceso MIXED o MIXED_COMPAT de un file system, utilice la siguiente sintaxis de comandos:$ server_mount <movername> -o accesspolicy=NT|UNIX|SECURE|NATIVE|MIXED|MIXED_COMPAT <fs_name> <mount_point>

donde:<movername> = nombre del Data Mover<fs_name> = nombre del file system que se monta<mount_point> = nombre del punto de montaje, que comienza con una barra diagonal (/)Ejemplo:Para restablecer la política de control de acceso en UNIX para el file system ufs1 en server_2, escriba:$ server_mount server_2 -o accesspolicy=UNIX ufs1 /ufs1

Salida

server_2 : done


Generación de una credencial de Windows NTLa Figura 4 en la página 36 detalla la manera en que Celerra Network Server genera una credencial de Windows NT después de que un cliente UNIX solicita acceso a un objeto del file system.

Figura 4 Creación de una credencial de Windows NT

Procesamiento de una credencial de Windows NTPara procesar una credencial de Windows NT, Celerra Network Server realiza los siguientes pasos:

Paso Acción

1. Comprueba si el ID de usuario de UNIX se encuentra en la memoria caché de la credencial de Windows NT:Si el ID de usuario no se encuentra en la memoria caché, continúa con el paso 2. Si el ID de usuario se encuentra en la memoria caché, comprueba el vencimiento del registro de fecha y hora de la credencial de Windows NT. Si ya venció, continúa con el paso 2; si no, continúa con el paso 7.

2. Intenta asignar el ID de usuario al SID de Windows.

Sí

CNS-000536

Sí No

¿Caducó el registro de fecha y hora TTL?

Inserte la entrada “mapping

failed” en la memoria caché

Busque el nombre asociado

al UID

No

No

Inserte una nueva credencial

NT en la memoria caché

¿Está el UID/GID

en la memoria caché de

credenciales NT?

Cree credenciales NT

Realice verificación de

acceso

Sí

Sí

No

¿Hay un UID/GID que coincida con

el SID?

¿Puede recuperar el SID del DC?


Acceso a un dominio confiable mediante Windows 2000Para Windows 2000, el acceso a un dominio confiable requiere la configuración de derechos adicionales para el servidor CIFS que recupera la lista de grupos a los que pertenece un usuario. Este servidor debe obtener el contenido de la lista y derechos de lectura para todas las propertiedades.Lleve a cabo la siguiente tarea para configurar los derechos del servidor CIFS:

3. Si no encuentra una coincidencia:• Busca un nombre asociado con el UID. Este nombre ayuda a recuperar el SID de su

controlador de dominio mediante el uso del dominio predeterminado de Windows del parámetro nfs NTcred.winDomain o la extensión de dominio recuperada del NIS, o el archivo de contraseña local del Data Mover.

• Si no encuentra un SID, inserta una entrada de mapping fallido en la memoria caché. En este caso, se usa la credencial de UNIX enviada en la solicitud de NFS para control de acceso. Esto previene que el sistema acceda continuamente al controlador de dominio en busca de una coincidencia de SID.

4. Cuando encuentra una coincidencia, recupera la lista de grupos del usuario del Domain Controller. Este puede ser el dominio del Data Mover o un dominio confiable.

5. Reemplaza la credencial de UNIX con la nueva credencial de Windows NT.

6. Inserta la credencial de Windows NT en la memoria caché para que los clientes UNIX realicen control de acceso.

7. Realiza control de acceso.

Paso Acción

1. Use la MMC para usuarios y computadoras de Active Directory de Microsoft en el modo experto.

2. Desde el menú, seleccione las funciones View (Ver) > Advanced (Avanzadas).

3. Haga clic con el botón secundario en el nombre del domino y seleccione Security (Seguridad) > Advanced (Avanzadas).

4. Conceda los siguientes derechos:• Para un nombre NetBIOS del Data Mover: Everyone (Todos) o Anonymous

(Anónimo)• Para un nombre de computadora del Data Mover: serverDomain\Domain Computers

Paso Acción


Configuración del dominio predeterminado de WindowsEl parámetro nfs NTcred.winDomain especifica el nombre del dominio predeterminado de Windows que usarán los usuarios de NFS que accedan a un file system en el que se use la opción ntcredential. Se usa el nombre si existen diversos SIDs que coincidan con el UID de UNIX del usuario o si el mapping inverso de UID a nombre arroja un nombre de usuario ambiguo.

Nota: Los nombres de parámetros y funcionalidades distinguen mayúsculas y minúsculas. Este parámetro no se aplica NFSv4, pero se puede usar con NFSv2 y NFSv3.

Definición de memoria caché para credenciales de Windows NTLa memoria caché para credenciales de NT es una memoria caché de espacio limitado que contiene credenciales de Windows NT y todas las entradas de UID que no es posible asignar a SIDs.Cada entrada posee un vencimiento de registro de fecha y hora. El tamaño de la memoria caché (la cantidad máxima de entradas) se configura con el parámetro nfs NTcred.size.

Nota: Si se detiene el servicio de CIFS, los usuarios conectados pueden seguir usando la memoria caché durante 20 minutos. Al reiniciar CIFS, se eliminan todas las entradas de mapping fallido de la memoria caché.

Acción

Para configurar el dominio predeterminado de Windows, utilice la siguiente sintaxis de comandos:$ server_param <movername> -facility nfs -modify NTcred.winDomain -value <new_value>

donde:<movername> = nombre del Data Mover<new_value> = un nombre de dominio NETBIOS válidoEjemplo:Para configurar el dominio predeterminado de Windows en nasdocs.emc.com, escriba:$ server_param server_2 -facility nfs -modify NTcred.winDomain -value nasdocs.emc.com

Salida

server_2 : done

Acción

Para configurar el tamaño de la memoria caché para credenciales de Windows NT, utilice la siguiente sintaxis de comandos:$ server_param <movername> -facility nfs -modify NTcred.size -value <new_value>

donde:<movername> = nombre del Data Mover<new_value> = la cantidad máxima de entradas en la memoria caché. El valor predeterminado es 1009.Ejemplo:Para configurar en 1.000 el tamaño de la memoria caché para credenciales de Windows NT, escriba:$ server_param server_2 -facility nfs -modify NTcred.size-value 1009


Configuración del vencimiento del registro de fecha y horaLos nombres de parámetros y funcionalidades distinguen mayúsculas y minúsculas. Este parámetro no se aplica NFSv4, pero se puede usar con NFSv2 y NFSv3.

Generación de credenciales de Windows NTLa función de credenciales de Windows NT es para file systems de múltiples protocolos. Utilice esta función únicamente con políticas de control de accesode MIXED y MIXED_COMPAT, NT y SECURE.

Salida

server_2 : done

Acción

Para configurar el vencimiento del registro de fecha y hora de una entrada de Windows NTen la memoria caché para credenciales de NT, utilice la siguiente sintaxis de comandos:$ server_param <movername> -facility nfs -modify NTcred.TTL -value <new_value>

donde:<movername> = nombre del Data Mover<new_value> = la cantidad de minutos. El valor predeterminado es 20 minutos.Ejemplo:Para configurar el vencimiento del registro de fecha y hora de las credenciales de Windows NTen 30 minutos, escriba:$ server_param server_2 -facility nfs -modify NTcred.TTL-value 30

Salida

server_2 : done

Acción

Para generar credenciales de Windows NT para un objeto de file system, utilice la siguiente sintaxis de comandos:$ server_mount <movername> -o accesspolicy=NT|UNIX|SECURE|NATIVE|MIXED|MIXED_COMPAT,ntcredential <fs_name> <mount_point>

donde:<movername> = nombre del Data Mover o VDM<fs_name> = nombre del file system que se monta<mount_point> = nombre del punto de montajeEjemplo:Para configurar la política de control de acceso en NT y generar la credencial de Windows NT para el file system ufs1 en server_2, escriba:$ server_mount server_2 -o accesspolicy=NT,ntcredential ufs1 /ufs1

Salida

server_2 : done


Inclusión de grupos UNIX en una credencial de Windows NTCuando el usuario accede a Celerra por medio de CIFS, es posible configurar el sistema Celerra para incluir los grupos de UNIX del usuario en su credencial de Windows. Esta es una adición a sus grupos de Windows. Celerra incluirá los grupos de UNIX del usuario en su credencial de Windows si se configura en 1 el parámetro cifs acl.extendExtraGid. No existe un límite para la cantidad de grupos que puede contener una credencial de Windows NT.Este parámetro se aplica únicamente en entornos de múltiples protocolos con un archivo NIS o un archivo .etc/group en el Data Mover. Los grupos UNIX se recuperan desde los servicios de nombres de UNIX configurados en el Data Mover, algunos ejemplos de archivos de grupos locales, NIS, LDAP, etc., mediante el uso del nombre de usuario sin la extensión .domain.

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

Acción

Para incluir el grupo UNIX del usuario en su credencial de Windows NT, utilice la siguiente sintaxis de comandos:$ server_param <movername> -facility cifs -modify acl.extendExtraGID -value <new_value>

donde:<movername> = nombre del Data Mover<new_value> = 1 (para activar el mapping) o 0 (para desactivar el mapping). Ejemplo:Para combinar los grupos de UNIX y Windows del usuario a fin de para generar una credencialde Windows NT, escriba:$ server_param server_2 -facility cifs -modify acl.extendExtraGid-value 1

Salida

server_2 : done


Uso exclusivo de permisos UNIX para control de accesoSe debe configurar el comando cifs acl.unixCheckAcl para realizar el control de acceso en los permisos UNIX solo cuando la política de acceso del file system esté configurada para UNIX. Cuando este parámetro se configura en cero para un Data Mover, las ACLs de Windows nunca se activan cuando la política de acceso del file system se encuentra configurada para UNIX. Utilice este comando para asegurarse de que:

◆ Nunca se controlen las ACLs de Windows cuando la política de acceso del file system esté configurada para UNIX.

Nota: Los nombres de parámetros y funcionalidades distinguen mayúsculas y minúsculas. El parámetro cifs acl.unixCheckAcl afecta solo los file systems de un Data Mover configurados para utilizar la política de acceso UNIX.

Acción

Para especificar que solo se controlen los permisos UNIX (cuando la política de acceso se encuentre configurada para UNIX), utilice la siguiente sintaxis de comandos:$ server_param <movername> -facility cifs -modify ac1.unixCheckAc1 -value <new_value>

donde:<movername> = nombre del Data Mover<new_value> = 0 (para descartar controles de ACLs) o 1 (para controlar ACLs) Ejemplo:Para asegurarse de que solo se controlen los permisos UNIX (cuando la política de acceso se encuentre configurada para UNIX), esbriba:$server_param server_2 -facility cifs -modify acl.unixCheckAcl-value 0

Salida

server_2 : done


Configuración de política de bloqueo de archivosEl bloqueo de archivos garantiza la integridad de los archivos cuando más de un usuario intenta acceder a un mismo archivo. Los bloqueos de archivos administran los intentos de lectura, escritura o bloqueo de los archivos que se encuentran en uso por otros usuarios.Los protocolos NFS y CIFS implementan las funciones del bloqueo de archivos de diferentes maneras, como se muestra en la Tabla 11 en la página 42.

En un entorno de múltiples protocolos, los usuarios de CIFS y NFS pueden configurar los bloqueos de un archivo. Debido a que los bloqueos de NFS (versión 2 o versión 3) y los modos de denegación, los oplocks o las delegaciones de CIFS o NFSv4 no son directamente equivalentes, Celerra Network Server debe traducir los modos de denegación, los oplocks y las delegaciones de CIFS o NFSv4 a bloqueos de NFS (versión 2 o versión 3) y, asimismo, los bloqueos de NFS (versión 2 o versión 3) se deben traducir a los modos de denegación, los oplocks o las delegaciones de CIFS o NFSv4. Por ejemplo:◆ Una solicitud de modo de denegación de lectura o escritura de CIFS se traduce

en un bloqueo exclusivo de lectura o escritura de NFS (versión 2 o versión 3).

◆ Un bloqueo de lectura compartida de NFS (versión 2 o versión 3) se traduce en un modo de denegación de escritura de CIFS.

Para controlar la interacción del bloqueo de archivos de CIFS y NFS, Celerra Network Server brinda tres políticas de bloqueo diferentes que pueden especificarse al montar un file system. Estas políticas se definen en la Tabla 12 en la página 43. Estas políticas se utilizan para un entorno de múltiples protocolos e indican el impacto del comportamiento del bloqueo sobre los clientes NFS para el caso del bloqueo simultáneo de archivos NFS y CIFS.

Tabla 11 Diferencias entre la versión 2 o la versión 3 de NFS y bloqueos de CIFS o NFSv4

Bloqueos en un entorno de versión2 o versión 3 de NFS Bloqueos en un entorno CIFS o NFSv4

Utilizan bloqueo de lectura y bloqueos exclusivos (de escritura).

CIFS utiliza bloqueos oportunistas (oplocks) y modos de denegación de acceso. Las delegaciones son el equivalente de oplocks en NFSv4.

Los bloqueos de NFS son bloqueos de advertencia, pero no obligatorios. Un bloqueo de advertencia no es un bloqueo activado(por lo tanto, no afecta el acceso de lectura y escritura), pero advierte a los demás clientes que el archivo ya se encuentra en uso.

Los protocolos CIFS y NFSv4 activan bloqueo estricto de archivos y acceso sin bloqueo a archivos. Los bloqueos de CIFS y NFSv4 son obligatorios. Cuando un proceso de CIFS o NFSv4 bloquea un archivo, no se permiten a otros usuarios ciertos tipos de acceso a archivos, según el tipo de bloqueo impuesto. Un cliente CIFS o NFSv4 puede bloquear un archivo mediante:• Una denegación de acceso de lectura o escritura

en todo el archivo.• Un rango de bloqueo en una porción del archivo.


Nota: Celerra Network Server solo activa los bloqueos de archivos (cuando está configurado para hacerlo) si la aplicación del cliente utiliza bloqueos. Algunas aplicaciones simples, como Windows Notepad o Wordpad, UNIX more y vi no utilizan bloqueo de archivos. Los archivos creados con estas aplicaciones no se bloquean y pueden abrirse y editarse por otra aplicación aun cuando se monta un file system con wlock o rwlock.

Montaje del file systemCuando se monta un file system, se puede especificar la política para controlar la interacción del bloqueo de CIFS y NFS. La opción de bloqueo de archivos elegida dependerá de los requerimientos del negocio y de si el entorno de red es solo CIFS o es un entorno de múltiples protocolos (combinación de CIFS y NFS).

Tabla 12 Políticas de bloqueo de archivos de Celerra Network Server

nolock1

1. Nolock es la única política de bloqueo que soportan los file systems MPFS.

wlock2

2. Podrían tener problemas las aplicaciones NFSv2 o NFSv3 que no esperan conflictos de bloqueo (permiso denegado) en las operaciones de lectura o escritura.

rwlock3

3. Podrían tener problemas las aplicaciones NFSv2 o NFSv3 que no esperan conflictos de bloqueo (permiso denegado) en las operaciones de lectura o escritura.

Sin bloqueo: trata todos los bloqueos como bloqueos de advertencia para clientes NFS (v2 o v3) (configuración predeterminada, menor nivel de seguridad).

Bloqueo de escritura: activa los bloqueos de escritura de CIFS o NFSv4 para el acceso de clientes NFSv2 o NFSv3.

Bloqueo de lectura o escritura: activa los bloqueos de lectura y escritura d CIFS o NFSv4 para el acceso de clientes NFSv2 o NFSv3 (mayor nivel de seguridad).

Solicitudes de bloqueo: Si un cliente CIFS o NFS bloquea un archivo, ningún otro cliente puede bloquear dicho archivo.



Solicitudes de acceso:• Los clientes CIFS ignoran

los bloqueos configurados por NFS.

• Los clientes NFSv2 o NFSv3 pueden leer o escribir los archivos bloqueados por CIFS o NFSv4.

Solicitudes de acceso:• Los clientes CIFS que

deniegan acceso simultáneo de escritura no pueden abrir los archivos bloqueados por NFS para acceso exclusivo.

• Los clientes NFSv2 o NFSv3 pueden leer los archivos bloqueados por CIFS o NFSv4, pero no escribirlos ni eliminarlos.

Solicitudes de acceso:• Los clientes CIFS que

deniegan acceso simultáneo de lectura o escritura no pueden abrir los archivos bloqueados por NFS para acceso exclusivo o compartido.

• Los clientes NFSv2 o NFSv3 no pueden leer, escribir ni eliminar los archivos bloqueados por CIFS.


Nota: Un mount_point debe comenzar con una barra diagonal (/). Managing EMC Celerra Volumes and File Systems proporciona información más detallada sobre la creación de un file system y un punto de montaje.

Acción

Para especificar el bloqueo del file system, utilice la siguiente sintaxis de comandos:$ server_mount <movername> -o nolock|wlock|rwlock <fs_name> <mount_point>

donde:<movername> = nombre del Data Mover<fs_name> = nombre del file system que se monta<mount_point> = nombre del punto de montajeEjemplo:Para montar el file system ufs1 con bloqueo de lectura o escritura, escriba:$ server_mount server_2 -o rwlock ufs1 /ufs1

Salida

server_2: done

../VolFSManually/index.htm


Visualización y configuración de permisos UNIX desde un cliente WindowsLa capacidad de los usuarios de Windows de ver y modificar los permisos UNIX se encuentra desactivada como opción predeterminada. El parámetro cifs acl.extacl permite a los usuarios Windows ver y configurar los permisos UNIX en archivos y directorios, y activa capacidades especiales para la administración de ACLs, como se explica en EMC Celerra Network Server Parameters Guide. Al configurar el parámetro cifs acl.extacl, los permisos UNIX aparecerán en el cuadro de diálogo Propiedades de Windows del archivo o directorio, como se muestra en la Figura 5 en la página 45.

Figura 5 Cuadro de diálogo Propiedades con permisos UNIX

ConsideracionesAntes de visualizar y modificar los permisos UNIX, considere lo siguiente:

◆ Debido a que los permisos de directorio UNIX no se heredan (opción configurada para “This folder only”), solo aparecerán en el área Advanced (Avanzadas). Por ese motivo, es mejor visualizar y editar los permisos de carpetas mediante el uso del área Advanced (Avanzadas).

◆ Cuando se modifican los permisos UNIX desde Windows, si se desactiva la casilla de verificación Allow (Permitir) no se borran todas las entradas (cuando se visualizan desde la configuración Avanced [Avanzadas]). Para borrar todas las entradas, se debe activar la casilla Deny (Denegar).

../Parameters/index.htm


◆ Si activa la casilla de verificación Allow Inheritable permissions (Permitir que los permisos heredables del primario se propaguen a este objeto), es posible que obtenga resultados inesperados al modificar los permisos UNIX desde Windows. Si se activa esta casilla de verificación, es posible que los permisos UNIX tomen valores predeterminados desde objetos principales.

Activación de capacidades especiales para la administración de ACLsAplique este procedimiento para activar capacidades especiales de administración de ACLs.El EMC Celerra Network Server Parameters Guide explica el comando cifs acl.extacl y sus valores.Existen solo dos tipos de capacidades para ACL:◆ Backup o restore de atributos UNIX específicos.

◆ Visualización o modificación de derechos de acceso de UNIX.

Acción

Para activar una capacidad específica de administración de ACLs, utilice la siguiente sintaxis de comandos:$ server_param <movername> -facility cifs -modify extac1 -value <new_value>

Donde:<movername> = nombre del Data Mover<new_value> = la lista de bits está compuesta por siete bits binarios (0 a 6).

0 = se presentan los metadatos UNIX asociados con los archivos y directorios al cliente de backup CIFS.1 = los clientes Windows pueden visualizar y modificar los permisos UNIX.2 = las aplicaciones de backup de red de CIFS pueden realizar backup y restores de los atributos de seguridad de los directorios y archivos UNIX.3 = las aplicaciones de backup de la red CIFS pueden realizar backup y restores de los enlaces simbólicos de UNIX.4 = las aplicaciones de backup de red CIFS pueden realizar backup y restores de los tres nombres de archivos y directorios.5 = permite a los clientes NFS v2 y v3 visualizar y modificar las ACLs mediante el uso de la herramienta del cliente emcsetsd.6 = modifica el comportamiento de bit 1. Los derechos UNIX que se aplican son los derechos concedidos, con exclusión de los derechos denegados por la ACL discrecional.

Ejemplo:Para permitir a los usuarios de Windows visualizar y modificar los permisos UNIX, escriba:$ server_param server_2 -facility cifs -modify extacl -value 1

Salida

server_2 : done



Configuración y administración de soporte de DFSPara configurar una raíz de DFS en un recurso compartido de CIFS, utilice la herramienta de línea de comandos Microsoft dfsutil.exe o la herramienta MMC DFS. Para dfsutil.exe, utilice el indicador opcional para operar con la API en lugar del Registro de Windows.

Nota: Para utilizar un servidor CIFS solo como servidor DFS independiente (sin infraestructura de dominios), se deberá crear con dfsutil.exe.

El contenido de la raíz de DFS se administra mediante el comando de Microsoft dfscmd.exe (por ejemplo, creación y eliminación de enlaces). No es posible eliminar una estructura de árbol de DFS mediante este comando.

Nota: No establezca una raíz de DFS en un objeto del file system con una política de control de acceso de UNIX o SECURE, ya que ninguno de los componentes del enlace de DFS se crea con derechos UNIX.

Las herramientas dfsutil.exe y dfscmd.exe se incluyen en las Herramientas de soporte de Windows 2000 o Windows Server 2003.

Nota: Cuando se envía una consulta al DFS en la red mediante la ejecución del comando dfsutil /siteinfo:<cifs_server_name> que se incluye con las Herramientas de soportede Microsoft Windows 2000, el cliente se conecta al srvsvc pipe y emite un comando NetrDfsManager ReportSiteInfo. Celerra arroja un error DCE RPC Fault of 0x1c010002o Range Error. Para evitar este error, utilice el comando Microsoft Windows Server 2003 dfsutil /sitename:<cifs_server_name>.

Antes de configurar y administrar el soporte de DFS Realice las siguientes tareas antes de configurar una raíz de DFS en un recurso compartido de CIFS. Configuración de CIFS en Celerra proporciona instrucciones en relación con estas tareas:1. Configure el servidor CIFS en el Data Mover.

2. Inicie el servicio CIFS en el Data Mover, que automáticamente activa el soporte de DFS.

3. En el servidor CIFS, configure un recurso compartido del file system para crear una raíz de DFS; use la Tabla 13 en la página 47 como guía.

Tabla 13 Entornos DFS

DFS provisto de Tipo de recurso compartido Cantidad de raíces de DFS

Windows 2000: Recurso compartido local Una

Equipo con Windows Server 2003 y Windows XP:

Recurso compartido globalEs posible visualizar una raíz de DFS en un recurso compartido global desde un servidor CIFS en el Data Mover.

Múltiples Se recomienda esta opción, ya que permite administrar múltiples raíces de DFS en el mismo servidor CIFS.



Creación de una raíz de DFS mediante dfsutil.exe

Creación de una raíz de DFS independiente mediante MMC DFSPara crear una raíz de DFS mediante la herramienta MMC DFS:

Paso Acción

1. Para crear una raíz de DFS en un recurso compartido global mediante dfsutil.exe en un entorno de Windows Server 2003:C:\>dfsutil /AddStdRoot /Server:DM2-ANA0-1-SA /Share:wl_root-1

Microsoft(R) Windows(TM) Dfs Utility Version 4.0Copyright (C) Microsoft Corporation 1991-2001. Todos los derechos reservados.

Indica que el comando DfsUtil se completó correctamente.

Paso Acción

1. Inicie la herramienta New Root Wizard (Asistente para crear nueva raíz) desde MMC DFS.


2. En el cuadro de diálogo Host Server (Servidor host), especifique el servidor CIFS del Data Mover que se usará como raíz de DFS.

3. En el cuadro de diálogo Root Type (Tipo de raíz), seleccione Stand-alone root (Raíz independiente).

Paso Acción


4. El cuadro de diálogo Root Name (Nombre de la raíz) muestra el path UNC a la raíz y al recurso compartido. Escriba un nombre exclusivo para DFS root y agregue los comentarios pertinentes.

Paso Acción


5. Si un nombre de raíz no corresponde a un recurso compartido existente que se haya especificado con anterioridad, escriba el path al recurso compartido.

Una vez completada esta operación, aparecerá el mensaje Completing the New Root Wizard (Finalización del Asistente para crear una nueva raíz).

Paso Acción


Activación y desactivación de soporte de DFSDespués de iniciar el servicio CIFS, se activa el soporte de DFS como opción predeterminada.Para desactivar el soporte de DFS:

Paso Acción

1. Configure en cero la clave de Registro de Windows en el Data Mover con una herramienta como RegEdit:HKEY_LOCAL_MACHINE\SOFTWARE\EMC\DFS\Enable

2. Detenga y reinicie el servicio CIFS.


Uso de wide links Antes de crear wide links, considere lo siguiente:◆ Los wide links se basan en la funcionalidad de Microsoft DFS. Antes de establecer

wide links, se deben cumplir los requerimientos de DFS, como se explica en "Uso del Data Mover como servidor DFS" en la página 11.

◆ El destino del wide link deberá estar en una raíz de DFS, que es un recurso compartido de CIFS o de Windows. Este recurso compartido puede ser localo ubicarse en un servidor remoto. Pueden crearse tantos wide links como sea necesario en el recurso compartido raíz.

◆ Dado que el DFS redirige únicamente directorios, se debe configurar un pathname del directorio en el enlace de DFS usado para wide links. Durante la redirección de los wide links, el sistema:• Busca un enlace de DFS que coincida con el comienzo del path de destino

del enlace simbólico.

• Anexa el resto de este path al destino de DFS para la redirección final.

◆ Es posible configurar un wide link por cada Virtual Data Mover (VDM). Esto permite dirigir un cliente Windows a tantas ubicaciones de directorio comosean necesarias.

◆ Una vez configurados los wide links, aparece un enlace simbólico con un path absoluto como directorio en lugar de un archivo en Windows Explorer.

◆ El path del enlace de DFS debe ser el mismo en Windows y en UNIX (en otras palabras, el nombre UNIX de cada componente debe coincidir con el nombre M256 de Windows).

◆ En un cliente NT4, no aparece la ficha Seguridad en el cuadro de diálogo Propiedades para un archivo ubicado en un recurso compartido que soporte wide links. Es posible puede configurar la seguridad mediante una herramienta de seguridad, como cacls. De manera alternativa, administre las ACLs delos archivos mediante archivos de un cliente de Windows 2000 o recursos compartidos que no soporten wide links simbólicos. Puede haber dos recursos compartidos diferentes en el mismo directorio, uno que soporte wide links y otro que no, y el recurso compartido que no soporte wide links puede usarse para administrar configuraciones de seguridad mediante clientes NT4.

◆ Si un cliente Windows está conectado a un recurso compartido de CIFS en una raíz de DFS y se elimina dicho recurso compartido de DFS, es posible que el cliente no tenga acceso al recurso. Debido a que la función de wide links se basa en Microsoft DFS, esto también se aplica a los wide links. Esto ocurre porque el cliente utiliza una memoria caché de DFS para realizar seguimientos de todos los enlaces de DFS. Hasta que se agote el tiempo de espera de las entradas de memoria caché del recurso compartido, los clientes Windows intentan acceder al recurso compartido eliminado aunque este no exista en el DFS.Para resolver esto:

• Espere a que se agote el tiempo de espera de las entradas de la memoria caché del DFS.

• O desconecte el cliente del recurso compartido, limpie la memoria caché de DFS del cliente mediante la herramienta de línea de comandos dfsutil/pktflush de Microsoft y vuelva a conectar el recurso compartido.


Pasos del proceso Los siguientes pasos describen la manera en que un cliente Windows procesa la función de wide links mediante el uso de DFS:

Establecimiento de wide linksEn el siguiente ejemplo, el file system w1_root-1 contiene el directorio user1 que posee los enlaces simbólicos:◆ enlace a fs_wslink-1\user1 en el Data Mover local

◆ enlace a fs_wlink-29\user1 en un Data Mover remoto

Ejemploel file system w1_root-1 existe en server_2:

$ server_export server_2 | grep -w "wl_root-1"export "/wl_root-1"share "wl_root-1" "/wl_root-1" maxusr=4294967295 umask=22

el directorio user1 se ubica en w1_root-1:[user1@LINUX1PAG01 user1]$ pwd/wl_root-1/user1

user1 cuenta con dos enlaces simbólicos UNIX a otros directorios en Data Movers separados:

[user1@LINUX1PAG01 user1]$ ls -lhattotal 8.0Kdrwxr-xr-x 3 root root 0 Feb 2 13:19 ..drwxr-xr-x 3 user1 group-1001 1.0K Feb 2 12:43 .-rw-r--r-- 1 user1 group-1001 0 Feb 2 12:43 NFS_user_filelrwxrwxrwx 1 user1 group-1001 15 Feb 2 12:25 user1_on_fs_wlink-29 -> /wlink-29/user1lrwxrwxrwx 1 user1 group-1001 14 Feb 2 12:25 user1_on_fs_wlink-1 -> /wlink-1/user1drwxr-xr-x 2 user1 group-1001 80 Feb 1 17:49 user1

Paso Acción

1. El cliente abre un path que cuenta con un enlace simbólico absoluto.

2. El servidor detecta un path de enlace absoluto y envía un error que indica que el path no está cubierto. Este es un comportamiento típico de DFS.

3. El cliente solicita las referencias de DFS de este path para determinar dónde efectuar la conexión después.

4. Desde la raíz de DFS en el Data Mover definido como base de datos widelink en el registro de Windows del Data Mover, el servidor CIFS busca un enlace que coincida con el comienzo del path de destino en el enlace simbólico y determina el recurso compartido que se debe usar para la resolución de wide links.

5. El servidor CIFS envía las referencias de DFS que indican al cliente el nuevo path.


Estos enlaces simbólicos hacen referencia a:◆ user1 en fs_wlink-1 en el Data Mover local (server_2):

[user1@LINUX1PAG01 user1]$ mount | grep wlink-1automount(pid26562) on /wlink-1 type autofs (rw,fd=5,pgrp=26562,minproto=2,maxproto=3)dm2-ana0-1-sa:/wlink-1/user1 on /wlink-1/user1 type nfs (rw,addr=172.24.100.50)

◆ user1 en fs_wlink-29 en un Data Mover remoto (server_3):[user1@LINUX1PAG01 user1_on_fs_wlink-29]$ mount | grep wlink-29automount(pid26592) on /wlink-29 type autofs (rw,fd=5,pgrp=26592,minproto=2,maxproto=3)vdm3-ana0-6-sa:/root_vdm_3/wlink-29/user1 on /wlink-29/user1 type nfs (rw,addr=172.24.100.58)

Desde Windows, los enlaces simbólicos de user1 se muestran como archivos:C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1 Volume in drive \\dm2-ana0-1-sa\wl_root-1 is 102 Volume Serial Number is 0000-0014

Directory of \\dm2-ana0-1-sa\wl_root-1\user1

02/02/2005 12:43 PM <DIR> .02/02/2005 12:23 PM <DIR> ..02/01/2005 05:49 PM <DIR> user102/02/2005 12:25 PM 14 user1_on_fs_wlink-102/02/2005 12:25 PM 15 user1_on_fs_wlink-2902/02/2005 12:43 PM 0 NFS_user_file 3 File(s) 29 bytes 3 Dir(s) 52,867,235,840 bytes free

Creación de wide linksEl siguiente procedimiento muestra cómo crear dos wide links que dirijan un cliente Windows al directorio fs_wslink-1\user1 en el Data Mover local y al directorio fs_wlink-29\user1 en el Data Mover remoto. Una vez creados los dos wide links,el directorio user1 muestra estos enlaces simbólicos como directorios de Windows y no como archivos, como se indicó anteriormente.


Paso Acción

1. Inicie la herramienta MMC Distributed File System (Sistema de archivos distribuido [DFS]).

Nota: Este procedimiento supone la activación del soporte de DFS (como opción predeterminada) y la creación de las raíces de DFS, como se explica en "Uso del Data Mover como servidor DFS" en la página 11.


2. Desde el cuadro de diálogo Action (Acción), seleccione Show Root (Mostrar raíz). Escriba el nombre NetBIOS del servidor CIFS que se usa como raíz de DFS (en este ejemplo, DM2-ANA0-1-SA) en el que se debe crear un wide link.

3. El sistema muestra las raíces de DFS para DM2-ANA0-1-SA. Seleccione el la raíz de DFS (en este ejemplo, \\DM2-ANA0-1-SA\w1_root-1) en la que se debe crear un wide link.

Paso Acción


4. Haga clic con el botón derecho en \\DM2-ANA0-1-SA\w1_root-1 de la raíz de DFSy seleccione New Link (Nuevo vínculo).

Aparece el cuadro de diálogo New Link (Nuevo vínculo), que muestra el path UNC a la raíz DFS. Cada enlace que se crea debe corresponder a un recurso compartido de CIFS o Windows.

5. Escriba los valores de los campos Link name (Nombre de vínculo) y Path to target (Ruta de acceso a destino [carpeta compartida]), que deben ser los mismos en Windows y en UNIX (en otras palabras, el nombre UNIX de cada componente debe coincidir con el nombre M256 de Windows), como se muestra en el siguiente ejemplo.Este ejemplo muestra cómo crear el primer wide link, wlink-1\user1, para user1 en wlink-1 en el Data Mover local.

Paso Acción


6. Cree el segundo enlace para el user1 en el Data Mover remoto; para esto, repita el paso 5 y escriba los valores de los campos Nombre de vínculo y Ruta de acceso a destino [carpeta compartida].Este ejemplo muestra cómo crear el segundo wide link, wlink-29\user1, que dirigea user1 en wlink-29.

Paso Acción


7. Configure el servidor CIFS en la raíz de DFS en el Registro de Windows:a. Configure el servidor CIFS y el recurso compartido de CIFS mediante el siguiente Registro:

HKEY_LOCAL_MACHINE\SOFTWARE\EMC\WideLink\Share

El Registro debe contener:\\server_name\share_name

Donde:• server_name es el nombre NetBIOS del servidor CIFS. Si se usa un recurso

compartido global, solo es necesario escribir el nombre del recurso compartido de CIFS.

• share_name es el nombre del recurso compartido de CIFS o Windows.A continuación, se muestra la clave de Registro para wl_root-1, que correspondea un recurso compartido global:

Windows Registry Editor Versión 5.00[HKEY_LOCAL_MACHINE\Software\EMC\WideLink]"Share"="wl_root-1"

b. Detenga el servicio CIFS.c. Reinicie el servicio CIFS.Si se actualiza el Registro con un nombre de recurso compartido que no se encuentre en DFS, aparecen errores similares a los siguientes en server_log:SMB: 3: Widelink:\\Global\w1_root-1 is not in DFS

SMB: 3: Widelink: error while updating from Registry 7

Si se configura el registro pero no la función de wide links, aparecerán en la pantalla mensajes similares a los siguientes:

C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-1\The network name cannot be found.C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-29\The network name cannot be found.

Una vez configurada la clave del Registro, aparecerán enlaces simbólicos como directorios en Windows, que permiten a los usuarios leer el contenido de los dos directorios siguientes:Data Mover local:

C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-1\Volume in drive \\dm2-ana0-1-sa\wl_root-1 is 102Volume Serial Number is 0000-0014Directory of \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-1

02/02/2005 11:07 AM <DIR> .02/02/2005 11:56 AM <DIR> ..02/01/2005 07:08 PM 0 user1_NFS_file02/02/2005 10:27 AM <DIR> CIFS-user 1 File(s) 0 bytes 3 Dir(s) 52,867,260,416 bytes free

Data Mover remoto:C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-29\Volume in drive \\dm2-ana0-1-sa\wl_root-1 is 102Volume Serial Number is 0000-0014

Directory of \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-29

02/02/2005 05:11 AM <DIR> .02/01/2005 05:17 AM <DIR> ..02/02/2005 05:11 PM 0 NFS_user1_wlink-29 1 File(s) 0 bytes 2 Dir(s) 52,867,268,608 bytes free

Paso Acción


Visualización y configuración de ACLs de Windows desde un cliente UNIXEs posible ver y modificar la configuración de ACLs de Windows en un archivo o directorio desde un cliente UNIX mediante las herramientas de línea de comandos emcgetsd y emcsetsd. Estas herramientas son particularmente útiles para un usuario UNIX que cuenta con acceso de lectura y escritura a un file system, pero que no puede acceder a un archivo directorio por no contar con los derechos de ACL pertinentes.

Nota: El file system se debe montar desde un Celerra Network Server para que estas herramientas funcionen.

Recuperación de emcgetsd y emcsetsdLas herramientas emcgetsd y emcsetsd se encuentran en el directorio CifsTools/ unixacltools en el Applications & Tools CD incluido con el producto. Las herramientas emcgetsd y emcsetsd se pueden usar con tres tipos diferentes de sistemas operativos UNIX: Linux, Solaris, SPARC y x86, y HP-UX. Se debe recuperar la herramienta ejecutable apropiada para el sistema operativo. Estas herramientas se pueden copiar en un cliente UNIX sin necesidad de realizar un procedimiento de instalación en el cliente.

Visualización de ACLsLa herramienta emcgetsd, que se describe en la Tabla 14 en la página 61, permite visualizar ACLs en un archivo o directorio desde un cliente UNIX o desde una Control Station.

Tabla 14 Uso de la herramienta de línea de comandos emcgetsd (página 1 de 2)

Comando Descripción

emcgetsd [-D <domain>] [-v] [-x]

<local_node_path>

emcgetsd –a <local_node_path>

Muestra el descriptor de seguridad de un file system. Un descriptor de seguridad incluye información sobre el propietario, la ACLs y las auditorías del file system.

Opción Descripción

-D <dominio> Dirige el comando a un dominio específico.Es posible que este dominio sea diferente al dominio del usuario si existe una relación de confianza entre el dominio del usuario y otro dominio. En este caso, el comando muestralos SIDs de ambos dominios. Si no se especifica el dominio, CNS usa el dominio predeterminado del servidor CIFS.

-v Muestra información detallada sobre ACLs.


Visualización de descriptor de seguridadEl comando emcgetsd se usa para mostrar el descriptor de seguridad de un file system. Si el archivo o el directorio posee SIDs en una ACL que pertenezcan a más de un dominio, la salida presenta información de domain/user o domain/group sin que se especifique la opción -D en el comando emcgetsd.

Tabla 14 Uso de la herramienta de línea de comandos emcgetsd (página 2 de 2)


-x Si no se inicia el CIFS o si no se encuentra el nombre Windows de un usuario o grupo, se devuelve el SID de este usuario en formato decimal, a menos que se especifique la opción –x.

-a Muestra los derechos de acceso de un usuario actualmente conectado desde un cliente UNIX o desde una Control Station.

<local_node_path> Path del archivo o directorio del cliente UNIX.

Acción

Para mostrar el descriptor de seguridad de un file system mediante la opción verbose, utilice la siguiente sintaxis de comandos:$ emcgetsd -v <local_node_path>

Donde:<local_node_path>= path del archivo o directorio del cliente UNIXEjemplo:Para mostrar el descriptor de seguridad del directorio /fs2000A/apache/logs del file system mediante la opción verbose, escriba:$ emcgetsd –v /fs2000A/apache/logs

Salida

Dump of /fs2000A/apache/logs Security Descriptor------------------------------------------------Owner uid=677 froGroup gid=2765 media

DACLDENY Gid=10 soft64

Access R-X--- 0x1200a9READ_DATAREAD_EAEXECUTE

READ_ATTRIBUTESREAD_CONTROL

Flags 0x3OBJECT_INHERITCONTAINER_INHERIT

GRANT Uid=698 acl1Access RWXPDO 0x1f01ff


READ_DATAWRITE_DATAAPPEND_DATAREAD_EAWRITE_EAEXECUTEDELETE_CHILD

READ_ATTRIBUTESWRITE_ATTRIBUTESDELETEREAD_CONTROLWRITE_DACWRITE_OWNER

Flags 0x1fOBJECT_INHERITCONTAINER_INHERITNO_PROPAGATE_INHERITINHERIT_ONLYINHERITED_ACE

GRANT EveryoneAccess R-X--- 0x1200a9

READ_DATAREAD_EAEXECUTE

READ_ATTRIBUTESREAD_CONTROL

Flags 0x3OBJECT_INHERITCONTAINER_INHERIT

SACLNone

Salida


Visualización de derechos de acceso

Modificación de ACLsLa herramienta emcsetsd permite modificar o visualizar la ACL en un archivoo directorio desde un cliente UNIX o desde una Control Station.

Nota: Para usar esta herramienta, deberá contar con los derechos pertinentes.

Cuando se modifican los permisos Windows con la herramienta emcsetsd, el propietario de Windows es reemplazado por el SID de UNIX y el UID/GID de UNIX, como se muestra en los siguientes ejemplos: Ejemplos:

Owner uid=898 Unix='luc' Sid=S-1-5-18-1-898Group gid=109 Unix='emc2' Sid=S-1-5-18-2-109

Antes de usar la herramienta emcsetsd, se debe activar mediante el parámetro cifs acl.extacl "Activación de capacidades especiales para la administración de ACLs" en la página 46 proporciona una descripción completa del parámetro cifs acl.extacl.

Acción

Para mostrar los derechos de acceso de un usuario actualmente conectado desde un cliente UNIX, utilice la siguiente sintaxis de comandos.$ emcgetsd -a <local_node_path>

Donde:<local_node_path>= path del archivo o directorio del cliente UNIX.Ejemplo:$ emcgetsd –a /fred/test1/TestDir

Salida

Server=dffr1, Path in the server=//test1/TestDirAccess of user uid=602 with groups gids={107-2765} on //test1/TestDir

NT Rights: R-XPDO 0x1f00e9 ReadExecute Read ListFolderContents


La Tabla 15 en la página 65 describe las opciones de comandos de la herramienta emcsetsd.

Tabla 15 Uso de la herramienta de línea de comandos emcsetsd (página 1 de 2)


emcsetsd [-D <domain>] [-r]

-g <user_or_group>,<rights>[,<flags>]

-d <user_or_group>,<rights>[,<flags>]

-s <user_or_group>,<rights>[,<flags>]

-f <user_or_group>,<rights>[,<flags>]

-a <user_or_group>,<rights>[,<flags>]

<local_node_path>

Configura, restablece y audita los derechos de control de acceso para los usuarios o grupos en un archivo o un directorio.

Nota: Si no se inicia el CIFS o si no se encuentra el nombre Windows de un usuario o grupo, se rechaza el comando.

UsuarioUn usuario puede ser uno de los siguientes:• UID=number• User=NIS name• domain\userGroupUn grupo puede ser uno de los siguientes:• GID=number• Group=NIS name• Everyone• CreatorOwner• CreatorGroup • domain\user

Nota: Es posible cambiar el propietario del usuario o grupo mediante el comando UNIX chown o chgrp.


DerechosLos derechos pueden ser cualquiera delos siguientes, separados por una barra vertical (|):READ_DATAWRITE_DATAAPPEND_DATAREAD_EAWRITE_EAEXECUTEDELETE_CHILDREAD_ATTRIBUTESWRITE_ATTRIBUTESDELETEREAD_CONTROLWRITE_DACWRITE_OWNERUna combinación de RWXPDO:R: ReadW: WriteX: ExecuteP: ChangePermissionD: DeleteO: TakeOwnershipUno o más de los siguientes, separados por una barra vertical (|):FullControlModifyReadExecute

• ListFolderContents• Read• Write

FlagsUno o más de los siguientes valores, separados por una barra vertical (|):OBJECT_INHERIT: los subarchivos heredan esta ACE.CONTAINER_INHERIT: las subcarpetas heredan esta ACE.NO_PROPAGATE_INHERIT: herencia de bloqueos del directorio principalINHERIT_ONLY: La ACE no forma parte de los derechos de acceso del directorio actual, solo por herencia.INHERITED_ACE: ACE heredada.

Tabla 15 Uso de la herramienta de línea de comandos emcsetsd (página 2 de 2)




-D <domain> Dirige el comando a un dominio específico. Es posible que este dominio sea diferente al dominio del usuario si existe una relación de confianza entre el dominio del usuario y otro dominio. En este caso, el comando muestra los SIDs de ambos dominios.Si no se especifica el dominio, CNS usa el dominio predeterminado del servidor CIFS.

-r Elimina las ACLs actuales.

Nota: cuando se usa la opción -r , los SIDs del propietario y del grupo son reemplazados por los SIDs de UNIX y, por lo tanto, después de usar la opción -r, la identidad del propietario y del grupo refleja los nuevos SIDs.

-g <user_or_group>,<rights>[,<flags>] Concede acceso a un usuario o grupo.

-d <user_or_group>,<rights>[,<flags>] Deniega acceso a un usuario o grupo.

-s <user_or_group>,<rights>[,<flags>] Audita el acceso correcto de un usuarioo grupo.

-f <user_or_group>,<rights>[,<flags>] Audita el acceso erróneo de un usuarioo grupo.

-a <user_or_group>,<rights>[,<flags>] Audita todos los accesos de un usuarioo grupo.

<local_node_path> Especifica el path del archivo o directorio del cliente UNIX.


Resolución de problemas del entorno Celerrade múltiples protocolosComo parte de su esfuerzo continuo por mejorar y optimizar el performance ylas 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 versiones 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 Soporte al cliente de EMC.

Dónde obtener ayudaPara obtener información sobre licencias, productos y soporte de EMC: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.comServicio técnico: para obtener servicio 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 soporte 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.

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

Construcción de mensajes de error de server_logEl formato del código de evento puede ayudar a reducir el rango de búsqueda de un mensaje. Existen varios componentes en el comienzo de cada línea que, por lo general, son consistentes en todo el log de eventos. Por ejemplo, los mensajes de eventos típicos presenta el siguiente formato:

2005-09-16 18:27:21: NFS: 3: commit failed, status = NoPermission2005-09-16 18:27:23: CFS: 3: Failed to open file, status NoPermission2005-09-16 18:27:23: LIB: 6: last message repeated 1 times

El Manual de referencia de comandos de Celerra Network Server proporciona información más detallada sobre server_log. Este mecanismo de log usa las funcionalidades de log típicas de varios sistemas. Los diversos componentes de un mensaje de evento son:

◆ La primera parte indica la fecha y la hora del evento de log.

http://Powerlink.EMC.com


../ProblemResolutionRoadmap/index.htm



◆ La segunda parte es el subsistema del código Celerra que informó el evento (por ejemplo, NFS, CFS y LIB).

◆ La tercera parte es un código de clasificación, que es típico en funcionalidades de log de eventos. La información acerca de los códigos de clasificaciónse puede encontrar en la mayoría de los sistemas UNIX bajo el archivo de encabezado syslog.h en el directorio /usr/include/sys.

Las definiciones de los códigos de clasificación posibles que soporta Celerra Network Server son las siguientes:#define LOG_EMERG 0 /* system is unusable */#define LOG_ALERT 1 /* action must be taken immediately */#define LOG_CRIT 2 /* critical conditions */#define LOG_ERR 3 /* error conditions */#define LOG_WARNING 4 /* warning conditions */#define LOG_NOTICE 5 /* normal but signification condition */#define LOG_INFO 6 /* informational */#define LOG_DEBUG 7 /* debug-level messages */

◆ La cuarta parte describe la condición de error. La condición de error en las primeras dos líneas del ejemplo no necesita explicación. Las operaciones que se realizan son 'commit' y 'open', con la condición de error NoPermission. Otros tipos de eventos no son tan descriptivos.

Códigos de error KerberosLos códigos de error Kerberos son códigos de estado que generalmente muestrael subsistema SMB. Estos se pueden reconocer en los eventos registrados por la existencia de un número negativo elevado.

Ejemplo2003-07-24 16:29:35: SMB: 3: SSXAK=c0020030 origin=401 stat=e0000,-1765328160

Debido a que Kerberos está estandarizado, existen recursos públicos donde buscar los significados de la mayoría de estos códigos de estado. Uno de elloses el sitio Web http://www.net.berkeley.edu/kerberos/k5msgs.html, en el que se encuentra una completa lista de los códigos de error Kerberos y sus definiciones.

Códigos de estado NTLos códigos de estado NT se reportan para las funciones de emulación de CIFS o de Microsoft Windows en los productos Celerra. Los códigos de estado NT son valores de 32 bits sin firmar que se separan en subgrupos de datos binarios que identifican las particularidades del estado de un evento. Los valores de 32 bits se distribuyen de la siguiente manera:

3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +---+-+-+-----------------------+-------------------------------+ |Sev|C|R| Facility | Code | +---+-+-+-----------------------+-------------------------------+

Donde:◆ Sev es el código de severidad.

• 00: Exitoso

• 01: Informativo

• 10: Advertencia

http://www.net.berkeley.edu/kerberos/k5msgs.html


• 11: Error

◆ C es el indicador del código de cliente.

◆ R es un bit reservado.

◆ Facility es el código de la funcionalidad.

◆ Code es el código de estado de la funcionalidad.

Por lo común, los códigos de estado NT aparecen en el server_log con una especificación de subsistema SMB. El código de estado NT se presenta de diferentes maneras en los eventos de sistemas registrados. Entre los más frecuentes, se encuentran:◆ Un número hexadecimal precedido por Em=0x:

SMB: 4: authLogon=SamLogonInvalidReply Es=0x0 Em=0xc0000064

◆ Un número hexadecimal simple sin prefijo ni indicación de su formato:

SMB: 4: SSXAuth_SERVER_EXT13 aT=3 mT=1 c0000016

◆ Un número hexadecimal simple con prefijo de respuesta= sin indicación del formato:

SMB: 4: lookupNames:bad reply=c0000073

◆ Un número hexadecimal simple con prefijo de error= sin indicación del formato:

SMB: 4: SessSetupX failed=c0000016

◆ Un número hexadecimal marcado claramente como NTStatus= pero sin indicación del formato:

SMB: 4: MsError sendLookupNames=21 NTStatus=c0000073

Problemas y limitaciones conocidos La Tabla 16 en la página 70 describe los problemas conocidos que pudieran ocurrir al usar Celerra para un entorno de múltiples protocolos y presenta soluciones alternativas.

Tabla 16 Situaciones problemáticas (página 1 de 3)

Problema conocido Efecto Solución alternativa

Con la autenticación de usuario NT, algunos clientes de Windows 95 tal vez no podrían asignar unidades de disco desde el Data Mover.

El nombre de dominio enviadopor el cliente al Data Mover se especificó incorrectamente, o el username.domain no fue asignado en el archivo de contraseña en el Data Mover.

Verificar que el cliente está enviando el nombre de dominio correcto al archivo de contraseña.Para verificar que el cliente esté enviando el dominio correcto:1. En la opción Network (Red) del

Control Panel (Panel de control), haga doble clic en el cliente de la red (Cliente para Redes Microsoft).

2. En General properties (Propiedades generales), compruebe que se muestra el nombre de dominio correcto.


Con la autenticación de usuario NT, aparecen los siguientes mensajesde error:Incorrect password o unknown username después de intentar conectarse al servidor; aparecerá la ventana de nombrede usuario y contraseña.

Es posible que falte la cuenta de usuario Windows NT del dominio PDC, o que el Data Mover no haya podido determinar un UID para este usuario.

Agregue el usuario Windows NT al PDC del dominio y asigne el usuario a un UID y nombre de usuario UNIX.

Con la autenticación de usuario NT, el cliente no se puede conectar al servidor, por lo que no aparecerá la ventana de nombre de usuario y contraseña en el lado del cliente.

No se encontró el controlador de dominio para el dominio.

o

Controle si el PDC o el BDC está activado. Controle si el Data Mover puede acceder a un servidor WINS que conozca el dominio PDC o que tenga el PDC y el BDC en la misma subred local del Data Mover.

El nombre NetBIOS del servidor no se registró como una cuenta para computadora en el dominio PDC, o no se ha establecido una relación de confianza entre los dominios cliente y servidor.Aparecerá el siguiente mensaje en el server_log:The SAM database on the Windows NT server does not have a complete account for this workstation trust relationship.

Compruebe que existe una cuenta para computadora y, si fuera necesario, agréguela. Sila cuenta para computadoraya existe, quítela y agréguela nuevamente antes de volvera ingresar el comando. La documentación del servidor4.0 de Microsoft NT proporciona mayor información acerca de la configuración de una relaciónde confianza entre los dominios.

Después de unir un servidor CIFS a un dominio, aparecerá el siguiente error en la salida de server_cifs, que indica que el sistema no puede actualizar el registro DNS:FQDN=dm4-a140-ana0.c1t1.pt1.c3lab.nsgprod.emc.com (Update of "A" record failed during update: Operation refused for policy or security reasons)

Es posible que la zona del servidor DNS incluya el mismo FQDN para otra cuenta de computadora.

Compruebe que la zona del servidor DNS no tenga el mismo FQDN con una dirección de IP distinta para otra cuenta de computadora.

0xC0000022

2004-04-26 10:49:40: SMB: 3: Srv=<Celerra_netbios_name> buildSecureChanel=Authenticate2InvalidReply E=0xc0000022

Se deniega el acceso porque, cuando la computadora se creó en el controlador de dominio, no se activó (en el cuadro Windows New Object - Computer dialog) el permiso de uso de esta opciónde cuenta para computadoras anteriores a Windows 2000.

Formatee la computadora y luego vuelva a crearla con el permisode computadoras anteriores a Windows 2000 para usar esta opción de cuenta habilitada.




Al intentar iniciar MMC, aparece el siguiente mensaje de error: OLE Object: PBrush

MMC requiere Internet Explorer 6.0 para usar su analizador de XML DOM (Document Object Model).

Actualice la versión de Internet Explorer a 6.0.

El cliente Solaris recibe el siguiente mensaje de advertencia durante la creación de una cuenta de usuario:UX:useradd: ADVERTENCIA: more than NGROUPS_MAX(16) groups specified

De todos modos, se creará la cuenta de usuario, aunque es posible que se pueda disponer de los datos.Cuando el cliente Solaris intenta acceder, recibe un mensaje de error similar al siguiente: nfs: [ID XXXXXX kern.notice] NFS access failed for server dm3-121-ana0-2: error 1 (RPC: Can not encode arguments)

Esto se debe, probablemente, a que el parámetro NGROUPS_MAX del kernel Solaris se configuró para más de 16 grupos, que es el límite predeterminado en los sistemas Solaris. El NFS solo soporta un máximo de 16 grupos.Según la implementación de UNIX, el límite para la cantidad de grupos por usuario es diferente: • Solaris tiene un límite de 16

grupos• Linux tiene un límite de 32 grupos

En un entorno de múltiples protocolos, se debe utilizar la función de credenciales NT de Celerra File Server para ampliar el número de grupos a más de 16.

Al actualizar de un dominio Windows NT a Windows 2000, no se puede cambiarel sufijo del dominio original durantela instalación de Windows 2000.

No hay posibilidad de cambiarel sufijo del dominio porque fue codificado de manera indelebleen DDNS.

Antes de la actualización, cambie el sufijo del dominio.

Se deniega el acceso a Internet Information Services 6.0 (IIS) al intentar conectarse al directorio Weben un recurso compartido Celerra.En el log Web de IIS, se muestra el error de nombre de usuario o contraseña incorrectos aunque el nombre de usuario y la contraseña estén en la base de datos del usuario local.

Para un servidor CIFS independiente con el soporte de usuario local activado, el nombre de usuario y la contraseña deberán ser los mismos en IIS 6.0, en el Data Mover y en el cliente.

Especifique idénticos nombres de usuario y contraseñas en IIS 6.0, en el Data Mover y en el cliente.




Mensajes de error del entorno de múltiples protocolos de Celerra.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 los detalles de un mensaje, utilice cualquiera de los métodos siguientes:◆ 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:

• Escriba nas_message -info <MessageID>, donde MessageID corresponde al número de identificación del mensaje.

◆ 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.

◆ Powerlink:

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

../ErrorMsgs/index.htm




Información relacionadaPara obtener información específica relacionada con las característicasy funcionalidades que se describen en este documento, consulte:◆ Configuring and Managing CIFS on EMC Celerra◆ Configuring EMC Celerra Naming Services◆ Configuring EMC Celerra Time Services◆ Configuración de mapping de usuario EMC Celerra◆ Configuring External Usermapper for EMC Celerra◆ Configuring NFS on EMC Celerra◆ Configuración de Data Movers virtuales para EMC Celerra◆ EMC Celerra Glossary◆ Manual de referencia de comandos de EMC Celerra Network Server◆ EMC Celerra Network Server Error Messages Guide◆ EMC Celerra Network Server Parameters Guide◆ Installing EMC Celerra Management Applications◆ Configuring and Managing CIFS on EMC Celerra◆ Administración de volúmenes y file systems EMC Celerra con Automatic

Volume Management◆ Managing EMC Celerra Volumes and File Systems Manually ◆ Replicating EMC Celerra CIFS Environments (V1)◆ Using EMC Utilities for the CIFS Environment◆ Using International Character Sets with EMC Celerra◆ Uso de herramientas administrativas de Windows con EMC CelerraEl EMC Celerra Network Server Documentation CD, que se incluye con Celerra Network Server y que también se encuentra disponible en Powerlink, brinda información general sobre otras publicaciones 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.


../NameServices/index.htm

../TimeServices/index.htm

../InternalUsermapper/index.htm

../ExternalUsermapper/index.htm

../CgNFS/index.htm

../ConfiguringVDMs/index.htm

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

../CommandReference/index.htm




../ManCIFS/index.htm



../ReplicatingCIFSENvironments/index.htm

../EMCUtilities/index.htm

../i18N/index.htm

../WindowsAdminTools/index.htm




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 asociados de negocios, y seleccione el menú Capacitación.



Índice

Aacceso a archivos

configuración de ACLs desde UNIX 61visualización de permisos UNIX 45

acceso de NFS 11ACE 8ACL y bits de modo, sincronización 27ACLs

definición 8modificación desde un cliente UNIX 64visualización desde un cliente UNIX 61

ampliación de membresías de grupos, credencial de usuario 40

Bbits de modo 6bloqueo de archivos

en un entorno CIFS 42en un entorno NFS 42limitaciones 43modos de denegación de CIFS 42políticas 42

CCIFS

acceso a archivos, modos de denegación 42definición 3enlaces simbólicos 17servicio, definición 5servidor, definición 5

configuración de política de control de acceso 32Consideraciones de interoperabilidad 16control de acceso, mediante permisos UNIX únicamente 41control de acceso, objetos de file systems 8convenciones de nombres de archivos 16credencial de Windows NT

adición de grupos a 40configuración del dominio predeterminado 38definición de 11generación 39membresías de grupos 11memoria caché 38procesamiento de 36

credenciales de usuario 8

DDACL 8Data Mover

servidor DFS independiente 11derechos de acceso

configuración de políticas 35, 39entorno de múltiples protocolos 26UNIX 6Windows 7

derivación de permisos, durante la traducción 33descriptor de seguridad 8, 62DFS

activación 52configuración 47desactivación 52servidores raíz 11wide links 12

dominio confiable, acceso 37

Eenlace, simbólico 17enlaces simbólicos 17

activación de paths ascendentes 17entorno de múltiples protocolos

convenciones de nombres de archivos 16creación de una credencial estilo Windows 11operaciones de backup de FSOs 31permisos 26políticas de control de acceso 10, 25, 26seguridad de FSOs 8

estado de traducción 35

Hherramienta emcgetsd 61, 64

Iinterfaces de usuario, opciones 14

Mmemoria caché, credencial de Windows NT 38MIXED/MIXED_COMPAT

migración a 32reglas de herencia 31restablecimiento de 35sincronización automática 27visión general 27

NNDMP 31NFS/CIFS

convenciones de nombres de archivos 16resolución de conflictos de nombres 16

Oobjetos de file systems

control de acceso 8operaciones de backup 31permisos de configuración 32seguridad 8

UNIX 6seguridad de Windows 7

78 de 80 Administración de EMC Celerra para un entorno de múltiples protocolosVersión 5.6

Pparámetro acl.extendExtraGid 40parámetro cifs acl.checkacl 41parámetro cifs acl.extacl 45parámetro NTcred.size 38parámetro shadow followabsolutpath 20parámetro shadow followdotdot 17parámetros

acl.extendExtraGid 40cifs acl.checkacl 41cifs acl.extacl 45NTcred.size 38shadow followabsolutpath 20shadow followdotdot 17

permisosentorno de múltiples protocolos 26seguridad 8sincronización de 34

Política de control de acceso MIXED 10Política de control de acceso MIXED_COMPAT 10política de control de acceso NATIVE 9política de control de acceso NT 9Política de control de acceso SECURE 9Política de control de acceso UNIX 9política maestra, traducción 33políticas de control de acceso

árbol de toma de decisiones 25configuración 32entorno de múltiples protocolos 26MIXED 10MIXED_COMPAT 10NATIVE 9NT 9proceso de traducción 33SECURE 9UNIX 9visión general 8

procesamiento, credencial de Windows NT 36proceso de traducción, políticas de control de acceso 33

Rraíz de DFS, creación

Data Mover independiente 48uso de dfsutil.exe 48uso de MMC 48

Registro de Windows, wide links 60reglas de herencia, políticas de control de acceso 30requerimientos del sistema 13restores, objetos de file systems 31

SSACL 8seguridad

entorno de múltiples protocolos 8Windows 7

seguridad, permisos 8servidor DFS independiente 11sincronización de, ACL y bits de modo 27, 34

Ttraducción de permisos

comando 34política maestra 33UNIX a Windows 29Windows a UNIX 28

Uumask 30, 31UNIX

bits de modo 6cliente, visualización de derechos de acceso 64credencial 8modelo de seguridad 6permisos, configuración desde Windows 45

Wwide links 12

configuración de WindowsRegistro 60

creación 56pasos del proceso 54visión general 12

WindowsACLs, configuración desde UNIX 61configuración de permisos de archivos 8credencial 8dominio predeterminado, configuración 38modelo de seguridad 7

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 soporte 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 80 de 80

administración de emc celerra para un entorno de … · administración de emc celerra para un...

Documents