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

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

• 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

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

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

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

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

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

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

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

• 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

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

• 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

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

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

En este post vamos a ver cómo configurar un servidor LDAP en OPNSense, así nos vamos a poder autenticar al firewall opnsense con usuarios del Active Directory y configurar vpn de acceso remoto con usuarios del Active Directory.

La topología que vamos a utilizar será esta:

• Accedemos a System > Access > Servers > +:

• Introducimos los datos necesarios para conectarnos a nuestro Active Directory:

• Como podemos ver, ya lo tenemos creado:

• Ahora sobre Firewall > Rules > IPsec debemos de crearnos esta regla de salida, para que OPNSense pueda acceder al puerto LDAP (389) de uno de nuestros controladores de dominio:

• Ahora, como nuestros controladores de dominio los tenemos en la parte on-premise, detrás de un fortigate, y como ya tenemos configurada la VPN IPSec site to site, debemos de configurar esta regla, para que OPNSense pueda acceder al puerto LDAP (389) de uno de nuestros controladores de dominio:

• Para comprobar que todo funciona correctamente y que OPNSense se comunica con nuestro servidor LDAP de Active DIrectory, accedemos a System > Access > Tester e introducimos las credenciales de uno de nuestros usuarios del dominio, damos clic a Test, y si todo está correctamente configurado, podemos ver que el usuario se autentica:

• Una vez que ya tenemos comunicación con nuestro Active Directory, vamos a configurar que podamos hacer logon en el OPNSense con uno de nuestros usuarios del dominio, para ello, lo primero que nos vamos a crear es un grupo de administradores de LDAP, accedemos a System > Access > Groups > +:

• Le indicamos un nombre y una descripción:

• Como podemos ver, aquí lo tenemos creado:

• Ahora debemos de editar los permisos de este grupo, y le asignamos todos los privilegios:

• Una vez creado el grupo, OPNSense requiere que todas las cuentas de usuario LDAP existan en la base de datos local, por lo que procederemos a crear la cuenta, System > Access > Users > +, esta cuenta la añadimos como miembro del grupo que hemos creado, la password no tiene porque ser la del usuario del dominio, podemos poner otra, lo que hace OPNSense es verificar primero la base de datos del LDAP y luego la base de datos local, por lo que si ponemos otra password a este usuario podemos acceder con las dos password (una del LDAP y la otra Local):

• Como podemos ver, aquí tenemos el usuario creado:

• A continuación, vamos a habilitar la autenticación LDAP, para ello, accedemos a System > Settings > Administration > Authentication > Server y seleccionamos la autenticación por LDAP Active Directory como primera opción, y como segunda opción seleccionamos la base de datos local, clic a Save:

• Ahora ya podemos acceder con las credenciales de nuestro usuario del dominio:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo copiar los miembros de un grupo de Active Directory a otro grupo.

• Tenemos estos dos grupos en nuestro Active Directory, y queremos copiar los miembros del GrupoA al GrupoB:

• Para ello, nos vamos a abrir un PowerShell y ejecutamos este cmdlet para que nos muestre los miembros del GrupoA, Get-ADGroupMember -Identity «GrupoA» | Select-Object name | Sort-Object name:

• Para copiar los miembros del GrupoA al GrupoB ejecutamos este cmdlet Get-ADGroupMember -Identity «GrupoA» | ForEach-Object {Add-ADGroupMember -Identity «GrupoB» -Members $_.distinguishedName}:

• Para ver que los miembros del GrupoA se han copiado correctamente al GrupoB, ejecutamos este cmdlet para que nos muestre los miembros del GrupoB, Get-ADGroupMember -Identity «GrupoB» | Select-Object name | Sort-Object name:

• Como podemos ver, los dos grupos ya tienen los mismos miembros:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo solucionar el problema de la replicación de la carpeta SYSVOL entre los controladores de dominio.

• Si accedemos al visor de eventos en cualquiera de nuestros controladores de dominio, y nos encontramos con estos dos ID de eventos 4612 y 5002, tenemos un problema en la replicación DFSR de la carpeta SYSVOL:

• Para solucionar este problema, lo primero que vamos a realizar será parar el servicio Replicación DFS en todos los controladores de dominio:

• En la herramienta ADSIEDIT.MSC, modificamos el siguiente DN y dos atributos en el controlador de dominio que deseamos convertir en autoritativo (preferiblemente el emulador PDC, que suele ser el más actualizado para contenidos de replicación sysvol):

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=FALSE

msDFSR-options=1

• Modificamos el siguiente DN y atributo único en todos los demás controladores de dominio en ese dominio:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=FALSE

• Ahora forzamos la replicación de Active Directory en todo el dominio y validamos que es correcto en todos los DC con repadmin /syncall dc01 /APed:

• Iniciamos el servicio DFSR en el controlador de dominio que se configuró como autorizado, es decir, DC01:

• Ahora veremos el ID de evento 4114 en el registro de eventos de DFSR, lo que indica que la replicación de sysvol ya no se está replicando:

• En la herramienta ADSIEDIT.MSC, volvemos a modificar el siguiente DN y este atributo en el controlador de dominio que convertimos en autoritativo, en nuestro caso DC01:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=TRUE

• Ahora volvemos a forzar la replicación de Active Directory en todo el dominio y validamos que es correcto en todos los DC con repadmin /syncall dc01 /APed:

• Volvemos a modificar el siguiente DN y atributo único en todos los demás controladores de dominio en ese dominio:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=TRUE

• Ahora paramos el servicio de Replicación DFS con Invoke-Command -ComputerName dc01, dc02 -ScriptBlock {Stop-Service DFSR} y volvemos a iniciarlo con Invoke-Command -ComputerName dc01, dc02 -ScriptBlock {Start-Service DFSR}:

• Ejecutamos el siguiente comando DFSRDIAG POLLAD desde un símbolo del sistema con permisos de administrador en el mismo servidor que configuramos como autorizado, DC01:

• Ahora veremos el ID de evento 4602 en el registro de eventos de DFSR, lo que indica que se ha inicializado la replicación de sysvol, ese controlador de dominio ahora ha realizado una replicación D4 de sysvol:

• Para terminar, ejecutamos el siguiente comando DFSRDIAG POLLAD desde un símbolo del sistema con permisos de administrador en todos los controladores de dominio no autoritativos, DC02:

• En el DC02, veremos el ID de evento 4604 en el registro de eventos de DFSR, indicando que la carpeta SYSVOL se ha replicado correctamente:

• Para verificar que la carpeta SYSVOL se está replicando correctamente accedemos a \\Controladordominio\netlogon y en el dc01 creamos un fichero llamado testdc01 que se debe de replicar en dc02, y en el dc02 creamos un fichero llamado testdc02 que se debe de replicar en dc01:

NOTA: Nos podemos encontrar con este error al ejecutar el comando DFSRDIAG POLLAD:

• Para solucionarlo nos abrimos un PowerShell como administrador y ejecutamos Install-WindowsFeature RSAT-DFS-Mgmt-Con:

• Una vez instaladas las herramientas remotas RSAT para DFS, volvemos a ejecutar DFSRDIAG POLLAD y veremos que se ejecuta correctamente:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como configurar la página de inicio en Microsoft Edge, Google Chrome y Mozilla Firefox a través de una GPO configurada en nuestro Active Directory.

• Empezaremos configurando la GPO para la página de inicio de Microsoft Edge, para ello, lo primero que vamos a realizar será descargarnos las plantillas admx y adml para la configuración de Microsoft Edge, desde este link las podemos descargar:

• Estas plantillas las copiamos en el GPO central store de nuestro Active Directory, si no tenemos configurado GPO central store, debemos de copiarlas en la ruta C:\Windows\PolicyDefinitions de cada controlador de dominio, en mi caso si lo tenemos configurado:

• Ahora sobre la consola Administración de directivas de grupo, nos creamos una nueva GPO:

• Le damos un nombre:

• Editamos la nueva GPO:

• Accedemos a la ruta Configuración del equipo > Directivas > Plantillas administrativas > Microsoft Edge > Inicio, página principal y página de la nueva pestaña:

• Sobre Configurar la dirección URL de la página principal la habilitamos e introducimos la URL:

• Sobre Acción que se realizará al inicio la habilitamos y le indicamos Abrir una lista de direcciones URL:

• Sobre Sitios que se abrirán cuando se inicia el explorador la habilitamos y le indicamos la URL:

• Sobre Mostrar el botón de inicio en la barra de herramientas la habilitamos:

• Así nos quedaría la GPO para Microsoft Edge:

• Ahora seguiremos configurando la GPO para la página de inicio de Google Chrome, para ello, lo primero que vamos a realizar será descargarnos las plantillas admx y adml para la configuración de Google Chrome, desde este link las podemos descargar:

• Estas plantillas las copiamos en el GPO central store de nuestro Active Directory, si no tenemos configurado GPO central store, debemos de copiarlas en la ruta C:\Windows\PolicyDefinitions de cada controlador de dominio, en mi caso, si lo tenemos configurado:

• Seguimos editando la GPO y accedemos a la ruta Configuración del equipo > Directivas > Plantillas administrativas > Google > Google Chrome > Inicio, Página principal y página Nueva pestaña:

• Sobre Configurar la URL de la página principal la habilitamos e introducimos la URL:

• Sobre Acción al iniciar la habilitamos y le indicamos Abrir una lista de URLs:

• Sobre URL que se deben abrir al inicio la habilitamos y le indicamos la URL:

• Sobre Mostrar botón de página principal en la barra de herramientas la habilitamos:

• Así nos quedaría la GPO para Google Chrome:

• Ahora seguiremos configurando la GPO para la página de inicio de Mozilla Firefox, para ello, lo primero que vamos a realizar será descargarnos las plantillas admx y adml para la configuración de Mozilla Firefox, desde este link las podemos descargar:

• Estas plantillas las copiamos en el GPO central store de nuestro Active Directory, si no tenemos configurado GPO central store, debemos de copiarlas en la ruta C:\Windows\PolicyDefinitions de cada controlador de dominio, en mi caso, si lo tenemos configurado:

• Seguimos editando la GPO y accedemos a la ruta Configuración del equipo > Directivas > Plantillas administrativas > Mozilla > Firefox > Página de inicio:

• Sobre URL de la página de inicio la habilitamos e introducimos la URL, no permitimos que se cambie la página de inicio:

• Sobre Mostrar botón de página principal en la barra de herramientas la habilitamos:

• Así nos quedaría la GPO para Mozilla Firefox:

• Así nos quedaría configurada nuestra GPO “Conf_Edge_Chrome_Firefox” para poner la página de inicio que nos interese a los equipos de nuestra infraestructura con estos tres navegadores, Microsoft Edge, Google Chrome y Mozilla Firefox:

• Una vez que ya tenemos la GPO “Conf_Edge_Chrome_Firefox” preparada y configurada, la vinculamos sobre las Unidades organizativas que nos interese:

• Como podemos ver ya está vinculada sobre la OU Equipos:

• Ahora en cualquiera de los equipos de nuestro dominio, iniciamos sesión y verificamos la página de inicio de los tres navegadores:

• Podemos verificar que las GPOs se están aplicando correctamente abriéndonos un PowerShell y ejecutando el comando gpresult /r:

Saludos y espero que os resulte de ayuda

En este post vamos a ver una configuración de GPO para LAPS alternativa a la que realizamos en el post anterior, ya que en la anterior GPO le indicamos una cuenta de usuario administrador, en esta nueva GPO, no utilizaremos ninguna cuenta de administrador, por lo que la password de LAPS se aplicará a la cuenta nativa con permisos de administrador, esta cuenta administrativa se puede llamar administrador, administrator o si la hemos cambiado de nombre tampoco tendríamaos problemas ya que el password se lo aplica por el SID.

• Como podemos ver, esta es la GPO que utilizamos para el post anterior, dónde en la directiva Name of administrator account to manage le indicamos un nombre de cuenta:

• Ahora vamos a crear una nueva directiva dónde Name of administrator account to manage la dejaremos en No configurada, por lo que, la cuenta nativa de administrador local de nuestros equipos van a utilizar las passwords proporcionadas por LAPS:

• Esta GPO la vamos a vincular sobre una Unidad Organizativa dónde se encuentra uno de nuestros equipos:

• Aplicamos los permisos para la gestión de LAPS en esta Unidad Organizativa, ejecutando el siguiente comando Set-AdmPwdComputerSelfPermission -OrgUnit <OU>:

• Ahora si accedemos a este equipo vemos que tenemos esta cuenta nativa con permisos de administrador, a esta cuenta es a la que se le va aplicar la directiva de LAPS:

• Hacemos un gpupdate /force para aplicar las políticas:

• Con gpresult /r vemos que esta nueva GPO se está aplicando sobre el equipo:

• Ahora para ver la password de los administradores locales de los equipos, accedemos a cualquiera de nuestros controladores de dominio y ejecutamos sobre PowerShell Get-AdmPwdPassword <HOSTNAME> | fl, esta password sería la que debemos de utilizar para la cuenta nativa administrativa que tiene el equipo:

• Desde el LAPS UI (ejecutándolo como administrador) del controlador de dominio donde instalamos LAPS también podemos ver el password:

Saludos y espero que os sea de ayuda