En una entrada anterior se ha mencionado el Directorio Activo ("Active Directory", en inglés), o Directorio Administrativo, como también se le llama.
Se trata de la implementación de servicio de directorio en una red distribuida de ordenadores de Microsoft. Utiliza distintos protocolos, principalmente LDAP, DNS, DHCP y Kerberos.
Se puede explicar fácilmente definiéndolo como un servicio establecido en uno o varios servidores en donde se crean objetos tales como usuarios, equipos o grupos, con el objetivo de administrar los inicios de sesión en los equipos conectados a la red, así como también la administración de políticas en toda la red.
Su estructura jerárquica permite mantener una serie de objetos relacionados con componentes de una red, como usuarios, grupos de usuarios, permisos y asignación de recursos y políticas de acceso.
El Directorio Administrativo permite a los administradores establecer políticas a nivel de empresa, desplegar programas en muchos ordenadores y aplicar actualizaciones críticas a una organización entera. Un Directorio Activo almacena información de una organización en una base de datos central, organizada y accesible. Pueden encontrarse desde directorios con cientos de objetos para una red pequeña hasta directorios con millones de objetos.
Su estructura jerárquica permite mantener una serie de objetos relacionados con componentes de una red, como usuarios, grupos de usuarios, permisos y asignación de recursos y políticas de acceso.
El Directorio Administrativo permite a los administradores establecer políticas a nivel de empresa, desplegar programas en muchos ordenadores y aplicar actualizaciones críticas a una organización entera. Un Directorio Activo almacena información de una organización en una base de datos central, organizada y accesible. Pueden encontrarse desde directorios con cientos de objetos para una red pequeña hasta directorios con millones de objetos.
El Directorio Administrativo organiza los objetos propios de un dominio creado en un servidor de Windows. Dichos objetos son:
- Unidades organizativas.
- Grupos
- Usuarios
UNIDADES ORGANIZATIVAS
Las unidades organizativas se utilizan para organizar los objetos dentro del Directorio Activo. Cualquier objeto (usuarios, grupos, equipos, etc.) puede ser colocado dentro de unidades organizativas para facilitar su administración. Las dos principales razones por las que se crean unidades organizativas son:
- Administrar varios objetos a la vez mediante políticas de grupo.
- Delegar ciertas tareas de administración a un usuario.
USUARIOS
El usuario es aquel que utiliza, en mayor o menor medida, el dominio, por lo que es un objeto importante del mismo. Pero, para que un usuario pueda emplear los servicios del dominio, debe tener una cuenta en él, así como un perfil de usuario.
Las cuentas de usuario
Tanto los usuarios como los equipos que se conecten a un dominio necesitan una cuenta de dominio creada para poder trabajar. Las cuentas de equipo se crean automáticamente cuando los equipos se conectan por primera vez al dominio, por defecto se crean en un contenedor llamado "Computers".
Las cuentas de usuario y equipo de Directorio Administrativo representan una entidad física, como un equipo o una persona. La cuenta de usuario hace posible lo siguiente:
Esto es así para no sobrecargar la red ni el dominio, si el usuario trabajara sobre el perfil móvil del servidor directamente, habría que estar continuamente enviando información entre la máquina y el servidor y sería muy lento desde el punto de vista del usuario. Otro motivo para trabajar con el perfil local, es que esto permite trabajar al usuario, aunque el servidor deje de estar operativo momentáneamente.
Una vez que el usuario cierra sesión, el perfil local se sincroniza con el perfil que está almacenado en el servidor, añadiendo todos los nuevos documentos y configuraciones, cambiando los que se hayan modificado, etc.
Por lo tanto, en la máquina donde el cliente ha estado trabajando se queda grabado un perfil local, que es, en teoría, una copia del perfil móvil que está almacenado en el servidor.
- Autentificar la identidad de la persona que se conecta a la red.
- Controlar el acceso a los recursos del dominio.
- Auditar las acciones realizadas utilizando la cuenta.
Windows Server sólo crea dos cuentas de usuario predefinidas: la cuenta Administrador, que otorga al usuario todos los derechos y permisos, y la cuenta Invitado, que tiene derechos limitados. El resto de las cuentas las crea un administrador y son cuentas de dominio (válidas a lo largo de todo el dominio de forma predeterminada). Un controlador de dominio no puede crear cuentas locales, como se puede comprobar si se intenta ejecutar "lusrmgr.msc" (gestión de usuarios locales) en un controlador de dominio.
El primer elemento principal de una cuenta de usuario es el nombre principal de usuario, o nombre de inicio de sesión de usuario (muy similar al nombre de inicio de sesión en cualquier sistema operativo individual o página web en la que un usuario esté registrado). Este nombre permite al usuario conectarse a una red del servidor de Windows, y está compuesto por dos partes separadas por el signo "@" (como si fuera una cuenta de correo electrónico).
De forma predeterminada, el nombre del usuario lo otorga un administrador al crear la cuenta de usuario, mientras que el sufijo principal es el nombre del dominio que se ha creado en el controlador de dominio.
Por motivos de seguridad, es conveniente que los administradores tengan dos cuentas en el sistema: una cuenta administrativa y una cuenta de usuario normal. Se debería utilizar la cuenta de usuario normal a menos que se estén realizando tareas administrativas.
El segundo elemento importante de la cuenta de usuario es, evidentemente, la contraseña. De este modo, todos los usuarios del dominio deberían tener contraseñas bien escogidas y se les debería requerir que las cambiasen periódicamente. Las cuentas deberían establecerse de forma que se bloqueasen cuando se introdujesen contraseñas incorrectas (permitiendo tres intentos, para dejar margen a errores tipográficos, por ejemplo). En este caso, se deberían aplicar las buenas prácticas con las contraseñas explicadas en una entrada anterior.
En Windows Server está activa por defecto la opción de seguridad que obliga a que todas las contraseñas cumplan los requisitos de complejidad, aunque se puede modificar su comportamiento.
Por otra parte, conviene educar a los usuarios sobre las contraseñas y su privacidad, pero, sobre todo, merece la pena hacer caso de los propios consejos: hay que asegurarse de que la contraseña seleccionada para administración es una buena contraseña y cambiarla frecuentemente. Hacer esto ayudara a evitar las consecuencias de que alguien se introduzca en el sistema y cause estragos. Si se permiten conexiones a la red desde sitios remotos, debería incluirse más seguridad que la autorización por contraseña de nivel de dominio.
Por otra parte, conviene educar a los usuarios sobre las contraseñas y su privacidad, pero, sobre todo, merece la pena hacer caso de los propios consejos: hay que asegurarse de que la contraseña seleccionada para administración es una buena contraseña y cambiarla frecuentemente. Hacer esto ayudara a evitar las consecuencias de que alguien se introduzca en el sistema y cause estragos. Si se permiten conexiones a la red desde sitios remotos, debería incluirse más seguridad que la autorización por contraseña de nivel de dominio.
Los perfiles de usuario
En Windows, un perfil de usuario consiste en un espacio de almacenamiento donde se guardan los documentos del usuario, distintas preferencias, la organización de su escritorio, los favoritos del navegador web, las configuraciones del registro de sistema de dicho usuario, etc.
Cuando se trabaja con un sistema operativo cliente, este perfil se almacena localmente, es decir, en la máquina donde se trabaje, y en una carpeta determinada.
Cuando se trabaja con un sistema operativo cliente, este perfil se almacena localmente, es decir, en la máquina donde se trabaje, y en una carpeta determinada.
Una de las ventajas de montar un dominio, es que es posible utilizar perfiles que no se almacenen localmente, sino en el servidor. En un dominio se pueden utilizar:
- Perfiles de usuario locales.
- Perfiles de usuario móviles.
- Perfiles de usuario obligatorios.
Obviamente los usuarios pueden ir almacenando sus documentos en lápices de memoria e irlos pasando de un ordenador a otro, pero esto no quita que sea una fuente de errores importante. Además, un perfil guarda mucha más información aparte de los documentos.
Otro problema con los perfiles de usuario locales, es la pérdida de datos por avería o cualquier otro motivo. Puesto que el perfil está grabado en el ordenador local, si este se estropea o tiene que ser cambiado, el usuario se encontrará con que ha perdido sus datos si no los tenía almacenados en algún otro sitio de respaldo.
Otro problema con los perfiles de usuario locales, es la pérdida de datos por avería o cualquier otro motivo. Puesto que el perfil está grabado en el ordenador local, si este se estropea o tiene que ser cambiado, el usuario se encontrará con que ha perdido sus datos si no los tenía almacenados en algún otro sitio de respaldo.
Las copias de seguridad de la empresa, también se ven muy afectadas por los perfiles de usuario locales. Cada vez que se pretenda hacer una copia de seguridad de todo, será necesario ir ordenador por ordenador copiando sus perfiles, con lo que se acumularán muchas versiones de un mismo fichero.
Para utilizar perfiles de usuario locales no hay que hacer nada. Es la opción por defecto del dominio y si no se configura, es la opción que se empleará.
Para utilizar perfiles de usuario locales no hay que hacer nada. Es la opción por defecto del dominio y si no se configura, es la opción que se empleará.
Por su parte, en un perfil de usuario móvil el perfil no se almacena en la máquina local donde se conecta el usuario, sino que se queda almacenado en una carpeta de red, normalmente ubicada en el mismo controlador de dominio. Cuando un usuario abre sesión en una máquina cliente del dominio, se carga el perfil móvil de dicho usuario desde el servidor, y se guarda una copia en la máquina cliente.
El usuario trabaja en la máquina cliente sobre ese perfil que se ha cargado desde el servidor, por lo que en realidad se comporta como si fuera un perfil local, es decir, cuando guarda un documento lo guarda localmente, no en el servidor.
El usuario trabaja en la máquina cliente sobre ese perfil que se ha cargado desde el servidor, por lo que en realidad se comporta como si fuera un perfil local, es decir, cuando guarda un documento lo guarda localmente, no en el servidor.
Esto es así para no sobrecargar la red ni el dominio, si el usuario trabajara sobre el perfil móvil del servidor directamente, habría que estar continuamente enviando información entre la máquina y el servidor y sería muy lento desde el punto de vista del usuario. Otro motivo para trabajar con el perfil local, es que esto permite trabajar al usuario, aunque el servidor deje de estar operativo momentáneamente.
Una vez que el usuario cierra sesión, el perfil local se sincroniza con el perfil que está almacenado en el servidor, añadiendo todos los nuevos documentos y configuraciones, cambiando los que se hayan modificado, etc.
Por lo tanto, en la máquina donde el cliente ha estado trabajando se queda grabado un perfil local, que es, en teoría, una copia del perfil móvil que está almacenado en el servidor.
Lo que sucede es que cada vez que un usuario inicia sesión, el servidor de Windows no se limita a copiar el perfil móvil en el perfil local, machacando todo lo que hubiera en el equipo cliente, sino que realiza una combinación, o sincronización, de ambos perfiles, sobreescribiendo los archivos y documentos siempre con el que tenga una fecha posterior, y combinando los archivos únicos de ambos perfiles.
Esto puede conllevar varios comportamientos “extraños” en los perfiles, sobre todo si existen varios usuarios que usen una misma cuenta de usuario, y esta se configura con perfil móvil. Por ello, hay que intentar siempre conceder perfiles móviles únicamente a las cuentas que se sepa que son usadas por una única persona.
Esto puede conllevar varios comportamientos “extraños” en los perfiles, sobre todo si existen varios usuarios que usen una misma cuenta de usuario, y esta se configura con perfil móvil. Por ello, hay que intentar siempre conceder perfiles móviles únicamente a las cuentas que se sepa que son usadas por una única persona.
GRUPOS
La razón más frecuente para crear grupos en un dominio es la de agrupar y organizar las cuentas de los usuarios, y, a su vez, asignarles permisos de forma conjunta. En general, siempre es recomendable asignar permisos a grupos, y nunca a usuarios de forma individual.
Existen dos tipos principales de grupos en el Directorio Administrativo: Grupos de distribución y grupos de seguridad.
Grupos de distribución
Estos grupos no cuentan con SID (identificador de seguridad) propio, de modo que no pueden ser introducidos en las ACL (listas de control de acceso a los recursos). Estos grupos solo se suelen utilizar cuando se pretende crear un grupo para realizar envíos de correo a varios usuarios habitualmente.
Grupos de seguridad
Estos grupos cuentan con un SID, de modo que pueden ser utilizados para ser introducidos en las ACL.
Independientemente de su tipo, todos los grupos tienen un atributo de ámbito que determina dónde se puede utilizar dicho grupo en una red:
Así, dependiendo del nivel funcional del dominio se podrán o no introducir determinados miembros dentro de cada tipo de grupo. De este modo:
- Grupos locales de dominio: Su ámbito es local, es decir, los grupos locales no son visibles fuera del dominio en el que se crean.
- Grupos globales de dominio: Su ámbito es global, es decir, los grupos globales son visibles en todos los dominios que formen parte del bosque.
- Grupos universales: Su ámbito es global, al igual que en los grupos globales.
Así, dependiendo del nivel funcional del dominio se podrán o no introducir determinados miembros dentro de cada tipo de grupo. De este modo:
- Grupos locales de dominio: Un grupo de este ámbito puede contener grupos globales y universales de cualquier dominio del bosque, así como cuentas de usuario y equipos de cualquier dominio del bosque, y otros grupos locales, pero únicamente del mismo dominio en el que se ha creado.
- Grupos globales de dominio: Un grupo del presente ámbito puede contener bien otros grupos globales del mismo dominio donde se crea el grupo global, o cuentas de usuario y equipos del mismo dominio donde se crea el grupo global. Sin embargo, no puede contener grupos universales ni grupos locales, ni grupos globales ni cuentas de usuario ni cuentas de equipo de fuera de su propio dominio.
- Grupos universales: Un grupo de este ámbito puede contener grupos universales, grupos globales, cuentas de usuario y cuentas de equipo de cualquier dominio del bosque. Un grupo universal no puede contener grupos locales.
Se debe tener en cuenta que el grupo de dominio local es un grupo de seguridad o distribución que puede contener grupos universales, grupos globales, otros grupos locales de dominio de su propio dominio y cuentas de cualquier dominio del bosque.
En los grupos de seguridad local, solamente puede otorgar derechos y permisos sobre los recursos que residen en el dominio en el que está ubicado el grupo local de dominio.
En los grupos de seguridad local, solamente puede otorgar derechos y permisos sobre los recursos que residen en el dominio en el que está ubicado el grupo local de dominio.
Por su parte, el grupo global es un grupo de seguridad o distribución que puede contener usuarios, equipo y grupos globales de su propio dominio. Puede conceder derechos y permisos a los grupos de seguridad global para los recursos de cualquier dominio del bosque.
Por otra parte, un grupo universal es un grupo de seguridad o distribución que puede contener usuarios, equipos, grupos universales y grupos globales de cualquier dominio del bosque. Se pueden conceder derechos y permisos a los grupos de seguridad universales sobre los recursos de cualquier dominio del bosque.
No obstante, se debe tener cuidado al anidar grupos (incluir grupos como miembros de grupos) si se tiene el nivel funcional del dominio elevado a Windows 2003 o superior, ya que el sistema permitirá anidar recursivamente, es decir, es posible llegar a formar un bucle infinito de membresías.
Para evitar esto no se recomienda introducir dentro de un grupo local otro grupo local, del mismo modo que no se recomienda utilizar grupos universales.
Los tipos de grupos se suelen utilizar mediante la estrategia AGDLP, donde "A" indica Accounts (Cuentas de usuario), "G" indica grupos Globales, "DL" indica grupos locales de dominio (Domain Local) y "P" indica permisos. Una forma de recordar la estrategia es: las cuentas de usuario se meten en grupos globales, que a su vez se meten en grupos locales, que es a los que se les asigna los permisos.
Los grupos universales se usan únicamente cuando se tienen infraestructuras con múltiples dominios, mediante la estrategia habitual AGUDLP (Cuentas –> Grupos Globales –> Grupos universales –> Grupos Locales –> Permisos).
Los grupos universales se usan únicamente cuando se tienen infraestructuras con múltiples dominios, mediante la estrategia habitual AGUDLP (Cuentas –> Grupos Globales –> Grupos universales –> Grupos Locales –> Permisos).
Espero que esta entrada haya sido interesante y/o útil al lector. Si es así, aguardo que el lector la comente y/o comparta, por favor.
Muchas gracias al blog de https://science-of-truth.com/como-guardar-un-correo-de-outlook/ porque tiene temas actualizados sobre los correos electrónicos que podemos aprender a manejar.
ResponderEliminar