active directory - practicas - ¿Cuándo debería el mantenimiento del servidor afectar las decisiones de implementación?

seguridad de dominio

Question

Aquí está mi situación ...

Estoy escribiendo un sistema de seguridad .NET / C # (autorización y autenticación) para una gran colección de aplicaciones web que requieren un proceso de inicio de sesión único. Estoy usando Active Directory como una tienda de datos y he escrito un prototipo muy agradable que se comunica con AD a través de LDAP. Este componente recupera información sobre el usuario conectado que he almacenado en AD, que luego utilizo para establecer sus funciones de seguridad en la autenticación de formularios .Net.

1) Todo está bien.

Al no ser un administrador del sistema o un ingeniero de red, no estaba familiarizado con la cantidad de administración del sistema involucrada en la configuración de una instancia de AD. No sabía que para cada dominio, necesitaba un servidor y un controlador de dominio por separado. Como resultado, hay como 9 dominios diferentes que mi equipo requiere que se configuren para todos los diferentes entornos en los que vamos a acceder AD ...

• env1.dev.mycompany.com
• env1.qa.mycompany.com
• env1.stage.mycompany.com
• env2.dev.mycompany.com
• etc

... Así que ahora me he puesto un poco de dolor de cabeza administrativo porque tendré que mantener todas estas máquinas (o máquinas virtuales), algo que no estoy necesariamente seguro de querer hacer.

2) Todo no es bueno.

El prototipo es realmente sólido, y AD es una base de datos muy buena para la solución, pero ahora me pregunto si debería eliminar el código y escribir un proveedor de datos SQL Server (sé que .Net ya proporciona uno, pero no lo hace). solo se ajustan a los requisitos de mi negocio para la autorización).

De todos modos, entonces estoy tratando de pensar en este problema desde una perspectiva de alto nivel. En general, sigo tropezando con el hecho de que estaría lanzando una solución realmente buena solo por el mantenimiento del servidor. Me pregunto si alguien aquí ha experimentado un escenario como este y qué decidiste hacer exactamente.

No tiene que ser específico para AD tampoco, solo una situación en la que tuvo que evaluar entre una buena solución de software y sus limitaciones de mantenimiento del servidor.

Answer 1

En general, la usabilidad de un producto es lo que hace que las personas elijan entre él y productos similares. Si el producto tiene mala usabilidad, a los usuarios no les importará qué tan alta sea su código, lo único que les importa es qué tan fácil y efectivo es usarlo y qué tan bien satisface sus necesidades.

El mantenimiento puede considerarse como un aspecto de la usabilidad. Me gustaría que sea una prioridad tener un producto fácil de mantener. A largo plazo, eso ahorrará muchas horas de trabajo a los administradores.

Una forma de pensarlo es primero diseñar cuál sería la solución más útil desde el punto de vista del usuario final / administrador, y luego convertirlo en un desafío intelectual para implementar realmente esa solución óptima. Probablemente requerirá más esfuerzo del programador, pero el resultado final será mejor.

Por ejemplo, ZFS es un producto donde el mantenimiento se ha cuidado bien (aunque no lo he usado personalmente). Cuando se diseñó, se hizo mucho esfuerzo para facilitar la administración del sistema de archivos con las herramientas de línea de comandos de ZFS, y esas decisiones de diseño afectan a todos los niveles de ZFS (por ejemplo, grupos de almacenamiento).

Como otro ejemplo, recientemente he estado planificando cómo realizar el mantenimiento en un futuro proyecto mío: una base de datos distribuida y un servidor de aplicaciones. Pensar en cómo las tareas de administración típicas sucederán (instalar / actualizar aplicaciones, agregar / eliminar servidores en el clúster, resolver fallas de hardware, etc.) me ha ayudado a resolver algunas decisiones de diseño. Algunos de ellos se adentran bastante en la arquitectura del sistema (por ejemplo, cómo se cargan las aplicaciones y extensiones en tiempo de ejecución, y cómo los servidores encuentran otros servidores en el clúster).

Answer 2

Si configuro un sistema de inicio de sesión único para un sistema Windows, es muy probable que use AD. Como un administrador de sistema. Intento seguir una política de fuente única de datos. AD ya tiene gran parte de mis datos de usuario / seguridad de Windows. Preferiría tener todo allí en lugar de un segundo sistema.

Al configurar los entornos de desarrollo / prueba / producción, intento asegurarme de que coincida estrechamente con el de Prod, especialmente en el área en que se trabaja (donde se realizan los esfuerzos de desarrollo, etc.). Por lo tanto, si configura el sistema para desarrollar una interfaz con AD, es probable que tenga varios servidores AD.

¿Qué opciones podrían simplificar al administrador?

¿Puede tener 1 servidor maestro que mantenga de la manera estándar y usar algo así como un proceso de copia de VMware para mantener todos o la mayoría de los demás? En lugar de hacer algo en 9 servidores, guarde los otros 8 como copias de ese espejo el maestro, excepto por los cambios realizados para soportar dev / test.

¿Puede ejecutar múltiples dominios Dev o Test desde 1 servidor AD?

¿Puedes guiar la acción?

¿Se puede reducir el número de entornos, especialmente en el extremo superior de la prueba? Por ejemplo, ¿ofrece múltiples entornos de desarrollo y versiones de rol en un solo Test uno?

Answer 3

Use un patrón de proveedor y abstraiga sus llamadas de fuente de datos.

Luego puede configurarlo para usar AD o SQL sobre la marcha.

public abstract SSODataProvider {
     public bool AuthenticateUser(string u, string p);
}

public ADSSODataProvider : SSODataProvider {
    public override AutheticateUser(string u, string p) {
       //do auth here
    }
}

public SQLSSODataProvider : SSODataProvider {
    public override AuthenticateUser(String u, string p) {
      //call DB
    }
}

public static SSODataProvider dataProvider;

if (ConfigurationSettings.AppSettings["SSODataProvider"] == "SQL")
   dataProvider = new SQLSSODataProvider();
else
   dataProvider = new ADSSODataProvider();

....

dataProvider.AuthenticateUser("sss","sss");

Answer 4

¿Por qué no simplemente usar unidades organizativas en lugar de dominios separados cuando se prueban? Es decir, tienen un solo dominio, pero especifican que los usuarios de versiones particulares deben encontrarse en una OU particular dentro de ese dominio. Lo que haría en las funciones de búsqueda para buscar usuarios, especificaría la OU particular como la raíz de búsqueda en lugar de la raíz del dominio. En cada unidad organizativa, puede tener identificadores que incorporen el entorno para mantenerlos únicos, por ejemplo, user_env1_dev , user_env2_dev , user_env1_qa , ...

Utilizo mucho AD para mis aplicaciones y nunca configuro dominios separados para desarrollo / prueba.