Cuando debería afectar el mantenimiento del servidor 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 único proceso de inicio de sesión. Estoy usando Active Directory como almacén de datos y he escrito un muy buen prototipo que se comunica con EA a través de LDAP. Este componente recupera información sobre el usuario conectado que he almacenado en la EA que luego utilizo para establecer sus funciones de seguridad en la autenticación de formularios .Net.

1) Todo es bueno.

Al no ser un administrador del sistema o ingeniero de la red, que no estaba familiarizado con la cantidad de la administración del sistema involucrado con la creación de una instancia de AD. Yo no era consciente de que para cada dominio, que necesitaba un controlador de servidor y dominio separado. Como resultado, hay como 9 dominios diferentes que mi equipo requiere que se creará 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 he colocado en a mí mismo algo de un dolor de cabeza administrativa porque voy a tener que mantener todas estas máquinas (o VM), que es algo que no estoy necesariamente seguro de que quiera hacer.

2) No todo está bien.

El prototipo es muy sólido, y AD hace por una muy buena base de datos para la solución, pero ahora me pregunto si debería desechar el código y escribir un proveedor de datos de SQL Server en lugar (sé .Net ya proporciona una, pero no se ajusta a solas mis requerimientos del negocio de autorización).

De todos modos, así que estoy tratando de pensar a través de este problema desde una perspectiva de alto nivel. En general, sigo tropezando con el hecho de que iba a ser lanzando una muy buena solución justa a causa de algún mantenimiento del servidor? Me pregunto si alguien aquí ha experimentado un escenario como este y qué es exactamente lo que decidió hacer.

No tiene que ser específica para AD o bien, sólo una situación en la que había que evaluar entre una buena solución de software y es las limitaciones de mantenimiento del servidor.

Answer 1

En general, la capacidad de uso de un producto es lo que hace la gente a elegir entre ella y productos similares. Si el producto tiene mala facilidad de uso, los usuarios no le importa cómo la calidad alta su código es -. Todo lo que importa a ellos es lo fácil y eficaz que es usar y lo bien que llena sus necesidades

Mantenimiento puede ser pensado como un aspecto de la facilidad de uso. Me gustaría hacer que la máxima prioridad a tener un producto fácil de mantener. En el largo plazo que ahorrará muchas horas de trabajo de los administradores.

Una forma de pensar en ello, es el primer diseñando lo que sería la solución más fácil de usar desde la perspectiva del usuario final / de administrador y, a continuación, por lo que es un reto intelectual para aplicar en la práctica que la solución óptima. Es probable que requieren más esfuerzo por parte del programador, pero el resultado final será mejor.

Por ejemplo ZFS es un producto donde el mantenimiento se ha tenido cuidado de bien (aunque no lo han utilizado personalmente). Cuando fue diseñado, mucho esfuerzo se puso en lo que es fácil de administrar el sistema de archivos con las herramientas de línea de comandos de ZFS -. Y esas decisiones de diseño afecta a todos los niveles de ZFS (por ejemplo piscinas de almacenamiento)

Como otro ejemplo, he estado recientemente, la planificación de cómo hacer el mantenimiento en un futuro proyecto mío - una base de datos distribuida y servidor de aplicaciones. Pensando en cómo las tareas típicas de administración sucederán (instalación / actualización de las aplicaciones, añadir / quitar los servidores del clúster, la resolución de fallo de hardware, etc.), me ha ayudado a resolver algunas decisiones de diseño. Algunos de ellos van bastante profundo en la arquitectura del sistema (por ejemplo, cómo las aplicaciones y extensiones se cargan en tiempo de ejecución, y cómo los servidores encontrar otros servidores del clúster).

Answer 2

Si la creación de un inicio de sesión único sistema por un sistema de Windows que ser muy likly a usar AD. Como administrador del sistema. Trato de seguir una política única fuente-de-datos. AD ya se está llevando a cabo la mayor parte de mis datos de usuario de Windows / de seguridad. Yo preferiría tener todo ahí en lugar de un segundo sistema.

Cuando la creación de entornos de desarrollo / pruebas / prod Trato de asegurar que el combate de cerca el uno Prod, más especialmente en el área que se está trabajando (en la que los esfuerzos de desarrollo se están poniendo, etc). Así que si la configuración del sistema para desarrollar una interfaz con AD Me probable es que tenga varios servidores de anuncios.

¿Qué opciones podría simplificar el administrador?

Se puede tener 1 servidor maestro que mantenga en la forma estándar y utiliza algo así como un proceso de copia de VMware para mantener la totalidad o la mayor parte de los otros? En lugar de hacer algo a 9 servidores, mantener a los otros 8 como copias de ese espejo del maestro a excepción de los cambios realizados para apoyar dev / prueba?

¿Se puede ejecutar múltiples dominios Dev o de prueba desde el servidor 1 AD?

Puede usted acción de script?

¿Se puede reducir el número de entornos, especialmente en el extremo más alto de la prueba? P.ej. proporcionar múltiples entornos dev y papel hasta lanzamientos en una sola prueba?

Answer 3

¿Por qué no simplemente usar unidades organizativas en lugar de dominios separados cuando se prueba? Es decir, tienen un solo dominio, pero especificar que los usuarios de versiones particulares deben encontrarse en una unidad organizativa en particular dentro de ese dominio. Lo que se puede hacer es en sus funciones de búsqueda para buscar usuarios, usted especifica la unidad organizativa 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, ...

Yo uso AD mucho para mis aplicaciones y nunca configurar dominios separados para el desarrollo / pruebas.

Answer 4

Utilice un patrón de proveedor y abstractos sus llamadas origen de datos.

A continuación, 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");