Sigo con mi migración de servidores de Windows server 2008 r2, esta vez voy a migrar el adconnect a otro servidor con un Windows server 2016.
El proceso es sencillo, pero si no lo has hecho nunca puede ser un poco lioso.
Un poco de culturilla general, Azure AD Connect es la herramienta de Microsoft diseñada para conectar una plataforma híbrida. Es decir, un conector, en este caso, de directorio activo local con el azure active directory, muy útil para usar autenticaciones con aplicaciones externas por medio de Azure.
Bien, una vez cogido en concepto de lo que hace vamos a migrar nuestro servidor viejo a uno nuevo.
Voy a hacer un post un poco largo, ya que quiero intentar explicarlo lo mejor posible.
Lo primero, vamos a instalar la aplicación adconnect en el servidor nuevo.
Según esta, le vamos a dar a install
Esto nos instala los requerimientos y los componentes necesarios.
Mientras va instalando. Vamos a ir al servidor viejo, y recogemos la información que nos va a pedir en nuestro servidor nuevo.
Como lo hacemos? pues vamos al servidor viejo y arrancamos la aplicación azure ad connect
Pulsamos en configure
Una vez aquí, vamos a ver que tipo de autenticación usa. Elegimos change user sign-in
Nos validamos con un usuario con privilegios
Y vemos que es un tipo hash con single sign-on
También, revisamos como esta configurada la autenticación de usuario. Esto lo vemos en la configuración general.
Vemos la configuración completa
En este caso es por upn.
También vamos a comprobar que OU sincronizan con azure.
Nos vamos a la aplicación synchronization services manager, elegimos connectors y elegimos el dominio local.
Una vez aquí, elegimos a configure directory partions y pulsamos containers.
Elegimos una cuenta de validación de dominio.
Vemos que OU están seleccionas, y cuales no.
Y por último, vamos a revisar las reglas especifica de sincronización. Estas reglas se pueden usar, por ejemplo, para que no sincronice usuario con mail distintos a nuestro dominio. Para que os hagáis una idea, es un filtrado mas especifico que el de OU, ya que lo hacemos por atributos de dc.
Una vez recogida la información del servidor. Volvemos al servidor nuevo, vamos a configurando tal y como lo tenemos en el viejo.
Lo primero que nos pregunta es la autenticación. La ponemos tal cual hemos visto en el otro servidor.
Después, nos va a pedir una validación con permisos correspondientes de administracion de azure, para registrar toda la configuración que le vamos a implantar.
Nos pide ahora, una cuenta con la que va a realizar la sincronización cada cierto tiempo de nuestro active directory local a azure
Si tenemos varios bosques elegiríamos cual se va a conectar, en mi caso solo tengo uno.
El tipo de validación que van a realizar los usuarios, hemos visto que era upn.
Como teníamos las OU que hemos apuntado de antes del servidor viejo, aquí las seleccionamos en el servidor nuevo.
En este caso nos pregunta, cómo deben identificarse los usuarios en los directorios locales podemos definir cómo se representan los usuarios de Azure AD.
Yo voy a elegir la opción de mail atribute, por explicarlo un poco más. Esta opción une a los usuarios y contactos si el atributo Mail tiene el mismo valor en bosques diferentes. Suele ser la que viene por defecto.
En este paso, vamos a sincronizar todos los usuarios y los dispositivos ya que nosotros lo tenemos así configurado.
En mi caso voy a usar la opción de hash que ya viene marcada. Y la opción de password writeback, que lo que hace es si cambias de contraseña desde azure la sincroniza con nuestro AD local, es decir, es un cambio bidireccional.
Dejamos la validación que nos ha pedido, ya que nos comenta que esta todo validado.
Le decimos que nos lo sincronice todo según termine de configurarlo, y que nos lo ponga el staging mode este servidor, esto significa que descarga de azure pero no lo sube. Mas a delante, haremos esto con nuestro servidor viejo.
Y nos va a configurar todo nuestro servidor adconnect nuevo con los datos nuevos.
Una vez terminado, nos comenta que advertencias podemos tener en un resumen de lo que él ha visto.
En este caso nos muestra algunas advertencias como, por ejemplo, activar la papelera del dc.
Si somos un poco impaciente, y vamos a arrancar cualquier aplicación de adconnect según acabamos de instalar en nuestro nuevo y flamante servidor, podemos encontrarnos con este error.
No os asustéis, es tan fácil como cerrar sesión de usuario y volvemos a entrar.
Revisamos el estado de la sincronización del nuevo servidor con la aplicación syncchronization services manager.
Y vemos que nos ha descargado un montón de objetos de DC a nuestra bbdd local.
Bien, es momento de cambiar al viejo servidor y ponerlo en modo staging mode. Con esto, como os he comentado, lo que hacemos es que solo descargue información, pero no la sube.
Para ello, vamos a la configuración de la aplicación de azure ad connect y en configuration staging mode.
Nos validamos y habilitamos en staging mode
Le decimos que los sincronice una vez mas.
Nos indica que el servidor está en staging mode y que se ha habilitado satisfactoriamente.
Con esto nos despedimos de nuestro viejo servidor, y vamos a deshabilitar el staging mode en el nuevo, para convertirlo en nuestro principal.
Mismos pasos que arriba, pero esta vez quitamos en check.
Es posible, que encontremos algún error de este tipo en la sincronización del nuevo servidor.
En mi caso concretamente hay 10 errores.
Son problemas de cambio de herencia que se ha cambiado en el dc local
Vamos a ir a solucionarlo. Entramos en nuestro active directory user and computer en las propiedades del usuario con problemas, pestaña security y pinchamos en avanzadas.
Ya habilitamos la herencia.
Nos dice que va a realizar unos cambios de permisos sobre ese usuario.
Ya estaría reparado con esto, al lanzar de nuevo la sincronización los errores habrán desaparecido.
Como pasos final, vamos a portal de azure, y pinchamos la opción de administración de dc.
Elegimos en el menú azure adconnect
Vamos a la opción Health and Analytics
Menu sync services
Seleccionamos el servidor y dentro vemos nuestros 2 servidores de conexión con azure.
En nuestro caso al dejarlo un rato, es más, yo lo he apagado para probar que todo es funcionado perfectamente con el nuevo, por eso vemos el error de sincronización.
Pinchamos sobre el viejo servidor y le damos a borrar.
Nos advierte que ya no va a sincronizar más con este servidor, etc… ponemos en el nombre del servidor y le decimos que borrar.
Y ya tenemos migrado nuestro servidor de adconnect a otro servidor
Espero que os sirva