Cambiar dirección IP en Active Directory

Con las necesidades de teletrabajo que presentan actualmente muchas empresas, una de las necesidades básicas en los departamentos IT es el cambio de direcciones IP en el Active Directory . En este artículo, exponemos un ejemplo rápido de cómo cambiar la IP del Active Directory, aunque siempre es conveniente que lo realice un profesional externo.

Situación actual

Vivimos en un momento de cambios. Como todos hemos notado ya a estas alturas, la pandemia nos está empujando cada vez más al teletrabajo. Y esto está a su vez estimulando a los departamentos de IT de las empresas a hacer algunos cambios en las infratestructuras de los clientes para añadir un valor a lo que ya tenían; la disponibilidad desde el exterior a sus recursos.

Pondremos de ejemplo un inventando caso práctico. Supongamos que un cliente de ICM tiene un Active Directory en HA, con ambos nodos separados entre sí, pero ambos dentro de la infraestructura de ICM. Este montaje era suficiente hasta ahora para las necesidades de nuestro cliente. Pero con la llegada forzada del teletrabajo, a nuestro cliente le surge una duda. Ahora que, desde casa, debe conectarse a una VPN proporcionada por ICM para llegar a su infraestructura OnPremise; «¿qué pasaría con mis 100 trabajadores si la conectividad contra la infraestructura de ICM cae o, si cae un meteorito sobre los varios Datacenters que ICM utiliza para gestionar su infraestructura?» La respuesta es obvia, es un desastre. Tendremos a 100 trabajadores intentando autenticarse para acceder a sus recursos y que no podrán.

Mover dirección IP en Active Directory

Algunas veces, la seguridad de acceso a esos recursos se puede garantizar de otras maneras, pero es muy común que, si no se puede disponer de infraestructura extra, se opte por mover uno de los nodos de ese HA que comentábamos antes fuera de la infraestructura de ICM. Por ejemplo, podemos llevarnos un nodo del HA a una máquina virtual de Azure, instancia Ec2 de Aws, etc.

Cuando se opta por una opción así, nos enfrentamos a un movimiento que, en ocasiones, puede ser un tanto problemático. «Romper» una sincronización de Active Directory temporalmente para mover uno de los nodos. Cambiar la dirección IP del Active Directory y volver a poner los nodos en sincronía.

Aunque ese proceso puede ser muy sencillo o complejo según la cantidad de servicios que dependan de Active Directory y que no exista una «receta estandar», a continuación, vamos a daros algunas claves para intentar que este cambio os sea lo menos problemático posible.

Cómo cambiar dirección IP de Active Directory

Asumiremos que bajo el entorno Active Directory de nuestro cliente X están presentes los siguientes servicios o configuraciones:

 # Active Directory
 # DNS Server
 # DHCP Server
 # Sync NTP
 # Firewall

Ahora, finalmente, veremos una serie de tips que podemos seguir para asegurarnos que el movimiento de la dirección IP del Active Directory nos saldrá bien. Ojo, cada infraestructura es un mundo y como siempre, esto es una entrada genérica que podría no cubrir sus circunstancias al 100%. Pero veamos a grandes rasgos cómo podríamos intentar afinar el tiro en una migración de este tipo.

Lo primero que debemos hacer es definir algunas variables de trabajo, en nuestro caso son:

Claves básicas

 # Dominio=clientX.icm
 # Active Directory A: aad.clientx.icm
 # Active Direcetory B: bad.clientx.icm
 # Conectividad con Azure: en este ejercicio suponemos que existe una conectividad entre el DataCenter de ICM que alberga aad.clientx.icm y la red que contendrá en Azure bad.clientx.icm.
 # A tener en cuenta: la IP de la máquina que moveremos a Azure Directory cambiará su direccionamiento IP pero sigue teniendo visibilidad completa a nivel de Red.
 # Tarea: para garantizar la disponibilidad de la infraestructura AD y garantizar el acceso a los servicios autenticados de nuestro cliente desde el exterior, vamos a mover bad.clientx.icm a infraestructura de Microsoft Azure.

Pasos a seguir

Lo primero que necesitamos hacer es aislar el nodo que va a sufrir cambios. Cuando tenemos varios nodos en un Active Directory, estos pueden estar realizando diferentes tareas o roles, así que necesitamos saber qué roles de Active Directory está ejecutando cada nodo del HA. Para ello, ejecutaremos el siguiente comando desde un cmd -obviaré cualquier cosa que tenga que ver con permisos en esta entrada del blog-:

<code>
 $ netdom query /domain:clientx.icm fsmo
    Schema master               aad.clientx.icm
    Domain naming master        aad.clientx.icm
    PDC                         bad.clientx.icm
    RID pool manager            bad.clientx.icm
    Infrastructure master       bad.clientx.icm
      The command completed successfully.
</code>

En el entorno de nuestro cliente X vemos que hay 2 roles manejados por Azure Active Directory y 3 roles manejados por bad. Esto no nos interesa. Queremos aislar bad.clientx.icm para poder moverlo con garantías y para ello, debemos conseguir que no ejecute ningún rol de Active Directory.

Hay varias formas de hacer esto; con la interfaz de usuario, con scripts en PowerShell o desde un cmd con el comando ‘ntdsutil’. Elije la opción con la que te sientas más cómo y mueva todos los roles FSMO de Active Directory al nodo que NO vas a mover. En nuestro caso, aad.clientx.icm. Esto lo haríamos ejecutando estos comandos dentro de la aplicación ‘ntdsutil’ -obviaré algunos comandos básicos-:

<code>
 $ ntdsutil
   ….
   server connection: connect to server aad.clientx.icm
   …
   fsmo maintenance: transfer pdc
   fsmo maintenance: transfer rid master
   fsmo maintenance: transfer infrastructure master
</code>

Si volvemos a comprobar quién tiene cada rol con el comando ‘netdom query /domain:clientx.icm fsmo’ deberíamos ver que todos están manejados por aad.clientx.icm. Ahora estamos en el punto en el que sí podemos empezar a hacer algún movimiento.

Siguientes pasos

Lo primero que vamos a hacer es apagar bad.clientx.icm y, después de apagarla, la moveremos a Azure. En este artículo no vamos a entrar en cómo mover una instancia de máquina virtual a Azure. Hay varios métodos y algunas limitaciones por parte de Microsoft en cuanto a qué sistema operativo y qué versión podemos llevarnos a Azure y podría haber diferencias sustanciales en el proceso según el entorno de quien lo siga.

Así que, a efectos de este artículo, asumiremos a partir de aquí que la máquina ya está en Azure correctamente desplegada. Para quien esté muy interesado en conocer más sobre este proceso de migración, un buen punto de partida podría ser la lectura de este artículo.

En este punto en el que tenemos las dos máquinas encendidas, una OnPremise y la otra en Azure, podemos empezar a tocar configuraciones básicas tales como:

Firewall

Dependiendo del tipo de infraestructura, es posible que tengamos muchas reglas en los firewalls de Windows o firewalls físicos. Es necesario revisar todas esas reglas para adaptarlas al nuevo direccionamiento.

Está claro que la máquina que mantenemos en nuestra infraestructura, aad.clientx.icm tiene que dar acceso a la máquina que hemos movido a Azure -y viceversa-, bad.clientx.icm, así que debemos adaptar las reglas de firewall que tuviésemos habilitadas por tal de dar acceso desde/hacia la nueva IP.

Entre varios Active Directory, es necesario que se vean algunos directorios en remoto, como \\.\NETLOGON y \\.\SYSVOL. Por ello, hay que asegurarse de que ambas máquinas ven esos recursos en su partner.

Además, ambos servidores se hablarán por UDP:53 para las consultas DNS. Por ello, debemos estar seguros de que ambos servidores pueden lanzarse consultas entre ellos y que ninguna retorna un «timeout». Podéis probarlo, por ejemplo, lanzando nslookups cruzados entre los servers.

DNS Server

Hay que configurar los servicios DNS, prestando especial atención al apartado «Name Servers» en la configuración global de nuestro dominio clientx.icm que, casi con total seguridad contendrá actualmente la IP que tenía bad.clientx.icm antes del movimiento a Azure. También deberemos prestar especial atención a los registros «A» de nuestro dominio, asegurándonos de que ninguna apunta a la antigua IP de bad.clientx.icm. Si nos la encontramos en algún punto de la config de aad.clientx.icm, debemos retirar la IP obsoleta y añadir la nueva IP del servidor bad.clientx.icm en Azure.

DHCP Server

Si utilizamos un servidor DHCP para asignar IPs a máquinas que se conectan a la red, como, por ejemplo, dentro de un entorno VDI, es bastante común que configuremos en el servidor DHCP las direcciones IP que se inyectarán a los clientes como IPs de DNS. Si este es nuestro caso, debemos estar seguros de que las IPs que se inyectan para configurar el cliente DNS de cada máquina cliente son las IPs correctas de aad.clientx.icm y bad.clientx.icm en su nueva ubicación.

Sync NTP

Si hemos configurado aad.clientx.icm o bad.clientx.icm para actualizar su reloj interno a partir de peticiones NTP a su partner, debemos asegurarnos de que no haya ningún problema a nivel de Networking . Volvemos a tener que revisar los firewalls y debemos también saber cómo se configuró el servicio ya que, si se hizo utilizando la IP de bad.clientx.icm, posiblemente tengamos problemas ya que esta cambió.

Para conocer cómo tenemos configurado el servicio NTP, deberíamos ejecutar en ambos servers el siguiente comando:

<code>
w32tm /query /status
</code>

Simplemente en este punto, estar seguros de que la configuración que aparezca continúe siendo válida después del movimiento y que se adapte a las IPs/nombres de host del nuevo entorno. Si debemos reconfigurar NTP o no lo teníamos y queremos implementarlo un buen punto de partida sería la lectura de esta entrada en la Wiki de Microsoft.

Tened en cuenta que dos Active Directory geográficamente separados pueden desincronizarse fácilmente en un periodo de tiempo relativamente corto.  Y que, llegado a un punto de desviación temporal alta, empezaremos a ver errores de sincronización en el visor de eventos. Así que es muy importante mantener en sincronía horaria los Active Directory de nuestra infraestructura.

Limpiemos cachés

Normalmente, cuando hacemos cambios en un servidor DNS, nos encontramos con que hay decenas de servicios que tienen cacheadas las IPs de servicio y que ya no van a preguntarle al DNS durante un tiempo para un nombre de host dado.

Como entendemos que no estáis haciendo esto en producción por primera vez, sino que se trata de un entorno de laboratorio, os diría que reiniciéis aad.clientx.icm con tal de que todos los servicios arranquen de nuevo teniendo el DNS toda su información corregida. Igualmente, reiniciaría bad.clientx.icm para asegurarnos de exactamente lo mismo. Podría ser que hubiera servicios funcionando aparentemente bien pero que, si actualizasen su listado interno de Host<->Ip empezarían a fallar y, como no queremos encontrarnos eso en un momento inesperado, es mejor forzar esos cambios ya.

En un entorno de producción os recomendaría no reiniciar máquinas completas, sino más bien servicios concretos como «DNS Server», «DNS client», «Server», «DFS», «DHCP Server» y todos los relacionados con Active Directory.

Para comprobar que los DNS tienen registrada la información de nuestros Active Directory correcta, podemos lanzar el siguiente comando:

<code>
 nslookup -type=all _ldap._tcp.dc._msdcs.clientx.icm
</code>

Este comando nos retornará la lista de Hosts e IPs que están dados de alta en nuestro Active Directory y en sus DNS’s. Debemos comprobar que la información retornada por ese comando es válida en aad.clientx.icm y en bad.clientx.icm y realizar los cambios pertinentes en nuestros DNS’s si no lo fuese.

Roles

Ahora que las máquinas se han reiniciado, se ven a nivel de red y tienen todas las configuraciones correctas -para comprobar esto, podéis mirar el visor de eventos para garantizar que no está habiendo errores en la sincronía- es el momento de devolver los roles que originalmente albergaba cada nodo a quién corresponda. Podemos hacerlo como vimos antes con ntdsutil:

<code>
 $ ntdsutil
   ….
server connection: connect to server bad.clientx.icm
   …
fsmo maintenance: transfer pdc
   fsmo maintenance: transfer rid master
   fsmo maintenance: transfer infrastructure master
</code>

Ahora, una consulta de los roles FSMO debería decirnos que están exactamente igual que al principio:

<code>
 $ netdom query /domain:clientx.icm fsmo
    Schema master               aad.clientx.icm
    Domain naming master        aad.clientx.icm
    PDC                         bad.clientx.icm
    RID pool manager            bad.clientx.icm
   Infrastructure master       bad.clientx.icm
      The command completed successfully.
</code>

Como os imaginaréis -y lo he comentado previamente- cada entorno es un mundo y el proceso que a un entorno le va bien podría ser insuficiente o demasiado si lo aplicamos a otro entorno. Por eso creemos que es importante analizar bien el entorno que vamos a modificar para intentar predecir qué errores causaremos en cada paso o movimiento.

En esta entrada del blog os hemos intentado dar una visión global del problema con un ejemplo que podría ser perfectamente real y que espero me haya ayudado a hacer visible o comprensible un caso real en el que podríamos necesitar modificar la IP de un Active Directory y qué pasos, consecuencias y problemas podemos encontrarnos.