Evitar que los usuarios unan equipos al dominio

domingo, 22 de febrero de 2015


Aunque muchos no lo sepan, cualquier usuario autenticado en un dominio puede unir su propia máquina al dominio, sin necesidad de contar con privilegios administrativos para ello, de hecho no solamente puede unir su máquina sino otras nueve (9) más, es decir; cada usuario autenticado en un dominio puede unir hasta 10 máquinas de manera predeterminada. ¿Cómo evitamos este comportamiento? veamos a continuación:

  1. Existe una directiva que aplica solamente a los controladores de dominio, la cual indica que los usuarios autenticados pueden unir máquinas al dominio, y en la misma ayuda de la directiva indica que puede unir hasta 10.





Bastaría con eliminar el grupo Usuarios Autenticados de la anterior directiva para prevenir que los usuarios sin permisos explícitos unan máquinas al dominio,

2. Podemos también realizar este cambio a través de ADSI Edit modificando el atributo ms-DS-MachineAccountQuota


Una vez tengamos abierto el editor ADSI, nos conectamos al Default naming context



Expandimos hasta el nombre de nuestro dominio y hacemos clic derecho sobre el mismo y luego elegimos Propiedades del menú contextual



En la propiedades tendremos el editor de atributos, allí debemos buscar el atributo ms-DS-MachineAccountQuota



Como se puede apreciar su valor está en 10, basta con editar el atributo y cambiar su valor a 0 para que ningún usuario pueda ingresar equipos al dominio, para mi caso lo dejaré en 2 con el fin de probar con un usuario y agotar la cuota y observar el error que arroja.


El valor del anterior atributo también puede ser consultado desde PowerShell utilizando el siguiente comando:

Get-ADDomain | select -ExpandProperty DistinguishedName | Get-ADObject -Properties 'ms-DS-MachineAccountQuota' | select -ExpandProperty ms-DS-MachineAccountQuota



Con cualquiera de las dos opciones anteriores podemos prevenir que los usuarios no autorizados unan equipos al dominio, solo podrán hacerlo aquellos a quienes les hemos otorgado el privilegio de manera explícita.

Aparte de asegurarnos que ningún usuario pueda ingresar máquinas al dominio, lo ideal y recomendado es siempre crear primero las cuentas de equipo en Active Directory y luego si realizar la unión al dominio, cuando creamos las cuentas previamente tenemos la posibilidad de indicar que usuario o grupo puede realizar la vinculación al dominio. Veamos en un mundo ideal como se logra esto.

Primero nos ubicamos en la OU donde deseamos crear la cuenta de equipo, clic derecho Nuevo - Equipo


Ponemos un nombre al equipo, en este caso DESKTOP01, y muy importante, haciendo clic en el botón Change podemos elegir el grupo o usuario al cual se le otorgará el permisos para unir la máquina al dominio


Ahora, nos vamos al equipo cliente y unimos la máquina al dominio.



Vemos como de manera satisfactoria hemos unido el equipo al dominio, ahora vamos a seguir uniendo máquinas con este mismo usuario, pero en esta ocasión no lo haremos creando la cuenta antes, como hicimos en el paso anterior, sino que esta vez la uniremos directamente desde el equipo cliente, tal como muchos estamos acostumbrados a hacerlo, recordemos que establecimos el límite a 2, veamos qué ocurre.


Se logró unir de manera satisfactoria una segunda máquina llamada DESKTOP02 utilizando el mismo usuario. Vamos por la tercera! ¿crees qué la dejara unir, recordemos el límite de 2?


Efectivamente dejó unir la máquina DESKTOP03, ¿permitirá más? veamos:


Y hasta aquí nos dejó llegar, como se puede observar en el mensaje de error, se ha superado el límite de cuentas de equipo que se pueden crear en este dominio.

En resumen nos dejó agregar 3 máquinas al dominio, ya que la primera no cuenta, porqué no cuenta? porque creamos la cuenta previamente, en este caso el objeto no es propiedad del usuario que une la máquina al dominio, en su lugar si agregamos la máquina al dominio sin antes crear la cuenta de equipo, el objeto queda como propiedad del usuario que lo une al dominio, y allí si aplica el límite de máquinas que puede unir, que ya mencionamos que por defecto es 10, en mi caso lo establecí a 2, y como podemos ver, efectivamente al intentar unir una tercera máquina que no fue creada previamente, el sistema arroja el mensaje de error que podemos apreciar en la imagen anterior.

Ahora, veamos cómo Active Directory sabe cuáles máquinas unió determinado usuario al dominio:

La cantidad de equipos que une un usuario al dominio se determina contando las máquinas que tienen el atributo ms-DS-CreatorSID igual al SID del usuario.

Primero, vamos a reaizar una consulta que indique todas aquellas máquinas que tienen algún valor en el atributo ms-DS-CreatorSID, 

Get-ADComputer -Filter {ms-DS-CreatorSID -like '*'}


Como se puede observar nos trajo dos cuentas de equipo, fueron precisamente las dos máquinas que se unieron al dominio ya que tenemos permitido unir hasta dos máquinas por usuario, cuando intentamos unir una tercera no fue permitido, la primera no aparece aquí ya que se trata de una cuenta previamente creada, la cual no tiene ningún valor en el atributo ms-DS-CreatorSID

En este caso, en mi dominio de prueba solamente se han unido estas dos máquinas al dominio, en un entorno de dominio en producción el comando anterior arrojará un listado de todas las máquinas que se hayan unido sin tener una cuenta previamente creada. Pero que tal si deseamos conocer no todas las máquinas, sino las máquinas unidas por un determinado usuario. Para ello podemos hacer lo siguiente:

1. Obtener el SID del usuario (recuerda que se compara el SID del usuario frente al atributo ms-DS-CreatorSID, deben ser iguales).

$sid = (Get-ADUser cherrada).SID

2. Traemos todos los equipos pero filtrando solo aquellos cuyo atributo ms-DS-CreatorSID sea igual a la variable $sid que contiene el SID del usuario.

Get-ADComputer -Filter {ms-DS-CreatorSID -eq $sid}


El resultado: Todas las máquinas unidas al dominio por el usuario cherrada

Cambiar contenedor predeterminado al unir equipos a un dominio


Una de las recomendaciones a la hora de trabajar con Active Directory, es cambiar la ubicación por defecto para los equipos que se unen al dominio. De manera predeterminada, todos los equipos una vez ingresados al dominio quedan ubicados en el contenedor "Computers", y muchos administradores dejan que los objetos de equipo permanezcan allí por mucho tiempo, y cuando menos se piensa el contenedor está lleno de bastantes cuentas de equipo donde en muchas ocasiones no se sabe si son equipos de escritorio, portátiles, servidores, etc.

Una razón importante para cambiar esta ubicación por defecto, no es solamente dar orden y facilitarnos la administración, sino para poder aplicar directivas destinadas a objetos de equipo.

Bien, pues ahora veremos como cambiar el contenedor por defecto, pero primero vamos a verificar si la ubicación actual si es Computers, no sabemos si depronto alguien en el pasado ya lo cambió :-)

Primero abrimos el módulo de Active Directory para Windows PowerShell. En caso de que ya tengas abierta la consola de PowerShell, basta con importar el módulo:



Luego, escribimos lo siguiente: (Get-ADDomain).ComputersContainer y nos arrojará la ubicación actual para los equipos que se unan al dominio.



Como podemos ver, efectivamente se encuentra en la ubicación predeterminada, así que ahora vamos a cambiar esa ruta hacia una OU que hemos creado llamada Equipos Nuevos.

Abrimos una consola de comandos elevada o desde la misma sesión de PowerShell que ya tenemos y ejecutamos lo siguiente:

redircmp "OU=Equipos Nuevos,DC=itpros-dc,DC=local"



Cambia el parámetro del comando redircmp con el DN de la OU que vayas a utilizar en tu caso.

Ahora para comprobar, volvamos a ejecutar la instrucción para ver la ubicación actual:



Como podemos apreciar, la ubicación por defecto ya no es el contenedor Computers sino la OU que hemos destinado para nuestros equipos nuevos.

Cloud OS - Identidad y Acceso

miércoles, 18 de febrero de 2015


El día de ayer se llevó a cabo la tercera sesión del ciclo de conocimiento Cloud OS, en esta ocasión el turno fue para mi. En el evento se trataron temas como los siguientes:
  • Qué es Azure Active Directory (AAD)
  • Diferencias entre AD On-premises y Azure AD
  • Herramientas de sincronización
  • El nuevo rol del administrador de AD en Azure
En la demo se enseñó el funcionamiento de la herramienta AAD Connect en vista previa, se realizó la sincronización de usuarios desde Active Directory local hacia Azure Active Directory, adicionalmente se asignó licencia de Office 365 a los usuarios sincronizados y se activó la característica de autenticación multifactor.

Algunas fotos del evento:




A continuación la presentación:


Primera sesión Grupos de Estudio 2015

sábado, 7 de febrero de 2015


El día hoy tuvimos nuestra primera sesión de Grupos de Estudio de este año, en esta ocasión hemos abierto 5 grupos:

  • SQL Server Fundamentals
  • Exchange Server Fundamentals
  • Active Directory Fundamentals ***el mío :-)***
  • System Center Fundamentals
  • Instalación y Configuración de Windows Server 2012 [70-410]
  • Cisco Intemedio

A partir de hoy estaremos aprendiendo de Active Directory todos los sábados hasta el 28 de Marzo, en horario de 2 a 6 de la tarde. Hoy hemos aprendido sobre:

Conceptos de Active Directory (Base de datos, dominios, bosques, sitios, objetos).
Funcionamiento interno de los servicios de directorio (SID, Security Token)
Entendiendo el inicio de sesión.
Maestros de operaciones.

Quedaron pendientes algunos temas para la segunda sesión tales como Global Catalog, Particiones del directorio y algo más.

Algunas fotos de mi grupo, todos muy atentos y con muchas ganas de aprender.




Y por supuesto...no faltó la celebración de esta primera sesión al final de la tarde.


Muchas gracias a todos los asistentes y nos vemos en la próxima sesión! a continuación les dejo la presentación:

Ciclo de conocimiento Cloud OS

domingo, 1 de febrero de 2015

Un saludo para todos, iniciamos los eventos del año 2015, empezamos el próximo 3 de Febrero, y en esta ocasión trataremos el tema de Cloud OS, yo estaré el último martes de Febrero, hablando específicamente sobre Azure y temas de identidad y acceso. No falten!


 

Lo más visto

Comunidad

Comunidad
Comunidad Técnica

Visitas