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 anterior | Volver al principio del trabajo | Página siguiente  |