En este post vamos a ver el funcionamiento y las configuraciones de Microsoft Entra Domain Services, que una vez instaladas las RSAT, es básicamente igual que un Active Directory clásico que hemos configurado y administrador a lo largo de los años, sólo hay que tener en cuenta algunas particularidades.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

• Si accedemos a la consola de Usuarios y equipos de Active Directory, está será la organización que nos vamos a encontrar por defecto, luego podemos crear nuevas Unidades Organizativas (OU) y organizar el AD según nos convenga en nuestra infraestructura:

• Vamos a explicar las más importantes y las particularidades de cada una, para empezar, tenemos la Unidad Organizativa (OU), AADDC Computers, en esta OU se van a ir añadiendo todas las máquinas que unamos a nuestro dominio, luego crearemos otras OUs y podemos mover estas máquinas a las nuevas OUs para tener más organizado nuestro Active Directory:

• La OU AADDC Users, va a contener todos los usuarios y grupos que se sincronizan desde Microsoft Entra ID, aquí no debemos mover los usuarios ni grupos de OU, ni editarlos, ni cambiar passwords…, nada, no los debemos tocar, si queremos editarlos lo debemos hacer desde Microsoft Entra ID, y los cambios se sincronizaran con Microsoft Entra Domain Services, lo que si podemos hacer es crear usuarios y grupos locales propios del dominio de AD en otras OU, y usar estos usuarios por ejemplo para algún tema de servicios:

• La OU AADDSDomainAdmin, es un contenedor protegido y reservado para las operaciones del servicio gestionado, microsoft delega ciertos privilegios allí para que la infraestructura funcione de forma transparente sin otorgarnos los permisos de «Enterprise Admin» o «Domain Admin» tradicionales del Active Directory clásico, NO debemos tocar absolutamente nada de lo que vemos en esta OU, ni cambiarle la contraseña al usuario dcaasadmin, ni modificar el grupo AADDS Service Administrators Group, el usuario dcaasadmin, Microsoft lo utiliza de forma automatizada para realizar tareas de mantenimiento, aplicar parches de seguridad del sistema operativo a los controladores de dominio, monitorizar la salud del directorio y asegurar la replicación subyacente, si le cambiamos la contraseña o intentamos deshabilitarlo, bloquearemos los scripts de automatización de Azure y el servicio pasará automáticamente a estado «Alert» o «Unhealthy» en nuestro portal y podríamos llegar a romper la infraestructura desplegada:

• En la OU Domain Controllers, al igual que en un Active Directory clásico se van a ubicar nuestros controladores de dominio, en este caso los dos DC PaaS que se han desplegado con el servicio de Microsoft Entra Domain Services:

• Estas son las OUs nuevas que nos hemos creado:

• Hemos movido esta máquina a una de las OU nuevas que nos hemos creado:

• Al igual que el Active Directory clásico, esta es la consola de Administración de directivas de grupo y estas son las GPO que trae por defecto, AADDC Computers GPO, AADC Users GPO, Default Domain Controllers Policy y Default Domain Policy, NO EDITAR NI TOCAR bajo ningún concepto, si queremos aplicar alguna GPO, creamos una nueva y la vinculamos sobre la OU que nos interese, también podemos trabajarlas aplicando filtros de seguridad a grupos y usuarios, como hicimos en este post, como podemos ver la replicación entre los controladores de dominio es correcta:

• La GPO AADDC Computers GPO vinculada sobre la OU AADDC Computers tiene esta configuración para que los miembros el grupo AAD DC Administrators sean administradores locales de las máquinas de nuestro dominio, esta GPO tiene problemas con los equipos que están en idioma español o cualquier idioma diferente al Inglés, ya que el grupo administrators no existe, en español el grupo es administradores, por lo que la GPO se aplica pero los usuarios de grupo AAD DC Administrators una vez hagan logon en las máquinas no van a ser administradores locales:

• Para solucionarlo, hemos creado esta GPO:
• Abrimos la consola de Administración de Directivas de Grupo, clic derecho sobre Objetos de directiva de grupo y seleccionamos Nuevo, le damos el nombre LocalAdmin, clic derecho sobre la nueva GPO y damos a Editar, no dirigimos a la siguiente ruta:
• Configuración del equipo > Preferencias > Configuración de Panel de control -> Usuarios y grupos locales, clic derecho en el espacio en blanco > Nuevo > Grupo local.
• Configuración clave dentro del grupo:
• Acción: Actualizar
• Nombre de grupo: Aquí está el secreto, no lo escribas a mano, hacemos clic en el desplegable de la derecha y buscamos el grupo integrado Administradores (integrados).
• Nota técnica, al seleccionarlo desde el desplegable, la GPO no guarda el texto «Administradores», sino que guarda el SID universal S-1-5-32-544, de esta forma, si el equipo está en español, francés o inglés, la GPO afectará al grupo correcto de administración local.
• Miembros, clic en Agregar y buscamos el grupo del dominio: RAGASYS\AAD DC Administrators.

• También podemos vincular esta GPO a las OUs personalizadas que hemos creado:

• Para hacer una prueba, hemos creado esta GPO, con este filtrado de seguridad y la hemos vinculado sobre la OU AADDC Users:

• Si volvemos a iniciar sesión con un usuario perteneciente a este grupo, se nos abre la calculadora:

• Nuestro DNS podemos administrarlo como lo hemos hecho siempre en Active Directory clásico:

• Hemos creado estor registros CNAME para nuestros Controladores de dominio:

• Ya podemos acceder a la consola DNS por nombre en lugar de por IP:

• Nos podemos crear zonas de búsqueda inversa al igual que hacemos en Active Directory clásico, y como vemos se han replicado correctamente del dc01 al dc02:

• En el DNS no se debe de tocar nada más, ni reenviadores ni ningún tema de configuración.
• En la consola de Sitios y servicios de Active Directory no debemos de tocar nada, ya que como es un servicio PaaS podemos averiar la replicación entre los controladores de dominio, comentan que se pueden crear subredes, pero según he estado viendo y trabajando prefiero dejarlo tal cuál viene, NO TOCAR:

Saludos y espero que os sea de ayuda

La entrada Funcionamiento y Configuraciones de Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como instalar las herramientas de administración remota RSAT en una máquina virtual unida a nuestro dominio, y así poder administrar el dominio de Microsoft Entra Domain Services al igual que hemos hecho siempre con nuestros controladores de dominio on-premise.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

• Esta es la configuración de red de la máquina dónde vamos a instalar las herramientas de administración remota RSAT, como podemos ver los DNS son las IPs de los controladores de dominio PaaS que se desplegamos con el servicio de Microsoft Entra Domain Services:

• Verificamos las comunicaciones con nuestros dos controladores de dominio PaaS:

• Unimos la máquina al dominio con el usuario al que elegimos como administrador del dominio:

• Una vez unido al dominio, reiniciamos y podemos iniciar sesión con este usuario en la máquina:

• Ejecutamos este comando para instalar las herramientas de administración remota RSAT que vamos a necesitar para administrar nuestro domino de Microsoft Entra Domain Services, Install-WindowsFeature -Name RSAT-AD-Tools, RSAT-DNS-Server, GPMC -IncludeAllSubFeature
• Ejecutando este comando tendremos las Consolas que tiene un Controlador de Dominio:
• Usuarios y equipos de Active Directory (ADUC)
• Administración de Directivas de Grupo (GPMC)
• Administrador de DNS
• Centro de Administración de Active Directory (ADAC)
• Sitios y servicios de Active Directory
• Dominios y confianzas de Active Directory
• Editor ADSI (ADSI Edit)

• Si nos abrimos el Administrador del Servidor > Herramientas, podemos ver todas las consolas que hemos instalado:

Saludos y espero que os resulte de ayuda

La entrada Instalación herramientas de administración remota RSAT en máquina virtual para Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo desplegar y configurar Microsoft Entra Domain Services (MEDS), veremos el despliegue de este servicio y las configuraciones iniciales para empezar a funcionar.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

• Lo primero que vamos a realizar será crearnos nuestro dominio administrado, para ello, desde Azure portal accedemos a Microsoft Entra Domain Services > + Crear:

• Sobre Datos básicos le indicamos la Suscripción, el Grupo de recursos, le indicamos el Nombre de dominio DNS, la Región y el SKU, en SKU seleccionaremos Estándar, para implementaciones en producción seleccionar Enterprise o Prémium, clic en Siguiente:

• Sobre Redes seleccionamos la Red virtual que tenemos desplegada en nuestra infraestructura con la subred que configuramos para este servicio, en este caso 192.168.130.0/24, clic en Siguiente:

• Sobre Administración seleccionamos Administrar pertenencia al grupo e incluiremos los miembros que van a ser los Administradores de Microsoft Entra Domain Services, los usuarios que sean miembros de este grupo serán los administradores de nuestro dominio, estos usuarios que se incluyan aquí no van a ser administradores de dominio como en un Active Directory clásico, en este servicio administrado Microsoft no nos proporciona un administrador del dominio total, nos ofrece este grupo y el servicio PaaS de Microsoft Entra Domain Services una vez desplegado, le asigna automáticamente los permisos necesarios a este grupo sobre el dominio, vamos lo que hace básicamente es delegar los permisos necesarios en el Active Directory para poder trabajar y configurar lo que necesitemos en nuestra infraestructura, clic en Siguiente:

• Sobre Sincronización seleccionamos el Tipo de sincronización, en este caso Todo, clic en Siguiente:

• Sobre Configuración de seguridad lo dejamos todo por defecto, clic en Siguiente:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, clic en Siguiente:

• Sobre Revisar y crear nos muestra un resumen de todo lo configurado, clic en Crear:

• Aceptamos:

• Podemos ver que la implementación se ha completado correctamente:

• Si accedemos al grupo de recursos que nos creamos anteriormente, podemos ver todos los recursos que se han creado:

• Si accedemos al recurso Microsoft Entra Domain Services (ragasys.net), sobre información general, podemos ver, que el estado del dominio está En ejecución:

• Como podemos ver se muestra una advertencia que debemos corregir, pulsamos sobre la flecha:

• Ejecutamos el diagnóstico:

• El diagnóstico nos indica que debemos de establecer la configuración del servidor DNS de direcciones IP de servicio de dominios administrados 192.168.130.4,192.168.130.5 para las redes virtuales West Europe/opnsense-vnet/SubnetMEDS-192_168_130_0-24, estas dos direcciones IP son los dos controladores de dominio de nuestra infraestructura PaaS, clic a Corregir:

• De nuevo nos indica los problemas detectados (Registros de DNS) y como solucionarlo, clic sobre Corregir:

• Como vemos, los diagnósticos se han completado correctamente:

• Si accedemos a Redes Virtuales > opnsense-vnet > Servidores DNS, podemos ver que se han agregado los dos controladores de dominio como servidores DNS de nuestra red virtual:

• Si accedemos a Redes Virtuales > opnsense-vnet > Dispositivos conectados, podemos ver los Dispositivos conectados a nuestra vnet, en este caso está conectado nuestro firewall opnsense y los dos controladores de dominio PaaS que hemos desplegado:

• Ahora en el grupo de seguridad de red que se nos ha creado tras el despliegue (aadds-nsg), vemos las reglas que incluye por defecto, tanto las de entrada como las de salida:

• Para que todas las comunicaciones pasen por nuestro firewall OPNsense desplegado en Azure, debemos de crear estas dos reglas en el grupo de seguridad de red, una de entrada y otra de salida:

• Para terminar y que nuestros usuarios de Microsoft Entra ID puedan iniciar sesión en el dominio de Microsoft Entra Domain Services, deben de hacer un cambio de contraseña para habilitar el hash de contraseña en Microsoft Entra Domain Services:

• Nosotros hemos realizado el cambio de contraseña al usuario que incluimos en el grupo AAD DC Administrators:

• En el próximo post instalaremos las RSAT en una máquina unida a este dominio y veremos que los accesos a estos controladores de dominio es exactamente igual que los que nos montamos en una infraestructura on-premise.

Saludos y espero que os sea de ayuda

La entrada Despliegue y configuración de Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo preparar los recursos de nuestra infraestructura, para el despliegue, la instalación y configuración de Microsoft Entra Domain Services (MEDS), veremos la red virtual a crear con la subred, las tablas de rutas que tenemos que configurar, creación de reglas en Fortigate on-premise y OPNsense Azure y grupo de administración de Microsoft Entra Domain Services para administrar nuestro dominio.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

• Para empezar, vamos a ver la red virtual que tenemos creada en Azure y la subred que vamos a utilizar para desplegar este servicio PaaS de Microsoft Entra Domain Services.
• Esta es la red virtual que vamos a utilizar con su espacio de direcciones configurado:

• Esta es la subred que vamos a utilizar para este servicio:

• Ahora, nos creamos esta tabla de rutas, llamada rt_meds_fw para enseñarle a los futuros controladores de dominio cómo responder a los servidores que tengamos en Azure y a los que tengamos en nuestra infraestructura on-premise, a través del firewall OPNsense que tenemos montado en Azure, importante no incluir NUNCA en esta tabla de ruta el rango de la subred donde van a estar los controladores de dominio de Microsoft Entra Domain Services 192.168.130.0/24:

• Modificamos la tabla de rutas MasterRoutes_rgs que ya la teníamos creada, para obligar a los servidores que tenemos en Azure a pasar por el firewall cuando busquen el Active Directory:

• Una vez creadas las tablas de rutas, tenemos que configurar las reglas o políticas en nuestros firewalls, tal y como vemos en topología de nuestra infraestructura, podemos ver que tenemos dos firewalls, un Fortigate para a parte on-premise y un OPNsense para la parte de Azure, entre ellos, tenemos configurada una VPN site to site, para el acceso entre los recursos de ambos entornos.
• Primero vamos a mostrar la regla que tenemos creada en nuestro firewall on-premise Fortigate, con esta regla, le estamos diciendo que todos nuestros equipos ubicados en la red 192.168.14.0/24 puedan acceder a los servicios de Microsoft Entra Domain Services, ubicados en los dos controladores de dominio que se desplegaran una vez que tengamos el servicio desplegado en Azure, en el grupo domaincontrollers_meds hemos ubicado los dos controladores de dominio, que tendrán las primeras IPs disponibles que tenga Azure para esa subred, normalmente las terminadas en .4 y .5 si usamos una máscara /24:

• Ahora vamos a mostrar las reglas que tenemos creadas en nuestro firewall de Azure OPNsense, con estas reglas, le estamos diciendo que todos nuestros equipos ubicados en las redes 192.168.128.0/24 de Azure y 192.168.14.0/24 om-premise, puedan acceder a los servicios de Microsoft Entra Domain Services, ubicados en los dos controladores de dominio que se desplegaran una vez que tengamos el servicio desplegado en Azure, en el grupo domaincontrollers_meds hemos ubicado los dos controladores de dominio, que tendrán las primeras IPs disponibles que tenga Azure para esa subred, normalmente las terminadas en .4 y .5 si usamos una máscara /24:

• Habilitamos también el ICMP para la pruebas de conexión:

• Por último, vamos a ver el grupo en Microsoft Entra ID al que tenemos que agregar los miembros que queramos que administren el dominio de Microsoft Entra Domain Services, el grupo está creado por defecto en Microsoft Entra ID, y se llama AAD DC Administrators:

Saludos y espero que os resulte de ayuda

La entrada Preparación de recursos para infraestructura de Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar, instalar y configurar Microsoft Entra Domain Services (MEDS), Microsoft Entra Domain Services (anteriormente Azure Active Directory Domain Services), que forma parte de Microsoft Entra, nos va a permitir usar servicios de dominio administrados, como la unión a un dominio de Windows, directiva de grupo, LDAP y la autenticación Kerberos, sin tener que implementar, administrar o aplicar revisiones a controladores de dominio.

Con Microsoft Entra Domain Services, vamos a tener exactamente lo mismo que tendríamos con controladores de dominios on-premise de manera tradicional con el servicio o función de Active Directory Domain Services, como el directorio LDAP, DNS, GPOs, Sitios y servicios, etc…, con algunas particularidades que iremos viendo a lo largo de estos posts.

Con Microsoft Entra Domain Services tendremos:

• PaaS alojado en la nube de Azure
• Autenticación LDAP, Kerberos y NTLM
• Usuarios, Grupos, Unidades Organizativas
• GPOs
• Integración con Microsoft Entra ID
• Sin cuenta de administrador de dominio

Los servicios de dominio de Microsoft Entra Domain Services proporcionan servicios de dominio administrados como unión de dominio, directiva de grupo, LDAP, autenticación Kerberos / NTLM que es totalmente compatible con Windows Server Active Directory. Nosotros consumiremos estos servicios de dominio, sin implementar, administrar ni aplicar parches a los controladores de dominio. Microsoft Entra Domain Services se integra con el inquilino de Azure AD existente. Esta integración permite a los usuarios iniciar sesión con sus credenciales corporativas, y podremos usar grupos y cuentas de usuario existentes para proteger el acceso a los recursos.

Para entendernos, podemos decir, que esta es la parte de PaaS (Plataforma como Servicio) de nuestros controladores de dominio en Windows Server.

Para implementar Microsoft Entra Domain Services necesitamos:

• Una suscripción de Azure activa.
• Un inquilino de Microsoft Entra ID asociado con su suscripción, ya sea sincronizado con un directorio local o un directorio solo en la nube.
• Privilegios de administrador global en el inquilino de Microsoft Entra ID para habilitar Microsoft Entra Domain Services.
• Privilegios de colaborador en la suscripción de Azure para crear los recursos necesarios de Microsoft Entra Domain Services.
• Una red virtual con servidores DNS que pueden consultar la infraestructura necesaria, como el almacenamiento. Los servidores DNS que no pueden realizar consultas generales de Internet pueden impedir la capacidad de crear un dominio administrado.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

Este post lo vamos a dividir en:

• Preparación de recursos para infraestructura de Microsoft Entra Domain Services
• Despliegue y configuración de Microsoft Entra Domain Services
• Instalación herramientas de administración remota RSAT en máquina virtual para Microsoft Entra Domain Services
• Funcionamiento y configuraciones de Microsoft Entra Domain Services

Saludos y espero que os sea de ayuda

La entrada Despliegue, Instalación y Configuración de Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post veremos cómo unir nuestro servidor Proxmox VE 9.0 a un dominio de Active Directory.

• En la consola de Usuarios y equipos de Active Directory, hemos creado el objeto equipo para nuestro servidor Proxmox, esto lo hacemos para cuando lo agreguemos al dominio:

• Para unir nuestro nodo de proxmox a un dominio de Active Directory, nos abrimos una consola, y ejecutamos los comandos para actualizar los paquetes, apt update y apt dist-upgrade:

• Instalamos adcli, packagekit y samba-common-bin realmd, para ello, ejecutamos apt install adcli packagekit samba-common-bin y apt install realmd:

• Ahora con este comando probaremos la conexión con nuestros controladores de dominio, realm -v discover ragasys.net, podemos ver que la conexión es correcta y que requiere la instalación de una serie de paquetes, estos paquetes se instalarán siguiendo las instrucciones del siguiente comando, instalarlos antes provocarían errores en las configuraciones:

• Ahora con este comando uniremos nuestro servidor de Proxmox al dominio de AD, realm -v join ragasys.net -U kyrios, aquí debéis poner vuestro dominio y un usuario con permisos para unir la máquina al dominio, nos pedirá credenciales, vemos que se instala toda la paquetería necesaria, y como ya habíamos creado el objeto equipo termina de configurar la cuenta de equipo en la Unidad Organizativa dónde lo hemos ubicado:

• Aquí vemos, que se ha agregado correctamente a nuestro dominio:

• Para verificar que todo está correcto, introducimos este comando id kyrios@ragasys.net y vemos que nos muestra el UID y el GID desde nuestros controladores de dominio:

Saludos y espero que os resulte de ayuda

La entrada Unión a dominio Active Directory en Proxmox VE 9.0 se publicó primero en RAGASYS SISTEMAS.

En este post veremos cómo conectar nuestro servidor Proxmox VE 9.0 a un dominio de Active Directory, una vez conectado al dominio de Active Directory, podremos usar los usuarios y grupos del dominio para asignar roles y permisos.

• Si accedemos a proxmoxlab11 > Sistema > DNS, debemos de tener configurados los DNS de nuestros controladores de dominio:

• Sobre proxmoxlab11 > Sistema > Hosts, configuramos el archivo de hosts con el FQDN y el nombre de host de nuestro servidor Proxmox:

• En nuestro DNS, creamos el registro tipo A para el servidor de Proxmox:

• Una vez realizado todo esto, accedemos a Centro de datos > Permisos > Dominios > Agregar > Servidor de directorio activo:

• Sobre General, completamos las configuraciones de nuestro dominio, introduciendo el dominio y los servidores con el rol de domain controller:

• Sobre Sincronizar opciones, introducimos el distinguisedName y las credenciales de este usuario de servicio del Active Directory, que solo tiene permisos de lectura, le indicamos que sincronice Usuarios y Grupos, Agregar:

• Como podemos ver, ya lo tenemos agregado, damos a Sincronizar para poder ver los Usuario y Grupos del Active Directory:

• Aquí vemos que se ha sincronizado correctamente:

• Ya vemos los usuarios y grupos de nuestro Active Directory desde Proxmox:

• Ahora ya podemos asignar roles y permisos a nuestros usuarios y grupos del Active Directory, para ello, accedemos a Centro de datos > Permisos > Agregar > Permisos de grupo, mostraremos el ejemplo, para aplicar permisos a un grupo:

• Le indicamos la Ruta, Grupo, el Rol y que propague permisos, Agregar:

• Y aquí tenemos el permiso o rol agregado al grupo del Active Directory:

• Para verificar que funciona, accedemos al sistema con un usuario del grupo del Active Directory que hemos configurado en los roles:

• Y aquí vemos, que ya estamos conectados con el usuario del Active Directory:

Saludos y espero que os sea de ayuda

La entrada Conexión a dominio Active Directory en Proxmox VE 9.0 se publicó primero en RAGASYS SISTEMAS.

• En este post vamos a ver como auditar los accesos a los a los objetos en nuestros equipos unidos a un dominio de Active Directory.
• Lo primero que debemos hacer es crearnos una GPO para habilitar la auditoría de objetos en nuestro Active Directory, para ello nos abrimos la consola de Administración de directivas de grupo y sobre Objetos de directivas de grupo le indicamos que queremos crearnos una nueva GPO:

• Le damos un nombre a la GPO y la editamos:

• Accedemos a Configuración del equipo > Dircetivas > Configuración de Windows > Configuración de seguridad > Directivas locales > Directiva de auditoría y configuramos-habilitamos la directiva Auditar el acceso a objetos:

• Ahora, esta configuración es opcional, pero muy recomendable, vamos a habilitar la auditoría avanzada, para ello, accedemos a Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Configuración de directiva avanzada de auditoría > Directiva de auditoría detallada > Acceso a objetos y configuramos-habilitamos las directivas Auditar almacenamiento extraíble y Auditar sistema de archivos:

• Una vez editada, aquí tenemos la configuración para habilitar la auditoría a objetos en nuestros equipos del AD:

• Aunque la GPO activa la auditoría, nosotros necesitamos configurar en cada equipo o mediante script qué carpetas/archivos serán auditados, vamos a ver un ejemplo:
• Para hacerlo de forma manual en una carpeta de cualquiera de nuestros equipos del dominio, debemos dar clic derecho sobre la carpeta > Propiedades > Pestaña Seguridad > Opciones avanzadas > Auditoría y agregamos:
• Usuario: Todos
• Tipo: Todo
• Se aplica a: Esta carpeta, subcarpetas y archivos
• Permisos avanzados: Crear archivos/escribir datos, Crear carpetas/anexar datos, Eliminar subcarpetas y archivos, Eliminar.

• Esto puede automatizarse mediante scripts de PowerShell, hemos creado este script, llamado auditoriausuarios.ps1, que lo podemos descargar desde este enlace, dónde vamos a auditar las carpetas del escritorio, documentos y descargas de todos los usuarios:

• Nos creamos este script en .bat, para cuando configuremos la GPO, invoquemos desde este script, al script de PowerShell:

• Ahora accedemos a cualquiera de nuestros controladores de dominio y copiamos estos dos scripts en esta ruta:

• En la consola de Administración de directivas de grupo, volvemos a editar la GPO que creamos y configuramos para la auditoria de objetos:

• Accedemos a Configuración del equipo > Directivas > Configuración de Windows > Scripts (Inicio o apagado) > Inicio > Scripts > Agregar > Examinar y añadimos el script .bat, Aceptar:

• Y así nos quedaría la GPO, completamente configurada:

• Ahora esta GPO, la vamos a vincular sobre la OU Equipos, para que empiece a auditar el acceso a los objetos:

• Como podemos ver, aquí la tenemos vinculada:

• Sobre uno de nuestros equipos del dominio ejecutamos un gpupdate /force para aplicar las nuevas directivas:

• Una vez aplicada la GPO, vamos que en las carpetas han cambiado sus permisos de auditoría:

• Con todo esto ya tenemos configurado las auditorías de los acceso a objetos en los equipos de nuestro Active Directory.
• Los registros de auditoría quedan todos guardados en el Visor de eventos de los equipos de los usuarios, en los Registros de Windows > Seguridad:

• Ahora vamos a crear y eliminar algunos ficheros de uno de nuestros equipos y veremos en el visor de eventos que usuario a creado y eliminado estos ficheros.
• Creamos estos dos ficheros:

• Eliminamos estos dos ficheros:

• Con el ID de evento 4663 vemos como se crean los ficheros:

• Y con el ID de evento 4659 vemos como se eliminan los ficheros:

Saludos y espero que os resulte de ayuda

La entrada Auditoría de acceso a objetos en equipos del Active Directory se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como migrar controladores de dominio con Windows Server 2022 a Windows Server 2025.

En este laboratorio, tenemos dos controladores de dominio con Windows Server 2022, y los vamos a migrar a Windows Server 2025.

• Como podemos ver, tenemos dos controladores de dominio en nuestra infraestructura con el sistema operativo MS Windows Server 2022 Standard:

• Los roles o funciones que tienen estos servidores son los siguientes, “Servicios de dominio de Active Directory y DNS”:

• Ahora debemos desplegar dos nuevos servidores con el sistema operativo MS Windows Server 2025 Standard, los actualizamos y los configuramos como un controlador de dominio adicional:

• Empezamos la configuración de nuestros controladores de dominio adicionales asignándole un nombre y una dirección IP estática, como DNS primario le asignamos la dirección IP de uno de los controladores de dominio y como DNS secundario la dirección IP del otro controlador de dominio, más tarde, le configuraremos su propia dirección IP como DNS:

• Ahora agregamos estos equipos como un miembro más del dominio:

• Le proporcionamos las credenciales del Administrador del dominio y reiniciamos el equipo:

• Como podemos ver se ha agregado correctamente, reiniciamos el servidor:

• Para el otro equipo hacemos las mismas operaciones.
• Ahora nos vamos a la consola de Usuarios y equipos de Active Directory en el controlador de dominio principal y cómo podemos ver, estos equipos ya pertenecen al dominio ragasys.local:

• Ahora iniciamos sesión en DCRGS03 (Servidor que hemos terminado de unir al dominio) como Administrador del dominio:

• En el Administrador del servidor agregamos roles y características:

• Se nos abre el asistente típico para desplegar los roles y características, hacemos clic en siguiente:

• Sobre Tipo de instalación, elegimos la opción, Instalación basada en características o roles:

• Seleccionamos nuestro servidor dcrgs03:

• Sobre Roles de servidor, marcamos la opción Servicios de dominio de Active Directory:

• Agregamos las características:

• Clic en siguiente:

• Todas las características que requiere nuestro controlador de dominio de Active Directory se seleccionan por defecto por lo que hacemos clic en siguiente:

• Información sobre Active Directory :

• Sobre Confirmación, iniciamos el despliegue del rol Servicios de dominio de Active Directory, marcamos que reinicie automáticamente en caso necesario y clic sobre Instalar:

• Comienza el despliegue de los Servicios de dominio de Active Directory:

• Una vez finalizada la instalación cerramos el asistente:

• Sobre el Administrador del servidor promovemos este servidor a controlador de dominio:

• Sobre Configuración de implementación, marcamos la opción Agregar un controlador de dominio a un dominio existente, seleccionamos nuestro nombre de dominio y le proporcionamos las credenciales del Administrador del dominio, clic en Siguiente:

• Sobre las Opciones del controlador de dominio, seleccionamos la función de DNS, ya que es un requisito imprescindible para Active Directory, también seleccionamos que sea Catálogo Global y luego introducimos una contraseña segura que será necesaria en caso de restauración de Active Directory:

• Sobre Opciones de DNS, la dejamos por defecto, ya que el DNS lo tenemos configurado sobre el controlador de dominio principal, por lo que el controlador de dominio adicional se va a configurar automáticamente con la misma configuración que el principal:

• En Opciones adicionales, le indicamos que replique desde cualquier controlador de dominio:

• Sobre Rutas de acceso las dejamos por defecto:

• Sobre Opciones de preparación, nos indica que para instalar este controlador de dominio el asistente debe realizar las operaciones de preparar el esquema y el bosque, y preparar el dominio:

• Sobre Revisar opciones, nos muestra un resumen de las configuraciones seleccionadas, clic en Siguiente:

• Sobre Comprobación de requisitos previos, nos muestra que todas las comprobaciones se realizaron correctamente, clic a Instalar:

• Sobre Instalación, podemos ver como comienza a instalar y configurar los Servicios de dominio de Active Directory, una vez instalados, el servidor se va a reiniciar automáticamente:

• Tras el reinicio, nos abrimos la consola de Usuarios y equipos de Active Directory, y cómo podemos ver, este equipo ya está como un Domain Controller más de nuestra infraestructura:

• Para el otro controlador de dominio DCRGS04, con Windows Server 2025 realizamos las mismas operaciones, y cómo podemos ver, este equipo está también, como un Domain Controller más de nuestra infraestructura:

• También podemos comprobarlo con el comando netdom query dc:

• Con el comando repadmin /showrepl, verificamos que nuestros nuevos controlador de dominio están replicando correctamente:

• Con el comando dcdiag /test:replications comprobamos la replicación y cualquier error de replicación entre los controladores de dominio:

• Con el comando dcdiag /test:connectivity comprobamos la conectividad y cualquier error de conexión entre los controladores de dominio:

• Con el comando dcdiag /test:DNS comprobamos que el DNS esté funcionando correctamente:

• Estas mismas pruebas de diagnóstico, las debemos de realizar sobre el controlador de domino principal y así nos aseguramos que nuestros controladores de dominio estén en perfecto estado.
• Una vez que tenemos agregados los dos controladores de dominio adicionales con sistema operativo MS Windows Server 2025, y por tanto, superior a MS Windows Server 2022, vamos a proceder a transferir los roles FSMO del controlador de dominio principal al adicional, así el nuevo controlador de dominio con el Server 2025 quedará como principal.
• Todos los dominios de Active Directory disponen de cinco roles FSMO (Flexible Single Master Operations), los roles FSMO son funciones específicas que realizan los controladores de dominio a nivel de bosque o de dominio:

• Sobre cualquiera de nuestros controladores de dominio vamos a ejecutar el siguiente comando netdom query fsmo para ver quien tiene asignados estos roles FSMO, y como podemos ver todos los roles los tiene asignados nuestro primer controlador de dominio con Windows Server 2022 (dcrgs01):

• Ahora lo que vamos a realizar será transferir los cinco roles FSMO a uno de los dos controladores de dominio adicionales con Windows Server 2025 (dcrgs03), convirtiéndolo así en el domain controller principal, para ello, utilizaremos Powershell.
• Para transferir los roles fsmo del controlador de dominio dcrgs01 al controlador de domino dcrgs03, ejecutamos el siguiente comando, Move-ADDirectoryServerOperationMasterRole -Identity «DCRGS03» -OperationMasterRole SchemaMaster, RIDMaster, InfrastructureMaster, DomainNamingMaster, PDCEmulator:

• Volvemos a ejecutar el comando netdom query fsmo, y cómo podemos ver, los roles fsmo ya los tiene asignados el dcrgs03:

• También podemos usar este otro comando Move-ADDirectoryServerOperationMasterRole -Identity «DCRGS03» -OperationMasterRole 0, 1, 2, 3, 4
• Cada número se corresponde con los roles fsmo:

0    PDCEmulator
1    RIDMaster
2    InfrastructureMaster
3    SchemaMaster
4    DomainNamingMaster

• Si los cinco roles FSMO no los transferimos de forma manual, el proceso de despromoción los transferirá de forma automática a cualquier Controlador de dominio disponible, a mí personalmente prefiero hacerlo de forma manual.
• Ahora accedemos a la configuración TCP/IPv4 de nuestros nuevos controladores de dominio recién desplegados y configuramos como DNS principal su propia dirección IP y como DNS secundario la dirección IP del controlador de dominio principal:

• Ahora ya podemos despromocionar como controlador de dominio los servidores con MS Windows Server 2022, para ello, vamos a realizar lo siguiente:
• Nos abrimos el Administrador del servidor y pinchamos sobre la opción Administrar > Quitar roles y funciones:

• Se nos abre este asistente, clic en siguiente para continuar:

• Seleccionamos el servidor y clic sobre siguiente:

• Sobre Roles de servidor, desmarcamos el check “Servicios de dominio de Active Directory” y sobre el asistente que se nos abre hacemos clic en “Quitar características”:

• Se nos abre el siguiente asistente, que nos indica que tenemos que disminuir el nivel, por lo tanto, hacemos clic sobre “Disminuir el nivel de este controlador de dominio”:

• Se nos vuelve a abrir otro asistente, dónde verificamos que las credenciales sean las correctas, esta es la opción más importante del asistente, ya que al ser un controlador de dominio adicional o secundario NO aparece la opción de marcar el check “Último controlador de dominio en el dominio”, clic sobre “siguiente”:

• Marcamos el check “Continuar con la eliminación” y clic sobre siguiente:

• Introducimos la nueva contraseña para el administrador local, al eliminar el rol de controlador de dominio, la cuenta de usuario de administrador pasará a formar parte de los usuarios locales de la máquina, clic sobre “siguiente”:

• Revisamos y hacemos clic sobre “Disminuir nivel”, al finalizar la operación se reiniciará el servidor:

• Como podemos ver comienza el proceso de degradación de nuestro controlador de dominio:

• El sistema nos va a indicar que ha disminuido el nivel del controlador de dominio, y se va a reiniciar automáticamente.
• Para el otro controlador de dominio (dcrgs02) con MS Windows Server 2022, realizamos las mismas operaciones.
• Una vez que los equipos han reiniciado verificamos que los dos servidores con MS Windows Server 2022 ya no son controladores de dominio, en el Administrador del servidor nos vuelve a indicar con una advertencia “Promover este servidor a controlador de dominio”:

• Sobre la consola de Usuarios y equipos de Active Directory del Controlador de dominio principal, podemos ver como los Controladores de dominio con Windows Server 2022 han pasado a formar parte del dominio como un equipo más de éste:

• Para desinstalar los binarios de los Servicios de dominio de Active Directory, lo haremos a través del Administrador del Servidor > Administrar > Quitar roles y funciones:

• Se nos abre este asistente, clic en siguiente para continuar:

• Seleccionamos el servidor y clic sobre siguiente:

• Desmarcamos el check, Servicios de dominio de Active Directory, y Quitar características:

• Desmarcamos el check, Servidor DNS, y Quitar características:

• Una vez desmarcados estos dos checks, damos clic a “siguiente”:

• Aquí no tocamos nada, clic sobre “siguiente”:

• Nos muestra un resumen de las opciones configuradas para eliminar, le indicamos que reinicie en caso necesario y procedemos a quitar:

• Comienza con la eliminación:

• Tras el reinicio podemos ver que la eliminación ha sido correcta:

• Todo se ha eliminado correctamente, en la bandera de las advertencias, ya NO nos avisa de la promoción de este servidor a Controlador de dominio, ya que todos los binarios han sido eliminados:

• Para el otro equipo Windows Server 2022 (dcrgs02) realizamos las mismas operaciones.
• Sobre el controlador de dominio principal (dcrgs03), en Sitios y servicios de Active Directory eliminamos los dos controladores de dominio antiguos:

• Para terminar ya sólo nos quedaría elevar los Niveles Funcionales a nivel de dominio y de bosque.
• Empezaremos elevando el Nivel Funcional del bosque, para ello, nos abrimos la herramienta Dominios y Confianzas de Active Directory:

• Como podemos observar, el Nivel Funcional del bosque se encuentra en Windows Server 2016, y lo vamos a Elevar a Windows Server 2025:

• Nos indica que este cambio afecta a todo el bosque, y que una vez que hayamos elevado el nivel funcioanl del bosque, ya no podremos revertirlo, Aceptar:

• Como podemos ver, el nivel funcional se aumentó correctamente, Aceptar:

• Ahora vamos a elevar el Nivel Funcional del dominio, para ello, nos abrimos la herramienta Usuarios y equipos de Active Directory:

• Automáticamente al elevar el Nivel Funcional del bosque se eleva también el del dominio, como podemos ver, el nivel funcional del dominio se encuentra en Windows Server 2025:

• Con la herramienta Centro de Administración de Active Directory tenemos opción a Elevar los Niveles Funcionales a nivel de bosque y de dominio:

• Para terminar, vamos a cambiarle las direcciones IP a los dos Controladores de dominio nuevos, y les vamos a dejar las IPs de los controladores de dominio antiguo:

• En la consola DNS nos debería de quedar de esta forma:

• Si en nuestra infraestructura, estábamos utilizando los nombres antiguos de los controladores de dominio en algún servicio (dcrgs01 y dcrgs02), nos vamos a crear estos registros del tipo CNAME en el DNS, para que estos servicios no se vean afectados:

• Con esto ya tendríamos migrado nuestros controladores de dominio de MS Windows Server 2022 a MS Windows Server 2025.

Saludos y espero que os resulte de ayuda

La entrada Migrar controladores de dominio con Windows Server 2022 a Windows Server 2025 se publicó primero en RAGASYS SISTEMAS.

En este post (hoy cortito), vamos a ver, cómo configurar las políticas de contraseñas granulares en nuestro Active Directory, estas políticas van a prevalecer sobre las políticas de contraseñas configuradas en las políticas de grupo (GPO) y las asignaremos a grupos de usuarios.

• Si accedemos a la consola de Administración de directivas de grupo de nuestro Active Directory, podemos ver que tenemos esta política configurada:

• Para configurar una política distinta de contraseña a un grupo de usuarios y que prevalezca sobre esta política, debemos de acceder a la consola, Centro de Adminsitración de Active Directory > Dominio > System > Password Settings Container > Nuevo > Configuración de contraseña:

• Configuramos la política de contraseña que nos interese, y le asignamos el grupo de usuarios al que le queremos aplicar esta política:

• Y aquí tenemos, nuestra política granular creada:

Saludos y espero que os resulte de ayuda

La entrada Configuración de políticas de contraseñas granulares en Active Directory se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como deshabilitar la ejecución del símbolo de sistema a través de una GPO en nuestro Active Directory.

• Accedemos a cualquiera de nuestros controladores de dominio, nos abrimos la consola de Administración de directivas de grupo > Objetos de directivas de grupo > Nuevo:

• Le asignamos un nombre y aceptamos:

• Clic derecho sobre la GPO y editamos:

• Accedemos a Configuración de usuario > Directivas > Plantillas administrativas > Sistema > Impedir acceso al símbolo del sistema:

• Habilitamos la GPO, clic en Aceptar:

• Una vez creada la GPO, la vamos a vincular sobre la unidad organizativa que nos interese aplicarla:

• Como podemos ver, aquí la tenemos vinculada:

• Si accedemos al dominio con cualquiera de estos usuarios, no vamos a poder ejecutar el símbolo del sistema:

• Si intentamos abrir un símbolo del sistema nos va a saltar este mensaje de error:

Saludos y espero que os resulte de ayuda

La entrada Deshabilitar Símbolo del sistema por GPO se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como deshabilitar la ejecución de PowerShell a través de una GPO en nuestro Active Directory.

• Accedemos a cualquiera de nuestros controladores de dominio, nos abrimos la consola de Administración de directivas de grupo > Objetos de directivas de grupo > Nuevo:

• Le asignamos un nombre y aceptamos:

• Clic derecho sobre la GPO y editamos:

• Accedemos a Configuración de usuario > Directivas > Plantillas administrativas > Sistema > No ejecutar aplicaciones de Windows especificadas:

• Habilitamos la GPO, sobre Lista de aplicaciones no permitidas damos a Mostrar y escribimos la lista que pueden ejecutar PowerShell, clic en Aceptar:

• Una vez creada la GPO, la vamos a vincular sobre la unidad organizativa que nos interese aplicarla:

• Como podemos ver, aquí la tenemos vinculada:

• Si accedemos al dominio con cualquiera de estos usuarios, no vamos a poder ejecutar PowerShell:

• Si intentamos abrir un Powershell nos va a saltar este mensaje de error:

Saludos y espero que os resulte de ayuda

La entrada Deshabilitar PowerShell por GPO se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo migrar del antiguo Microsoft LAPS al nuevo Windows LAPS, en nuestra infraestructura, tenemos dos controladores de dominio con Windows Server 2019 y el antiguo sistema Microsoft LAPS implantado, en este link podemos ver como lo implantamos.

• Antes de empezar, si tenemos configurado el almacén central para nuestras GPO, tendremos que copiar la carpeta PolicyDefinitions ubicada en C:\Windows, a la carpeta de SYSVOL dónde residen las políticas de grupo del dominio Active Directory, C:\Windows\SYSVOL\sysvol\dominioAD\Policies:

• Ahora vamos a migrar de Microsoft LAPS a Windows LAPS, para ello, seguimos este post que realizamos anteriormente, para implantar Windows LAPS, pero las dos nuevas GPOs que nos hemos creado (LAPS_Equipos y LAPS_Servidores) no las vamos a vincular de momento a ninguna Unidad Organizativa (OU), esto lo haremos en un paso posterior, aquí vemos las dos GPOs que nos hemos creado:

• El siguiente paso para seguir con la migración, es desvincular la GPO de LAPS antigua o heredada de las Unidades Organizativas donde esté:

• Ahora vamos a vincular las dos nuevas GPOs creadas, LAPS_Equipos y LAPS_Servidores, sobre las unidades organizativas que nos interese:

• Verificamos en cualquier equipo de nuestra infraestructura que todo lo configurado se está aplicando, empezamos ejecutando los comandos gpupdate /force y gpresult /r:

• Ahora para ver la password del administrador local de los equipos, accedemos a cualquiera de nuestros controladores de dominio, accedemos a la consola de Usuarios y equipos de Active Directory, y abrimos las propiedades de cualquier equipo:

• Accedemos a la pestaña LAPS, y desde aquí podemos ver el Nombre de la cuenta de administrador local de LAPS, la Contraseña de la cuenta de administrador local de LAPS (Copiar y Mostrar), podemos ver la Expiración actual de contraseña de LAPS, y Establecer nueva expiración de contraseña de LAPS:

• Si nos abrimos un PowerShell en cualquiera de nuestros controladores de dominio, y ejecutamos primero el comando Get-Command -Module LAPS, para ver los comandos disponibles en el módulo de LAPS:

• Ejecutando el comando Get-LapsADPassword “nombreequipo” -AsPlainText, podemos ver, la cuenta del administrador local del equipo con su contraseña:

• Para terminar, eliminamos el software de LAPS heredada:

Saludos y espero que os sea de ayuda

La entrada Migrar Microsoft LAPS a Windows LAPS se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo configurar Windows LAPS para la contraseña DSRM (restauración de servicios de directorio) de Active Directory, esta contraseña la asignamos cuando desplegamos el rol de Servicios de dominio de Active Directory, esta es una nueva característica del nuevo Windows LAPS.

• Lo primero que vamos a realizar es acceder a uno de nuestros controladores de dominio y nos abrimos la consola de Usuarios y equipos de Active Directory, nos vamos a la Unidad Organizativa (OU) Domain Controllers, damos Propiedades sobre uno de ellos, y sobre la pestaña LAPS podemos ver, que es aquí dónde nos va a mostrar la contraseña de DSRM, una vez que tengamos la GPO configurada y vinculada sobre la OU Domain Controllers:

• Nos abrimos la consola Administración de directivas de grupo y nos vamos a crear una nueva GPO llamada LAPS_DSRM con la siguiente configuración:

• Luego vinculamos esta GPO sobre la OU Domain Controllers:

• Ahora si nos abrimos un PowerShell sobre el controlador de dominio DCRGS01 y ejecutamos un gpupdate /force, vamos a forzar a que se activen estas nuevas configuraciones de directivas que hemos creado:

• Si accedemos de nuevo a la consola de Usuarios y equipos de Active Directory, nos vamos a la Unidad Organizativa (OU) Domain Controllers, damos Propiedades sobre DCRGS01, y sobre la pestaña LAPS podemos ver, que ya se ha aplicado esta nueva GPO para controlar las contraseñas de DSRM de los controladores de dominio de nuestra infraestructura:

• Ahora si nos abrimos un PowerShell sobre el controlador de dominio DCRGS02 y ejecutamos un gpupdate /force, vamos a forzar a que se activen estas nuevas configuraciones de directivas que hemos creado:

• Si accedemos de nuevo a la consola de Usuarios y equipos de Active Directory, nos vamos a la Unidad Organizativa (OU) Domain Controllers, damos Propiedades sobre DCRGS02, y sobre la pestaña LAPS podemos ver, que ya se ha aplicado esta nueva GPO para controlar las contraseñas de DSRM de los controladores de dominio de nuestra infraestructura:

Saludos y espero que os resulte de ayuda

La entrada Configurar Windows LAPS para contraseña DSRM de Active Directory se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo instalar y configurar Windows LAPS (Local Administrator Password Solution) en Windows Server 2022, LAPS determina si la contraseña de la cuenta del administrador local ha caducado, si la contraseña ha caducado, cambia la contraseña del administrador local a un nuevo valor aleatorio y transmite la nueva contraseña y la fecha de caducidad a Active Directory dónde se almacena en unos atributos especiales asociados con el objeto de equipo de AD. Las contraseñas se almacenan en Active Directory y están protegidas por listas de control de acceso (ACLs) por lo que solo los usuarios elegibles pueden leerlas o solicitar su restablecimiento.

• Los requisitos para configurar esta nueva implementación de LAPS, son los siguientes, ya que anteriormente a estas nuevas actualizaciones, LAPS había que implementarlo de forma manual, en este link os dejo como se hacía anterior a estas actualizaciones, con estas nuevas actualizaciones LAPS se implementa de forma nativa en estos sistemas:
• Windows 11 22H2 – Actualización 11 abril 2023
• Windows 11 21H2 – Actualización 11 abril 2023
• Windows 10 – Actualización 11 abril 2023
• Windows Server 2019 – Actualización 11 abril 2023
• Windows Server 2022 – Actualización 11 abril 2023
• Para implementar y configurar este laboratorio, he utilizado dos máquinas Windows Server 2022 Standard como Controladores de dominio, uno principal y otro adicional, una máquina Windows Server 2022 Standard y otra con Windows 11 Pro, que serán miembros del dominio ragasys.local implementado en los dos controladores de dominio:

• Para empezar, vamos a extender el schema de Active Directory, para que se añadan los atributos nuevos a las propiedades de los equipos de nuestra infraestructura, para ello, accedemos a nuestro controlador de dominio principal, dcrgs01, nos abrimos un PowerShell y nos importamos los módulos de LAPS con el comando Import-Module LAPS:

• Para ver los comandos disponibles en este módulo ejecutamos Get-Command -Module LAPS:

• Para extender el schema de nuestro Active Directory y soportar toda la configuración de LAPS, vamos a utilizar el comando Update-LapsADSchema, le indicamos que Si (S) uno a uno o podemos indicarle que Sí a todo (O), aquí he elegido la primera opción, para mostrar todos los atributos que se van a añadir en las propiedades de los equipos de nuestra infraestructura de dominio:

• Para verificar que los atributos se han añadido correctamente a nuestros equipos, sobre nuestro controlador de dominio principal, accedemos a Usuarios y equipos de Active Directory y abrimos las propiedades de cualquier equipo:

• Accedemos a la pestaña Editor de atributos, y como podemos ver, ya se han añadido los atributos de LAPS a los equipos:

• Ahora vamos a establecer los permisos para LAPS en las Unidades Organizativas (OU) que nos interesen, en este caso, las OUs que vamos a utilizar serán las de Equipos para las máquinas clientes y la de Servidores para las máquinas con el rol de servidor, estos permisos va a permitir a LAPS modificar los atributos de las cuentas de equipos que se encuentran en estas OUs, permitiendo así crear y modificar las contraseñas, para ello ejecutamos el comando, Set-LapsADComputerSelfPermission -Identity “DistinguisedName OU”:

• Ahora vamos a configurar las GPOs para LAPS en Active Directory, en nuestro caso, vamos a configurar dos GPOs, una para los equipos clientes llamada LAPS_Equipos y otra para los servidores llamada LAPS_Servidores, habilitamos la política y en el caso de que el administrador local no sea el nombre por defecto (Administrator o Administrador) indicamos el nombre de la cuenta local tipo administrador que esté configurada en los equipos del dominio y los parámetros de las passwords como la complejidad, longitud y expiración, estas serían las dos GPOs configuradas:

• Una vez que tenemos creadas las GPOs las vamos a vincular sobre las unidades organizativas que indicamos anteriormente:

• Con esto ya tendríamos implementado y configurado LAPS en nuestra infraestructura, lo primero que vamos a verificar es que la GPO se está aplicando en los equipos de cada unidad organizativa, para ello, en cualquiera de los equipos de ambas unidades organizativas ejecutamos el comando gpresult /r:

• Ahora para ver la password del administrador local de los equipos, accedemos a cualquiera de nuestros controladores de dominio, accedemos a la consola de Usuarios y equipos de Active Directory, y abrimos las propiedades de cualquier equipo:

• Accedemos a la pestaña LAPS, y desde aquí podemos ver el Nombre de la cuenta de administrador local de LAPS, la Contraseña de la cuenta de administrador local de LAPS (Copiar y Mostrar), podemos ver la Expiración actual de contraseña de LAPS, y Establecer nueva expiración de contraseña de LAPS:

• Si nos abrimos un PowerShell en cualquiera de nuestros controladores de dominio, y ejecutamos primero el comando Get-Command -Module LAPS, para ver los comandos disponibles en el módulo de LAPS:

• Ejecutando el comando Get-LapsADPassword “nombreequipo” -AsPlainText, podemos ver, la cuenta del administrador local del equipo con su contraseña:

• Sólo los usuarios Administradores del dominio tienen permisos de lectura y escritura sobre los valores de los atributos donde se almacena la password y la fecha de expiración, en muchas ocasiones, necesitamos dar permisos a otros usuarios, por lo que vamos a crear este grupo, LAPS_HelpDesk, y dentro de este grupo añadiremos a los usuarios o grupos que nos interesen, si hacemos esto, el grupo Administradores del dominio también lo tenemos que añadir al grupo, ya que si no, no podremos visualizar las contraseñas con las cuentas de administrador:

• Ahora tenemos que volver a configurar las dos GPOs que creamos anteriormente y habilitar estas dos opciones, Habilitar cifrado de contraseña y Configurar descifradores de contraseñas autorizados que incluiremos al grupo que hemos creado anteriormente:

• Ahora asignamos los permisos para el grupo LAPS_HelpDesk.
• Con este comando asignamos los permisos de lectura sobre la OU especificada:
• Set-LapsADReadPasswordPermission -Identity “distinguisedname OU” -AllowedPrincipals “DOMINIO\GRUPO”
• Con este comando asignamos los permisos de lectura-escritura sobre la OU especificada:
• Set-LapsADResetPasswordPermission -Identity “distinguisedname OU” -AllowedPrincipals “DOMINIO\GRUPO”

• Con el siguiente cmdlet verificamos la asignación de permisos asignados a las Unidades Organizativas, Find-LapsADExtendedRights -Identity “distinguisedname OU”:

• Ahora si accedemos a cualquier equipo de nuestra infraestructura, con el usuario ubicado en el grupo LAPS_HelpDesk, podemos ver las credenciales del usuario local administrador y resetear las contraseñas:

Saludos y espero que os resulte de ayuda

La entrada Instalar y configurar Windows LAPS (Local Administrator Password Solution) en Windows Server 2022 se publicó primero en RAGASYS SISTEMAS.

• Lo primero que vamos a realizar, será configurar el DNS del Windows 10 para que apunte al controlador de dominio samba:

• Accedemos a la Configuración avanzada del Sistema, sobre la pestaña Nombre de equipo > Cambiar introducimos el nombre de nuestro dominio:

• Nos pedirá las credenciales del administrador del dominio samba para poder unirlo:

• Como podemos ver, se ha unido correctamente a nuestro dominio:

• Ahora nos pide que reiniciemos el equipo:

• Una vez reiniciado, vamos a acceder al equipo con uno de los usuarios que nos creamos anteriormente en controlador de dominio samba:

• Aquí vemos el equipo unido al dominio samba:

• Si accedemos a nuestro controlador de dominio Samba y ejecutamos el comando samba-tool computer list podemos ver, el listado de máquinas unidas a nuestro dominio:

• Crearemos dos grupos, cada uno de ellos con dos usuarios, para ello, ejecutamos samba-tool group add nombregrupo:

• Añadimos dos usuarios a cada grupo, para ello, ejecutamos samba-tool group addmembers nombregrupo nombreusuario:

• Con el commando samba-tool group listmembers «nombregrupo», vemos los miembros de cada grupo:

• Con el comando samba-tool group list podemos ver todos los grupos de nuestro dominio samba:

• En el fichero de configuración de samba, nano /etc/samba/smb.conf hemos configurado el siguiente recurso compartido, con los siguientes permisos:

• A la carpeta local /opt/share le asignamos permisos de control total con chmod 777 /opt/share ya que los permisos más restrictivos lo va a gestionar el servicio de samba:

• Ahora desde el equipo windows 10 vamos a verificar, que podemos acceder a un recurso compartido de nuestro controlador de dominio samba, y que podemos crear un documento:

• Como podemos ver, nos aparecen los recursos compartidos por el servidor:

• Accedemos al recurso compartido (share) que creamos anteriormente y nos creamos un fichero .txt para verificar que todo esto funciona correctamente, esto ha sido con el usuario2 que tiene permisos de escritura:

• Si accedemos al recurso compartido (share) con el usuario3, que sólo tiene permisos de lectura, no nos dejará crear ningún fichero:

Saludos y espero que os sea de ayuda

La entrada Agregar Windows 10 como cliente del dominio Samba se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como agregar una máquina Ubuntu desktop 22.04 como cliente del dominio Windows Server 2022.

• Lo primero que vamos a configurar será el fichero /etc/hosts para que el equipo linux pueda resolver el nombre de nuestro controlador de dominio:

• Le hacemos un ping al nombre del controlador de dominio y como podemos ver, ya nos resuelve:

• A continuación vamos a configurar la conexión de red, para ello, editamos el fichero /etc/netplan/01-network-manager-all.yaml:

• Aplicamos la nueva configuración de red con netplan apply:

• Con nslookup nombre del dominio vemos si el equipo está resolviendo bien el dominio:

• Una vez que hemos verificado que la comunicación entre el equipo linux y el servidor funciona correctamente, actualizaremos el sistema operativo con las últimas versiones de los paquetes disponibles en los repositorios, para ello, ejecutaremos apt-get update && apt-get upgrade recibiremos un detalle con todos los paquetes que van a actualizarse le indicamos que SI los instale:

• Modificaremos el hostname del equipo para que incluya al dominio, hostnamectl set-hostname asoubntdesk.jrrg.local:

• Editamos de nuevo el fichero hosts, nano /etc/hosts e introducimos nuestro hostname:

• Reiniciamos el equipo, reboot:

• Instalamos los paquetes necesarios, para ello, ejecutamos el siguiente commando, apt install -y realmd sssd sssd-tools libnss-sss libpam-sss krb5-user adcli samba-common-bin packagekit:

• También ahora nos aparece un listado con todos los paquetes que van a actualizarse y un resumen final con el número de paquetes que se actualizarán, los paquetes nuevos que se instalarán y los que se eliminarán de la instalación.
• Ahora nos pregunta por el reino (realm en inglés). En realidad, se refiere al nombre del dominio al que vamos a unirnos, debemos de ponerlo en MAYÚSCULAS:

• Si por alguna razón esta pantalla no aparece o queremos hacer alguna modificación posteriormente, podemos editar el fichero /etc/krb5.conf. En este mismo fichero es bueno añadir tres entradas en la sección [libdefaults] que le dirán específicamente al cliente que use los servidores DNS para las búsquedas.

rdns = false

dns_lookup_realm = true

dns_lookup_kdc = true

• Ahora añadimos nuestro controlador de dominio como servidor de tiempo, nano /etc/systemd/timesyncd.conf:

• Realizamos lo siguiente:
• timedatectl set-ntp true, Habilita la sincronización por NTP
• systemctl restart systemd-timesyncd.service, reinicia el servicio
• timedatectl –adjust-system-clock, fuerza la sincronización
• Luego podemos comprobar el estado hacienda, timedatectl status
• En caso de que haya que cambiar la zona horaria, ejecutamos timedatectl set-timezone Europe/Madrid

• Nos creamos el fichero /etc/realmd.conf con la siguiente configuración, hay que asegurarse que la ruta a la OU es la misma que la que hemos creado para la nueva máquina:

[users]

default-home = /home/%D/%U

default-shell = /bin/bash

[active-directory]

default-client = sssd

os-name = Ubuntu Desktop

os-version = 22.04 LTS

[service]

automatic-install = no

[jrrg.local]

fully-qualified-names = yes

automatic-id-mapping = no

user-principal = yes

manage-system = yes

computer-ou= OU=Equipos,OU=JRRG,DC=jrrg,DC=local

dyndns_update = true

dyndns_refresh_interval = 43200

dyndns_update_ptr = true

dyndns_ttl = 3600

• Ahora configuramos la creación automática del home del usuario, para ello, ejecutamos pam-auth-update y seleccionamos la opción de crear el directorio home al hacer login:

• Una vez que se ha instalado y configurado todo, vamos a unir el equipo linux al dominio, para ello, ejecutamos realm join –verbose –user=Administrador jrrg.local:

• Si accedemos a nuestro controlador de dominio, podemos ver el equipo unido al dominio:

• Una vez unido al dominio debemos modificar a True la entrada ldap_id_mapping en el fichero /etc/sssd/sssd.conf para poder hacer login, también podemos añadir el sufijo del dominio por defecto con el parámetro

default_domain_suffix = JRRG.LOCAL

full_name_format = %1$s

[sssd]

domains = jrrg.local

config_file_version = 2

services = nss, pam

default_domain_suffix = JRRG.LOCAL

full_name_format = %1$s

[domain/jrrg.local]

default_shell = /bin/bash

krb5_store_password_if_offline = True

cache_credentials = True

krb5_realm = JRRG.LOCAL

realmd_tags = manages-system joined-with-adcli

id_provider = ad

fallback_homedir = /home/%d/%u

ad_domain = jrrg.local

use_fully_qualified_names = True

ldap_id_mapping = True

access_provider = ad

• Para que los cambios se apliquen reiniciamos el servicio sssd, con systemctl restart sssd y con systemctl status sssd vemos el estado del servicio:

• Si quisiéramos sacar el equipo del dominio debemos de ejecutar realm leave –verbose –user=Administrador JRRG.LOCAL
• Para que los usuarios del dominio puedan logarse, se debe reconfigurar la pantalla de login, para ello, añadimos al fichero /usr/share/lightdm/lightdm.conf.d/50-ubuntu.conf la línea, greeter-show-manual-login=true:

• Ahora cerramos la sesión del equipo con el usuario local, y vamos a acceder con uno de nuestros usuarios del dominio:

• Como podemos ver, ya estoy logueado con el usuario del dominio:

• Para dar permisos de sudo a los usuarios del dominio se pueden crear grupos de seguridad en AD para que al añadirlos se les apliquen esos permisos por pertenecia al grupo.
• Para habilitar un grupo de AD y que tenga permisos de sudo, en el fichero de /etc/sudoers añadir:

%<nombre_grupo_AD> ALL=(ALL:ALL) ALL

Ejemplo:

%DomainAdminsJRRG ALL=(ALL:ALL) ALL

• Ahora desde el equipo Ubuntu 22.04 LTS vamos a verificar, que podemos acceder al recurso compartido que creamos anteriormente en nuestro controlador de dominio, y que podemos crear un documento.
• Instalamos smbclient con apt-get install smbclient y ejecutamos smbclient –list 192.168.5.51 o podemos poner en lugar de la direccion IP del servidor el nombre, como podemos ver, accedemos a los recursos compartidos de nuestro controlador de dominio:

• Accedemos al recurso compartido (share) que creamos anteriormente y nos creamos un fichero .txt para verificar que todo esto funciona correctamente, nos conectamos al servidor, nos pedirá las credenciales de usuario, nos ubicamos sobre el recurso compartido y añadimos el fichero .txt:

Saludos y espero que os resulte de ayuda

La entrada Agregar Ubuntu desktop 22.04 como cliente del dominio Windows Server 2022 se publicó primero en RAGASYS SISTEMAS.

• Accedemos a la Configuración avanzada del Sistema, sobre la pestaña Nombre de equipo > Cambiar introducimos el nombre de nuestro dominio:

• Nos pedirá las credenciales del administrador del dominio para poder unirlo:

• Como podemos ver, se ha unido correctamente a nuestro dominio:

• Ahora nos pide que reiniciemos el equipo:

• Una vez reiniciado, vamos a acceder al equipo con uno de los usuarios que nos creamos anteriormente en el Active Directory:

• Aquí vemos el equipo unido al dominio:

• Si accedemos al controlador de dominio podemos ver el equipo como miembro del dominio:

• Ahora desde el equipo windows 10 vamos a verificar, que podemos acceder al recurso compartido que creamos anteriormente en nuestro controlador de dominio, y que podemos crear un documento:

• Como podemos ver, nos aparecen los recursos compartidos por el servidor:

• Accedemos al recurso compartido (share) que creamos anteriormente y nos creamos un fichero .txt para verificar que todo esto funciona correctamente:

Saludos y espero que os sea de ayuda

La entrada Agregar Windows 10 como cliente del dominio Windows Server 2022 se publicó primero en RAGASYS SISTEMAS.

En este primer post, vamos a ver como instalar y configurar Active Directory Domain Services en Windows Server 2022.

• Empezamos la configuración de nuestro controlador de dominio asignándole un nombre y una dirección IP estática, y como DNS le asignamos su propia dirección IP, ya que se encargará de toda la gestión DNS de nuestro entorno:

• Abrimos el Administrador del servidor y agregamos roles y características:

• Se nos abre el siguiente asistente, clic en siguiente:

• Elegimos la opción instalación basada en características o roles:

• Seleccionamos nuestro servidor dc01aso:

• Ahora agregamos el rol de Servicios de dominio de Active Directory:

• Agregamos las características:

• Continuamos con la instalación del rol:

• Todas las características que requiere nuestro controlador de dominio de Active Directory se seleccionan por defecto por lo que hacemos clic en siguiente:

• Aquí nos muestra información sobre Active Directory, clic en siguiente:

• Iniciamos el despliegue de la función Servicios de dominio de Active Directory, clic sobre “Instalar”:

• Una vez finalizada la instalación cerramos y reiniciamos nuestro controlador de dominio:

• Tras el reinicio nos abrimos el Administrador del servidor y promovemos este servidor a controlador de dominio:

• Se nos abre el siguiente asistente y añadimos un nuevo bosque, ya que este es nuestro primer controlador de dominio en la infraestructura, escribimos nuestro nombre de dominio raíz:

• Seleccionamos el nivel funcional de nuestro bosque, en este caso Windows Server 2016, ya que no tenemos otros controladores de dominio sobre Windows Server 2003, 2008 0 2012. También seleccionamos la función de DNS en la que apoyaremos toda la infraestructura de nombres de nuestra red, aparte de que es un requisito imprescindible para Active Directory, luego introducimos una contraseña segura que será necesaria en caso de restauración de Active Directory:

• Windows no puede encontrar una delegación para el servidor DNS ya que éste es el primer bosque de nuestro entorno, hacemos clic en siguiente:

• Agregamos el nombre NETBIOS:

• Las rutas de acceso las dejamos por defecto:

• Nos muestra un resumen de las opciones configuradas:

• Vemos que la comprobación de los requisitos previos está correcta, clic sobre Instalar:

• Comienza el proceso de instalación y promoción a controlador de dominio:

• Una vez que la instalación termina, nuestro servidor se reinicia automáticamente, y tras el reinicio, introducimos las credenciales de Administrador que será la cuenta del administrador del dominio:

• Con esto ya tendríamos nuestro servidor promovido a controlador de dominio:

• Ahora vamos a abrir la consola de DNS y agregamos una zona nueva para la resolución inversa:

• Vamos configurando el asistente con los siguientes parámetros:

• Para verificar que la zona de resolución inversa está funcionando correctamente, sobre la zona de búsqueda directa y sobre las propiedades del registro tipo A de nuestro servidor controlador de dominio, marcamos el check PTR:

• Y como vemos en nuestra zona de búsqueda inversa se actualiza el registro:

• Otra de las configuraciones que debemos realizar en nuestro DNS es agregar los reenviadores (pondremos los DNS públicos de google 8.8.8.8 y 8.8.4.4, el DNS público de IBM 9.9.9.9 especializado en bloquear malware) y el 1.1.1.1 para que el servidor DNS resuelva también dominios externos, para ello hacemos lo siguiente:

• Así quedarían configurados nuestros reenviadores:

• Configuramos la dirección IP que dará servicio a las consultas DNS:

• Con todo esto, ya tendríamos nuestro controlador de dominio implementado en nuestra infraestructura, ya podríamos empezar a crear usuarios y a organizar el Active Directory.
• Ahora vamos a crear varias unidades organizativas, grupos y usuarios.
• Estas son las unidades organizativas que hemos creado:

• Ahora vamos a crear varios usuarios:

• Crearemos dos grupos, cada uno de ellos con dos usuarios:

• Ahora vamos a crear una carpeta compartida en nuestro controlador de dominio llamada share, con permisos de escritura para los grupos creados, para el uso compartido avanzado le vamos a asignar control total a Todos, y luego filtraremos los permisos a los grupos creados con los permisos NTFS en Seguridad > Opciones avanzadas:

Saludos y espero que os resulte de ayuda

La entrada Instalar y configurar Active Directory en Windows Server 2022 se publicó primero en RAGASYS SISTEMAS.

En estos posts vamos a mostrar como desplegar, instalar y configurar servicios de directorios en sistemas operativos Windows y Linux.

Este post lo vamos a dividir en:

• Instalar y configurar Active Directory en Windows Server 2022
• Instalar y configurar Controlador de dominio Samba
• Instalar y configurar Controlador de dominio OpenLDAP
•  Agregar Windows 10 como cliente del dominio Windows Server 2022
• Agregar Ubuntu desktop 22.04 como cliente del dominio Windows Server 2022
• Agregar Windows 10 como cliente del dominio Samba
• Agregar Ubuntu desktop 22.04 como cliente del dominio Samba
• Agregar Ubuntu desktop 22.04 como cliente del dominio OpenLDAP

Saludos y espero que os sea de ayuda

La entrada Administración de servicios de directorios se publicó primero en RAGASYS SISTEMAS.