.net - usuario - query active directory c#

¿Qué significa "integración de directorio activo" en su aplicación.NET? (5)

Nuestro departamento de marketing regresa con la "integración activa de directorios" como una solicitud clave del cliente, pero nuestra empresa no parece tener la capacidad de atención para (1) decidir qué cambios funcionales queremos realizar con este fin, (2) entrevistar a un una amplia gama de clientes para identificar los cambios funcionales más solicitados, y (3) todavía tiene que ser el tema "hot potato" la próxima semana. Para ayudarme a ir más allá del amplio tema de la "integración de directorio activo", ¿qué significa en su aplicación .NET, tanto ASP.NET como WinForms?

Aquí hay algunos cambios de muestra que tengo que considerar:

Al crear y administrar usuarios en su aplicación, ¿se les presenta a los administradores una lista de todos los usuarios de AD o solo un grupo de usuarios de AD?
Al crear nuevos grupos de seguridad dentro de su aplicación (los llamamos Departamentos, como "Recursos humanos"), ¿debería crear nuevos grupos de AD?
¿Los administradores asignan usuarios a grupos de seguridad dentro de su aplicación o fuera de AD? ¿Importa?
¿El usuario ha iniciado sesión en su aplicación en virtud de haber iniciado sesión en Windows? Si no es así, ¿realiza un seguimiento de los usuarios con su propia tabla de usuarios y algún tipo de clave externa en AD? ¿Qué clave externa usas para vincular a los usuarios de la aplicación con los usuarios de AD? ¿Debe probar que su proceso de inicio de sesión protege las contraseñas de los usuarios?
¿Qué clave externa usas para vincular grupos de seguridad de aplicaciones a grupos de seguridad de AD?
Si tiene un componente de WinForms para su aplicación (tenemos ASP.NET y WinForms), ¿usa el Proveedor de Membresía en su aplicación WinForms? Actualmente, nuestra gestión de Membresía y Roles es anterior a la versión del marco, por lo que no usamos el Proveedor de membresía.

¿Me falta alguna otra área de cambios funcionales?

Siguiente pregunta

¿Las aplicaciones que admiten la "integración de directorio activo" tienen la capacidad de autenticar usuarios en más de un dominio? No es que un usuario se autenticara en más de un dominio, pero que diferentes usuarios del mismo sistema se autenticaran contra diferentes dominios.

¿El usuario ha iniciado sesión en su aplicación en virtud de haber iniciado sesión en Windows?

Para mí, esto es ante todo lo que significa la integración AD (aparte de Windows lockin :-). Entonces, por ejemplo, si la organización ha implementado el inicio de sesión de clave pública, la obtendrá en su aplicación en vano.

¿Debe probar que su proceso de inicio de sesión protege las contraseñas de los usuarios?

Normalmente, nunca debería ver una contraseña si está utilizando AD, a menos que tenga algún NT4 heredado (ciertamente no debería tener que almacenar una contraseña).

¿Los administradores asignan usuarios a grupos de seguridad dentro de su aplicación o fuera de AD? ¿Importa?

A través de AD. Después del inicio de sesión único, un beneficio importante sería poder utilizar cualquier herramienta de AD que tenga para administrar la aplicación de seguridad, informar sobre permisos, crear ACL, etc. No debería reinventar esto para cada aplicación.

Como clave para mapear AD-users / groups para rellenar la aplicación, generalmente utilizo Security Identifier (SID) del AD-usuario / grupo.

Una de las principales ventajas de usar AD es que permite a un equipo dedicado administrar todas las cosas de usuario / donaciones. Normalmente, cuando llega un nuevo usuario, su gerente le pide al equipo dedicado que le dé acceso a la aplicación AB y C, y este equipo puede hacer todo esto directamente desde AD. De hecho, a menudo duplican a otro usuario (por lo general, un compañero de trabajo).

desde la perspectiva de los administradores quiero una integración de anuncios para hacer las siguientes cosas

nunca escribas de nuevo al AD, simplemente no confío en el software de terceros en este punto
poder importar usuarios de AD
ser capaz de establecer un grupo de seguridad, por ejemplo, "Usuarios de ApplicationXYZ" para ser utilizados para distribución de software y derechos (carpetas compartidas, ...) si es necesario, pero esto debe obedecer al número 1. Por lo tanto, el administrador crea el grupo de seguridad y le dice al servidor de aplicaciones uno es.
inicio de sesión único (lo hace más fácil para los usuarios porque solo necesitan saber su inicio de sesión de Windows, y aplica la política de contraseña amplia de dominio)
un usuario AD desactivado o un usuario AD que ya no se encuentre en "Usuarios de la aplicación XYZ" no deberían poder iniciar sesión
enlace AD-Group al grupo de aplicaciones pero eso sería opcional, realmente puedo vivir sin eso

hth

Como alguien que es a la vez el administrador de AD y actualmente está desarrollando una aplicación interna que debe integrarse con AD, aquí están mis pensamientos:

Los usuarios de Active Directory tienen un GUID único; si su aplicación necesitaba ser compatible con la autenticación AD y AspNetSqlMembership, podría tener un campo GUID FK en su tabla Usuario / Persona y una bandera que indica a qué almacén de información pertenecía el usuario (formularios o AD)
Como administrador, debería poder limitar el acceso a mi aplicación a los usuarios que se encuentran debajo de una unidad organizativa determinada. ¡No quiero que las cuentas de mi servidor SQL Server o BackupExec puedan iniciar sesión!
En su documentación, use una unidad organizativa que no sea la unidad organizativa estándar "Usuarios": la mayoría de las implementaciones del mundo real mueven a sus usuarios fuera de este contenedor, y para los administradores noveles se asegura un ejemplo de consulta LDAP que incluye unidades organizativas (por ejemplo, MyCompany / Usuarios / Ejecutivo o somesuch)
Si usa la autenticación de formularios AD, entonces es posible que pueda atrapar y hacer algo malicioso con la contraseña. Es mejor que su departamento legal lo resuelva en su contrato / garantía de servicio.