none
Planteamiento complicado Directorio Activo 2008R2 RRS feed

  • Pregunta

  • Muy buenas a todos,

    tengo un entorno de directorio activo nativo Windows 2008R2 con 4 Sites y con un único dominio. En cada site existen 2 DCs. Actualmente existen muchos problemas de replicación, hay muchos firewalls de por medio y además muchas personas meten mano en la configuración.

    Me han pedido que realice una valoración de mantener cada Site de manera independiente, es decir, que no exista replicación entre Sites, que cada Site actuase como si fuera un único dominio de directorio activo, autenticando usuarios, autenticando herramientas y resolviendo nombres de equipos y direcciones de Internet.

    Ya sé que es una locura pero me han pedido valoración en cuanto a tareas a realizar y sobretodo si es viable. A priori, a pesar de ser una chapuza de las grandes, existen 3 Sites que están funcionando en la actualidad sin replicación de ningún tipo pero autenticando usuarios y herramientas de ese Site, con lo cual, para ellos les vale. He de decir que existen herramientas que utilizan la autenticación y no quieren que se reconfiguren, por lo que crear subdominios o algo relacionado que tengan que reconfigurarse los puestos de usuarios o las herramienas es inviable.

    LLevo muchos años gestinando y diseñando despliegues de directorio activo (desde NT 4.0) y lo cierto es que nunca me había encontrado con una necesidad similar. Es el mundo al revés...

    Desearía que me ayudarais a identificar los problemas que podría encontrarme en una situación de estas características.

    Para empezar, lo primero que he pensado es que tendría que solventar los problemas de replicación, kerberos y demás, ya que hay DCs que ni siquiera replican dentro del mismo Site.

    ¿Que problemas se os ocurren que podrían surgir una vez que tuviéramos cada Site aislado? en principio solo se van a crear grupos globales, cuentas de usuario y entradas en el dns.

    Gracias!!

    lunes, 3 de marzo de 2014 16:36

Respuestas

  • Hola nuevamente Manuel, unas consideraciones para que las tengas en cuenta:

    - No podrás tener dos dominios con el mismo nombre en la misma red, te recomiendo formatear alguno de los dos DC, reinstalar y SIN conectar a la red crear el dominio, apagar el segundo DC, hacer que los clientes apunten al DC recien instalado y posteriormente formatear el segundo DC.

    - Sería posible una migración si utilizaras nombres de dominio diferentes, como no es posible tendrías que recrearlos manualmente.

    - Tendrás que sacar y volver a meter al dominio cada equipo manualmente.

    - En cuanto a los registros DNS no debería haber mayor complicación.

    - Un paso adicional para cuando desees trabajar en el site con el DC que contiene los FSMO roles, el primer DC que vuelvas a instalar deberá hacer SEIZE de los roles.

    - Recuerda que una vez hecho esto tus sitios ya no deberán tener ningún tipo de conexión por compartir el mismo nombre de dominio.

    Saludos.


    EL CONTENIDO ES PROVISTO "COMO ESTA" SIN GARANTIA DE NINGUN TIPO, YA SEA EXPLICITA O IMPLICITA& Gracias TechNet Community Support Por favor recuerda "Marcar como respuesta" las respuestas que resolvieron tu problema. Es una manera común de reconocer a quienes te ayudaron, y hace más fácil para otros visitantes el encontrar una solución después.

    • Marcado como respuesta Uriel Almendra lunes, 10 de marzo de 2014 16:23
    jueves, 6 de marzo de 2014 19:11

Todas las respuestas

  • Eso es como tener una bomba y encender la mecha a esperar a ver qué pasa.

    Aunque en principio te pueda parecer que cada sitio funciona porque los usuarios se validan, al cabo de un tiempo comenzarán los problemas. Por poner un ejemplo, en el dominio hay un rol maestro que es el RID master, y sólo un DC del dominio, que estará en uno de los sitios, tiene ese rol. Este DC asigna un pool de RIDs (Relative Identifiers) a cada DC del dominio, que éstos usan cada vez que se crea un objeto de cualquier tipo (y no solo cuentas de usuario). Cuando a un DC se le van acabando los RIDs que le quedan en su pool le pide al RID master que le asigne un pool nuevo. En tu caso, si ese DC está en un sitio distinto al del RID master y se le termina el pool, simplemente ese DC ya no podrá crear objetos de ningún tipo. Cuando ocurriera en los dos DCs de ese sitio, imagina las consecuencias.

    Evidentemente este problema no te lo vas a encontrar hasta que no pase un tiempo, pero podría llegar a ocurrir. Del resto de roles, por ejemplo el schema master sólo te influiría en caso de que en uno de los sitios quisieras instalar determinadas aplicaciones servidor que requieren añadir clases al esquema, o necesites actualizar un DC a una versión de sistema operativo posterior. Si no va a ser el caso, lo podrías obviar. En tu escenario, el maestro de nombres de dominio y el maestro de infraestructura no los vas a usar, y por último, el emulador pdc es conveniente que sea accesible desde todos los sitios, pero se puede vivir sin él.

    Mi consejo, resuelve los problemas de sincronización. En gran parte de los casos se deben a una configuración de red incorrecta en los DCs, por ejemplo por no haber configurado bien los servidores DNS de cada DC. Un primer paso para resolver los problemas de sincronización está en configurar todos los DCs para que tengan como servidor DNS sólo la IP del DC que sea emulador PDC, forzar el registro en DNS de los DCs y esperar que repliquen el AD, que incluirá la zona del dominio (más que aconsejable esto) antes de reponer la configuración DNS. Asegúrate también de que la zona DNS del emulador PDC no tiene registros obsoletos que puedan interferir negativamente, y si es así, los borras a mano, que los correctos ya se repondrán.

    Para forzar el registro en DNS de los DCs, en su configuración ip marca la casilla que hay en la pestaña DNS para ello y escribes la zona del dominio en el cuadro de edición (esto no sería estrictamente necesario, pero no cuesta nada hacerlo). Una vez hecho, abre una ventana de comando con elevación y teclea los siguientes comandos:

    IPCONFIG /REGISTERDNS

    NET STOP NETLOGON

    NET START NETLOGON

    Y tras ello espera un tiempo prudencial para comprobar si la replicación entre sitios y entre DCs del mismo sitio vuelve a funcionar. De continuar los problemas, comprueba en Sitios y Servicios de AD si todos los DCs tienen la información de correcta en cuanto a los enlaces de réplica, y si ves que en algún DC falta alguno lo creas a mano, o también si sobra alguno, lo borras (caso de algún DC antiguo que se hubiera eliminado incorrectamente).

    Ya dirás como te ha ido tras intentar todo esto.


    Saludos
    José Antonio Quílez
    Mi Blog

    • Propuesto como respuesta Uriel Almendra lunes, 3 de marzo de 2014 18:35
    lunes, 3 de marzo de 2014 18:24
    Moderador
  • Muchas gracias José Antonio por tu respuesta, la verdad es que no tenía idea de como empezar a ver todo ese problema, esperemos que le ayuden tus comentarios.

    Saludos.


    EL CONTENIDO ES PROVISTO "COMO ESTA" SIN GARANTIA DE NINGUN TIPO, YA SEA EXPLICITA O IMPLICITA& Gracias TechNet Community Support Por favor recuerda "Marcar como respuesta" las respuestas que resolvieron tu problema. Es una manera común de reconocer a quienes te ayudaron, y hace más fácil para otros visitantes el encontrar una solución después.

    lunes, 3 de marzo de 2014 18:35
  • De nada Uriel. La verdad es que los problemas de replicación están relacionados generalmente con configuraciones incorrectas. He visto hasta DCs que tienen por DNS principal un servidor DNS de internet (no digo que sea su caso). Un buen repaso a la configuración tcpip suele hacer milagros.

    Saludos


    Saludos
    José Antonio Quílez
    Mi Blog

    lunes, 3 de marzo de 2014 19:10
    Moderador
  • Hola Jose Antonio y resto de compañeros,

    ante todo agradecer tu tiempo en responderme. Voy a aportar más datos. Los 2 DCs que existen en cada Site tienen el rol de CG y DNS con zona integrada en Directorio Activo. Como cliente DNS, cada DC, en la configuración tcp/ip tiene, como indicas, marcada la opción de registrarse en el dns y además agregado el sufijo de búsqueda. Supongamos que la nomenclatura es DC1-SITE1 y DC2-SITE1, pues bien, como dns primario, tanto equipos como servidores como los mismos DCs, tienen a DC1-SITE1 y DC2-SITE1. Después, solo dentro del servicio DNS de DC1 tiene configurados 2 forwarders públicos para también resolver direcciones de Internet.

    Me faltó explicar un detalle muy muy importante que omití en mi mensaje original y por lo que digo que el tema DNS es el menor de mis problemas. Resulta que el DC donde tengo todos los roles FSMO, digamos DC1-SITE2, los admins del Site vieron que había problemas de autenticación y después de comprobar los servicios de netlogon y demás, se les ocurrió recuperar un backup (snapshot) "a cholón" de dicho servidor. No realizaron una recuperación del System State Data como deberían haber hecho. La cuestión es que como resultado todo el tema de autenticación kerberos se fue al carajo. Ahora en variosDCs de otros Sites aparece "Access is Denied", "******* WARNING: KCC could not add this REPLICA LINK due to error" y "The target principal name is incorrect". Comprobé con repadmin /options y ví que la sincronización INBOUND y OUTBOUND estaba deshabilitada...lo modifiqué.

    Con lo cual, ahora, entre otras cosas, es necesario purgar los tickets kerberos y resetear la cuenta del DC parando el servicio y comunicando con el PDC Emulator si no me equivoco. Además he podido comprobar que el servicio DFS (puerto 5722) del DC1-SITE2 (el que tiene los 5 roles) está parado, con lo que entiendo que el recurso SYSVOL no está replicando correctamente.

    Por otro lado, también he podido comprobar que en los flujos de cada fw local de cada Site, a pesar de estar abierto el puerto RPC 135 TCP no están abiertos los puertos efímeros que necesita RPC 135 para poder asignar a cada solicitud de servicio por parte de un cliente. Necesitaría que me aclararais si los FW son Statefull Inspection necesitan abrir este pool de puertos o directamente desde el puerto RPC 135 sabe redirigirlos y los mantiene en su tabla de estado. El AD es Windows 2008R2 nativo y los puertos efímeros que usa para RPC son del 49152 tcp y udp al 16384 tcp y udp. Ya se que se puede redirigir a un solo puerto o disminuir el pool de puertos, pero de momento no he querido modificar nada. La cuestión es que dicho pool no está abierto. No estoy seguro si eso influye o no en la situación actual. No consigo identificar el motivo del por qué comenzó todo a dejar de sincronizar.



    Un saludo y gracias por vuestros comentarios,

    Manuel


    martes, 4 de marzo de 2014 11:58
  • Hola Manuel, bastante complicado tu escenario, empecemos un sencillo plan de acción y sobre cada punto podemos ahondar más adelante:

    - Asignar al personal autorizado para hacer cambios en el dominio que se creará.

    - Revisar tu red en cada sitio (Cableado, IPs, ping) hasta que los equipos de cada site se puedan ver internamente.

    - Restablecer la conexión al site donde esta el DC con los FSMO Roles.

    - Revisar detalladamente el problema de Kerberos (esto requerirá un poco más de trabajo)

    - Y lo principal de la situación, sugiero que crees un bosque nuevo y conviertas cada site en un dominio.

    Comentanos tus avances para seguir viendo el caso.

    Saludos.


    EL CONTENIDO ES PROVISTO "COMO ESTA" SIN GARANTIA DE NINGUN TIPO, YA SEA EXPLICITA O IMPLICITA& Gracias TechNet Community Support Por favor recuerda "Marcar como respuesta" las respuestas que resolvieron tu problema. Es una manera común de reconocer a quienes te ayudaron, y hace más fácil para otros visitantes el encontrar una solución después.

    jueves, 6 de marzo de 2014 0:12
  • Muy buenas de nuevo,

    esta mañana he tenido una reunión y he presentado un plan de acción para resolver los problemas de sincronización entre sites. Dicha planificación se va bastante en el tiempo. Por lo que me han pedido que valorara la opción de que existiera el mismo dominio en cada Site (país) y que funcionara de manera independiente, por tanto no habría sincronización entre Sites. Es decir, si ahora el dominio es por ejemplo empresa.es, dicho dominio plano está en varios sites, lo que quieren es mantener el nombre del dominio en cada site pero formando un nuevo dominio con los DCs locales, de tal manera que si tengo 4 sites, tener 4 dominios, pero con el mismo nombre ya que no tendrán interacción entre ellos.

    Realmente es la opción más "limpia" que veo, ya que la gestión global del dominio como tal, no quiere hacerse cargo ningún país, por tanto la mejor solución es que tenga cada uno su propio dominio, el requisito es que no se puede modificar el nombre ya que dependen de ello herramientas desplegadas al igual que puestos  de trabajo, autenticación centralizada con ACS redirijida al dominio, etc, etc.

    Ahora mismo tengo un site con 2 DCs por país que son parte del dominio empresa.es. Ya que no dispongo de recursos adicionales, he pensado reinstalar uno de los DCs y crear en éste un nuevo dominio con el mismo nombre de dominio empresa.es.

    Lo que me preocupa y no estoy seguro en cuanto a consideraciones es:

    - Tener un conflicto de algún tipo teniendo 2 nombres de dominio igual en la misma lan y se cortase el servicio en producción del DC en producción.  No se si me explico.

    - La migración de usuarios (son pocos) se puede realizar manualmente del dominio origen al dominio nuevo.

    - La migración de cuentas de equipo al nuevo dominio. Esto me preocupa bastante.Desconozco si hay alguna manera de "engañar" al puesto de usuario para no tener que sacarlo del dominio antiguo y meterlo en el nuevo, siendo el mismo nombre. Desearía evitar que me creara un nuevo perfil y hubiera que volver a configurar las herramientas de cada usuario. Necesito saber si es posible.

    - Registros en el dns. Se recrearían de manera manual.

    Básicamente el directorio activo se está usando para autenticación de usuarios y herramientas, nada para acceder a recursos compartidos ni impresoras.

    ¿Que os parece la idea? Yo pienso que podría solucionar los problemas de sincronización, pero por problemas logísticos, de recursos y organizativos prefieren tomar esa solución, que aunque más drásticas, al final se consigue que los países sean  independientes siempre y cuando dicha solución sea viable.

    La cuestión es que tengo que realizar pruebas en maqueta para ver si es viable o no tener 2 dominios en paralelo, y si se os ocurre alguna forma sencilla de pasar los objetos ya creados en el dominio "roto" y recrearlos en el nuevo, en cada dominio de cada país.

    Gracias de nuevo por la ayuda.

    Un saludo,

    Manuel


    jueves, 6 de marzo de 2014 11:18
  • Hola nuevamente Manuel, unas consideraciones para que las tengas en cuenta:

    - No podrás tener dos dominios con el mismo nombre en la misma red, te recomiendo formatear alguno de los dos DC, reinstalar y SIN conectar a la red crear el dominio, apagar el segundo DC, hacer que los clientes apunten al DC recien instalado y posteriormente formatear el segundo DC.

    - Sería posible una migración si utilizaras nombres de dominio diferentes, como no es posible tendrías que recrearlos manualmente.

    - Tendrás que sacar y volver a meter al dominio cada equipo manualmente.

    - En cuanto a los registros DNS no debería haber mayor complicación.

    - Un paso adicional para cuando desees trabajar en el site con el DC que contiene los FSMO roles, el primer DC que vuelvas a instalar deberá hacer SEIZE de los roles.

    - Recuerda que una vez hecho esto tus sitios ya no deberán tener ningún tipo de conexión por compartir el mismo nombre de dominio.

    Saludos.


    EL CONTENIDO ES PROVISTO "COMO ESTA" SIN GARANTIA DE NINGUN TIPO, YA SEA EXPLICITA O IMPLICITA& Gracias TechNet Community Support Por favor recuerda "Marcar como respuesta" las respuestas que resolvieron tu problema. Es una manera común de reconocer a quienes te ayudaron, y hace más fácil para otros visitantes el encontrar una solución después.

    • Marcado como respuesta Uriel Almendra lunes, 10 de marzo de 2014 16:23
    jueves, 6 de marzo de 2014 19:11
  • Hola Uriel, gracias por la respuesta.

    En principio he valorado las opciones y por la que opto es de instalar de nuevo el AD con el mismo nombre y recreando los objetos que ya existían, por lo que estoy con una maqueta haciendo pruebas. De momento esto es lo que he realizado:

    1º. Instalar 4 equipos: SERVER1, SERVER2, CLI1 y CLI2

    2º. Promocionar SERVER1 a DC y crear el dominio empresa.es

    3º. Introducir el equipo CLI1 al dominio empresa.es

    4º. Promocionar SERVER2 a DC y crear un nuevo dominio empresa.es. Como bien decías hay conflicto de nombre netbios. He puesto un sniffer y todo es tráfico NBNAME (broadcast netbios UDP 137). Lo primero que hace es preguntar si existe ese nombre y si no existe se registra con él en la red. Al existir dicho nombre no puedo optar por el mismo nombre de dominio.

    5º. Apago SERVER1 y vuelvo a promocionar SERVER2. Esta vez si que me permite instalar el mismo nombre de dominio empresa.es.

    6º. Recreo en SERVER2 la cuenta de equipo de CLI1 y el usuario del dominio que venía usando para el dominio en SERVER1.

    7º. Reconfiguro el dns en CLI1 para que ahora apunte a SERVER2 para validarse. Aparecen errores del canal de confianza que estaba establecido. Quiero conseguir no tener que sacar el equipo del dominio y volver a meterlo en el nuevo, porque me creará un nuevo perfil, y lo que quiero es evitar tener que reconfigurar equipo por equipo, además de programas, etc.

    Estoy probando con Reset-ComputerMachinePassword -Server <Name of any domain controller> -Credential <domain admin account> pero no funciona correctamente. No quiero usar NETDOM porque solo es para servidores, y en mi caso lo que me afecta son equipos de operadores, esto es Windows 7.

    He entrado en las propiedades de la cuenta CLI1 en SERVER2 y en la pestaña "Attribute Editor" he modificado los campos dNSHostName y servicePrincipalName con los datos que tenía en SERVER1, pero no he conseguido que me valide la cuenta del equipo. 

    La siguiente cosa que he probado es resetear el nombre del equipo en AD Users and Computers, reiniciado nuevamente CLI1 pero tampoco.

    ¿Se os ocurre alguna forma de resetear el canal seguro sin tener que sacar el equipo del dominio)

    Otra cosa, no entiendo muy bien el paso que comentas de hacer SEIZE de los roles, ya que según tengo entendido esto es cuando el DC está offline y no es posible recuperarlo, pero en mi caso yo tengo el nuevo DC con los roles, por lo que una vez tenga instalado SERVER2 con el nuevo dominio, será él quien tenga los roles FSMO. Lo que tendré que hacer a posteriori, una vez que resintale SERVER1 y empiece a pertenecer al nuevo dominio empresa.es será volver a pasar los roles de SERVER2 a SERVER1.

    En conclusión, veo más factible reinstalar el dominio con el mismo nombre en cada país que resolver los problemas de sincronización. La cuestión es como hacerlo bien y tener el menor impacto posible en las herramientas y sobretodo en los equipos de operación. Si se os ocurre como hacerlo de la mejor forma posible os lo agradeceré enormemente.

    Un saludo,

    Manuel

    lunes, 10 de marzo de 2014 16:49
  • A propósito...el error por el cual no puedo resetear la cuenta de equipo es que no me admite la variable     "-Credential"

    PS C:\Users\Administrator> Reset-ComputerMachinePassword -Server SERVER2 -Credential empresa\administrator

    Reset-ComputerMachinePassword : A parameter cannot be found that matches parameter name 'Credential'.
    At line:1 char:65
    + Reset-ComputerMachinePassword -Server SERVER2 -Credential <<<<  empresa\administrator
        + CategoryInfo          : InvalidArgument: (:) [Reset-ComputerMachinePassword], ParameterBindingException
        + FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.PowerShell.Commands.ResetComputerMachinePasswordCommand

    lunes, 10 de marzo de 2014 16:56