• 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 realizar una conmutación por error de prueba, una conmutación por error planeada y una conmutación por error en las réplicas de máquinas virtuales que hemos mandado desde Hyper-V a Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Lo primero que vamos a ver, es como se realiza una Conmutación por error de prueba, para ello, accedemos a almacén de recovery service > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error de prueba:

• Le indicamos la dirección de conmutación por error y la red virtual, clic sobre Aceptar:

• Aquí vemos como se está realizando el trabajo:

• Una vez terminada la conmutación por error de prueba, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina levantada:

• Una vez realizada la prueba, vamos a proceder a realizar la limpieza de la conmutación por error de prueba, para ello, accedemos al elemento replicado y sobre Información general, damos a Limpiar conmutación por error de prueba:

• Le ponemos una nota y marcamos el check de que la prueba está completa, Aceptar:

• Como vemos, la limpieza de la conmutación por error de prueba se ha realizado correctamente:

• Ahora vamos a realizar una Conmutación por error planeada, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Como podemos ver, la conmutación por error planeada, se ha realizado correctamente:

• Una vez terminada la conmutación por error planeada, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina virtual levantada:

• Este proceso también nos puede valer para migrar máquinas virtuales de Hyper-V On-premise al Cloud de Azure, en caso de querer migrar daríamos a Aceptar:

• Ahora en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Ahora, para volver a dejar todo como estaba, es decir, que la máquina virtual replique desde el entorno on-premise de Hyper-V a Azure, debemos de hacer otra conmutación por error planeada, para ello, en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, que ahora es al contrario que antes, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver, como se está realizando la conmutación por error en sentido inverso, y todos los cambios que se hayan hecho en la máquina virtual levantada en Azure, se van a aplicar a la máquina virtual on-premise:

• Cuando nos salga este aviso, debemos de Completar la conmutación por error:

• Le indicamos que Sí:

• Como podemos ver, la conmutación por error planeada en el sentido inverso, se ha realizado correctamente:

• Vemos que la máquina virtual en Azure se ha detenido:

• Y se está ejecutando de nuevo, en nuestro entorno on-premise de Hyper-V:

• Para terminar, en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Como podemos ver, si accedemos al grupo de recursos donde se ubicaba la máquina virtual que habíamos levantado en Azure tras la conmutación por error planeada, esta máquina ha desaparecido, tras la confirmación:

• Una vez confirmada, debemos de habilitar la replicación inversa, para ello, nos vamos al Elemento replicado > Información general > … > Replicación inversa y Aceptar:

• Como podemos ver, todo nos ha quedado como estaba originalmente en Azure:

• Como podemos ver, todo nos ha quedado como estaba originalmente en on-premise Hyper-V:

• Ahora vamos a suponer, que nuestra máquina virtual principal en el servidor on-premise de Hyper-V, no nos inicia, por el motivo que sea, vemos que esta apagada:

• Vamos a realizar entonces una Conmutación por error, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error:

• Nos indica la dirección de conmutación por error, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error:

• Como podemos ver, la conmutación por error se ha realizado correctamente:

• Una vez terminada la conmutación por error, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina virtual levantada:

• Este proceso también nos puede valer para migrar máquinas virtuales de Hyper-V On-premise al Cloud de Azure, en caso de querer migrar daríamos a Aceptar:

• Ahora en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Ahora, para volver a dejar todo como estaba, es decir, que la máquina virtual replique desde el entorno on-premise de Hyper-V a Azure, debemos de hacer otra conmutación por error planeada, para ello, en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, que ahora es al contrario que antes, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver, como se está realizando la conmutación por error en sentido inverso, y todos los cambios que se hayan hecho en la máquina virtual levantada en Azure, se van a aplicar a la máquina virtual on-premise:

• Cuando nos salga este aviso, debemos de Completar la conmutación por error:

• Le indicamos que Sí:

• Como podemos ver, la conmutación por error planeada en el sentido inverso, se ha realizado correctamente:

• Vemos que la máquina virtual en Azure se ha detenido:

• Y se está ejecutando de nuevo, en nuestro entorno on-premise de Hyper-V:

• Para terminar, en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Como podemos ver, si accedemos al grupo de recursos donde se ubicaba la máquina virtual que habíamos levantado en Azure tras la conmutación por error planeada, esta máquina ha desaparecido, tras la confirmación:

• Una vez confirmada, debemos de habilitar la replicación inversa, para ello, nos vamos al Elemento replicado > Información general > … > Replicación inversa y Aceptar:

• Como podemos ver, todo nos ha quedado como estaba originalmente en Azure:

• Como podemos ver, todo nos ha quedado como estaba originalmente en on-premise Hyper-V:

Saludos y espero que os resulte de ayuda

En este post vamos a ver, cómo replicar máquinas virtuales desde un entorno on-premise con Hyper-V a un entorno cloud con Microsoft Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Para empezar, vemos que tenemos nuestro servidor de Hyper-V con la máquina virtual que vamos a replicar a Azure, esta máquina tiene dos discos, uno de sistema y otro de datos:

• En Azure vamos a crear un grupo de recursos llamado replicas-hv-rg, dónde vamos a ubicar todo lo necesario para realizar las réplicas de las máquinas virtuales de Hyper-V, en este link de este mismo blog, podemos ver como se crea un grupo de recursos:

• También nos debemos de crear una red virtual con su espacio de direcciones y con una subred, para cuando realicemos una conmutación por error de la réplica, podamos levantar la máquina virtual en Azure, en este link de este mismo blog, podemos ver como se crea una red virtual:

• Ahora nos creamos una cuenta de almacenamiento, para ello, nos vamos a Cuentas de almacenamiento > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el Grupo de recursos, el nombre de la cuenta, la Región, el Rendimiento que es nuestro caso será Estándar y la Redundancia que en nuestro caso será Almacenamiento con redundancia local (LRS):

• Sobre Avanzado, lo dejaremos todo por defecto:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Protección de datos, debemos de deshabilitar, la eliminación temporal para blobs, la eliminación temporal para contenedores y la eliminación temporal para recursos compartidos de archivos, ya que si no, cuando configuremos el almacén de recovery services nos dará error:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

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

• Si nos vamos al grupo de recursos, podemos ver, que ya la tenemos creada, esta cuenta de almacenamiento será usada para almacenar los datos de las réplicas y los puntos de recuperación de las máquinas virtuales:

• Ahora vamos a crear un almacén de recovery services, que se va a encargar de gestionar los puntos de recuperación y las réplicas de las máquinas virtuales, para ello, accedemos a Almacénes de Recovery Services > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el grupo de recursos, le asignamos un nombre y la región:

• Sobre Redundancia, le indicamos Redundancia local:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Propiedades del almacén, lo dejamos tal cual está, no habilitamos la inmutabilidad:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

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

• Si nos vamos al grupo de recursos, podemos ver, que ya tenemos creado este almacén de recovery services:

• Ahora accedemos al almacén de recovery services y nos vamos a Infraestructura de Site Recovery:

• Como podemos ver, tenemos para configurar todo tipo de infraestructuras, para máquinas virtuales de Azure, máquinas físicas, máquinas de VMware (que lo vamos a ver en otro post), para System Center VMM, y la que nos interesa a nosotros en estos momentos que son Para sitios de Hyper-V:

• Lo primero que vamos a realizar será crearnos un Sitio de Hyper-V, donde le indicamos un nombre:

• Como vemos, ya tenemos creado el sitio:

• Lo siguiente será, agregar un host de Hyper-V, para ello nos vamos a Hosts de Hyper-V > Agregar servidor:

• Aquí se nos muestran todos los pasos para agregar el host de Hyper-V:

• Los dos primeros pasos, los cumplimos, procedemos por tanto a descargar el instalador del proveedor de Microsoft Azure Site Recovery (paso 3) y a descargar la clave de registro del almacén para registrar el host en un sitio de Hyper-V (paso 4):

• Una vez descargados, sobre nuestro servidor de Hyper-V vamos a proceder a instalar el proveedor de Microsoft Azure Site Recovery usando la clave de registro del almacén para registrar el servidor en el almacén (paso 5).
• Activamos las actualizaciones de Microsoft update:

• Damos a instalar:

• Comienza el proceso de instalación:

• Aquí vemos que ha finalizado correctamente, ahora procedemos a registrar el servidor en el almacén de recovery services de Azure, clic en Registrarse:

• Sobre Configuración del almacén, añadimos el Archivo de clave:

• Sobre Configuración de proxy, le indicamos que nos vamos a conectar directamente con Azure Site Recovery sin un servidor proxy:

• Comienza con el registro:

• Pasados unos minutos, ya tenemos nuestro servidor de Hyper-V registrado en nuestro almacén de recovery services de Azure, finalizamos:

• Para verificar que todo está correcto, nos vamos a nuestro almacén de recovery services en Azure, a la parte de Infraestructura de Site Recovery > Hosts de Hyper-V, y vemos que nos aparece como un servidor registrado y en estado Conectado:

• Ahora vamos a crear una directiva de replicación, para ello, nos vamos a Infraestructura de Site Recovery > Directivas de replicación > + Directiva de replicación:

• Le indicamos un Nombre, el tipo de origen que será Hyper-V, el tipo de destino que será Azure, la frecuencia de copia, retención de puntos de recuperación en horas, la frecuencia de instantáneas coherentes a nivel de aplicación y la hora de inicio de la replicación inicial:

• Aquí vemos la directiva de replicación creada:

• Una vez creada, la tenemos que asociar al sitio de Hyper-V:

• Como podemos ver, ya está asociada:

• Una vez definida la infraestructura de Site Recovery para Hyper-V, vamos a proceder a configurar las réplicas de nuestras máquinas virtuales de HyperV, para ello, accedemos a nuestro Almacén de recovery services > Elementos protegidos > Elementos replicados > Replicar > Máquinas de Hyper-V a Azure:

• Sobre Entorno de origen, seleccionamos el sitio de Hyper-V que nos creamos anteriormente:

• Sobre Entorno de destino, seleccionamos la suscripción, el grupo de recursos, el modelo de implementación, el tipo de almacenamiento y la red dónde se va a ubicar la máquina virtual en caso de que tengamos que levantarla en Azure al hacer la conmutación por error:

• Sobre el Tipo de almacenamiento debemos de hacer una aclaración, ya que vamos a usar un disco administrado (esta opción es nueva), esto no era posible usarlo antes, y teníamos que hacerlo con una cuenta de almacenamiento, de ahí que anteriormente nos creásemos esa cuenta, si usamos un discos administrados no hace falta crearnos la cuenta de almacenamiento:

• Sobre Selección de la máquina virtual, seleccionamos las máquinas que nos interesen:

• Sobre Configuración de replicación, seleccionamos el tipo de sistema operativo, el disco del sistema operativo, los discos a replicar, en este caso replicamos los dos discos que tiene la máquina virtual, le indicamos el tipo de disco administrado y la cuenta de almacenamiento en caché:

• En Directiva de replicación, seleccionamos la directiva que nos creamos anteriormente:

• En Revisar, nos muestra un resumen de todo lo configurado, damos a Habilitar replicación:

• Sobre el almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el proceso está en curso:

• Si clicamos sobre el proceso, en Información general, podemos ver el estado y una vista de la infraestructura de replicación:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver que la réplica inicial está en proceso:

• Sobre el servidor de Hyper-V, y la máquina virtual a replicar > Replicación > Ver mantenimiento de la replicación, podemos ver, que la réplica se está realizando correctamente:

• Accedemos de nuevo a almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el Estado se encuentra esperando el primer punto de recuperación:

• Pasados unos minutos, podemos ver, que el Estado se encuentra en Protected, esto quiere decir que la réplica ya la tenemos hecha y que disponemos de puntos de recuperación, para levantar la máquina virtual en Azure:

• Si accedemos al elemento replicado, información general, Puntos de recuperación más recientes, vemos que ya nos muestra los últimos cinco puntos de recuperación:

• Sobre General > Propiedades, podemos ver, todas las propiedades del proceso de replicación configurado:

• Sobre General > Proceso y red, vemos las propiedades de la máquina virtual en Azure:

• Sobre General > Discos, vemos los discos que estamos replicando de la máquina virtual de Hyper-V:

• Si accedemos al grupo de recursos que nos configuramos anteriormente, podemos ver, los dos discos de réplica que se han creado:

• Con esto, ya tendríamos configuradas las réplicas desde un entorno on-premise con Hyper-V hacia un entorno cloud en Azure, en el próximo post veremos como realizar una conmutación por error de prueba, una conmutación por error planeada y una conmutación por error.

Saludos y espero que os sea de ayuda

En este post vamos a ver, cómo mover las máquinas virtuales de Hyper-V, en algunas ocasiones nos vamos a encontrar en el caso de que tengamos que mover nuestras máquinas virtuales de ubicación dentro del mismo servidor de Hyper-V, ya sea en el mismo disco en otro directorio, a otro disco porque en el que está se está quedando sin espacio por ejemplo, etc…, también tendremos la opción de mover la maquina a otro servidor distinto de Hyper-V, aquí vamos a mostrar la manera correcta de mover estas máquinas virtuales.

• Como podemos ver, tenemos esta máquina virtual y la tenemos ubicada en:

• Para mover de forma correcta la máquina virtual, damos clic derecho sobre la máquina y Mover:

• Se nos abrirá este asistente, que nos va a guiar en el proceso, sobre Antes de empezar nos muestra la información del proceso, clic en Siguiente:

• Sobre Elegir tipo de movimiento vamos a seleccionar Mover la máquina virtual, clic en Siguiente:

• Sobre Especificar destino, vamos a seleccionar otro hypervisor de nuestra infraestructura, clic en Siguiente:

• Sobre Elegir opciones de movimiento, vamos a seleccionar la primera opción, Mover los datos de la máquina virtual a una sola ubicación, clic en Siguiente:

• Sobre Máquina virtual, le indicamos la ubicación en el equipo de destino, clic en Siguiente:

• Sobre Resumen, nos muestra todo lo que hemos configurado, clic en Finalizar:

• Una vez finalizado el movimiento, si accedemos al hypervisor de destino, podemos ver ya la máquina virtual:

• Aquí vemos la estructura de carpetas que nos ha creado tras el movimiento:

Saludos y espero que os resulte 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

En este post vamos a ver, cómo actualizar la versión de configuración en las máquinas virtuales de Hyper-V.

La versión de configuración de las máquinas virtuales en Hyper-V nos indica que configuraciones y funcionalidades están disponibles para nuestras máquinas virtuales, cuando Microsoft lanza actualizaciones importantes para sus sistemas operativos suele cambiar la versión de configuración, para poder aplicar estas nuevas funcionalidades.

• Como podemos ver tenemos cuatro máquinas virtuales en este servidor de Hyper-V, dos están en versión 9.0 y otras dos en versión 8.0:

• Vamos a cambiar la versión de configuración de las máquinas virtuales que están en versión 8.0 para que estén en la última versión 9.0, lo vamos a hacer de dos formas, una a través de la consola de Hyper-V y otra a través de PowerShell.
• Empezamos por cambiar la versión de configuración a través de la consola de Hyper-V, para ello, damos botón derecho sobre la máquina que queremos cambiar, y seleccionamos Actualizar versión de configuración:

• Nos indica, si estamos seguros del cambio, ya que este cambio implica que si queremos migrar esta máquina a otro servidor de Hyper-V con una versión de configuración inferior no va a ser posible, damos a Actualizar:

• Como podemos ver, ya la tenemos cambiada a versión 9.0:

• Ahora vamos a cambiar la versión de configuración a través de PowerShell, para ello, nos abrimos un PowerShell como Administrador:

• Y ejecutamos el siguiente cmdlet, Update-VMVersion nombreMV, nos indica si estamos seguros del cambio, ya que este cambio implica que si queremos migrar esta máquina a otro servidor de Hyper-V con una versión de configuración inferior no va a ser posible, le indicamos que Sí:

• Ahora si accedemos a la consola de Hyper-V, podemos ver, que ya la tenemos cambiada a versión 9.0:

• Si damos botón derecho sobre cualquiera de las máquinas, que están ya en versión 9.0, esta opción no está disponible en la máquina virtual, esto quiere decir que ya tiene la versión de configuración más alta compatible con el host de Hyper-V:

• Si ejecutamos el cmdlet, Get-VMHostSupportedVersion, podemos ver qué versiones de configuración de máquina virtual admite el host de Hyper-V:

Saludos y espero que os resulte de ayuda

En este post (hoy cortito), vamos a ver, cómo configurar la interface de red de un equipo Windows a través de la consola cmd.

• Nos abrimos un terminal de cmd como administrador:

• Y ejecutamos el comando netsh interface ipv4 set address name=»LAN» source=static address=192.168.5.2 mask=255.255.255.0 gateway=192.168.5.210:

• Ahora para configurar el DNS primario ejecutamos, netsh interface ip add dnsservers «LAN» 8.8.8.8 index=1:

• Para terminar, configuramos el DNS secundario ejecutando, netsh interface ip add dnsservers «LAN» 8.8.4.4 index=2:

• Para verificar que todo se ha configurado correctamente, ejecutamos un ipconfig /all:

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 cambiar la zona horaria de un equipo Windows a través de PowerShell.

• Con este cmdlet nos va a mostrar un listado de todas las zonas horarias disponibles, Get-TimeZone -ListAvailable:

• Ahora con este cmdlet Get-TimeZone nos va a mostrar la zona horaria en la que se encuentra nuestro equipo:

• Nosotros queremos cambiarla a (UTC+01:00) Brussels, Copenhagen, Madrid, Paris:

• Para ello, introducimos el cmdlet Set-TimeZone -Id «Romance Standard Time» aquí debemos introducir el Id de la zona horaria a la que queramos cambiar:

• Introduciendo de nuevo el cmdlet Get-TimeZone podemos ver como la zona horaria de nuestro equipo a cambiado:

Saludos y espero que os resulte 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 como instalar y configurar un servidor NTP en Windows Server 2022.

• Lo primero que vamos a realizar es abrir el registro de Windows desde Inicio > Ejecutar > regedit:

• En el registro de Windows nos vamos hasta Equipo\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer y sobre la entrada Enabled vemos que está a 0:

• Para poder habilitar el servicio NTP en nuestro Windows Server 2022 vamos a modificar la entrada Enabled a 1:

• Ahora nos vamos a ir hasta esta ubicación en el registro de Windows Equipo\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config y vamos a modificar la entrada AnnounceFlags que como podemos ver tiene el valor a en Hexadecimal ó 10 en decimal:

• Vamos a modificar la entrada AnnounceFlags a 5:

• Para finalizar vamos a parar el servicio de hora de Windows con net stop w32time y lo vamos a volver a iniciar con net start w32time:

• Para verificar que el servicio NTP está funcionando correctamente, desde cualquier equipo de nuestra red interna, ejecutamos w32tm /stripchart /computer:ntpwin.ragasys.net /dataonly /samples:5:

• Si nos muestra que la verificación no es correcta, seguramente la parada y el inicio del servicio de hora de Windows no haya funcionado correctamente, lo que debemos de hacer es darle un reinicio a nuestro servidor NTP, una vez reiniciado volvemos a verificar, y veremos como ya nos funciona correctamente.

• Ahora desde cualquier equipo de nuestra red interna, si ejecutamos con nmap el siguiente comando, nmap -p 123 -sU -P0 servidorNTP podemos ver que el puerto UDP 123 utilizado por el servidor NTP lo tenemos abierto:

Saludos y espero que os resulte de ayuda