Autenticación LDAP y sesiones

De lo que podría percibir, su problema no es específico de Active Directory. Aún tendría este problema si estuviera basado en SQL o en cualquier otro tipo de backend de autenticación. Lo que tenemos que resolver es: ¿cómo nos damos cuenta del estado de la cuenta de usuario que inició sesión sin recordar las credenciales de la cuenta o pedir una nueva autenticación Y no renunciar a la seguridad?

La respuesta es simple: No podemos. La única forma de asegurarnos de que el usuario sigue siendo válido es volver a verificar en el servicio de autenticación.

Su única opción debería ser los tiempos de espera más largos (creo que no necesitamos abordar el tema de por qué no debemos conservar la credencial del usuario, ¿no?), pero esa es exactamente la razón por la que enfrenta este estado de coherencia problema.

Esa es la razón por la que tenemos una categoría de vulnerabilidad adecuada para ese tipo de problema . Simplemente debe NO habilitar largos períodos de tiempo de espera de sesión o (en opinión de algunas personas) sesiones de larga duración.

Puedes probar algo sobre ese SSO mencionado por @Abu. Pero eso se abre a otro problema acerca de la forma en que Windows se autentica porque NTLM no funciona y también la configuración predeterminada de Kerberos, como se explicó en el enlace anterior. Por supuesto, es posible configurar Kerberos correctamente para que no use el cifrado afectado, pero eso también implica la necesidad de un plan de administración de infraestructura ajustado (y ni siquiera estoy seguro de que invalide la sesión en este momento). la cuenta se elimina, se bloquea, etc.).

La seguridad siempre viene a expensas de la usabilidad. Hable con su gerente, explíquele la situación y haga lo que quiera. De una forma u otra, estará al tanto de los pros y los contras de su decisión, ya sea de menor seguridad (¿algunos servidores pirateados o borrados?) O de algunos correos electrónicos quejándose de una nueva autenticación (dependiendo de la tiempo de espera elegido).

Desde donde miro el asunto, el impacto de la menor seguridad en este caso supera ampliamente el impacto de la segunda opción.

Pero solo tú puedes decir dónde duele más.

No se garantiza que el uso de solo BIND restrinja el acceso a los usuarios deseados. Por ejemplo, también querrá comprobar si el usuario está bloqueado, por ejemplo, el atributo userAccountControl.

Si está realmente preocupado por el almacenamiento de credenciales en la memoria y desea una rápida suspensión de los derechos de los usuarios a través de LDAP, puede mantener la sesión abierta con consultas periódicas de los atributos apropiados. Esto tiene otros problemas, pero resolverá esta preocupación.

Sin embargo, creo que está sobre estimando la necesidad de expulsar rápidamente a un usuario de una aplicación cuando la información del directorio del usuario cambia. Si realmente necesita expulsar rápidamente al usuario, debe tener un mecanismo en la aplicación para invalidar la sesión del usuario.

También creo que está excesivamente preocupado por almacenar las credenciales de los usuarios en la memoria. Este es un objetivo relativamente difícil, y si las credenciales de los usuarios son tan sensibles, entonces no debería usar nada que pueda almacenarse en la memoria, sino usar algo como la autenticación multifactor, donde uno de los factores es el tiempo o criptográficamente seguro, por ejemplo SecurID, o PC / SC.