13. Grupos Locales
El termino local refiere a que el grupo es "local" a la base de datos de la computadora en la cual reside. El grupo puede ser definido en una base de datos, y de esta manera pueden ser asignados derechos y permisos a recursos en la computadora que contiene esta base de datos.
En computadoras corriendo sobre Windows NT Workstation o Server (instalado como un server), los grupos locales se limitan a la computadora en donde ellos fueron creados. En controladores de dominio Windows NT, los grupos locales se limitan a la base de datos y a todas las copias de la misma (BDCs).
Entonces:
– Un grupo local creado en un Windows NT WKS o SERVER (stand-alone) solamente podrá ser utilizado únicamente en esa computadora.
– Un grupo local creado en un controlador de dominio Windows NT podrá ser utilizado en otro controlador de dominio que pertenezca al dominio en donde el grupo fue creado.
Grupos locales incluídos en el server
Estos grupos se utilizan para otorgar derechos a los usuarios para realizar tareas del sistema como, realizar backups o restore d archivos, cambiar la hora del sistema y también administrar los recursos del sistema.
Estos grupos se dividen en tres categorías:
– Administrators – los miembros de este grupo poseen capacidad full sobre la computadora.
– Operator – los miembros de estos grupos tiene capacidades administrativas limitadas para ejecutar ciertas tareas específicas.
– Otros – los miembros de estos grupos tienen capacidades para ejecutar ciertas tareas.
Grupos:
– Administrators: Crear, borrar, administrar cuentas de usuarios, grupos globales y grupos locales.
Compartir directorios e impresoras, garantizar permisos y derechos a los recursos.
Instalar archivos del sistema operativo y programas.
– Users: Ejecutar tareas en las que tienen derechos.
Acceder a recursos en los que tienen permisos
– Guests: Ejecutar tareas en las que tienen derechos.
Acceder a recursos en los que tienen permisos.
– Server Operators: Compartir y dejar de compartir recursos
Bloquear o desbloquear un server.
Formatear los discos del server.
Logonearse a los servers.
Realizar backups o restore de archivos.
Apagar el server.
– Print Operators: Compartir y dejar de compartir impresoras.
Administrar impresoras.
Logonearse localmente al server y apagar servers.
- Backup Operators:Realizar backups y restore de los servers.
- Logonearse localmente.
- Apagar el server.
– Account Operators: Crear, borrar y modificar usuarios, grupos globales y grupos locales.
– Replicator: Usado en conjunto con el Directory Replicator Service.
Nota: el grupo Power Users es un grupo local provisto específicamente para computadoras corriendo Windows NT Workstation y Server (instalado como server y no como controlador de dominio). Los Power Users pueden crear y modificar cuentas de usuarios y compartir recursos.
Los grupos incluidos no puede ser borrados o renombrados.
Miembros de grupos locales
En un entorno de Workgroup, una computadora con Windows NT puede incluir en grupos locales solamente cuentas de usuario de la base de datos de cuentas de la misma computadora.
Un grupo local en una computadora corriendo Windows NT Workstation o Server (instalado como Server o como Controlador de dominio) en un dominio puede incluir los siguientes miembros:
– Cuentas de usuario de la propia computadora
– Usuarios y grupos globales de las computadoras del dominio
– Usuarios y grupos globales de otros dominios en confianza con las computadoras del dominio.
Nota: los grupos locales no pueden contener otros grupos locales.
El termino "global" refiere a que el grupo puede ser utilizado globalmente. Un grupo global reside en los controladores de dominio y contiene cuentas de usuario de esedominio. Pero, el uso de un grupo global no está restringido a la base de datos en la cuál reside; un grupo global puede ser miembro de un grupo local definido en el mismo dominio o en otros dominios a través de la relaciones de confianza. Los grupos globales son un mecanismo para colectar cuentas de usuarios dentro de los grupos que van a ser utilizados en el dominio y en toda la empresa.
Según el gráfico, en lugar de asignar permisos a cada grupo global, el administrador asigna permisos al grupo local en donde el grupo global a sido agregado. Si se deben asignar más usuarios, el administrador simplemente agrega los nuevos usuarios al grupo global apropiado que es parte del grupo local.
Por default, cuando una cuenta es creada en un dominio, es automáticamente asignada al grupo global Domain Users.
Importante: los grupos locales y globales no pueden usar el mismo nombre. Los nombres de grupos deben ser únicos en la base de datos.
Miembros de los grupos globales
Los Grupos Globales solamente pueden contener cuentas de usuarios como miembros. No pueden contener grupos locales u otros grupos globales.
Ya que los grupos locales están limitados a las base de datos en la cuál residen, se recomienda introducir los usuarios en grupos globales y los grupos globales dentro de los grupos locales para minimizar la administración en las computadoras con NT Workstation y Server.
Grupos Globales incluídos en Controladores de dominio Windows NT.
– Domain Admins
– Domain Users
– Domain Guests
Los grupos Globales no tienen la autoridad para poder ejecutar funciones de red que los grupos Locales hacen. Para ejecutar tareas administrativas, los grupos globales deben ser agregados al grupo local, como por ejemplo agregar el grupo global Domain Admins al grupo local Administrators.
Estrategias de grupos
Puede ser posible utilizar grupos globales y locales incluidos en NT. El método recomendado para implementar grupos en un dominio es:
1. En dominios, crear los usuarios y agregarlos a los grupos globales existentes o a nuevos grupos globales para que puedan acceder a los recursos del dominio.
2. Agregar los grupos globales a los grupos locales.
3. Asignar el grupo local a los derechos de los usuarios y a los permisos a los recursos.
Esta estrategia requiere un mínimo mantenimiento cuando se deben realizar cambios. Todos los cambios son hechos para los miembros del grupo global en el controlador de dominio, no se necesita tocar a los grupos locales o los permisos y derechos asignados para esos grupos locales.
Los controladores de dominio de Windows NT utilizan esta estrategia por default. Por ejemplo:
– Cuando una cuenta es creada, es automáticamente agregada como miembro del grupo global Domain Users.
– Domain Users es miembro del grupo local Users. Entonces, el nuevo usuario creado es un miembro del grupo local Users.
– Entonces, cuando una computadora Windows NT Workstation o Server se instala en dominio, el grupo global, Domain Users, es automáticamente agregado como miembro del nuevo grupo local de la computadora, Users.
Para usar grupos locales y globales efectivamente como una herramienta para administrar una red, un administrador deber seguir los siguientes puntos:
1- Determinar que se necesita:
Responsabilidad sobre la red (asignando tareas administrativas, creación de usuarios)
Asignar permisos a los recursos.
2- Ver si hay algún grupo local que puede ejecutar la tarea. Si no, crear uno.
3- Asignar permisos al grupo local si es necesario.
4- Asignar los usuarios apropiados al grupo local existente o al nuevo grupo.
5- Asignar grupos globales a los apropiados grupos locales.
¿Que tipos de grupos usar para cada tarea administrativa?
– El grupo de usuarios del dominio como una simple unidad en otro dominio (Global): Un grupo global puede ser puesto dentro de grupos locales y así poder tener permisos y derechos directamente en otros dominios.
– Administrar permisos y derechos en un dominio particular (Local): el grupo local puede contener usuarios y grupos globales del mismo dominio o de otros dominios que poseen relación de confianza.
– Se necesitan permisos en una computadora con Windows NT Workstation o Server en un dominio (Global): los grupos locales en un dominio solamente trabajan en Controladores de dominio Windows NT Server.
– Contener otro grupos (Local): los grupos locales pueden incluir usuarios y grupos globales.
– Incluir muchos usuarios desde muchos dominios (Local): un grupo local puede incluir usuarios y grupos globales del mismo dominio o de otros dominios que mantienen relaciones de confianza.
Creación de Grupos.
- Se utiliza la herramienta User Manager for Domains.
- Los grupos globales son creados en un Controlador de dominio.
- Los grupos locales son creados en al computadora local (NT Workstation, Server como controlador de dominio o no).
15. Estableciendo relaciones de confianza
Introducción a Relaciones de Confianza (Trust Relationship)
Una relación de confianza es un link de comunicación entre dos dominios, donde los usuarios de otro dominio pueden llegar a tener los accesos necesarios para acceder al dominio en donde no tienen cuenta de usuario. Cuando las relaciones están bien establecidas entre los dominios de una red, los usuarios poseen solamente una sola cuenta para acceder a todos los dominios de toda la red. Todas las computadoras de la red pueden reconocer la cuenta de usuario. Un usuario necesita logonearse y proveer una contraseña solamente al acceder a una computadora de la red.
Las relaciones de confianza llevan a la conveniencia de centralizar la administración al nivel de empresa, mas que ajustarla al nivel de dominio.
Ventajas para los administradores.
La confianza simplifica la administración al enlazar dos dominios en una simple unidad administrativa. Usar relaciones de confianza para centralizar la administración de cuentas de usuarios en un solo dominio en lugar de administrar dos dominios en forma separada.
Una relación de confianza entre dos dominios permitirá que las cuentas de usuarios y grupos globales podrán ser utilizados en otros dominios distintos al dominio en donde las cuentas están definidas.
Ventajas para los usuarios.
Permite que los usuarios de un dominio puedan utilizar recursos en otro dominio, sin necesidad que le usuario tenga una cuenta definida en el lugar en donde está definido el recurso.
Todos los Windows NT en una red pueden reconocer la cuenta de usuario. Un usuario tiene que logonearse y proveer una contraseña solamente una vez para acceder al recurso compartido en la red donde la cuenta del usuario posee permisos de acceso.
Confianza entre dos dominios
Todas las relaciones de confianza trabajan con dos dominios.
- Confianza en un sentido: solamente un dominio le permite al otro confiar en él.
- Confianza en dos sentidos: ambos dominios confían uno del otro.
Trusting vs. Trusted Domains.
El concepto de trusted versus trusting puede ser visto en términos de usuarios y recursos. El dominio con los recursos confía en los usuarios de un dominio remoto y le permite que puedan acceder a los recursos si las relaciones de confianza están bien establecidas y los permisos fueron asignados.
Consideraciones para la planificación.
– Las relaciones de confianza puede ser establecidas solamente entre dominios Windows NT.
– Determinar el nro de relaciones en un sentido.
– La ubicación física o lógica de los usuarios no es importante. Solamente interesa en donde residen las cuentas. Como la cuenta del usuario está definida en dominio que permite confiar, entonces el usuario puede logonearse en cualquiera de los otros dominios, siempre y cuando haya una relación de confianza con el dominio en donde las cuentas están registradas.
Estrategias de grupo para establecer confianzas
El usar grupos locales y globales sobre relaciones de confianza es una manera de facilitar la administración y el mantenimiento de la red.
Los roles de la confianza.
Cuando se establecen relaciones de confianza entre dominios, los grupos globales en los dominios trusted pueden ser miembros de un grupo local en un dominio trusting. Los grupos locales del dominio trusting pueden tener asignados permisos a los recursos o de poder realizar tareas administrativas, en el dominio trusting.
El efecto de esta estrategia es que los miembros del grupo global del dominio trusted tengan los permisos que les fueron garantizados al grupo local del dominio trusting.
En un entorno de múltiples dominios con relaciones de confianza la estrategia de grupo primario es la misma que la de un dominio simple: colocar los usuarios dentro de grupos globales y los grupos globales dentro de los grupos locales. Luego de establecer las relaciones de confianza, los grupos globales son definidos en el dominio trusted, y los grupos locales en todos los dominios existentes. El uso apropiado de las relaciones de confianza, y los grupos globales y locales, puede facilitar la administración centralizada en un entorno de múltiples dominios.
Estrategia para la planificación de los grupos.
En un entorno de múltiples dominios conectados por relaciones de confianza, usar los siguientes lineamientos para la implementación de grupos:
- Determinar que es necesario hacer:
- Responsabilidades en la red (asignar tareas administrativas, crear usuarios).
- Asignación de permisos a los recursos.
- Usar los grupos globales y locales incorporados en NT. Determinar si alguno de los grupos existentes pueden ejecutar la tarea.
- En el PDC de algún dominio trusted:
- Crear nuevas cuentas de usuario y los grupos globales que fueran necesarios.
- Asignar los usuarios apropiados a los grupos globales existentes o a los nuevos grupos globales.
- En las computadoras con Windows NT del dominio o del dominio trusting:
- Crear algún grupo local nuevo si es necesario.
- Adicionar los grupos globales del dominio trusted al grupo local apropiado.
- Asignar al grupo local los derechos de usuario y permisos a los recursos.
Estableciendo relaciones de confianza.
El menú Policies dentro de User Manager for Domains provee una opción de Trust Relationships. Mediante esta opción el administrador puede crear relaciones de confianza.
Hay dos pasos claves para establecer relaciones de confianza en una vía:
- El dominio trusted permite a otros dominios a confiar en él.
- El dominio trusting debe agregarse al dominio trusted.
Agregar dominios Trusting al dominio Trusted.
Ya que las relaciones de confianza son esencialmente una herramienta para administrar cuentas de usuario, se debe primero identificar el dominio donde las cuentas residen. Este dominio se conoce como dominio de cuentas o trusted.
Una vez que el dominio de cuentas (trusted) ha sido identificado, éste permitirá que otros dominios puedan confiar en él.
Para completar la confianza, el dominio de los recursos o trusting permitirá que los usuarios del dominio de cuentas (trusted) tengan permisos para acceder a los recursos en el dominio de los recursos (trusting).
Configuración de la confianza en un sentido.
Arrancar el User Manager for Domains, y seleccionar la opción correspondiente a la configuración de relaciones de confianza desde el menú Policies. Hay dos secciones en el cuadro de dialogo de Relaciones de Confianza:
- El cuadro para incorporar dominios trusted es completado en el domino trusting. Esta sección especifica "en que dominios el dominio trusting va a confiar".
- El cuadro para incorporar dominios trusting es completado por el dominio trusted. Esto especifica "que dominios confían en el dominio trusted".
El orden en que se establece la relación no es crítico. Sin embargo, es mejor establecer la relación que hace referencia al segundo paso en primer lugar, para luego definir la relación restante. En la definición de una nueva relación de confianza esto toma efecto inmediatamente. Si se establece la relación al revés de lo propuesto anteriormente, para que tenga efecto se tendrá que esperar por le menos 15 minutos.
Entonces, para definir la relación se debería proceder de la siguiente manera:
- El administrador del dominio de cuentas (trusted) inicia la relación incorporando el nombre del dominio de los recursos (trusting) en el cuadro "trusting domains".
- El administrador del dominio de recursos (trusting) completa la relación incorporando el dominio de cuentas (trusted) en el cuadro "trusted domains".
Esta secuencia es la preferida cuando se implementa una relación de confianza ya que el administrador del dominio de los recursos (trusting) recibirá un mensaje en donde se le indica que la relación de confianza fue establecida satisfactoriamente.
Configuración de la confianza en dos sentidos.
- Establecer la confianza en un sentido.
- Configurar otra relación de confianza en un sentido pero cambiando los roles anteriores en cuanto a los dominios trusted y trusting .
Cuando se establece una relación de este tipo, el mismo nombre de dominio aparece en ambos cuadros de diálogo, el de los dominios trusted y trusting.
Contraseñas.
El administrador en el dominio de cuentas (trusted) puede proveer una contraseña como parte de la implementación de la confianza. El administrador en el dominio de los recursos (trusting) debe ingresar esta contraseña en el momento apropiado para que el dominio trusting pueda completar la relación de confianza. Solamente una vez el administrador del dominio trusting debe ingresar la contraseña.
Esta contraseña es otra forma de seguridad. El administrador del dominio de cuentas usa la contraseña para controlar que dominios participarán en las relaciones de confianza.
Otorgar permisos a través de la relación de confianza.
Luego de establecer la relación de confianza, un administrador puede garantizar permisos utilizando esta relación.
En el momento de otorgar permisos, al agregar usuarios o grupos a una lista de seguridad sobre un recurso aparece la opción de seleccionar desde que dominio vamos a realizar la selección de los usuarios o grupos. De la misma manera, es posible seleccionar el dominio en el momento de otorgar políticas de derechos a los usuarios. Esto es posible gracias a las relaciones de confianza.
Autenticación de usuarios por Pass-Through.
Esto posibilita a los usuarios a logonearse a computadoras o dominios en donde ellos no posee cuenta de usuario. Gracias a este tipo de autenticación, un usuario puede tener una cuenta solamente en un dominio y así podrá acceder a toda la red incluyendo todos los dominios que confían en el dominio donde el usuario posee la cuenta. Una vez logoneado, el usuario será conocido en la red como Nombre de dominioNombre de usuario, donde Nombre de dominio es el dominio que contiene la cuenta del usuario y que autentica el requerimiento de logon del usuario.
Ocurrencia de la autenticación por Pass-Through.
Esta autenticación ocurre en alguna de las siguientes circunstancias:
- El logon comienza desde la workstation cuando algún usuario se logonea en un dominio de cuentas (trusted).
- En la conexión a un recurso en un dominio de recursos (trusting).
El proceso de logon en un dominio de cuentas (trusted) se realiza en la siguiente secuencia:
- La computadora con Windows NT arranca. Cuando arranca el servicio de Net Logon, este realiza el proceso de detección de un controlador de dominio Windows NT Server en su dominio (Dominio_B).
- Usuario_2 intenta logonearse en una computadora en el Dominio_B con una cuenta de usuario del Dominio_A. Esto lo hace desde el cuadro de logon de la computadora, en el campo From se le indica el dominio (en este caso Dominio_A).
- El controlador de domino del Dominio_B no puede autenticar el requerimiento de logon ya que el mismo se realizó sobre un cuenta de usuario del Dominio_A.
- El requerimiento de autenticación es pasado a través de la confianza (pass_through) a un controlador de dominio en el Dominio_A. Este controlador de dominio Windows NT chequea en la base de datos de cuentas si la cuenta Usuario_2 existe y si la misma posee una correcta información de password.
- El controlador de domino en el Dominio_A autentica el requerimiento de Usuario_2 y pasa la información del SID y grupo desde el Usuario_2 al controlador de dominio en el Dominio_B. El controlador de dominio en el Dominio_B entonces pasa la información al Usuario_2 que se está logoneado en la computadora con Windows NT.
Confianza No transitiva.
Una relación de confianza envuelve solamente dos dominios, por lo que una relación de confianza es no transitiva. Por ejemplo, si el dominio Ventas mantiene confianza con el dominio Producción, y el dominio Producción mantiene confianza con el dominio Marketing, entonces el dominio Ventas no mantiene confianza en forma automática con el dominio Marketing.
Un usuario con una cuenta en el dominio Marketing que intenta logononearse físicamente en una máquina del dominio Ventas no será autenticado ya que entre estos dominios no se puede establecer una autenticación por Pass_through. Marketing y Ventas deben setear la respectivas relaciones de confianza antes de poder realizar autenticación por pass-through entre ellos.
Posibles Problemas de las Relaciones de Confianza.
- No se puede establecer una relación de confianza:
- verificar el PDC en cada dominio esté corriendo
- No se puede verificar la relación de confianza:
- el dominio de cuenteas (trusted) deber permitir la relación al dominio de recursos (trusting), antes de que el domino trusting intente realizar la relación de confianza.
- Se ha roto una relación de confianza:
- Si una relación de confianza se ha roto, las cuentas trusted no estarán disponibles para se utilizadas. En este caso se debe restablecer la relación.
- No se puede restablecer la relación rota:
- Windows NT automáticamente cambiará la password inicial asignada luego de que la relación de confianza ha sido establecida. En este caso, se debe cortar la relación desde los dos dominios, y luego se debe restablecer una nueva relación.
- No se pueden utilizar cuentas trusted:
- La relación de confianza ha sido establecida con una dirección errónea. Parar la relación existente, y luego permitir al dominio trusted que dominio trusting confiará en él, y al dominio trusting en que dominio trusted podrá confiar. Si la confianza se rompe, restablecerla.
- No se puede administrar otro dominio:
- Verificar que el grupo Domain Admins del dominio trusted, ha sido agregado al grupo local Administrators del dominio trusting.
- Acceso denegado al utilizar una cuenta trusted:
- Chequee si el nombre de la cuenta existe en ambos dominios. En un relación de confianza, cada cuenta debe aparecer sólo en un dominio, en el dominio trusted o en el dominio local, pero no en ambos.
- Puede acceder a recursos de otro dominio utilizando una cuenta local:
- Chequee si el nombre de la cuenta existe en ambos dominios. En un relación de confianza, cada cuenta debe aparecer sólo en un dominio, en el dominio trusted o en el dominio local, pero no en ambos.
16. Implementación de los cuatro modelos de dominios
Antes de determinar el modelo de dominio a implementar, considerar lo siguiente:
- Número de cuentas de usuarios – Una cuenta de usuario debe ser definida solamente una vez en la red. Si esta regla no se respeta, la misma cuenta de usuario puede dos o mas diferentes SIDs. Esto puede causar inconsistencias administrativas en la asignación de permisos o derechos de usuarios.
- Número de departamentos de la organización o grupos – Determinar si es factible tener centralizada la administración de las cuentas y los recursos.
- Los recursos disponibles tendrán que ser accedidos a través de las relaciones de confianza.
- El modelo de dominio que se decida implementar determinará la ubicación de las cuentas.
Los recursos podrán ser localizados en el modelo de varias maneras:
Modelo Single Domain
Este modelo consiste de solamente un dominio, con un PDC y uno o mas BDC. Este modelo es apropiado en alguna de las siguientes situaciones:
- Número limitado de usuarios.
- Administración centralizada de cuentas y recursos.
- El número exacto de usuarios y grupos en un dominio depende del número de servers en el dominio y el hardware que provee a los mismos.
Ventajas:
- Ideal para compañías con pocos usuarios y recursos.
- Administración centralizada de cuentas de usuarios.
- Administración centralizada de recursos.
- No es necesario mantener relaciones de confianza.
Desventajas:
- Performance pobre si el dominio tiene muchos usuarios y grupos para el hardware del controlador de dominio.
- No agrupación de usuarios en departamentos.
- No agrupación de recursos.
- El browsing del dominio es pobre si es grande el número de servers.
El modelo Master Domain
Este modelo consiste de dos dominios. Cada dominio tiene sus propios controladores de dominio, pero toda la información de cuentas permanece en el PDC del master domain. Este modelo ofrece los beneficios de múltiples dominios, administración de cuentas centralizada, administración de recursos descentralizada, y logoneo simple para cada cuenta de usuario.
Este modelo es aplicable a compañías que poseen un complejo ordenamiento en departamentos y divisiones, cada uno con su propia administración de los recursos, pero con una administración centralizada de las cuentas de usuarios.
Ventajas:
- Optimo para compañías que no tienen muchos usuarios en relación al hardware del dominio y deben tener recursos compartidos agrupados según propósitos de administración.
- Las cuentas de usuarios pueden estar ubicadas en forma centralizada.
- Los recursos se agrupan logicamente en los dominios de recursos (trusting).
- Los dominios de recursos (trusting) pueden tener sus propios administradores para administrar los recursos en el dominio.
- Los grupos globales necesitan ser definidos solamente un vez (en el master domain).
Desventajas:
- Performance pobre si el dominio posee muchos usuarios y grupos para el hardware disponible.
- Los grupos locales deben ser definidos en cada dominio donde serán utilizados.
- Los administradores locales de los dominios de recursos (trusting) deben confiar en la administración del master domain en lo que hace a los grupos globales.
Relaciones de confianza en el Modelo Master Domain
El Master domain es un dominio de cuentas (trusted). Todos los demás dominios son de recursos (trusting), los cuáles se relación con el Master domain a través de una relación de confianza en un sentido.
Este modelo separa la red en dos areas diferentes de administración:
- Cuentas de usuarios – localizadas y administradas en el master domain (trusted).
- Recursos – localizados y administrados en los dominios de recursos (trusting).
Solamente los controladores de dominio en el master domain tienen copias de la base de datos de cuentas del master domain.
Grupos en modelo Master Domain
En un modelo Master Domain, la regla es mantener solamente una cuenta para cada ususario. Esto es posible si todas las cuentas están localizadas en el master domain. Si la confianza está implementada correctamente, un usuario puede logonearse desde cualquier dominio ya que la autenticación por pass-through envía el requerimiento de logon al master domain donde el usuario será verificado.
Grupos locales y globales
Los grupos globales son importantes en el master domain porque son solamente grupos que pueden ser accedidos fuera del dominio donde fueron creados.
Para simplificar la administración, un administrador del dominio de recursos (trusting) incorporará el grupo global, desde el master domain, dentro de los grupos locales de los dominios trusting.
Cuando los grupos globales se incorporan a los grupos locales, el administrador del master domain tiene que adicionar solamente el grupo global para que pueda tomar el acceso de usuario que posee el grupo local sobre los recursos del dominio.
De esta manera el administrador solamente maneja solamente un nivel de grupos – grupos globales. La red entera y todos los dominios y grupos pueden ser administrados desde una computadora.
El modelo Muliple Master Domain
Para grandes compañías que pretenden administración centralizada, este modelo es el apropiado ya que resulta el mas escalable.
Este modelo tiene un número pequeño de master domains. Cada server del master domain tiene una cuenta en el dominio, y cada cuenta de un usuario de la red es creada en alguno de esos master domains. Otros dominios en la red son los dominios de recursos, que son típicamente creados a nivel de departamento.
Ventajas:
- Ideal para empresas con muchos usuarios y con una administración centralizada de cuentas.
- Escalable para redes con diversa cantidad de usuarios.
- Los recursos son agrupados lógicamente.
- Los dominios departamentales pueden tener sus propios administradores para poder administrar los recursos en el departamento.
Desventajas:
- Los grupos locales y globales podrían ser definidos varias veces.
- Mas relaciones de confianza por administrar.
- No todas las cuentas de los usuarios estarían ubicadas en un dominio.
Relaciones de confianza en el modelo Multiple Master Domain
Cada master domain está asociado a otro master domain con una relación de confianza en dos sentidos. Todos los dominios de recursos confían en los master domains, pero no tiene establecida la confianza con otros dominios de recursos.
Como en los otros modelos, cada cuenta de usuario se define sólo una vez. Ya que cada cuenta de usuario en el modelo existe en uno de los master domain y todos los dominios en el modelo confían en el master domain, cada cuenta de usuario en el modelo está disponible en todos los dominios.
Los usuarios se logonean en el master domain que contiene la cuenta del usuario. Cada master domain debe contener dos o mas controladores de dominio Windows NT (para redundancia) para validar logons de usuarios. Luego de logonearlos en los master domain, los usuarios pueden acceder a algún recurso para los cuales tienen permisos. Esto se extiende a cualquier dominio de la red porque todos los recursos confían en los master domains.
Grupos en el Modelo Multiple Master Domain
Con este modelo, un administrador puede crear múltiples grupos globales (uno en cada master domain) de manera de poder distribuir todos los usuarios en la red.
El uso de grupos globales es más complejo en este modelo que el modelo master domain. Si un grupo local necesita contener grupos de usuarios de dos o más master domains, múltiples grupos globales pueden ser creados para el mismo propósito (uno en cada uno de los master domains). Los grupos globales de los múltiples dominios serán miembros del grupo local.
Para minimizar la complejidad, se puede planificar los siguiente:
- Distribuir los usuarios entre los master domains según funciones organizacionales dentro de la compañía.
- Crear grupos locales en los dominios de recursos, y hacer que los grupos globales (de los dominios de cuentas) sean miembros de los grupos locales.
El Modelo de Confianza Completo entre dominios
Si usted necesita administrar los usuarios y recursos en forma distribuida entre diferentes departamentos, en lugar de administrar de manera centralizada, usted debe utilizar este modelo. Con este modelo, cada dominio en la red confía en otro dominio; ningún dominio ejerce control sobre alguno de los otros. El modelo de confianza completa distribuye la administración de los usuarios, grupos, dominios, y recursos entre los diferentes departamentos en lugar de centralizarla.
Ventajas:
- Ideal para empresas con un grupo de administración no centralizado.
- Escalable para redes con cualquier número de usuarios.
- Cada departamento tiene control total sobre las cuentas de usuarios y los recursos.
- Los recursos y las cuentas de usuarios son agrupadas en unidades departamentales.
Desventajas:
- Ya que la administración de usuarios no es centralizada, este modelo no es práctico para empresas donde la administración de los departamentos es centralizada.
- Muchas relaciones de confianza para administrar.
- Cada departamento debe confiar en los otros departamentos, en realidad debe confiar en que los adminstradores de los otros departamentos no coloquen usuarios inapropiados en los grupos globales.
Relaciones de confianza en un Modelo de Confianza Completa
En el este modelo, cada dominio de la red confía en los otros dominios. Cada departamento administra su propio dominio y define los usuarios y los grupos globales. Los usuarios y grupos globales pueden ser usados en todos los dominios en el modelo de confianza completa.
Determinación del número de Confianzas
El número de relaciones de confianza requerida para una compañía con n dominios: n * (n-1)
Por ejemplo, 4 dominios requieren 12 relaciones de confianza y 10 dominios requieren 90 relaciones de confianzas. El agregar un dominio a una red existente de 10 dominios requiere establecer 20 nuevas relaciones de confianza.
Seguridad
Ya que la administración es no centralizada, los usuarios de otros dominios que tengan acceso a los recursos podrían incrementar el riesgo sobre la seguridad.
Este modelo requiere un alto grado de confianza en los grupos globales de otros dominios trusted. Cuando se le asignan permisos a un grupo global de otro dominio (o se incorpora el grupo global dentro de un grupo local en el dominio), usted está confiando en que el administrador de otro dominio no agregará usuarios no autorizados o inapropiados al grupo global.
17. Protección de los datos del server
Windows NT ofrece tres tipos de opciones de tolerancia a fallas basadas en software:
– Disk mirroring
– Disk striping with parity
– Sector sparing
Sistemas RAID
Las opciones de tolerancia a fallas son estándar y se categorizan en seis niveles, de nivel 0 a nivel 5 conocidos como RAID (Redundant Arrays of Inexpensive Disks. Estos niveles ofrecen varias combinaciones de performance, confiabilidad y costo. Windows NT Server soporta RAID 0, 1 y 5. Los niveles 2, 3 y 4 fueron parte de la evolución al nivel 5.
Soluciones de Hardware
La tolerancia a fallos, pueden ser aplicada también con hardware. Algunos vendedores implementan RAID 5 directamente en el hardware, esto lo hacen posible con tarjetas controladoras de discos múltiples. Ya que estos métodos son específicos de cada vendedor, pueden proveer algunas ventajas adicionales a la protección por software. En algunos casos, ciertas implementaciones de hardware permiten reemplazar unidades de discos dañadas sin apagar el equipo. Las desventajas de la implementación de la protección por hardware son en principio el costo y la necesidad de quedar atado a algún vendedor en especial.
RAID 0 – Disk Striping
Divide los datos en bloques de 64 Kb y los esparce en un orden fijo entre todos los discos en un arreglo.
Graba los datos a todas las particiones a la misma velocidad y al mismo tiempo. Ya que no provee redundancia, este método no puede ser aplicado como método para tolerancia a fallas. Si alguna partición en el conjunto de discos falla, se perderán todos los datos.
Nota: para implementar este método, se necesitan como mínimos dos discos y hasta 32 discos pueden ser soportados. También las controladoras de discos múltiples pueden agregar performance a esta tarea.
No se puede utilizar sobre una partición de booteo o del sistema.
RAID 1 – Disk Mirroring
Es la duplicación de la partición de datos en otro disco físico. Cualquier partición, incluyendo las particiones del sistema o de booteo, pueden ser espejadas. Esta estrategia sirve para simplificar la manera de proteger el sistema ante la falla de un disco.
En términos de costos de pesos por megabyte, el espejado de disco es mas caro que otras formas de tolerancia a fallas ya que la utilización de espacio de disco es solamente 50 por ciento. De todas manera, para pequeñas redes peer-to-perr , el espejado de discos puede ser una buena alternativa por su bajo costo de puestas en marcha, ya que se requieren solamente dos discos.
Disk duplexing
Este método toma un par de discos espejados y agrega una controladora de disco al segundo disco del espejado. Esto reduce el trafico del canal y aumenta la performance. Duplexing permite la protección del sistema ante la falla de una controladora como bien puede fallar un disco.
RAID 5 – Striping with Parity
En estos momento es el método más popular para el diseño de la tolerancia a fallas. Difiere de los otros niveles en que la escritura de la información de paridad se escribe a través de todos los discos en un arreglo. La información de paridad y los datos son almacenados de manera que permanezcan siempre sobre discos diferentes.
Nota: un mínimo de tres y un máximo de treinta y dos discos son soportados
Un bloque de paridad existe para cada fila de datos a través de los discos. El block de paridad es usado para reconstruir los datos ante una falla física del disco.
Si un disco falla, entonces la información que permanece en los demás discos, junto con la información de paridad permite que se reconstruya la información faltante. Por ejemplo, si el disco 3, en el gráfico, falla y necesita ser reemplazado, los datos del nuevo disco pueden ser regenerados usando los datos y la información de paridad en cada fila o bloque de los cuatro discos restantes.
Todas las particiones, excepto la partición del sistema o de booteo pueden ser utilizadas para aplicar este método.
Ofrece la mejor performance para operaciones de lectura. Pero, cuando un disco falla, la performance de lectura se degrada, ya que los datos son recuperados utilizando la información de paridad.
Las operaciones normales de escritura requieren tres veces mas memoria para calcular la información de paridad.
Disk Mirroring vs. Striping with Parity
La implementación de la estrategia de tolerancia a fallas requiere una comparación entre los distintos métodos según el nivel de protección deseado.
Las diferencias mas notables entre disk mirroring y striping with parity son la performance y el costo.
Características del Espejado de discos
– Soporta FAT, HPFS y NTFS
– Se puede espejar la partición del booteo o del sistema
– Requiere dos discos rígidos
– Alto costo por Megabyte (50% de la utilización)
– Buena performance para lectura y escritura
– Baja utilización de memoria.
Características del RAID 5
– Soporta FAT, HPFS y NTFS
– No se puede armar sobre una partición de booteo o del sistema
– Requiere como mínimo tres discos
– Bajo costo por megabyte (para cuatro discos se pierde un 25 % de la capacidad)
– Performance de escritura moderada (por el calculo de la paridad)
– Excelente performance de lectura
– Requiere mas memoria (para calcular la información de paridad)
– Soporta hasta 32 discos
Sector Sparing
En conjunción con las opciones de soporte para tolerancia a fallas en el RAID, Windows NT Server brinda posibilidades recuperación de sectores del file system durante la operación del sistema. El file system verifica todos los sectores cuando un volumen es formateado, y cualquier sector defectuoso es retirado de servicio.
Nota: El Sector Sparing es aplicable para dispositivos SCSI (Small Computer System Interface), pero los dispositivos IBM PC/AT (ESDI e IDE) no pueden utilizar esta propiedad.
Cuando un volumen es formateado, el sistema de archivos verifica los sectores en la partición y deja sin efecto cualquier sector defectuoso.
Como trabaja este sistema
En un sistema tolerante a fallas con copias redundantes de los datos, todas las operaciones de lectura/escritura al disco son verificadas. Si se detecta un sector con fallas, ocurre los siguiente:
1- El driver de tolerancia a fallas de NT remueve el dato desde el sector defectuoso
2- El driver coloca el dato en un sector bueno
3- El driver marca al sector como inutilizable. Si esto ocurre sin problema, el sistema de archivos no es avisado del problema.
Luego, el driver de tolerancia a fallas le solicita el driver del disco que obtenga el dato desde el nuevo sector (una vez que el dato fue escrito)
Implementación de la Tolerancia a Fallas
El programa de Administración de discos es la principal herramienta para configurar la tolerancia a fallas de Windows NT Server. La interface gráfica del Administrador de discos hace sencillo configurar y administrar las particiones de discos y la tolerancia a fallas.
El Administrador de discos es utilizado para configurar distintas configuraciones de discos, incluyendo:
– Stripe sets with parity (RAID 5): acumula múltiples áreas de discos en una partición mas grande, distribuyendo los datos almacenados entre todos los discos simultáneamente, agregando la información de paridad a la tolerancia a fallas.
– Mirror sets (RAID 1): se hace un duplicado de una partición y el mismo se graba en otro disco separado
– Volume sets: acumula las áreas de múltiples discos en una partición mas grande, el set se arma en secuencia.
– Stripe sets (RAID 0): acumula múltiples áreas de disco en una partición mas grande, los datos se distribuyen entre todos los discos simultáneamente.
Recuperación de datos
Fallas en la partición: cuando el disco es miembro de sistemas de Espejado y RAID 5
Un miembro de un set de espejado, o de un RAID 5, es una partición de un disco físico que pertenece al set. Cuando un miembro de estos sistemas falla (como una caída de energía o la ruptura del disco), el driver de tolerancia a fallas direcciona todas las entradas/salidas al miembro activo del volumen tolerante a fallas. Esto asegura la continuidad del servicio, al menos hasta que el sistema sea reiniciado. Si la falla envuelve a la partición del sistema en el disco físico primario, un disco de booteo tolerante a fallas es requerido para reiniciar el sistema. El procedimiento para crear este disco de booteo es discutido mas adelante.
Rearmado del espejado
Cuando un miembro del set de espejado falla, usar el administrador de discos para:
1- Cortar la relación del set de espejado y colocar la partición que queda (sin problemas) como un volumen separado.
2- Si no lo hace automáticamente, asignar al miembro del set que queda trabajando la letra de la unidad que previamente estaba asignada al set de espejado completo.
3- Asignar a la partición que falló la próxima letra disponible o cualquier letra disponible
Opcionalmente, se puede usar el espacio libre en otro disco para crear un nuevo set de espejado. Cuando la computadora es reiniciada, el dato de la partición buena es copiado al nuevo miembro del set de espejado.
Regeneración de un RAID 5:
Cuando un miembro de un sistema RAID 5 falla, se puede continuar utilizando la computadora y acceder a los datos. Sin embargo cuando se leen datos, se deben regenerar los datos en la RAM utilizando los bits de paridad, y la performance del sistema bajará considerablemente.
Para que la computadora retorne al estado original del RAID 5 luego de que un miembro del sistema ha fallado, se puede regenerar el dato del miembro con fallas desde los miembros del set que quedan sin problemas.
Para que la computadora regrese al estado original:
1- Usar el Administrador de discos, seleccionar el set de RAID 5, y luego seleccionar una nueva área de espacio libre de disco (en un disco diferente) del mismo tamaño, o mas grande, que los otros miembros del RAID 5.
2- Seleccionar el comando Regenerate del menú Fault Tolerance.
Cuando se reinicia la computadora, el driver de tolerancia a fallas lee la información desde los otros miembros del set del RAID 5. Entonces recrea el dato del miembro con fallas y escribe el dato regenerado al nuevo miembro.
Creación de un disco de booteo tolerante a fallas
Cuando se espeja la partición de booteo de una computadora con Windows NT Server, se necesita crear un disco de booteo tolerante a fallas para se utilizado en caso de que un disco físico falle. Este disco puede ser creado en cualquier momento con la computadora en línea; y debe ser formateado en una computadora con Windows NT Server.
Creación del disco de booteo:
1- Formatear un disquete usando Windows NT Server. Esto escribe información a la pista de booteo del disquete para que se puedan leer los archivos de arranque cuando el sistema arranca
2- Copiar los siguientes archivos desde la partición primaria de la computadora al disquete de booteo. Algunos de estos archivos están ocultos en el directorio raíz.
Archivos: NTLDR, NTDETECT.COM, NTBOOTDD.SYS (para disco SCSI con la BIOS SCSI no cargada), BOOT.INI
3- Modificar el BOOT.INI para que apunte a la copia espejada de la partición de booteo
4- Testear el disquete de booteo para asegurarse de que trabaje correctamente booteando desde la copia espejada de la partición de booteo.
Cualquier información de la partición que sea modificada, debe se contemplada actualizando el archivo BOOT.INI.
Recuperación de un Set Espejado
Si la partición del sistema en un set espejado falla, el set espejado no booteará. Sin embargo, el datos no se pierde, y puede ser recuperado.
Para recuperar un set espejado:
1- Reemplazar el disco con fallas
2- Bootear el sistema con un disquete de booteo Windows NT que cargue el sistema operativo desde la partición espejada.
3- Romper el espejado existente.
4- Colocar otra unidad de disco de backup
5- Restablecer el espejado con el nuevo disco
6- Rebootear el sistema sin el disquete de booteo.
Importante: El disco de booteo con NT no puede ser creado cuando el sistema esta bajo. Debe ser creado antes de la falla. Puede ser generado en otra computadora corriendo Windows NT Server que mantenga una configuración idéntica a la que se está manejando.
Autor:
Pablo A. Bauducco
19 años, DNI: 28897162 Estudiante 2º año Analista de Sistemas Sunchales – Santa Fe – Argentina
| Página siguiente |