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

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 necesita para ser configurado para todos los diferentes ambientes que vamos a acceder a AD ...

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

... Así que ahora me han puesto en contra yo mismo som Es un dolor de cabeza administrativo porque voy a tener que mantener todas estas máquinas (o máquinas virtuales), algo que no estoy seguro de querer hacer.

2) No todo 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 (lo sé .Net ya proporciona uno , pero no solo se ajusta 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 las 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ñando cuál sería la solución más útil desde el punto de vista del usuario final/administrador, y luego convirtiendo en un desafío intelectual 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 el 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 exactamente con Prod, especialmente en el área en la 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?

¿Se puede escribir la acción?

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

Answer 3

¿Por qué no simplemente usar unidades organizativas en lugar de dominios separados durante las pruebas? 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 que podría tener las identificaciones que incorporan el medio ambiente para mantenerlos único, por ejemplo, user_env1_dev, user_env2_dev, user_env1_qa, ...

utilizo AD muchos de mis aplicaciones y nunca configurar dominios separados para el desarrollo/pruebas.

Answer 4

Utilice 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");