Grupos en Active Directory I

El tema de grupos en Active Directory, siempre ha sido incomprendido por un gran número de personas, esto lo digo basado en mi experiencia con clientes y con alumnos en mis clases sobre este tema. Entonces, lo que pretendo con este artículo es tratar de explicar el tema de la manera más clara y sencilla posible, ojalá lo logre! y si lo logró por favor házmelo saber con un comentario al final de este artículo.

Empezaré haciendo la primer pregunta que siempre hago en mis clases. ¿Cuándo crean un grupo cuál de las siguientes opciones eligen?

Como se aprecia en la imagen anterior, son los valores que por defecto están seleccionados, lo curioso es que la mayoría de personas escriben el nombre del grupo hacen clic en aceptar, y listo!

Pues en realidad funciona, y el objetivo del grupo recién creado se cumple, pero cuando haces una pregunta del tipo ¿qué pasa si lo cambias a Universal o Dominio local?, probablemente ante esta pregunta muchos no saben que responder, y es precisamente ese el objetivo  de este artículo, aclarar cada una de las opciones que tenemos al crear un grupo, y sobre todo comprender claramente la opción que activemos al momento de la creación, pero no solo eso, durante el recorrido hablaré de las mejores prácticas y aclararé cualquier tema relacionado con grupos y su administración.

Permisos basados en grupos 

Una primera e importante recomendación antes de iniciar, es que te acostumbres a otorgar acceso a los recursos basado en grupos de seguridad, es decir, evita al máximo dar permisos a usuarios individuales, ¿por qué?, porque si damos acceso a usuarios y en algún momento del tiempo el usuario se elimina del directorio, observaremos que en los recursos donde otorgamos permisos a este usuario simplemente no desaparece de allí, en lugar de ello veremos su identificador de seguridad o SID, en este momento es cuando hablamos de SID fantasmas, veamos un ejemplo.

1. Damos permisos a un usuario llamado John Smith en una carpeta llamada Documents del disco local C:

2. Pasado el tiempo, John Smith se retira de la organización, por lo cual su cuenta es eliminada del directorio, al volver a la pestaña de seguridad de la carpeta Documents veremos el famoso SID fantasma, seguramente muchos lo han visto, y tal vez otros se habrán preguntado ¿qué será esto? pues ya lo saben.

Para que esto no ocurra, y como buena práctica, siempre otorgemos permisos a grupos en lugar de a usuarios individuales, ya que generalmente los grupos hacen referencia a funciones, por ejemplo, tenemos un grupo llamado Ventas del cual es miembro el usuario John Smith, para los permisos en la carpeta Documents ponemos el grupo Ventas en lugar del usuario John Smith, con ello así eliminemos al usuario John Smith, el grupo Ventas seguirá apareciendo en la pestaña de seguridad, el usuario John Smith al ser eliminado también lo será del grupo Ventas.

Al trabajar de esta forma, se facilitará la administración, ya que no tenemos que andar "depurando" las listas de control de acceso. 

Grupos predeterminados

En Active Directory, existe una serie de grupos predeterminados, es decir, que se crean durante la instalación de los servicios de dominio, y es importante saber cuáles son y donde se encuentran ubicados.

¿Dónde se encuentran esos grupos por defecto?, en los contenedores Builtin y Users

características importantes de estos dos contenedores.

Builtin

los grupos en este contenedor tienen ámbito local ¿recuerdan la introducción a este artículo?, por ahora no hay que preocuparse ya veremos de que se trata este ámbito. El ámbito y tipo de los grupos que se encuentran aquí no se puede cambiar, por ejemplo el grupo Administradores

Como se puede apreciar en la imagen, las opciones Ámbito de grupo y Tipo de grupo se encuentran deshabilitadas.

Ninguno de los grupos de este contenedor se puede eliminar, es más ni siquiera te da la opción, tampoc es posible cambiar el nombre por defecto.

Algunos grupos que podemos encontrar en este contenedor: Administradores, Operadores de copia de seguridad, Opers. de cuentas, Opers. de servidores, Opers. de impresión, Usuarios de escritorio remoto, Invitados.

Users

El contenedor Users tiene grupos de diferentes ámbitos: Dominio local, Global y Universal, también contiene algunas cuentas integradas, como por ejemplo: Administrador, Invitado y krbtgt.

A diferencia del contenedor Builtin, los grupos y cuentas allí existentes sí pueden ser movidos a otro contenedor o Unidad Organizativa.

El ámbito y tipo de grupo en este contenedor tampoco puede ser modificado.

Ninguno de los grupos en este contenedor puede ser eliminado, aunque la opción está habilitada, si intentas hacerlo recibirás el siguiente mensaje:

El nombre predeterminado de los grupos en este contenedor sí es posible cambiarlo, a diferencia del contenedor Builtin, en la siguiente imagen he cambiado el nombre al grupo Admins. del dominio

Algunos grupos que podemos encontrar en este contenedor: Administradores de empresas, Administradores de esquema, Admins. del dominio, Usuarios del dominio.

Cuentas y grupos privilegiados

Un saludo para todos, bienvenidos y gracias por su interés en el tema, en esta ocasión publicaré una serie de artículos en los cuales explicaré las mejores prácticas para asegurar nuestro servicio de directorio, la información que presentaré está basada primero que todo en mi experiencia con clientes y en documentación técnica de Microsoft, la idea es empezar explicando algunas bases conceptuales las cuales son fundamentales para abordar el tema de seguridad con unas bases sólidas, si ya posees estos conocimientos podrás iniciar desde cualquiera de los artículos, la idea es construir una base completa que pueda ser utilizada tanto por personas con conocimientos básicos y también por personas experimentadas en el tema, el único requisito es trabajar con Active Directory y sobre todo tener muchos deseos de conocer y aplicar las mejores prácticas en el aseguramiento del servicio de directorio de Microsoft.

CUENTAS Y GRUPOS PRIVILEGIADOS

---

En Active Directory, existen grupos que poseen elevados privilegios a lo largo del bosque y dominio, pero frecuentemente he observado como se uitilizan estos grupos para cualquier tipo de actividad, no sé en que momento los administradores empezaron a creer que para hacer ciertas actividades es necesaria una cuenta con privilegios elevados a nivel de dominio, me refiero específicamente a las cuentas pertenecientes a los siguientes grupos: Administradores de empresas, Administradores del dominio, y Administradores. He llegado a ver escenarios donde incluso se usa la cuenta Administrador integrada para unir equipos a un dominio, que es lo que debemos empezar a erradicar a partir de esta serie de artículos de seguridad en Active Directory.

Para empezar, vamos a ver algo de teoría, no te desesperes, poco a poco avanzaremos y mostraré técnicamente cómo hacer las cosas, pero es muy importante la base teórica para lograr exitosamente nuestro objetivo.

GRUPOS CON ALTOS PRIVILEGIOS EN ACTIVE DIRECTORY

---

Administradores de empresas (Enterprise Admins) 

Este grupo existe solamente en el dominio raíz del bosque, básicamente en el primer dominio que instalemos, y de manera predeterminada es miembro de todos los grupos Administradores en todos los dominios del.bosque, tiene permisos para hacer cambios en todo el bosque, cualquier cambio afecta a todos los dominios en el bosque como por ejemplo la eliminación o adición de dominios, establecimiento de relaciones de confianza, elevación de nivel funcional de bosque.

La utilización de este grupo se requiere solamente cuando se van a realizar operaciones como la implementación inicial del bosque, o cuando se va a establecer una relación de confianza con otro bosque, muchos de los permisos que se obtienen con este grupo pueden ser delagados en grupos menos privilegiados.

Admins. del dominio (Domain Admins) 

Este grupo es miembro del grupo Administradores en el dominio, y también es miembro del grupo Administradores de todos los equipos unidos a un dominio, es decir, al momento de unir un equipo al dominio, la cuenta Admins. del dominio se agrega al grupo Administradores local de la máquina unida al dominio, el único usuario que pertenece a este grupo es la cuenta Administrador la cual posee los privilegios más elevados a nivel del dominio, nótese que a diferencia del grupo Administradores de empresas que tiene privilegios a lo largo de todo el bosque, el grupo Admins. del dominio los tiene solo a nivel de dominio, muchos privilegios que tiene este grupo, pueden delegarse, razón por la cual este grupo debería usarse solamente en casos de emergencia, todo depende de la debida delegación de funciones que se implemente.

Administradores (Administrators)

A este grupo pertenecen los dos grupos vistos anteriormente (Administradores de empresas y Admins. del dominio), el grupo posee elevados privilegios a nivel de controlador de dominio, sin embargo, no posee los mismos privilegios en servidores miembro y en los equipos cliente del dominio, ya que este grupo no hace parte del grupo Administradores local de los equipos del dominio, lo cual si existe con el grupo Admins. del dominio.

Con lo anterior hemos visto el objetivo de cada uno de los grupos más privilegiados en Active Directory y sobre los cuales trabajaremos para asegurar nuestro directorio, como podemos observar los elevados privilegios de este grupo hacen que cualquier miembro de éstos pueda tomar el control completo del dominio y bosque, por lo cual debemos enfocarnos en cómo proteger y vigilar la pertenencia a ellos.

Ahora, vamos a ver la aparición de un cuarto grupo llamado Administradores de esquema

Administradores de esquema (Schema Admins)

Este grupo existe solamente en la raíz del bosque, este grupo al igual que Administradores de empresas solo tiene como miembro la cuenta Administrador, se debe agregar un miembro solo en caso que se requiera, ya que el uso de este grupo es muy eventual, solo en casos donde se requiera hacer una modificación del esquema de Active Directory. Por esta razón podemos mantener el grupo sin miembros, y en el caso que se requiera agregamos el miembro temporalmente, una vez finalice la actividad volvemos a retirar el usuario del grupo.

¿Qué hay de nuevo en Windows Server 2012 Active Directory?

Hola a tod@s

Este Miércoles 19 de Febrero los invito a un webcast que realizaré para Microsoft Technet Latinoamérica, donde hablaré sobre las novedades en Windows Server 2012 Active Directory, algunos de los temas son: Uso de interfaz gráfica para Recycle Bin y políticas de contraseña refinadas, virtualización segura de controladores de dominio, clonación de controladores de dominio, mejoras en Kerberos, control de acceso dinámico, mejoras en el bloque RID y más.

Enlace para registro: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032577878&Culture=es-AR&community=0

Crear una conexión VPN Point-to-Site en Windows Azure

Actualización 26/03/2017: Esta información ha sido actualizada al nuevo portal de Azure con ARM. Artículo actualizado aquí

En esta ocasión veremos cómo crear una conexión VPN Poin-to-Site entre Windows Azure y cualquier equipo local, existe otro tipo de conexión en Azure llamado VPN Site-toSite que permite conectar la red de Windows Azure con una red local, la diferencia es clara la opción que trataremos me permite conectar un único equipo a la red de Azure, mientras que la segunda opción permite conectar toda una red local a la red de Windows Azure.

Vamos a empezar creando la conexión VPN, para ello debemos hacer uso de una red virtual en Windows Azure, si aún no tienes una red virtual o no sabes a que me refiero, te recomiendo primero leer el siguiente artículo: Creación de una red virtual en Windows Azure

Nota: La configuración de las VPN se puede realizar durante la creación de la red virtual, pero en este caso dividí la tarea en dos partes.

Ingresamos al sitio de administración de Azure: http://manage.windowsazure.com/ 

Primero debemos editar la configuración de nuestra red virtual, para mi caso editaré la red virtual llamada network2

Ahora seleccionamos la opción Configurar del menú superior

Más abajo, encontramos la opción conectividad de punto a sitio (opción disponible por ahora en vista previa), marcamos la casilla de verificación Configurar la conectividad de punto a sitio inmediatamente se desplegará la opción para elegir el espacio de direcciones a utilizar para los equipos que se conecten a la VPN.

En este caso elegí el espacio 10.0.0.0 para asignar a los clientes que se conecten, si bien la conexión se hace por equipo, está permitido conectar hasta un máximo de 250 equipos individuales a través de la conexión Point-to-Site.

Una vez habilitada la conectividad de punto a sitio debemos agregar una subred de puerta de enlace, necesaria para establecer conectividad entre la red local y Windows Azure, simplemente debemos presionar el botón agregar subred de puerta de enlace.

Como se puede apreciar automáticamente se agregó la subred de puerta de enlace, hacemos clic en el botón Guardar de la parte inferior y esperamos a que la configuración finalice.

Una vez terminada la tarea nos pasamos a la opción Certificados del menú superior y veremos el siguiente mensaje.

Bueno, el mensaje es muy claro, debemos cargar un certificado, pero de dónde lo sacamos?, bien pues por ahora Windows Azure solo trabaja con certificados autofirmados, así que debemos recurrir a una utilidad llamada Makecert para generar el certificado, esta utilidad la podemos obtener de dos formas, una de ellas es si tenemos Visual Studio instalado, pues este la incorpora, o bien podemos instalar el SDK de Windows 8 el cual también la incluye.

Está bien, si no tienes Visual Studio instalado y tampoco tienes tiempo para descargar e instalar el SDK de Windows 8 puedes descargar la utilidad directamente a través del siguiente enlace:http://www.inventec.ch/chdh/notes/makecert_5_131_3790_0.zip

Ya con la herramienta descargada ejecutamos la siguiente instrucción para generar el certificado para el servidor:

makecert -sky exchange -r -n "CN=Azure-Root-Cert" -pe -a sha1 -len 2048 -ss My

Listo, ahora que hemos creado el certificado para el servidor, debemos crear uno para los equipos cliente que se van a conectar a través de la VPN a la red de Windows Azure.

makecert.exe -n "CN=Client-VPN-Cert" -pe -sky exchange -m 96 -ss My -in "Azure-Root-Cert" -is my -a sha1

Ahora que ya tenemos ambos certificados, tanto el del servidor como el del cliente, debemos exportarlos, veamos como.

Iniciamos la utilidad certmgr desde la misma línea de comandos.

Expandimos Personal - Certificados y veremos los dos certificados que creamos con la utilidad Makecert

Ahora debemos exportar cada uno de ellos, empecemos con el certificado root

Hacemos clic sobre el certificado en Todas las tareas seleccionamos Exportar

En el asistente seleccionamos No exportar la clave privada

Dejamos la opción por defecto para el formato del certificado

Por último elegimos la ruta donde vamos a guardar el certificado y el nombre que le daremos.

Bien, ahora vamos a exportar el certificado del cliente de la misma forma que hicimos con el de root, pero ahora sí vamos a exportar la clave privada como se muestra a continuación.

Mantenemos las opciones de formato por defecto

Establecemos una contraseña para proteger la clave privada

Por último elegimos el nombre y la ubicación para el certificado de cliente.

El certificado de cliente debe ser instalado en cada uno de los equipos que se utilizarán para conectarse a la VPN

Una vez terminada la instalación del certificado volvemos al sitio de administración de Windows Azure para crear la conexión de punto a sitio, volvemos a la opción de certificados de la red virtual y elegimos la opción Cargar un certificado raíz

Y hacemos clic para buscar el certificado raíz que creamos previamente, lo cargamos y esperamos hasta que aparezca con estado creado.

Ahora seleccionamos la opción Panel de la parte superior, podemos observar que en la gráfica de la red virtual aparece un mensaje indicando que no se creó la puerta de enlace, bien, pues lo único que debemos hacer es clic en el botón de la parte inferior que dice Crear puerta de enlace.

Esperamos unos cuantos minutos hasta que finalice el proceso de creación de la puerta de enlance, al final el gráfico tendrá un aspecto como el siguiente:

Como se puede apreciar, la puerta de enlace ha sido creada, y además nos muestra información de los Bytes de entrada y salida, así como la dirección IP que se utilizará.

También una vez creada la puerta, se generan los enlaces para descargar el paquete de conexión VPN para el cliente, descargamos según la arquitectura del equipo cliente.

Al finalizar la instalación del paquete, se creará una conexión SSTP para establecer la VPN con la red de Windows Azure

Al hacer clic en conectar se abrirá la utilidad Windows Azure Virtual Network y hacemos clic en el botón Conectar

Una vez finalizada la conexión haremos un ipconfig para comprobar que efectivamente hemos recibido una dirección IP del segmento que definimos.

Como podemos apreciar, ya tenemos conectividad entre el equipo local y la red de Windows Azure, por lo tanto podemos hacer uso de todos los servicios dispuestos en la nube de Windows Azure desde nuestro equipo local. Por último veamos el estado de la conexión VPN en el sitio de administración de Windows Azure.

Nótese que se armó la conexión entre nuestra red virtual y el equipo local, recordemos que podemos realizar conexión Point-to-Site en un máximo de 250 equipos.

Bueno, por ahora esto es todo, espero sea de utilidad y nos vemos en un próximo artículo sobre el apasionante mundo de la nube Microsoft. Hasta pronto!

Creación de una red virtual en Windows Azure

En esta oportunidad mostraré los pasos que se deben llevar a cabo en Windows Azure para crear una red virtual. Es importante aclarar que solo podemos crear redes con direcciones IPv4, Windows Azure no soporta direccionamiento IPv6, las redes que podemos crear deben estar en el espacio de redes privadas (10.x, 172.x, 192.x).

Una vez creada la red virtual, podemos crear máquinas virtuales y asignarlas al segmento de red que ya hemos definido, y todas las máquinas que vayamos agregando a la red tendrán comunicación entre sí. También es importante saber que existe la posibilidad de crear las redes virtuales que necesitemos, pero no es posible comunicar las máquinas entre dichas redes, es decir; solo podemos establecer comunicación con las máquinas que se encuentren dentro del mismo segmento, generando de este modo asilamiento entre ellas. 

A través de la creación de redes virtuales, podemos extender nuestro centro de datos local (on-premises) a la nube de Windows Azure, es decir; podemos conectar nuestro segmento de la red corporativa con la red virtual de Windows Azure que creemos, esto a través de una conexión VPN site to site.

Otra consideración importante acerca de las redes virtuales en Windows Azure, es que no podemos realizar traza de rutas (tracert) para diagnosticar la conectividad, así como tampoco es permitida la salida de paquetes ICMP, por lo cual no es posible hacer ping a direcciones IP fuera de nuestra red. También considero importante tocar en este momento el tema del direccionamiento de las máquinas virtuales, pues es importante saber que no debemos asignar direcciones IP estáticas a nuestros servidores, así como lo ven!!..Windows Azure utiliza su propio sistema de direccionamiento dinámico (DHCP) y no recomienda que asignemos direcciones IP estáticas a nuestras máquinas o perdemos la conectividad. Pero entonces, qué sucede con sistemas que requieren de una dirección IP estática, como por ejemplo un controlador de dominio, donde las "Best practices" indican que estos servidores deben tener una dirección IP estática.(actualización: ya es posible trabajar con IP estática, artículo aquí) Pues bien, resulta que Windows Azure, si bien asigna una dirección dinámica, esta no cambia durante el tiempo de vida de la máquina virtual, es decir; la dirección se conserva hasta que eliminemos o desasignemos la máquina, lo cual viene siendo muy parecido a tener una dirección IP estática.

Bien, creo que ya es suficiente de teoría, creo que con lo mencionado podemos tener una idea general de lo que se tratan las redes virtuales en Windows Azure, ahora vamos a crear una para ver lo sencillo que resulta.

Lo primero, ingresar al sitio de gestión de Windows Azure y en el panel de opciones seleccionar Redes

Luego, en la parte inferior izquierda de la pantalla hacemos clic en la opción Nuevo

En Servicios de Red elegimos Red Virtual y por último Creación Personalizada como se muestra a continuación.

Ahora debemos empezar a diligenciar los detalles de nuestra red virtual, le asignamos un nombre a nuestro gusto, en mi caso network2, ya que antes había creado una network1 ;-) el grupo de afinidad lo llame del mismo modo, recordemos que le grupo de afinidad hace referencia a la ubicación física de nuestra red dentro de los datacenters de Microsoft.

En el paso 2 del asistente encontramos las opciones para establecer un servidor DNS y para configurar la conectividad VPN con la red local, lo cual veremos en otro artículo, por ahora simplemente dejaremos estos datos sin diligenciar y continuaremos con el paso 3 del asistente.

En el tercero y último paso del asistente podemos elegir nuestro espacio de direcciones y crear las subredes, como se puede apreciar en la imagen a continuación, podemos elegir cualquiera de los espacios de direcciones IP privadas definidos en la RFC1918.

En este caso elegiré el espacio 192.168.0.0, y podemos elegir las direcciones a utilizar, donde la menor que podemos elegir es una /29 con capacidad para 8 hosts, en mi caso elegí crear una subred, la cual re nombré como Subred-1 con CIDR /24. Finalmente así quedó mi subred:

Y con esto ya quedó  creada nuestra red virtual.

Finalmente veamos la opción que nos permite asignar una máquina a nuestra red virtual durante la creación de una máquina virtual.

Una vez asignada la máquina a nuestra red virtual le será asignada mediante DHCP una dirección perteneciente al segmento que definimos.

Muchas gracias y hasta la próxima!

Windows Azure Identidad y Acceso

Amig@s, los invito a que me acompañen en el último ciclo de conocimiento del año, el cual inicia este martes 12 de Noviembre, el ciclo lo iniciará Guillermo Taylor, yo los estaré acompañando con una charla sobre Windows Azure Active Directory el día 19 de Noviembre. A continuación les dejo los datos del evento. Espero me acompañen.

Lugar: Microsoft Colombia (Cra 7a No. 71 - 21 Torre B Piso 15)

Fecha:  Todos los martes de Noviembre (12, 19, y 26)

Hora: 6:30 - 8:30 p.m.

Evento Active Directory desde Cero

Muchas gracias a todos los asistentes al ciclo de conocimiento de Active Directory, y como lo prometido es deuda, para los miembros de la comunidad ya se encuentran disponibles las diapositvas en el sitio ITPros-DC, si no eres miembro de la comunidad debes registrate para poder descargarlas. Un saludo para todos.

Les dejo algunas imágenes del evento! :-)

Ciclo de Conocimiento Active Directory - Microsoft Colombia