En este post vamos a ver como añadir certificados SSL de Let’s Encrypt en Nginx Proxy Manager configurados por DNS Challenge y como DNS Provider utilizaremos Azure, que es dónde tenemos alojada nuestra zona DNS.

• Para empezar, nos vamos a crear un registro tipo CAA en nuestra zona DNS de Azure para Let’s Encrypt, para ello, accedemos a Zonas DNS > ragasys.eu > Administración de DNS > Registros > Agregar:

• Ahora en nuestra nuestra zona DNS de Azure y debemos de tener en cuenta estos datos:
• Nombre exacto de la zona
• Grupo de recursos donde se encuentra
• Id. de suscripción

• Creamos una aplicación, para ello, accedemos a Microsoft Entra ID > Registro de aplicaciones > Nuevo registro:

• Le indicamos el Nombre y Solo cuentas de este directorio organizativo (Inquilino único), Registrar:

• Aquí tenemos la aplicación creada:

• Ahora vamos a crear el secreto de cliente, para ello, en esta nueva aplicación, accedemos a Administrar > Certificados y secretos > Secretos de los clientes > Nuevo secreto de cliente:

• Le indicamos una descripción y el tiempo de expiración, Agregar:

• Aquí tenemos el secreto de cliente, lo copiamos y guardamos en un lugar seguro, ya que sólo nos lo mostrará una sola vez:

• Sobre la Información general de la aplicación, anotamos los siguientes valores, que serán los que utilice Nginx Proxy Manager para el DNS Challenge:

• Ahora damos permisos a la aplicación sobre la Zona DNS, con esto, nuestra aplicación ya tiene permiso para crear/eliminar registros TXT dentro de la zona ragasys.eu, el rol que debemos asignar es el de Colaborador de zona DNS:

• Como la zona ragasys.eu también la tenemos en nuestro DNS interno, nos creamos el registro CNAME _acme-challenge apuntando a _acme-challenge.ragasys.eu, para que resuelva externamente hacia Azure:

• Con esto, ya tenemos preparado la parte de la zona DNS de Azure, ahora accedemos al portal de Nginx Proxy Manager > SSL Certificates > Add SSL Certificate > Let’s Encrypt y vamos a añadir las configuraciones para obtener el certificado wildcard para para nuestro dominio:

• Añadimos Let’s Encrypt:
• Domain Names, añadimos ragasys.eu y *.ragasys.neu, nos aseguramos de incluir el dominio raíz y el wildcard, Let’s Encrypt requiere que se valide también la raíz cuando pedimos el wildcard.
• Email Address for Let’s Encrypt
• Marcamos Use a DNS Challenge.
• En DNS Provider seleccionanamos Azure.
• Rellenaremos los valores para estos campos, Tenant ID, Client ID, Client Secret, Subscription ID, Resource Group, Zone Name.
• Propagation Seconds, ponemos un valor entre 300 y 600.
• Marcamos I Agree to Let’s Encrypt Terms of Service y pulsamos Save, Nginx Proxy Manager iniciará el proceso ACME, creará el TXT _acme-challenge en la zona DNS de Azure, esperará la propagación y Let’s Encrypt validará.
• Este es el contenido del Credentials File Content:
• dns_azure_sp_client_id =
• dns_azure_sp_client_secret =
• dns_azure_tenant_id =
• dns_azure_zone1 = ragasys.eu:/subscriptions/eliddemisuscripcion/resourceGroups/zonasdnspublicas-rg/providers/Microsoft.Network/dnsZones/ragasys.eu

• Este es el registro TXT _acme-challenge que se genera, Let’s Encrypt valida que el TXT coincida con el valor que generó para esa verificación, después de emitir el certificado, Nginx Proxy Manager debería borrar automáticamente el TXT de la zona si todo funciona bien:

• Aquí podemos ver, los certificados SSL de Let’s Encrypt con Azure como DNS Provider, listos para usar en nuestros Hosts:

Saludos y espero que os sea de ayuda

En este post vamos a ver como añadir certificados SSL de Let´s Encrypt en Nginx Proxy Manager configurados por DNS Challenge y como DNS Provider utilizaremos Cloudflare, que es dónde tenemos alojadas nuestras zonas DNS.

• Para empezar, nos vamos a crear un registro tipo CAA en nuestra zona DNS de Cloudflare para Let´s Encrypt, para ello, accedemos a DNS > Registros > Agregar registro:

• Ahora vamos a crear un API Token en nuestra zona DNS de Cloudflare, accedemos a Mi Perfil > Tokens de API > Crear Token:

• Seleccionamos Editar zona DNS > Usar plantilla, también podemos usar Crear Token Personalizado:

• Le indicamos un nombre para el token, le indicamos los permisos, los recursos de zona, Ir al resumen:

• Nos muestra un resumen y creamos el token para nuestra zona:

• Aquí tenemos el token generado, debemos de copiar el valor, ya que lo mostrará sólo una vez, guardamos el token en un sitio seguro:

• Verificamos el token y vemos que es válido:

• Aquí vemos que ya tenemos el token activo:

• Con esto, ya tenemos preparado la parte de la zona DNS de Cloudflare, ahora accedemos al portal de Nginx Proxy Manager > SSL Certificates > Add SSL Certificate > Let’s Encrypt y vamos a añadir las configuraciones para obtener el certificado wildcard para para nuestro dominio:

• Añadimos Let’s Encrypt:
• Domain Names, añadimos ragasys.net y *.ragasys.net, nos aseguramos de incluir el dominio raíz y el wildcard, Let’s Encrypt requiere que se valide también la raíz cuando pedimos el wildcard.
• Email Address for Let’s Encrypt, nuestro email registrado en Cloudflare.
• Marcamos Use a DNS Challenge.
• En DNS Provider seleccionanamos Cloudflare.
• Pegamos el API Token que copiamos desde Cloudflare.
• Propagation Seconds, ponemos un valor entre 300 y 600).
• Marcamos I Agree to Let’s Encrypt Terms of Service y pulsamos Save, Nginx Proxy Manager iniciará el proceso ACME, creará el TXT _acme-challenge en Cloudflare, esperará la propagación y Let’s Encrypt validará.

• Aquí podemos ver los certificados SSL de Let’s Encrypt con Cloudflare como DNS Provider listos para usuar en nuestros Hosts:

• Estos son los registros TXT _acme-challenge que se generan, Let’s Encrypt valida que el TXT coincida con el valor que generó para esa verificación, después de emitir el certificado, Nginx Proxy Manager debería borrar automáticamente el TXT de la zona si todo funciona bien:

• Tengo otro dominio DNS llamado ragasyssistemas.com en cloudflare, y también quiero añadir a Nginx Proxy Manager los certificados SSL de Let’s Encrypt para este dominio, para ello, vuelvo a repetir todo el proceso, y aquí vemos, que ya los tengo agregados y listos para usar en nuestros Hosts:

Saludos y espero que os resulte de ayuda

En este post veremos cómo agregar un certificado SSL de Let’s Encrypt en un nodo Proxmox VE 9.0, los haremos a través de DNS Challenge y cómo DNS Provider usaremos Azure que es donde tenemos nuestra zona DNS llamada ragasys.eu

• Para empezar, nos vamos a crear un registro tipo CAA en nuestra zona DNS de Azure para Let’s Encrypt, para ello, accedemos a Zonas DNS > ragasys.eu > Administración de DNS > Registros > Agregar:

• Ahora en nuestra nuestra zona DNS de Azure y debemos de tener en cuenta estos datos:
• Nombre exacto de la zona
• Grupo de recursos donde se encuentra
• Id. de suscripción

• Creamos una aplicación, para ello, accedemos a Microsoft Entra ID > Registro de aplicaciones > Nuevo registro:

• Le indicamos el Nombre y Solo cuentas de este directorio organizativo (Inquilino único), Registrar:

• Aquí tenemos la aplicación creada:

• Ahora vamos a crear el secreto de cliente, para ello, en esta nueva aplicación, accedemos a Administrar > Certificados y secretos > Secretos de los clientes > Nuevo secreto de cliente, lo copiamos y guardamos en un lugar seguro, ya que sólo nos lo mostrará una sola vez:

• Aquí tenemos los datos que necesitamos más el client secret:

• Ahora damos permisos a la aplicación sobre la Zona DNS, con esto, nuestra aplicación ya tiene permiso para crear/eliminar registros TXT dentro de la zona ragasys.eu, el rol que debemos asignar es el de Colaborador de zona DNS:

• Como la zona ragasys.eu también la tenemos en nuestro DNS interno, nos creamos el registro CNAME _acme-challenge apuntando a _acme-challenge.ragasys.eu, para que resuelva externamente hacia Azure:

• Con esto, ya tenemos preparado la parte de la zona DNS de Azure.
• Ahora en nuestro nodo de Proxmox, lo primero que vamos a realizar será crearnos una cuenta en Let’s Encrypt, para ello, sobre nuestro nodo proxmox accedemos a Centro de datos > ACME > Cuentas > Agregar:

• Le indicamos el nombre de la cuenta, un correo válido, y el directorio ACME, Registrar:

• Ya tenemos la cuenta de Let’s Encrypt generada:

• Ahora en Centro de datos > ACME > Plugins de desafío > Agregar, vamos a agregar el plugin para Azure:

• Le indicamos un ID de plugin, el retardo de validación, el API DNS
• AZUREDNS_SUBSCRIPTIONID=
• AZUREDNS_TENANTID=
• AZUREDNS_APPID=
• AZUREDNS_CLIENTSECRET=
• Agregar:

• Y aquí vemos que ya tenemos el plugin añadido:

• Los datos del plugin los obtenemos de nuestro portal de Azure.
• Ahora vamos a agregar el certificado de Let’s Encrypt al nodo proxmox, para ello accedemos a proxmoxlab11 > Certificados > ACME y usamos la cuenta de Let’s Encrypt que nos hemos creado anteriormente, Aplicar:

• Damos a Agregar para añadir el dominio:

• Introducimos el Tipo de desafío DNS, el plugin que añadimos anteriormente y el nombre de dominio de nuestro nodo Proxmox, Crear:

• Y aquí vemos que ya tenemos la configuración realizada:

• Damos a Solicitar certificados ahora y vemos cómo se han validado:

• Aquí tenemos el certificado SSL de Let’s Encrypt para nuestro nodo Proxmox:

• Accedemos a través del navegador a nuestro nodo Proxmox y vemos como reconoce el certificado SSL de Let’s Encrypt:

Saludos y espero que os sea de ayuda

En este post veremos cómo agregar un certificado SSL de Let’s Encrypt en un nodo Proxmox VE 9.0, los haremos a través de DNS Challenge y cómo DNS Provider usaremos Cloudflare que es donde tenemos nuestra zona DNS llamada ragasys.net.

• Lo primero que vamos a realizar será crearnos una cuenta en Let’s Encrypt, para ello, sobre nuestro nodo proxmox accedemos a Centro de datos > ACME > Cuentas > Agregar:

• Le indicamos el nombre de la cuenta, un correo válido, y el directorio ACME, Registrar:

• Ya tenemos la cuenta generada de Let’s Encrypt:

• Ahora en Centro de datos > ACME > Plugins de desafío > Agregar, vamos a agregar el plugin para Cloudflare:

• Le indicamos un ID de plugin, el retardo de validación, el API DNS, CF_Account, CF_Email, CF_Token y CF_Zone_ID, Agregar:

• Y aquí vemos que ya tenemos el plugin añadido:

• Los datos del plugin los obtenemos de nuestra cuenta de Cloudflare:

• El Token de API, seguimos este enlace en este mismo blog para crearlo.
• Ahora vamos a agregar el certificado de Let’s Encrypt al nodo proxmox, para ello accedemos a proxmoxlab11 > Certificados > ACME y usamos la cuenta de Let’s Encrypt que nos hemos creado anteriormente, Aplicar:

• Damos a Agregar para añadir el dominio:

• Introducimos el Tipo de desafío DNS, el plugin que añadimos anteriormente y el nombre de dominio de nuestro nodo Proxmox, Crear:

• Y aquí vemos que ya tenemos la configuración realizada:

• Damos a Solicitar certificados ahora y vemos cómo se han validado:

• Aquí tenemos el certificado SSL de Let’s Encrypt para nuestro nodo Proxmox:

• Accedemos a través del navegador a nuestro nodo Proxmox y vemos como reconoce el certificado SSL de Let’s Encrypt:

Saludos y espero que os sea 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 vamos a ver cómo crear y configurar una zona DNS secundaria en Azure mediante la zona DNS primaria.

• Como podemos ver, tenemos esta zona DNS primaria en Azure, en este link podéis ver cómo se crea y se configura:

• Ahora, vamos a crear una zona DNS secundaria y delegarla en la zona DNS primaria, para ello, nos vamos a Información general > + Zona secundaria:

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

• Sobre Editor de zonas DNS, lo dejamos como está:

• Sobre Etiquetas, podemos configurar las que nos interesen:

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

• Como podemos ver, se ha implementado correctamente:

• Si accedemos al grupo de recursos, podemos ver el recurso que hemos implementado:

• Una vez que hemos creado la zona DNS secundaria ragasysweb.com, comprobamos que la delegación se ha configurado correctamente, para ello debemos verificar, que los registros del servidor de nombres NS de la zona secundaria están en la zona primaria:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo instalar y configurar servidores DNS externos con bind9, estos servidores DNS externos serán los servidores públicos DNS de nuestra infraestructura, dónde vamos a publicar nuestros servicios en Internet, vamos a desplegar un servidor primario y otro secundario.

Que vamos a necesitar:

• Máquina Ubuntu Server 24.04 LTS con el Rol de DNS bind9, este será el DNS primario, ubicada en nuestro entorno on-premise
• Máquina Ubuntu Server 24.04 LTS con el Rol de DNS bind9, este será el DNS secundario, ubicada en nuestro entorno cloud de Azure
• Los dos servidores estarán en nuestra DMZ (on-premise y cloud)
• Proveedor ISP de DNS, dónde vamos a configurar nuestros propios Servidores DNS
• Un dominio DNS público contratado con un ISP, en nuestro caso, el dominio es ragasysweb.com
• En Firewall Fortigate, vamos a configurar un NAT Static y crear las reglas de acceso para la parte on-premise
• En Firewall OPNsense, vamos a configurar un NAT Static y crear las reglas de acceso para la parte cloud

Está será la infraestructura que vamos a desplegar:

• Como podemos ver, tenemos dos máquinas con Ubuntu Server 24.04 LTS, una para el DNS primario on-premise y otra para el DNS secundario en Azure:

• En las dos máquinas debemos de instalar bind9 ejecutando apt-get install bind9:

• Una vez que ya tenemos desplegado el rol de DNS en ambas máquinas, lo primero que vamos a realizar, es en nuestros firewalls fortigate on-premise y opensense en Azure, realizar las configuraciones necesarias para el acceso externo a nuestros servidores DNS públicos.
• Empezamos en el fortigate on-premise, dónde hemos creado este NAT estático, que lo que hace es mapear nuestra IP externa 192.168.1.210 con la IP interna dónde se ubica el servidor DNS, en este caso el servidor DNS primario, mapeando también el puerto TCP/UDP 53 externo con el puerto TCP/UDP 53 interno, que es el que utiliza el servicio DNS:

• Una vez creado el NAT estático, configuramos la siguiente política en nuestro fortigate, dónde le indicamos que desde cualquier origen externo y con destino al servicio DNS Externo de nuestra infraestructura, le vamos a permitir el acceso:

• Seguimos en el opnsense de Azure, dónde hemos creado este NAT estático, que lo que hace es mapear nuestra interface WAN externa con la IP interna dónde se ubica el servidor DNS, en este caso el servidor DNS secundario, mapeando también el puerto TCP/UDP 53 externo con el puerto TCP/UDP 53 interno, que es el que utiliza el servicio DNS:

• Una vez creado el NAT estático, configuramos la siguiente política en nuestro opnsense, dónde le indicamos que desde cualquier origen externo y con destino al servicio DNS Externo de nuestra infraestructura, le vamos a permitir el acceso:

• Una vez que ya tenemos desplegado bind9 en ambas máquinas y los accesos configurados en nuestros firewalls, vamos a trabajar sobre el servidor primario DNS01, y nos creamos una zona primaria de resolución directa «ragasysweb.com» cuyo archivo de zona se llamará «db.ragasysweb.com» y se almacenará en «/var/lib/bind»:

nano /etc/bind/named.conf.local

zone «ragasysweb.com» {

type master;

file «/var/lib/bind/db.ragasysweb.com»;

};

• Ahora, nos vamos a crear una zona primaria de resolución inversa (esta parte de la resolución inversa, es solo a modo de ejemplo), para que resuelva direcciones IP pertenecientes a la dirección de red 80.31.203.0/24, el nombre del archivo de zona será db.80.31.203.rev y se almacenará en «/var/lib/bind»:

nano /etc/bind/named.conf.local

zone «203.31.80.in-addr.arpa» {

type master;

file «/var/lib/bind/db.80.31.203.rev»;

};

• Ahora, en nuestro servidor secundario DNS02, vamos a crear una zona secundaria de resolución directa «ragasysweb.com» cuyo archivo de zona se llamará «db.slave.ragasysweb.com» y se almacenará en «/var/lib/bind», en esta zona debemos de indicar cual es el servidor DNS primario:

nano /etc/bind/named.conf.local

zone «ragasysweb.com» {

type slave;

file «/var/lib/bind/db.slave.ragasysweb.com»;

masters { 80.31.203.9; };

};

• Nos creamos también, una zona secundaria de resolución inversa, para que resuelva direcciones IP pertenecientes a la dirección de red 80.31.203.0/24, el nombre del archivo de zona será db.slave.80.31.203.rev y se almacenará en «/var/lib/bind»:

nano /etc/bind/named.conf.local

zone «203.31.80.in-addr.arpa» {

type slave;

file «/var/lib/bind/db.slave.80.31.203.rev «;

masters { 80.31.203.9; };

};

• Lo siguiente será configurar, la transferencia de zona en el servidor primario DNS01, para que las zonas primarias se transfieran a la zonas secundarias, para ello, volvemos editar, nano /etc/bind/named.conf.local y añadimos el servidor secundario al que tiene que transferir la zona, tanto para la zona directa como para la inversa, allow-transfer { 13.X.X.X; }; Mi ip pública de Azure:

• Una vez configuradas las zonas, vamos a acceder a nuestro proveedor ISP de DNS, y en nuestro dominio público (ragasysweb.com) vamos a configurar nuestros servidores DNS propios o personalizados con nuestras IPs públicas:

• Con esto ya tendríamos configuradas las zonas de resolución directa e inversa, en el servidor primario y en el secundario.
• Para continuar, vamos a crear los registros de las zonas, para indicar que DNS01 y DNS02 son servidores DNS en la zona «ragasysweb.com» y que el servidor autoritativo o con autoridad sobre la zona es DNS01.

• Zona primaria para la resolución directa:

nano /var/lib/bind/db.ragasysweb.com

$ttl                    604800

ragasysweb.com.     IN       SOA    ns1.ragasysweb.com.   it.ragasys.eu  (

2025012401                 ; Serial

604800                          ; Refresh

86400                            ; Retry

2419200                       ; Expire

604800 )                       ; Negative Cache TTL

@                                   IN      NS       ns1.ragasysweb.com.

@                                   IN      NS       ns2.ragasysweb.com.

• Zona primaria para la resolución inversa:

nano /var/lib/bind/db.80.31.203.rev

$ttl                    604800

203.31.80.in-addr.arpa.    IN    SOA  ns1.ragasysweb.com.   it.ragasys.eu (

2025012401                 ; Serial

604800                          ; Refresh

86400                            ; Retry

2419200                       ; Expire

604800 )                       ; Negative Cache TTL

203.31.80.in-addr.arpa.    IN    NS     ns1.ragasysweb.com.

203.31.80.in-addr.arpa.    IN    NS     ns2.ragasysweb.com.

• Para que las zonas primarias (directa e inversa) se transfieran sobre las secundarias, debemos de crear los registros tipo A y PTR para los dos servidores DNS:

• Hacemos un systemctl restart bind9 y un systemctl status bind9, a ambos servidores, y como podemos ver ya se están replicando las zonas correctamente, haciendo ls /var/lib/bind en el servidor secundario podemos ver como se han creado los ficheros para las zonas secundarias:

• NOTA: La configuración de zona para la resolución inversa, cuando estamos configurando DNS público, realmente no es así, la he mostrando aquí en este lab de esta manera, para que se viese también, a modo de ejemplo, como se replica una zona primaria de resolución inversa en un servidor secundario, para la configuración del PTR debe configurarse, solicitando al proveedor de Internet que ponga un nombre de host a la IP pública, es probable que si contratamos servidores cloud, tengamos una opción para poner el PTR a las IPs públicas.
• Para verificar que todo funciona correctamente, desde cualquier equipo con conexión a Internet le vamos a hacer un ping a uno de los registros DNS de nuestro servidor, y cómo podemos ver, nos responde correctamente:

Saludos y espero que os sea de ayuda

En este post, vamos a ver, cómo configurar servidores DNS internos con bind9, para ello, vamos a desplegar dos máquinas con Ubuntu Server 24.04 LTS, una será el servidor DNS primario y la otra el servidor DNS secundario.

• Esta máquina será nuestro servidor DNS primario, y tendrá esta configuración IP:

• Esta máquina será nuestro servidor DNS secundario, y tendrá esta configuración IP:

• En las dos máquinas debemos de instalar bind9 ejecutando apt-get install bind9:

• Lo primero que vamos a realizar sobre el servidor primario DNSBIND1, será crear una zona primaria de resolución directa «ragasys.net» cuyo archivo de zona se llamará «db.ragasys.net» y se almacenará en «/var/lib/bind»:

nano /etc/bind/named.conf.local

zone «ragasys.net» {

type master;

file «/var/lib/bind/db.ragasys.net»;

};

• Ahora, nos vamos a crear una zona primaria de resolución inversa, para que resuelva direcciones IP pertenecientes a la dirección de red 192.168.5.0/24, el nombre del archivo de zona será db.192.168.5.rev y se almacenará en «/var/lib/bind»:

nano /etc/bind/named.conf.local

zone «5.168.192.in-addr.arpa» {

type master;

file «/var/lib/bind/db.192.168.5.rev»;

};

• Ahora, en nuestro servidor secundario DNSBIND2, vamos a crear una zona secundaria de resolución directa «ragasys.net» cuyo archivo de zona se llamará «db.slave.ragasys.net» y se almacenará en «/var/lib/bind», en esta zona debemos de indicar cual es el servidor DNS primario:

nano /etc/bind/named.conf.local

zone «ragasys.net» {

type slave;

file «/var/lib/bind/db.slave.ragasys.net»;

masters { 192.168.5.21; };

};

• Nos creamos también, una zona secundaria de resolución inversa, para que resuelva direcciones IP pertenecientes a la dirección de red 192.168.5.0/24, el nombre del archivo de zona será db.slave.192.168.5.rev y se almacenará en «/var/lib/bind»:

nano /etc/bind/named.conf.local

zone «5.168.192.in-addr.arpa» {

type slave;

file «/var/lib/bind/db.slave.192.168.5.rev»;

masters { 192.168.5.21; };

};

• Lo siguiente será configurar, la transferencia de zona en el servidor primario DNSBIND1, para que las zonas primarias se transfieran a las zonas secundarias, para ello, volvemos editar, nano /etc/bind/named.conf.local y añadimos el servidor secundario al que tiene que transferir la zona, tanto para la zona directa como para la inversa, allow-transfer { 192.168.5.22; }; :

• Con esta ya tendríamos configuradas las zonas de resolución directa e inversa, en el servidor primario y en el secundario.
• Para continuar, vamos a crear los registros de las zonas, para indicar que DNSBIND1 y DNSBIND2 son servidores DNS en la zona «ragasys.net» y que el servidor autoritativo o con autoridad sobre la zona es DNSBIND1.

• Zona primaria para la resolución directa:

nano /var/lib/bind/db.ragasys.net

$ttl                    604800

ragasys.net.     IN       SOA    dnsbind1.ragasys.net.   it.ragasys.net  (

2024112800                 ; Serial

604800                          ; Refresh

86400                            ; Retry

2419200                       ; Expire

604800 )                       ; Negative Cache TTL

@                                   IN      NS       dnsbind1.ragasys.net.

@                                   IN      NS       dnsbind2.ragasys.net.

• Zona primaria para la resolución inversa:

nano /var/lib/bind/db.192.168.5.rev

$ttl                    604800

5.168.192.in-addr.arpa.    IN    SOA  dnsbind1.ragasys.net.   it.ragasys.net  (

2024112800                 ; Serial

604800                          ; Refresh

86400                            ; Retry

2419200                       ; Expire

604800 )                       ; Negative Cache TTL

5.168.192.in-addr.arpa.    IN    NS     dnsbind1.ragasys.net.

5.168.192.in-addr.arpa.    IN    NS     dnsbind2.ragasys.net.

• Para que las zonas primarias (directa e inversa) se transfieran sobre las secundarias, debemos de crear los registros tipo A y PTR para los dos servidores DNS:

• Hacemos un systemctl restart bind9 y un systemctl status bind9, a ambos servidores, y como podemos ver ya se están replicando las zonas correctamente, haciendo ls /var/lib/bind en el servidor secundario podemos ver como se han creado los ficheros para las zonas secundarias:

• Ahora, vamos a configurar en el archivo de configuración de opciones globales de bind, /etc/bind/named.conf.options, para indicar que el servidor DNS va a usar como reenviadores los servidores DNS con estas direcciones IP, así tendremos resoluciones de nombres externos, realizamos esta configuración en el servidor primario y secundario:

nano /etc/bind/named.conf.options

options {

forwarders { 8.8.8.8; 8.8.4.4; 1.1.1.1; 9.9.9.9; };

};

• Comprobamos lo que llevamos hecho hasta ahora con nslookup, como podemos ver, nos resuelve bien:

• A partir de ahora, ya podemos empezar a crear, todo tipo de registros (A, CNAME, MX, PTR …) en nuestro servidor primario, y automáticamente se replicará en el secundario, como ejemplo hemos creado estos registros:

Saludos y espero que os sea 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 cómo crear y configurar una zona DNS privada en Azure.

• Lo primero que vamos a realizar es crearnos este grupo de recursos, dónde almacenaremos todas las zonas DNS privadas que configuremos en nuestra infraestructura:

• Para crear la zona DNS privada, accedemos a Zonas DNS privadas > Crear:

• Sobre Datos básicos le indico el Grupo de recursos y el nombre:

• 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, clic en Siguiente:

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

• Como podemos ver, ya se ha creado la zona:

• El siguiente paso será vincular la red virtual a la zona DNS privada, para ello sobre la zona privada accedemos a Vínculos de red virtual > Agregar:

• Le indicamos el nombre del vínculo, la suscripción, la red virtual y habilitamos el check Habilitar el registro automático para que las máquinas virtuales que creemos en esta red virtual se les añada automáticamente el registro tipo A en la zona privada DNS:

• Como podemos ver ya está creado el vínculo a la red virtual:

• Nos hemos creado una máquina virtual llamada ws2019 en esta red virtual:

• Si accedemos a la Zona DNS privada > Información general podemos ver que nos ha creado automáticamente un registro tipo A para esta máquina:

• Si accedemos a Conjunto de registros podemos crearnos manualmente los registros tipo A, CNAME, MX, PTR … que necesitemos:

• Como ejemplo, nos hemos creado este registro PTR para la máquina virtual que hemos desplegado:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo crear y configurar una zona DNS pública en Azure.

• Lo primero que vamos a realizar es crearnos este grupo de recursos, dónde almacenaremos todas las zonas DNS públicas que configuremos en nuestra infraestructura:

• Para crear la zona DNS pública, accedemos a Zonas DNS > Crear:

• Sobre Datos básicos le indico el Grupo de recursos y el nombre:

• 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, clic en Siguiente:

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

• Como podemos ver, ya se ha creado la zona:

• El siguiente paso será obtener los servidores de nombres de DNS de Azure, para ello accedemos al recurso de zona que hemos creado y sobre Información general podemos ver los cuatro servidores DNS de Azure:

• Con esta información de los cuatro servidores de nombres de DNS de Azure, vamos a actualizar la configuración en nuestro registrador de dominios, que en mi caso es IONOS, y le indicamos que vamos a utilizar servidores DNS personalizados:

• Introducimos los cuatro servidores de nombres de DNS de Azure:

• Este cambio puede tardar hasta 48 horas en hacerse efectivo:

• Aquí podemos ver los DNS de Azure, ya configurados:

• Ahora vamos a comprobar la delegación de los servicios de nombres de dominio, para comprobar si la delegación de dominio se ha efectuado correctamente, consultamos el registro del inicio de autoridad (SOA), el registro SOA se ha creado automáticamente al configurar la zona DNS de Azure, podemos hacerlo con una herramienta de terceros como nslookup. El registro SOA representa nuestro dominio y se convertirá en el punto de referencia cuando otros servidores DNS busquen nuestro dominio en Internet. Para comprobar la delegación, usa nslookup de la siguiente manera, nslookup -type=SOA ragasysweb.com:

• Para verificar que todo funciona, nos vamos a crear un registro tipo A y otro del tipo CNAME en la zona DNS pública que hemos creado:

• Aquí tenemos los registros creados:

• Y aquí vemos como ya están operativos:

Saludos y espero que os sea de ayuda

1. WINDOWS:

• Vamos a empezar bloqueando el acceso a youtube desde un equipo Windows, para ello, nos abrimos el fichero hosts ubicado en c:\windows\system32\drivers\etc con permisos de administrador y añadimos la línea 127.0.0.1 www.youtube.com:

• Ahora desde el equipo Windows al que le hemos modificado el fichero hosts, intentamos conectarnos desde un navegador a youtube y como podemos ver, no tenemos conexión:

2. LINUX:

• Vamos a bloquear el acceso a youtube desde un equipo Linux, para ello, nos abrimos el fichero hosts ubicado en /etc y añadimos la línea 0.0.1 www.youtube.com:

• Ahora desde el equipo Linux al que le hemos modificado el fichero hosts, intentamos conectarnos desde un navegador a youtube y como podemos ver, no tenemos conexión:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo instalar y configurar servidores DNS externos con Windows Server 2022, estos servidores DNS externos serán los servidores públicos DNS de nuestra infraestructura, dónde vamos a publicar nuestros servicios en Internet, vamos a desplegar un servidor primario y otro secundario.

Que vamos a necesitar:

• Máquina Windows Server 2022 con el Rol de DNS, este será el DNS primario
• Máquina Windows Server 2022 con el Rol de DNS, este será el DNS secundario
• Los dos servidores estarán en nuestra DMZ
• Proveedor ISP de DNS, dónde vamos a configurar nuestros propios Servidores DNS
• Un dominio DNS público contratado con un ISP, en nuestro caso, el dominio es ragasysweb.com
• En Firewall Fortigate, vamos a configurar un NAT Static y crear las reglas de acceso

• Como podemos ver, tenemos dos máquinas con Windows Server 2022, una para el DNS primario y otra para el DNS secundario:

• Lo primero que vamos a realizar será desplegar el rol de DNS en ambos servidores, lo vamos a ver en el servidor primario, ya que para el secundario será exactamente igual, para ello, nos vamos al Administrador del servidor > Administrar > Agregar 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 dnswinext01:

• Sobre Roles de servidor, marcamos la opción Servidor DNS:

• Agregamos las características:

• Clic en siguiente:

• En características se seleccionan por defecto, por lo que no tocamos nada y hacemos clic en siguiente:

• Nos muestra información sobre el Servidor DNS, clic en siguiente:

• Sobre Confirmación, iniciamos el despliegue del rol Servidor DNS, marcamos que reinicie automáticamente en caso necesario y clic sobre Instalar:

• Comienza el despliegue del rol de Servidor DNS:

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

• Una vez instalado el rol de Servidor DNS, sobre el Administrador del servidor > Herramientas > DNS accedemos a la consola de nuestro servidor DNS, que como podemos ver ya la tenemos lista para empezar con las configuraciones:

• Para el servidor DNS secundario realizamos la misma operación, y cómo podemos ver, aquí tenemos el rol de Servidor DNS desplegado sobre esta segunda máquina:

• Una vez que ya tenemos desplegado el rol de DNS en ambas máquinas, lo primero que vamos a realizar, es en nuestro firewall, realizar las configuraciones necesarias para el acceso externo a nuestros servidores DNS públicos, para ello hemos creado este NAT estático, que lo que hace es mapear nuestra IP externa 192.168.1.210 con la IP interna dónde se ubica el servidor DNS, en este caso el servidor DNS primario, mapeando también el puerto UDP 53 externo con el puerto UDP 53 interno, que es el que utiliza el servicio DNS, para el servidor DNS secundario tendríamos que hacer lo mismo, pero no disponemos ahora mismo de otra interface wan:

• Una vez creado el NAT estático, configuramos la siguiente política en nuestro Firewall, dónde le indicamos que desde cualquier origen externo y con destino al servicio DNS Externo de nuestra infraestructura, le vamos a permitir el acceso:

• Una vez que ya tenemos desplegado el rol de DNS en ambas máquinas y los accesos configurados en nuestro firewall, vamos a configurar la Zona de búsqueda directa en el servidor DNS primario, para ello, accedemos a Zonas de búsqueda directa > Zona nueva:

• Se nos abre este asistente para agregar la nueva zona de búsqueda directa, clic en siguiente:

• Le indicamos que el tipo de zona que queremos crear es una Zona principal, clic en siguiente:

• Le indicamos el nombre de zona, clic en siguiente:

• Creamos un nuevo archivo de zona, clic en siguiente:

• Le indicamos que no admita actualizaciones dinámicas, clic en siguiente:

• Nos muestra un resumen y finalizamos:

• Como podemos ver, ya tenemos la zona creada:

• Una vez creada la zona de búsqueda directa, nos creamos estos tres registros tipo A, dos de ellos serán, los servidores DNS externos que apuntan a mi IP pública y el otro registro será el www apuntando también a mi IP pública:

• Ahora accedemos a las propiedades de la zona:

• Y sobre la pestaña Servidores de nombres agregamos nuestros servidores DNS externos con su IP pública:

• Y así nos quedaría la Zona de búsqueda directa:

• También cambiamos el Inicio de autoridad (SOA) para que apunte a ns1, y nos creamos un registro tipo A (igual que la carpeta principal) que apunte a mi IP pública:

• Ahora nos vamos a crear una Zona de búsqueda inversa, para ello, accedemos a Zonas de búsqueda inversa > Zona nueva:

• Se nos abre este asistente para agregar la nueva zona de búsqueda inversa, clic en siguiente:

• Le indicamos que el tipo de zona que queremos crear es una Zona principal, clic en siguiente:

• Le indicamos que es una Zona de búsqueda inversa para IPv4, clic en siguiente:

• Configuramos el Id. de red, clic en siguiente:

• Creamos un nuevo archivo de zona, clic en siguiente:

• Le indicamos que no admita actualizaciones dinámicas, clic en siguiente:

• Nos muestra un resumen y finalizamos:

• Como podemos ver, ya tenemos la zona creada, configuramos el SOA y los NS tal y como lo hicimos para la zona de búsqueda directa:

• Una vez configuradas las zonas, vamos a acceder a nuestro proveedor ISP de DNS, y en nuestro dominio público (ragasysweb.com) vamos a configurar nuestros servidores DNS propios o personalizados con nuestra IP pública:

• Para terminar, vamos a configurar nuestro DNS secundario, pero antes de nada, debemos de habilitar la transferencia de zona en el DNS primario, para ello, en la zona de búsqueda directa accedemos a propiedades:

• Sobre la pestaña Transferencias de zona permitimos la transferencia de la zona al servidor DNS secundario:

• Sobre Notificar, le indicamos que notifique los cambios automáticamente al servidor DNS secundario:

• Para la Zona de búsqueda inversa hacemos lo mismo:

• Ahora vamos a configurar las zonas en el DNS secundario, para ello, accedemos a Zonas de búsqueda directa > Zona nueva:

• Se nos abre este asistente para agregar la nueva zona de búsqueda directa, clic en siguiente:

• Le indicamos que el tipo de zona que queremos crear es una Zona secundaria, clic en siguiente:

• Le indicamos el nombre de zona, clic en siguiente:

• Le indicamos el servidor DNS maestro desde el que se va a copiar la zona, clic en siguiente:

• Nos muestra un resumen y finalizamos:

• Como podemos ver, aquí tenemos la zona de búsqueda directa replicada desde el servidor primario:

• Para terminar, vamos a crear la Zona de búsqueda inversa, para ello accedemos a, Zonas de búsqueda inversa > Zona nueva:

• Se nos abre este asistente para agregar la nueva zona de búsqueda inversa, clic en siguiente:

• Le indicamos que el tipo de zona que queremos crear es una Zona secundaria, clic en siguiente:

• Le indicamos que es una Zona de búsqueda inversa para IPv4, clic en siguiente:

• Configuramos el Id. de red, clic en siguiente:

• Le indicamos el servidor DNS maestro desde el que se va a copiar la zona, clic en siguiente:

• Nos muestra un resumen y finalizamos:

• Como podemos ver, aquí tenemos la zona de búsqueda inversa replicada desde el servidor primario:

• Para verificar que todo funciona correctamente, desde cualquier equipo con conexión a Internet le vamos a hacer un ping a uno de los registros DNS de nuestro servidor, y cómo podemos ver, nos responde correctamente:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo configurar un certificado SSL para nuestro dominio personalizado y darle la capa de seguridad para las comunicaciones de nuestro App Service, así todas las peticiones que entran y salen de la web llevarán la información encriptada.

• Antes de comenzar, debemos de tener preparado el certificado SSL con el que vamos a encriptar la información entrante y saliente de nuestro App Service, en este ejemplo, para no comprar un certificado, lo he desplegado de mi propia entidad emisora de certificado que tengo montada sobre un Windows Server, en este post del blog podéis ver como se genera el certificado.
• Una vez generado el certificado, accedemos a App Services > miappserice > Dominios personalizados y sobre el dominio que hemos añadido damos al link Agregar enlace:

• Agregamos y cargamos el certificado PFX:

• Agregamos el enlace:

• Como podemos ver, ya tenemos el certificado SSL agregado al App Service con nuestro dominio personalizado:

• Sobre Configuración de TLS/SSL > Enlaces > Enlaces TLS/SSL podemos ver el enlace configurado:

• Sobre Configuración de TLS/SSL > Certificados de clave privada (.pfx) podemos ver los certificados agregados a nuestro sitio web:

• Si accedemos a App Services > miappserice > Introducción podemos ver que la URL ya no es la que nos pone por defecto Azure, es la URL de nuestro domino personalizado, que al tener certificado SSL configurado se sustituye por la otra:

• Si le damos a Examinar vemos el acceso por https a nuestro sitio web con el dominio personalizado y con el certificado que le hemos agregado, en este caso, el navegador me lo muestra como no seguro porque no confía en la entidad emisora del certificado, ya que esta entidad, al ser propia local de mi infraestructura no está dada de alta en ningún lado, cuando el certificado es comprado a una entidad de confianza, esto nos lo mostraría correctamente, pero bueno, para mostrar el ejemplo, nos puede valer:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo configurar un dominio personalizado para nuestro App Service utilizando registros tipo CNAME para subdominios.

• Accedemos a App Services > miappserice > Dominios personalizados > + Agregar dominio personalizado, agregamos nuestro subdominio y Validar:

• Una vez validado, vamos a seleccionar el Tipo de registro de nombre de host, que será del tipo CNAME, para verificar la Propiedad del dominio debemos crear un registro TXT y CNAME con nuestro proveedor DNS mediante la configuración que se indica:

• Desde nuestro proveedor DNS añadimos los registros del tipo TXT y CNAME a nuestro subdomino:

• Una vez creados los registros, volvemos a validar, esto se puede demorar hasta 48 horas, ya que se tienen que propagar los cambios en las entradas DNS:

• Como podemos ver, ya lo tenemos validado, ahora clicamos sobre Agregar domino personalizado:

• Y aquí lo tenemos añadido, vemos que el acceso no es seguro, ya que es por HTTP, en otro post veremos el tema de los certificados para añadir la capa SSL y hacer que nuestro App service sea seguro:

• Aquí vemos el acceso por http a nuestro sitio web con el dominio personalizado:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo configurar un dominio personalizado para nuestro App Service utilizando registros tipo A para dominio raíz.

• Si accedemos a App Services > miappserice > Dominios personalizados nos indica que para configurar un dominio personalizado tenemos que cambiar el Plan de App Service en el que se encuentra nuestro App Service:

• Para ello, accedemos a App Services > miappserice > Escalar verticalmente (Plan de App Service), como podemos ver sobre los planes de Desarrollo y prueba, estamos usando el plan F1 que es gratuito y no dispone de dominios personalizados:

• Debemos de escalar verticalmente nuestro Plan de App Service, por ejemplo, a un plan del tipo B1, que como podemos ver, tiene como características incluidas Dominios personalizados/SSL, Aplicar:

• Una vez escalado verticalmente el Plan de App Service, accedemos de nuevo a App Services > miappserice > Dominios personalizados > + Agregar dominio personalizado, agregamos nuestro dominio y Validar:

• Una vez validado, vamos a seleccionar el Tipo de registro de nombre de host, que será del tipo A, para verificar la Propiedad del dominio debemos crear un registro TXT y A con nuestro proveedor DNS mediante la configuración que se indica:

• Desde nuestro proveedor DNS añadimos los registros del tipo TXT y A:

• Una vez creados los registros, volvemos a validar, esto se puede demorar hasta 48 horas, ya que se tienen que propagar los cambios en las entradas DNS:

• Como podemos ver, ya lo tenemos validado, ahora clicamos sobre Agregar domino personalizado:

• Y aquí lo tenemos añadido, vemos que el acceso no es seguro, ya que es por HTTP, en otro post veremos el tema de los certificados para añadir la capa SSL y hacer que nuestro App service sea seguro:

• Aquí vemos el acceso por http a nuestro sitio web con el dominio personalizado:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como migrar un controlador de dominio con Windows Server 2019 a Windows Server 2022.

En este laboratorio, sólo tenemos un controlador de dominio con Windows Server 2019, el cual lo vamos a migrar a Windows Server 2022.

• Como podemos ver, tenemos un controlador de dominio en nuestra infraestructura con el sistema operativo MS Windows Server 2019 Standard:

• Los roles o funciones que tiene este servidor son los siguientes, “Servicios de dominio de Active Directory, DNS y DHCP”:

• Ahora debemos desplegar un nuevo server con el sistema operativo MS Windows Server 2022 Standard, lo actualizamos y lo configuramos como un controlador de dominio adicional:

• Empezamos la configuración de nuestro controlador de dominio adicional asignándole un nombre y una dirección IP estática, como DNS primario le asignamos la dirección IP del controlador de dominio principal y como DNS secundario no configuramos nada, más tarde, le configuraremos su propia dirección IP:

• Ahora agregamos este equipo 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:

• Ahora nos vamos a la consola de Usuarios y equipos de Active Directory en el controlador de dominio principal y cómo podemos ver, este equipo ya pertenece al dominio ragasys.net:

• Iniciamos sesión en DC02 (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 dc02:

• 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 y 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 el controlador de dominio principal:

• Sobre Rutas de acceso las dejamos por defecto:

• 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:

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

• Ahora accedemos a la configuración TCP/IPv4 de nuestro controlador de dominio recién desplegado y configuramos como DNS principal su propia dirección IP y como DNS secundario la dirección IP del controlador de dominio principal:

• Con el comando repadmin /showrepl, verificamos que nuestro nuevo controlador de dominio está replicando con el controlador de domino principal:

• 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 agregado un controlador de dominio adicional con sistema operativo MS Windows Server 2022, y por tanto, superior a MS Windows Server 2019, vamos a proceder a transferir los roles FSMO del controlador de dominio principal al adicional, así el nuevo controlador de dominio con el Server 2022 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 2019 (dc01):

• Ahora lo que vamos a realizar será transferir los cinco roles FSMO al controlador de dominio adicional (Windows Server 2022), convirtiéndolo así en el domain controller principal, para ello utilizaremos las siguientes herramientas.
• Para transferir los roles de PDC Emulator, RID Master e Infraestructure Master vamos a utilizar la herramienta Usuarios y equipos de Active Directory, que nos la abrimos en nuestro controlador de dominio adicional con MS Windows Server 2022:

• Primero vamos a transferir el RID Master:

• Segundo vamos transferir el PDC Emulator:

• En tercer lugar vamos a transferir el Infrastructure Master:

• En cuarto lugar, vamos a transferir el Domain Naming Master, para ello vamos a utilizar la herramienta Dominios y Confianzas Active Directory, que nos la abrimos en nuestro controlador de dominio adicional con MS Windows Server 2022:

• En quinto lugar, vamos a transferir el Schema Master, para ello vamos a utilizar la herramienta de consola Esquema de Active Directory, para poder utilizar esta herramienta tenemos que registrar la dll dll y personalizarnos una consola mmc, para ello, en nuestro controlador de dominio principal con MS Windows Server 2019 hacemos lo siguiente:

• Al intentar cambiarlo nos da el siguiente error, ya que como destino se encuentra el mismo controlador de dominio:

• Procedemos a cambiar el controlador de dominio de Active Directory:

• Como podemos ver ya tenemos como destino el controlador de dominio adicional:

• Como podemos ver, ya tenemos como Schema Master al controlador de dominio adicional (Windows server 2022):

• Una vez que hemos realizado la transferencia de los cinco roles FSMO entre los controladores de dominio, sobre cualquiera de ellos vamos a ejecutar el siguiente comando netdom query fsmo para verificar que la transferencia se ha realizado correctamente, y como podemos ver, todos los roles los tiene asignados el que estaba como controlador de dominio adicional, lo hemos convertido por tanto en el controlador de dominio principal:

• 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 ya podemos despromocionar como controlador de dominio el servidor con MS Windows Server 2019, 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:

• En las opciones de eliminación marcamos el check para “Quitar delegación de DNS”, introducimos las credenciales 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.
• Una vez que el equipo ha reiniciado verificamos que este servidor ya no es un controlador 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 el Controlador de dominio secundario ha 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 los checks, Servicios de dominio de Active Directory y Servidor DNS:

• Para los Servicios de dominio de Active Directory nos pide quitar las siguientes características:

• Para el Servidor DNS nos pide quitar las siguientes 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:

• El único Controlador de dominio de nuestra infraestructura sería el servidor con MS Windows Server 2022:

• 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, ya que Microsoft no ha sacado niveles funcionales nuevos desde Windows Server 2016:

• 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, pero como ya comentamos antes, Microsoft no ha sacado niveles funcionales nuevos desde Windows Server 2016:

• 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:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como configurar un dominio personalizado (utilizaremos nuestro dominio empresarial), en Azure Active Directory, y una vez que tengamos este dominio operativo, vamos a configurar el sufijo UPN (User Principal Name) en nuestro Active Directory de Windows Server, esto lo vamos a realizar ya que en un post posterior vamos a sincronizar nuestro Active Directory local con AzureAD, utilizando la herramienta Azure AD Connect.

• Para configurar nuestro dominio personalizado, desde Azure Active Directory, accedemos a Nombres de domino personalizados:

• Como podemos ver, nos muestra el dominio inicial que configuramos cuando desplegamos un nuevo inquilino (nombredenuestrempresa.onmicrosoft.com), para añadir un dominio personalizado, nos vamos a Agregar un dominio personalizado:

• Introducimos el nombre de nuestro dominio empresarial y que tenemos comprado a un proveedor de dominios en Internet, y agregamos el dominio:

• Una vez agregado nuestro dominio, nos va a mostrar, el tipo de registro TXT que tenemos que crear en nuestro DNS público (el que hemos comprado al proveedor de dominios en Internet), una vez que lo hemos registrado, damos a clic a Comprobar, así verifica Azure que este dominio pertenece a nosotros:

• Aquí vemos cómo se añade el registro TXT en nuestro DNS público:

• Una vez comprobado, podemos ver que ya tenemos nuestro dominio empresarial personalizado configurado y listo para usarlo:

• Ahora sobre Información general > Cambiar inquilino vamos a convertirlo en el inquilino predeterminado:

• Vamos a realizar una prueba creando un usuario nuevo, así vamos a ver como ya nos asigna el sufijo DNS de nuestro dominio personalizado, para ello, accedemos a Usuarios > Nuevo usuario:

• Configuramos los datos de la identidad y la contraseña, creamos el usuario:

• Aquí vemos el usuario creado con nuestro dominio personalizado:

• Con esto ya tendríamos nuestro dominio personalizado, configurado en Azure Active Directory, ahora este dominio lo vamos a agregar como sufijo UPN (User Principal Name) en nuestro Active Directory local (el de Windows Server de toda la vida), para ello, vamos a acceder a cualquiera de nuestros controladores de dominio y nos abrimos la consola de Dominios y confianzas de Active Directory:

• Sobre Dominios y confianzas de Active Directory nos abrimos las Propiedades:

• Y agregamos el sufijo UPN alternativo, que en este caso va a ser el dominio personalizado que hemos configurado en Azure Active Directory:

• Una vez agregado, guardamos los cambios:

• Ahora si nos abrimos la consola de Usuarios y equipos de Active Directory y accedemos a las propiedades de cualquiera de nuestros usuarios, podemos ver que podemos configurar el sufijo UPN local y el sufijo UPN alternativo para utilizarlo con Azure Active Directory, para que las cuentas de los usuarios se sincronicen con Azure Active Directory a través de Azure AD Connect (que lo vamos a ver más adelante) debemos de tener configurado como UPN principal en la cuenta del usuario, el dominio personalizado de Azure:

Saludos y espero que os sea de ayuda

En este post vamos a ver como instalar y configurar Pi-hole en nuestra infraestructura de Active Directory para bloquear la publicidad de Internet en todos los equipos de nuestra red.

La infraestructura utilizada es la siguiente:

• Lo primero que haremos será prepararnos una máquina Linux con Ubuntu Server 16.04 LTS y unirla a nuestro dominio Active Directory, en este link de este mismo blog podemos ver como unir una máquina Linux a un dominio Active Directory Windows, como podemos ver ya la tenemos unida al dominio:

• Una vez que tenemos nuestra máquina unida al dominio, vamos a ejecutar el siguiente comando para instalar Pi-hole, curl -sSL https://install.pi-hole.net | bash y poder así bloquear la publicidad de Internet en nuestros equipos:

• Comienza a preparar los paquetes necesarios para la instalación:

• En esta primera pantalla nos indica que nuestro sistema se va a convertir en un bloqueador de publicidad, le indicamos “Aceptar”:

• Aquí nos indica la URL, por si queremos realizar alguna donación al proyecto, “Aceptamos”:

• Ahora nos indica que nuestro servidor Pi-hole debe tener direccionamiento estático, ya se lo configuramos anteriormente, cuando unimos nuestra máquina al dominio Active Directory, “Aceptamos”:

• En esta opción elegimos los DNS públicos de Google, para que nuestro servidor Pi-hole resuelva los nombres en Internet:

• Seleccionamos todas las blacklists para bloquear los anuncios:

• Seleccionamos únicamente el protocolo IPv4, ya que en nuestra red sólo estamos trabajando con este protocolo:

• Confirmamos las configuraciones TCP/IP:

• El sistema nos indica que la dirección IP del servidor Pi-hole debe estar fuera del rango que tengamos configurado en nuestro DHCP, para no tener conflictos con el direccionamiento, “Aceptamos”:

• Habilitamos la administración por la interface web:

• Habilitamos la opción de Web server:

• Habilitamos los registros para los logs:

• Marcamos el check para mostrarlo todo:

• Comienza la instalación:

• Una vez finalizada la instalación, nos muestra el acceso por http y la password de acceso:

• Aquí nos indica que la instalación se ha realizado correctamente, y que podemos cambiar el password del usuario pihole:

• Procedemos a cambiar el password del usuario pihole, introduciendo el siguiente comando, pihole –a –p nuevopassword:

• Una vez que hemos finalizado la instalación, vamos a configurar el servidor Pi-hole como reenviador de nuestro servidor DNS:

• Con esto ya tenemos todo configurado para bloquear la publicidad de Internet en todos los equipos de nuestra infraestructura.

• Ahora accedemos a nuestro servidor Pi-hole a través de su interface web, y este es el aspecto que tendrá:

Saludos y espero que os sea de ayuda

En este post vamos a ver como migrar un controlador de dominio con Windows Server 2012 R2 a Windows Server 2016.

• Supongamos que tenemos un controlador de dominio en nuestra infraestructura con el sistema operativo MS Windows Server 2012 R2 Standard:

• Los roles o funciones que tiene este servidor son los siguientes, “Servicios de dominio de Active Directory, DNS y DHCP”:

• Nos instalamos un nuevo server con el sistema operativo MS Windows Server 2016 Standard, lo actualizamos y configuramos como un controlador de dominio adicional:

• Empezamos la configuración de nuestro controlador de dominio adicional asignándole un nombre y una dirección IP estática, como DNS primario le asignamos la dirección IP del controlador de dominio principal y como DNS secundario su propia dirección IP:

• Ahora agregamos este equipo 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:

• Ahora nos vamos a la consola de Usuarios y equipos de Active Directory en el controlador de dominio principal y cómo podemos ver, este equipo ya pertenece al dominio ragasys.net:

• Iniciamos sesión en DC01 (Servidor que hemos terminado de unir al dominio) como Administrador del dominio (Una buena práctica es cambiar el nombre del Administrador del dominio, nosotros lo dejaremos como Administrador, ya que para temas de laboratorios no implementaremos este tipo de seguridad):

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

• Hacemos clic en siguiente:

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

• Seleccionamos nuestro servidor dc01:

• Ahora agregamos 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 :

• Iniciamos el despliegue de la función, Servicios de dominio de Active Directory:

• Comienza el despliegue del Active Directory:

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

• Tras el reinicio vamos al Administrador del servidor y promovemos este servidor a controlador de dominio:

• Agregamos un controlador de dominio a un dominio ya existente, seleccionamos nuestro nombre de dominio y le proporcionamos las credenciales del Administrador del 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 (introducimos la misma contraseña que pusimos en el controlador de dominio principal):

• Esta opción 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 las opciones de replicación le decimos que replique desde el controlador de dominio principal:

• Las rutas de acceso las dejamos por defecto:

• Comienza a preparar el bosque y dominio:

• Revisamos las opciones e instalamos:

• 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 vamos a la consola de Usuarios y equipos de Active Directory en DC01, y podemos ver que este equipo ya está como un Domain Controller más de nuestra infraestructura:

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

• Una vez que tenemos agregado un controlador de dominio adicional con sistema operativo MS Windows Server 2016 y por lo tanto superior a MS Windows Server 2012 R2, vamos a proceder a transferir los roles FSMO del controlador de dominio principal al adicional, así el nuevo controlador de dominio con el Server 2016 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 2012 R2 (oficala):

• Ahora lo que vamos a realizar será transferir los cinco roles FSMO al controlador de dominio adicional (Windows Server 2016), convirtiéndolo así en el domain controller principal, para ello utilizaremos las siguientes herramientas.
• Para transferir los roles de PDC Emulator, RID Master e Infraestructure Master vamos a utilizar la herramienta Usuarios y equipos de Active Directory, que nos la abrimos en nuestro controlador de dominio adicional con MS Windows Server 2016:

• Primero vamos a transferir el RID Master:

• Segundo vamos transferir el PDC Emulator:

• En tercer lugar vamos a transferir el Infraestructure Master:

• En cuarto lugar vamos a transferir el Domain Naming Master, para ello vamos a utilizar la herramienta Dominios y Confianzas Active Directory, que nos la abrimos en nuestro controlador de dominio adicional con MS Windows Server 2016:

• En quinto lugar vamos a transferir el Schema Master, para ello vamos a utilizar la herramienta de consola Esquema de Active Directory, para poder utilizar esta herramienta tenemos que registrar la dll schmmgmt.dll y personalizarnos una consola mmc, para ello, en nuestro controlador de dominio principal con MS Windows Server 2012 R2 hacemos lo siguiente:

• Al intentar cambiarlo nos da el siguiente error, ya que como destino se encuentra el mismo controlador de dominio:

• Procedemos a cambiar el controlador de dominio de Active Directory:

• Como podemos ver ya tenemos como destino el controlador de dominio adicional:

• Como podemos ver ya tenemos como Schema Master al controlador de dominio adicional (Windows server 2016):

• Una vez que hemos realizado la transferencia de los cinco roles FSMO entre los controladores de dominio, sobre cualquiera de ellos vamos a ejecutar el siguiente comando “netdom query fsmo” para verificar que la transferencia se ha realizado correctamente, y como podemos ver, todos los roles los tiene asignados el que estaba como controlador de dominio adicional, lo hemos convertido por tanto en el controlador de dominio principal:

• Ahora ya podemos despromocionar como controlador de dominio el servidor con MS Windows Server 2012 R2, para ello vamos a seguir los pasos indicados en un post de este mismo blog, Eliminar controladores de dominios sobre MS Windows Server 2012 R2.

• 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.

• Como podemos ver ya tenemos despromocionado como controlador de dominio el server con MS Windows Server 2012 R2, ahora se quedaría como un equipo más miembro del dominio ragasys.net:

• El único Controlador de dominio de nuestra infraestructura sería el servidor con MS Windows Server 2016:

• 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 2012 R2, ya que el controlador de dominio anterior trabajaba sobre este sistema operativo, procedemos a elevarlo a Windows Server 2016:

• 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:

• 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:

• Con esto ya tendríamos migrado nuestro controlador de dominio de MS Windows Server 2012 R2 a MS Windows Server 2016.

Espero que os sea de ayuda