Active Directory
Con todos los catch subredes en Active Directory
John Policelli
En resumen:
- El localizador de controlador de dominio
- La topología radial de concentradores
- Implementación de una subred de catch-todos
Contenido
Cómo los clientes buscar controladores de dominio
El problema
La subred de captura de todos los
Ajustar hacia arriba
En un mundo ideal, los usuarios se dirigen al controlador de dominio adecuado (DC) para la autenticación de Active Directory. Sin embargo, esto no es necesariamente el caso en la mayoría de las organizaciones debido a la información de subred IP no correctamente está definida en Active Directory. Como resultado, un número de usuarios se autentiquen en un controlador de dominio arbitrario, lo que no es óptimo para la autenticación de Active Directory.
En este artículo, ofrecen una solución posible para garantizar que los usuarios ubicar el DC adecuado para la autenticación cuando información de subred IP no está totalmente definido en Active Directory.
Cómo los clientes buscar controladores de dominio
Cuando un equipo intenta encontrar un controlador de dominio, se inicia un proceso denominado el localizador de controlador de dominio (localizador) por lo que puede se encuentra el controlador de dominio de Active Directory adecuado. Localizador utiliza la información que se almacena en Active Directory y DNS para intentar encontrar un controlador de dominio con las funciones deseadas y que se encuentra en un sitio más próximo al cliente.
El localizador utiliza información que está definido en el contenedor de configuración en el dominio raíz del bosque, que se replica en cada controlador de dominio del bosque. Objetos de sitio, los objetos de subred y objetos de servidor de controlador de dominio son todos los imprescindible para el localizador buscar el controlador de dominio más cercano de un equipo cliente. Objetos de sitio se utilizan para representar sitios de Active Directory. Los objetos de subred se utilizan para representar los segmentos de la dirección IP y están asociados con el objeto de sitio adecuado. Objetos de servidor de controlador de dominio se utilizan para representar los controladores de dominio y se asocian con un objeto de sitio.
Los controladores de dominio de Active Directory registran registros de DNS que especifique el sitio en el que reside el controlador de dominio. El número de registros DNS que cada controlador de dominio registra depende de las funciones que tiene el controlador de dominio. Por ejemplo, un controlador de dominio que es un servidor de catálogo global registran un registro de DNS adicional que anuncia sí mismo como. De forma similar, un controlador de dominio que desempeñe una función de maestro de operaciones registran un registro DNS que anuncia a sí mismo como this.
El proceso en un equipo cliente encontrar un controlador de dominio es el siguiente:
- El localizador se inicia en el equipo cliente como una llamada de procedimiento remoto (RPC) al servicio de inicio de sesión de red local.
- El cliente recopila la información que es necesario para seleccionar un controlador de dominio y pasa la información en el servicio de inicio de sesión de red.
- El servicio de inicio de sesión de red en el equipo cliente utiliza la información recopilada para crear una consulta para enviar a DNS para identificar el controlador de dominio correspondiente.
- El servicio de inicio de sesión de red en el equipo cliente envía un datagrama a los controladores de dominio descubiertos.
- El servicio de directorio intercepta la consulta y lo pasa al servicio de inicio de sesión de red en el controlador de dominio.
- El servicio de inicio de sesión de red en el controlador de dominio busca la dirección IP del cliente en su tabla asignación de subred para sitio por buscar el objeto de subred que mejor coincide con la dirección IP del cliente y, a continuación, devuelve la siguiente información al cliente: el nombre del sitio en la que el cliente se encuentra o el sitio que mejor coincida con la dirección IP del cliente; el nombre del sitio en el que el controlador de dominio actual se encuentra; y un bit que indica si se encuentra el controlador de dominio se encuentra en el sitio más próximo al cliente.
- El cliente inspecciona la información para determinar si debe intentar encontrar un controlador de dominio mejor. Se toma la decisión de manera: si el controlador de dominio devuelto está en el sitio más cercano, el cliente usa este controlador de dominio; si el cliente ha encontrado un controlador de dominio en el sitio en el que el controlador de dominio dice el cliente se encuentra, el cliente usa este controlador de dominio; si el controlador de dominio es no en el sitio más cercano, el cliente actualiza su información de sitio y envía una nueva consulta DNS encuentre un controlador de dominio nuevo en el sitio. Si la segunda consulta es correcta, se utiliza el nuevo controlador de dominio. Si la segunda consulta falla, se utiliza el controlador de dominio original.
- Si el dominio que consultar el cliente es el mismo que el dominio al que se une el equipo, el sitio en el que reside el equipo se almacena en el registro en el equipo cliente.
- Después de que el cliente busca un controlador de dominio, se almacena en caché la entrada del controlador de dominio. Si el controlador de dominio no está en el sitio óptimo, el cliente vacía la caché después de 15 minutos y descarta la entrada de caché. Después intenta buscar un controlador de dominio óptimo en el mismo sitio que el cliente.
En el caso de que un equipo cliente utiliza una dirección IP que no se representa en la tabla de asignación de subred para sitio, el controlador de dominio devuelve un nombre de sitio NULL y el cliente utiliza el controlador de dominio devuelto, que puede residir en cualquier sitio de Active Directory.
El problema
Si el controlador de dominio no puede determinar el sitio más cercano, debido a la información de subred IP no está definido en Active Directory, a continuación, la autenticación utiliza un controlador de dominio que no es óptima.
la figura 1 muestra un diseño de sitio de Active Directory de ejemplo que utiliza una topología radial de concentradores. Los usuarios que inicien sesión desde un equipo que está en una de las subredes que están definidas en Active Directory se dirigen a un controlador de dominio en su sitio de Active Directory más cercano para la autenticación. Sin embargo, los usuarios que inicien sesión desde un equipo que está en ninguna otra subred, 10.1.4.0/24 por ejemplo, se dirigen a un controlador de dominio arbitrario.
Figura 1 diseñar sitios de topología de concentrador y radiales de ejemplo
La corrección apropiada para solucionar este problema, por supuesto, es definir las subredes adicionales en Active Directory y asociarlos con el sitio correspondiente. Sin embargo, las organizaciones (especialmente medianas y grandes organizaciones) a menudo los problemas de cara obtener la información necesaria para agregar esas subredes adicionales a Active Directory. Más específicamente, los administradores de Active Directory normalmente se convierten en conocer la existencia de las subredes adicionales a través de errores y los archivos de registro, pero no sabe qué oficina física esas subredes pertenecen a, impide que identificar qué sitio para asociar la subred con.
La subred de captura de todos los
Una solución más práctica el problema consiste en utilizar una o varias subredes todos los catch-en Active Directory. Una subred de todos los catch-es una subred de Active Directory que se utiliza para detectar la autenticación de clientes que se encuentran en subredes que no están definidas en Active Directory. Una subred de todos los catch-es esencialmente un super-subnet.
Como se muestra en la figura 1 , la subred 10.1.1.0/24 se define en Active Directory y asociada con el sitio Toronto Active Directory. Decir que verá que un número de clientes de las subredes 10.1.4.0/24 y 10.1.5.0/24 se autentican en Active Directory. Cree que estas las subredes son en la oficina de Toronto basándose en el prefijo (10.1.x.x). Desea asegurarse de que los equipos de esas subredes, así como otras subredes que utilizan el prefijo 10.1.x.x, se autentiquen en un controlador de dominio en el sitio Toronto. Por lo que se crea una subred catch-todos, que utiliza el prefijo 10.1.0.0/16, para dirigir todas las subredes que piensa a estar ubicado en la oficina de Toronto, la autenticación y se asegura que la autenticación utiliza un controlador de dominio en el sitio Toronto. En texto rojo en la figura 2 se muestra la asignación de todos los catch-subred para en este ejemplo se.
La Figura 2 con una subred de todos los catch - para sitios concentrador
En la mayoría de las organizaciones, es comunicar información de subred IP para las oficinas remotas los administradores de Active Directory. Normalmente, existe la separación para subredes IP para las oficinas centrales, ubicaciones de concentrador y los centros de datos. La subred de todos los catch-puede utilizarse para mejorar la autenticación en estos casos así. Puesto que las subredes IP para las oficinas remotas son relativamente estáticas, y normalmente tiene una buena visión en esas subredes, puede crear una subred de todos los catch-para todas las subredes.
En este ejemplo, puede crear una subred catch-todos, que utiliza el prefijo 10.0.0.0/8 detectar la autenticación de todas las subredes que piensa que no pertenecen a una oficina remota y garantizar la autenticación utiliza un controlador de dominio en el sitio Toronto central. En texto rojo en la figura 3 se muestra la asignación de todos los catch-subred para en este ejemplo se. Y puede incluso utilizar varias subredes de todos los catch-, tal como se muestra en la figura 4 , si desea.
La figura 3 una subred de todos los catch - para todas las ubicaciones
La figura 4 con varias subredes de catch-todos
Observe en la figura 3 y 4 que las subredes de todos los catch-usar un prefijo que se superpone a los prefijos utilizados en los sitios remotos (10.0.0.0/8 cubre 10.1.1.0/24 por ejemplo). Es posible que se pregunte si la autenticación de equipos en las oficinas remotas aún se dirigirá a controlador de dominio de la oficina remota adecuado como resultado. La respuesta es sí. Cuando existen superpuestas subredes IP en Active Directory, se utiliza la subred IP con la máscara de subred más pequeño coincidente. Por ejemplo, 10.1.1.0/24 se utilizará en lugar de 10.0.0.0/8 si el equipo tiene una dirección IP de subred 10.1.1.5/24. Sin embargo, 10.1.1.1./32 se utiliza en lugar de 10.1.1.0/24 para un equipo que tenga una dirección IP de 10.1.1.5.
Ajustar hacia arriba
Antes de continuar y implementar catch-todas las subredes, tiene que tenga en cuenta que el concepto de una subred de todos los catch-no es adecuado para todos los entornos. La viabilidad de esta solución depende mucho el esquema de direccionamiento IP.
En los ejemplos que he incluido aquí, el esquema de direccionamiento IP es bastante sencillo. Sin embargo, a medida que el esquema de direccionamiento IP se más complejo, deja de estar menos probable que la viabilidad del uso de catch-todas las subredes. Por ejemplo, si su entorno consta de varios segmentos de red y el esquema de direccionamiento IP no es secuencial en cada ubicación, será virtualmente imposible crear subredes en todos los catch-que proporcionarán cualquier valor. Como con todas las soluciones, tiene que considerar el técnico, empresa y factores ambientales específicos de su entorno al determinar la viabilidad de la implementación catch-todas las subredes.
Y observe que el uso de catch-todas las subredes no resuelve el problema de falta subredes completamente. De hecho, si presentar catch-todas las subredes en su entorno, es más importante que defina explícitamente todas las subredes conocidas en Active Directory.
El uso de las subredes de todos los catch-aumentará el número de usuarios que encontrar el controlador de dominio más cercano. Sin embargo, su objetivo debe ser todavía solucionar el origen del problema y garantizar que reciben la información adecuada para todas las adiciones, modificaciones y eliminaciones de subredes de red por lo que puede mantener un diseño de sitio de Active Directory actualizado que proporciona autenticación eficaz para todos los usuarios.
John Policelli (Microsoft MVP para servicios de directorio MCTS, MCSA, ITSM, iNet +, Network + y A +) es consultor de TI de las soluciones de centrado con a través de una década de éxito combinada en arquitectura, seguridad, plan estratégico y planes de recuperación de desastres. Juan ha dedicado los últimos nueve años enfocados a la administración de identidades y acceso y proporcionar considerar liderazgo para algunas de las instalaciones más grandes de Active Directory en Canadá. John mantiene un blog en http://policelli.com/blog.