Windows Server: Utilización de Grupos Restringindos (“Restricted Groups”)–Parte 1 de 2

La utilización de Grupos Restringidos es una solución muy buena cuando hay que controlar la membresía en grupos, ya sea para restringir los miembros de un grupo, como para automatizar la inclusión de cuentas en determinados grupos

Un ejemplo clásico de esto último es cuando se desea que un grupo de soporte de usuarios se incluya en el grupo administradores locales de todas las estaciones de trabajo

Por otra parte, y para dar un ejemplo del primer caso, es cuando por una falta de planificación previa se quieren controlar las cuentas que tendrán privilegios administrativos sobre servidores, quitando las cuentas no apropiadas

Todo esto se puede hacer automáticamente mediante GPOs con Grupos Restringidos

En esta primera nota veremos justamente cómo podemos controlar y limpiar si fuera necesario la membresía de grupos en un ambiente de servidores, aunque sería análogo para máquinas cliente

Y aprovecharé para mostrar algunos detalles muy importantes que a veces provocan confusiones y efectos no deseados

Administración Centralizada de los Administradores Locales – Parte 2 de 2

Habiendo completado todos los procedimientos de la nota anterior (“Administración Centralizada de los Administradores Locales – Parte 1 de 2”) en esta vamos a completar las configuraciones necesariasy demostrar su utilización

Comenzaremos con una forma de saltarse las limitaciones que mencionamos anteriormente como es habilitar la cuenta de administrador y asignarle una contraseña en forma remota

Administración Centralizada de los Administradores Locales – Parte 1 de 2

Hace un tiempo ya publiqué una nota sobre cómo poder administrar la cuenta administradora local de las máquinas de un Dominio Active Directory (“Habilitar y Renombrar el Administrador Local Usando Group Policies (Directivas de Grupo”). En su momento funcionaba perfectamente, pero una actualización de seguridad de Windows hizo que dejara de ser posible usar ese método (“Microsoft Security Bulletin MS14-025 – Important”)

Esta actualización, evitaba por riesgo de seguridad que la contraseña de usuario esté incluida en una GPO, porque aunque la misma se almacenaba en forma “oscurecida” aún era posible que bajo ciertas circunstancia pueda ser legible

Como una forma de remediar el problema que provoca en la administración centralizada Microsof ha liberado una aplicación adicional que permite volver a hacer la administración centralizada: Local Administrator Password Solution (LAPS)

Vamos a ver su implementación y uso, incluyendo las configuraciones adicionales que hay que hacer

Cambiar un Servidor o su Nombre y Actualizar los Accesos Directos

En algunas ocasiones, debemos cambiar el nombre de un servidor, o simplemente redirigir los accesos directos a un nuevo servidor, o inclusive deseamos consolidar diferente servicios provistos por diferentes servidores en uno solo

La consecuencia de cualquiera de los casos anteriores es tener que cambiar todos los accesos directos que pueden estar incluidos en muchos lugares, scripts, inclusive mapeos de carpetas compartidas en scripts

Lo primero que se puede ocurrir como solución es crear en DNS un Alias (CNAME) pero esto en sistemas operativos “viejos” era un problema y requería configuración adicional en todas las máquinas que usaran los accesos directos. Actualmente no es así, y vamos a demostrarlo

Cambiar la Configuración Regional Usando Group Policies (Directivas de Grupo)

Una consulta que he escuchado varias veces es el cambio de la configuración regional en forma masiva en máquinas cliente

En lugar de tener que hacer que cada usuario lo tenga que configurar individualmente, este procedimiento puede automatizarse a través de Group Policies (GPOs) y es muy sencillo, si uno conoce un pequeño “truco” ;)
De todas formas, como veremos, a mi entender tiene una falla

Habilitar y Renombrar el Administrador Local Usando Group Policies (Directivas de Grupo)

[Actualización 28-07-15] Consultar la nueva forma de hacerlo en: Administración Centralizada de los Administradores Locales – Parte 1 de 2:
https://windowserver.wordpress.com/2015/07/28/administracin-centralizada-de-los-administradores-locales-parte-1-de-2/

Una muy buena medida de seguridad en todas las últimas versiones de Windows cliente, es que la cuenta predefinida de Administrador (“Administrator”) por omisión queda deshabilitada

Pero a veces es conveniente, por diferentes motivos tenerla habilitada, pero para mitigar los riesgos podemos cambiarle el nombre a esta cuenta

Aunque es fácil hacerlo manualmente en cada máquina, si lo anterior lo debemos hacer en muchas máquinas, entonces puede ser algo tedioso. Pero lo podemos hacer en forma masiva a través de Directivas de Grupo (“Group Policies = GPO)

Remote Desktop: Limitar a un Usuario Normal las Herramientas Administrativas que Puede Utilizar

En las dos notas anteriores vimos cómo configurar para permitir que un usuario normal pueda acceder por Remote Desktop (Escritorio Remoto) en modo administración a un Controlador de Dominio, y además cómo permitirle utilizar las herramientas administrativas

En esta ocasión veremos cómo podemos limitar qué herramientas puede utilizar, ya que el hecho de que pueda, aunque sólo sea ver información, es un problema de seguridad

Como había comentado en la nota anterior, supondré un caso como es: una persona de confianza que sólo debe poder acceder al “Event Viewer” (Visor de Sucesos)

Remote Desktop: Permitir a Usuarios Normales Utilizar las Heramientas Administrativas en Controlador de Dominio

En la nota anterior vimos cómo configurar un Controlador de Dominio para permitir que un usuario normal pueda conectarse por Remote Desktop (Escritorio Remoto) en modo administración

Pero hemos visto que con la configuración hecha, no alcanza para que pueda ejecutar las herramientas administrativas

En esta nota veremos la configuración adicional, para que pueda utilizarlas, aunque por supuesto si no se ha delegado ninguna tarea administrativa no podrá modificar nada. Pero que sólo pueda ver toda la información del Dominio ya es un riesgo importante de seguridad. En la tercera y última nota de la serie veremos cómo podemos limitar qué consolas y aplicaciones podrá utilizar

Remote Desktop: Permitir a Usuarios Conectarse a un Controlador de Dominio

Esta nota será el comienzo de una serie de tres donde veremos que configuraciones debemos hacer, para que:

1. Un usuario normal pueda conectarse por Remote Desktop a un Controlador de Dominio
2. Qué debemos configurar para que pueda usar las herramientas administrativas
3. Cómo limitar qué herramientas administrativas puede utilizar

En esta primera nota de la serie veremos cómo permitir que un usuario normal pueda conectarse por Remote Desktop (Escritorio Remoto) a un Controlador de Dominio, ya que la configuración es diferente que si se tratara de un servidor miembro

Es importante tener en cuenta que esta configuración no es una buena práctica de seguridad, ni es recomendada, pero muchas veces en pequeñas organizaciones es una configuración que se hace, y tiene pasos adicionales de configuración

Dynamic Access Control – 2

Continuando con el tema Dynamic Access Control, y habiendo visto en la nota anterior “Dynamic Access Control – 1” las configuraciones inciales y cómo asignar acceso a recursos mediante “User Claims”, en esta nota veremos la otra opción disponible, como es asignar el acceso mediante propiedades del recurso

En esta nota veremos la creación y administración de propiedades de los recursos en forma manual, más sencillo pero que permite ver el comportamiento, dejando para una futura nota cómo se pueden clasificar automáticamente los recursos, o inclusive cómo asignar el privilegio de acuerdo al equipo en que se incie sesión

Dynamic Access Control – 1

A partir de Windows Server 2012 disponemos de una nueva forma de asignar permisos, además de los conocidos de compartido (“Share”) y de seguridad (“NTFS”), como es Dynamic Access Control

He leído bastante sobre el tema, pero todos los ejemplos de implementación que he visto de parte de Microsoft y algunos sitios, han resultado prácticamente un “copiar y pegar” del mismo ejemplo, que a mi entender es muy poco claro para comprender y comenzar a implementarlo

Por lo tanto he decido hacer una pequeña introducción teórica del tema, e ir desarrollando un ejemplo, desde lo más básico a las posibilidades más avanzadas

Delegar Administración en Active Directory

Una capacidad muy importante de Active Directory es la habilidad de poder delegar en forma muy granular algunas tareas administrativas en usuarios que no pertenezcan a alguno del los grupos con poderes administrativos irrestrictos, como por ejemplo los administradores

En una organización muy chica probablemente no se haga delegación de tareas, pero es algo casi imprescindible en grandes organizaciones, ya que no todo el que tenga que ejecutar alguna tarea administrativa tiene que tener los “super poderes” de un administrador
A veces, sobre todo en las medianas, no se delegan tareas por desconocimiento de su funcionamiento
Es una opción muy poderosa, que permite delegar definiendo:

• Qué tarea/s se delegará o delegarán
• Sobre qué tipo de objetos (usuarios, grupos, GPOs, unidades organizativas, etc.)
• Sobre qué partes del Dominio (unidades organizativas, el Dominio, etc.)

Esto también responde a una consulta que se escucha con frecuencia: “que sea administrador, pero que no pueda …”. Lo cual es imposible, ya que si pertence al grupo de Administradores (“Administrators”) no hay forma de quitarle privilegios sobre la máquina o el Dominio

Veremos una demostración muy simple, donde sólo es necesario una máquina Controlador de Dominio

Cinco Formas de Compartir Carpetas – Permisos de Compartido, de Seguridad, y Efectivos

Hace ya mucho tiempo publiqué una nota sobre los permisos efectivos cuando se accede a datos en “Permisos – Permisos Efectivos” pero como las consultas continúan y el sistema de permisos no es tan sencillo en ambiente Windows, me he decidido a agregar esta nota que complementa y avanza un poco más sobre el tema

En especial, demostraré el tema de la combinación de los diferentes permisos, y cómo interactua una entidad especial como es “Creator Owner”

Desde la interfaz gráfica, hay cinco formas diferentes de compartir una carpeta, y cada una tiene sus particularidades, y los permisos efectivos pueden ser diferentes en cada caso

Windows Server: “Shadow Copies” (Instantáneas) y Versiones Anteriores

En mi experiencia de capacitaciones, he visto que la gran mayoría de los administradores de redes desconocen las “Shadow Copies” (Instantáneas), y es algo que puede ahorrarles mucho tiempo cuando hay que recuperar archivos desde una copia de seguridad (Backup)

El objetivo de la funcionalidad es que el propio usuario, y fácilmente, pueda recuperar archivos borrados o versiones anteriores de datos que han sido modificadas

Aunque en forma muy primitiva la funcionalidad viene desde Windows Server 2000 y está muy mejorada actualmente. En Windows Server 2000 se llamaba “Shadow Copies of Shared Folders” o sea que trabajaba sólo sobre carpetas compartidas; pero a partir de Windows Server 2008 además de no usar más esta denominación está integrado a lo que conocemos como “Versiones Anteriores”

Aunque es importante destacar que no es un reemplazo de las copias de seguridad (Backups), pero que en muchos casos puede evitar tener que ir buscando en que copia están los datos a recuperar. Y además, lo puede hacer el propio usuario muy rápidamente

Windows Server – Administración Centralizada – Parte 3

En esta última parte, ahora sí ya estamos en condiciones de mostrar lo que habíamos prometido en la primera nota

Recuerdo lo que venimos haciendo:

• Windows Server – Administración Centralizada – Parte 1
• Windows Server – Administración Centralizada – Parte 2

Y ahora finalmente llegaremos a

Windows Server – Administración Centralizada – Parte 2

Continuando la nota anterior Windows Server – Administración Centralizada – Parte 1, y para mostrar opciones más avanzadas y potentes voy a agregar un servidor más a la infraestructura usada hasta ahora

Lo que nos permitirá hacer la “magia” prometida es “Remote Desktop” (Escritorio Remoto), y esta función no debemos instalarla en un Controlador de Dominio (DC1), ni tampoco sería conveniente en donde está la Autoridad Certificadora (SRV1)

Pero es lo que nos permitirá la administración centralizada casi desde cualquier dispositivo

Siga leyendo si le interesa ;-)

Windows Server – Administración Centralizada – Parte 1

Teniendo en la mayoría de las redes varios servidores, y además como no es deseable acceder físicamente a la sala de servidores, vamos a ver diferentes posibilidades de administración en forma remota

Desde las más conocidas, hasta alguna inpensada

¿Qué opina de la siguiente pantalla? Si, es un Windows 7, pero también podría ser un Windows XP, y aún desde un teléfono móvil, pudiendo administrar todos nuestros servidores Windows Server 2012 R2

En esta primera parte comenzaremos con las más sencillas, aunque no todos las conocen :-)

La Vista del Cuadro de Tareas (“Taskpad Views”) ¿Sabe Qué Es y Como Crearlas?

La Vista del Cuadro de Tareas (“Taskpad Views”) es uno de los elementos que creo que pasa desapercibido para muchos administradores de Dominios Active Directory, y además Microsoft las ha promocionado muy poco

Son consolas (MMCs) personalizadas, orientadas fundamentalmente a facilitar la administración, y por sobre todo cuando se hace delegación de tareas administrativas

¿Ha visto alguna vez algo así?

Sistema Distribuído de Archivos (DFS = “Distributed File System”) Replicación y Sincronización de Datos

En la nota anterior “Sistema Distribuido de Archivos (DFS = “Distributed File System”) ¿Realmente lo Conoce?” hemos visto algunos de los términos fundamentales que debemos conocer para interpretar correctamente su funcionamiento, y además hemos visto la configuración de una de sus funcionalidades principales, la consolidación de carpetas compartidas desde el punto de vista lógico, que no físico

En esta demostración veremos cómo podemos configurar que las carpetas que definimos anteriormente se pueden replicar y sincronizar con otras en diferentes servidores, de forma tal que las podríamos aprovechar para por ejemplo: disminuir el tráfico sobre enlaces WAN, proveer tolerancia a fallas, distribuir información, e inclusive recopilar centralizadamente informacion que se genera en diferentes lugares

Sistema Distribuido de Archivos (DFS = “Distributed File System”) ¿Realmente lo Conoce?

He decidido hacer una nota sobre este tema porque he visto cuando dicto capacitación que muchos no lo conocen, o por lo menos desconocen una parte de su funcionalidad

El Sistema Distribuido de Archivos, en adelante DFS, tiene dos utilidades fundamentales:

1. La primera, y quizás menos conocida, es la de presentar una estructura lógica ordenada de carpetas compartidas, aunque estén ubicadas físicamente en diferentes servidores y sitios geográficos
2. La segunda, y creo que es la más conocida, es poder mantener en forma sincronizada una carpeta entre diferentes servidores
   Esto último, tiene la ventaja de aprovechar la infraestructura física de la red, ya que un cliente siempre va a tratar de conectarse a la copia local, pero también provee en cierta medida tolerancia a fallas

Por supuesto que esto no es un sistema ideal, ni reemplaza a una copia de seguridad (“Backup”), ni sincroniza archivos abiertos, pero es de utilidad