Migrar adconnect a otro servidor

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

install_adconnect

Esto nos instala los requerimientos y los componentes necesarios.

install_adconnect

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

app_adconnect

Pulsamos en configure

app_adconnect

Una vez aquí, vamos a ver que tipo de autenticación usa. Elegimos change user sign-in

conf_adconnect

Nos validamos con un usuario con privilegios

validate_adconnect

Y vemos que es un tipo hash con single sign-on

validate__adconnect

También, revisamos como esta configurada la autenticación de usuario. Esto lo vemos en la configuración general.

view_conf_adconnect

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.

sync__adconnect

Una vez aquí, elegimos a configure directory partions y pulsamos containers.

sync_adconnect

Elegimos una cuenta de validación de dominio.

credential_adconnect

Vemos que OU están seleccionas, y cuales no.

adconnect_containers

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.

sync_rules

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.

user_sign-in

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.

connect_azure_ad

Nos pide ahora, una cuenta con la que va a realizar la sincronización cada cierto tiempo de nuestro active directory local a azure

ad_forest

Si tenemos varios bosques elegiríamos cual se va a conectar, en mi caso solo tengo uno.

connect_directories

El tipo de validación que van a realizar los usuarios, hemos visto que era upn.

azure_ad_sing-in_conf

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.

uniquely_identifitying

En este paso, vamos a sincronizar todos los usuarios y los dispositivos ya que nosotros lo tenemos así configurado.

filter_users

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.

optionals_features

Dejamos la validación que nos ha pedido, ya que nos comenta que esta todo validado.

enabled_sign-in

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.

ready_conf

Y nos va a configurar todo nuestro servidor adconnect nuevo con los datos nuevos.

configuring

Una vez terminado, nos comenta que advertencias podemos tener en un resumen de lo que él ha visto.

conf_complete

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.

error_adconnect

No os asustéis, es tan fácil como cerrar sesión de usuario y volvemos a entrar.

singout

Revisamos el estado de la sincronización del nuevo servidor con la aplicación syncchronization services manager.

sync_sercvice_manager

Y vemos que nos ha descargado un montón de objetos de DC a nuestra bbdd local.

import

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.

conf_staging_mode

Nos validamos y habilitamos en staging mode

enabled_staging_mode

Le decimos que los sincronice una vez mas.

start_sync

Nos indica que el servidor está en staging mode y que se ha habilitado satisfactoriamente.

conf_complete

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.

disabled_staging_mode

Es posible, que encontremos algún error de este tipo en la sincronización del nuevo servidor.

sync_service_manager

En mi caso concretamente hay 10 errores.

error_import

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.

security_tap

Ya habilitamos la herencia.

adv_security_tap

Nos dice que va a realizar unos cambios de permisos sobre ese usuario.

warning_permission

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.

azure_active_directory

Elegimos en el menú azure adconnect

azure_ad_connect

Vamos a la opción Health and Analytics

health_and_analitycs

Menu sync services

sync_services

Seleccionamos el servidor y dentro vemos nuestros 2 servidores de conexión con azure.

azure_ad_connects_servers

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.

delete_server

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.

azure_ad_connect_servers

Y ya tenemos migrado nuestro servidor de adconnect a otro servidor

Espero que os sirva

 

 

 

 

Deja un comentario