Autenticación de Active Directory, equilibrio de carga y conmutación por error

Para las aplicaciones que se autentican en un DC de Active Directory, obviamente sería mejor señalarlas al registro DNS del dominio principal en lugar de un DC específico para conmutación por error, equilibrio de carga, etc.

¿Cuáles son las mejores prácticas para esas aplicaciones que lo obligan a codificar la IP de un DC? En su lugar, podríamos codificar la dirección IP de un equilibrador de carga, por lo que si un DC fallara, esa aplicación aún podría autenticarse. ¿Hay alguna alternativa mejor?

Active Directory ya tiene incorporadas técnicas de equilibrio de carga. Su cliente de Windows sabe cómo ubicar los controladores de dominio redundantes en su propio sitio y cómo usar otro si el primero no está disponible. No es necesario realizar un equilibrio de carga adicional, como DC "agrupados", etc. siempre que tenga DC redundantes.

En cierto modo, puede pensar en un sitio de Active Directory como un "equilibrador de carga", porque los clientes en ese sitio elegirán aleatoriamente uno de los DC en el mismo sitio. Si todos los DC en un sitio fallan o si el sitio no tiene DC, entonces los clientes elegirán otro sitio (ya sea el sitio más cercano o al azar).

Puede equilibrar la carga del servicio DNS proporcionado por Active Directory para clientes unidos a un dominio colocando un VIP en un equilibrador de carga de hardware y teniendo ese equilibrio de carga VIP entre varios de los controladores de dominio. Luego, en sus clientes, coloque ese VIP como el servidor DNS preferido en la configuración TCP / IP.

Lo estoy haciendo ahora para una infraestructura global y está funcionando muy bien.

Pero eso solo se aplica al servicio DNS.

No intente equilibrar la carga de sus controladores de dominio para la autenticación. Está pidiendo problemas. Al menos tendría que hacer mucho trabajo complejo de SPN personalizado y se saldría de los límites de soporte de Microsoft. De este blog, que deberías leer , lo citaré:

Vuelva a los proveedores y dígales que no los considera AD Integrated y encontrará una solución diferente.

¿Ahora en cuanto a las aplicaciones que le piden que escriba la dirección IP de un controlador de dominio? Bueno, solo reiteraré mi comentario:

Quien escribió una aplicación que lo obliga a codificar la dirección IP de un controlador de dominio no sabe lo que está haciendo.

nunca ha habido una buena razón para codificar una IP o usar una IP para resolver consultas de AD. No hay mejores prácticas para las malas prácticas.

Varias de las otras respuestas a esta pregunta parecen suponer que no hay otro mundo que las aplicaciones compatibles con Microsoft. Lamentablemente, este no es el caso, como lo demuestra la pregunta original:

¿Cuáles son las mejores prácticas para esas aplicaciones que lo obligan a codificar la IP de un DC?

Si bien Microsoft no admite ni recomienda el uso de una solución NLB frente a Active Directory, de hecho parece haber algunas opciones para autenticar aplicaciones que no son compatibles con Microsoft AD.

• Comprender la autenticación de proxy en AD LDS
• IApp certificada F5 para LDAP de equilibrio de carga
• Autenticación Pass-Trough con SASL

Una necesidad real de AD externa de "equilibrio de carga" es rara, y es difícil de hacer correctamente. La necesidad de consultas típicas puede funcionar bien, sin embargo, un cliente y aplicaciones típicos de Windows necesitan realizar actualizaciones. Un cliente de Windows intenta establecer una afinidad con una CC en particular, de modo que si actualiza algo e intenta inmediatamente una operación posterior, llega a la misma CC. Los desarrolladores de aplicaciones hacen lo mismo. Si escribe un código que crea una cuenta de usuario, intente cambiar la contraseña de esa cuenta 1 ms más tarde, debe presionar la misma CC.

Si fuera a AD front-end con alguna solución de equilibrador de carga, se responsabiliza de garantizar que esos enfoques y afinidades no se rompan.

Si la necesidad es disponibilidad, en lugar de equilibrar la carga, la agrupación puede ser más apropiada (aparte la lata de gusanos).

En implementaciones de AD grandes, un enfoque más tradicional es identificar a los consumidores mayoritarios y colocarlos en un sitio con sus propios DC. Por ejemplo, si tiene cinco servidores de Exchange, cree un sitio para las subredes para esos servidores y coloque GC dedicados en ese sitio. Lo mismo se aplicaría para otros servidores como SharePoint.