.net - c# active directory authentication

¿Puedes calcular el hash de contraseña utilizado por Active Directory?

Question

Actualmente almacenamos usuarios de nuestra aplicación web en nuestra base de datos, junto con los hashes / sales de sus contraseñas. Los valores hash se calculan cuando el usuario se crea y establece su contraseña y se almacena en una tabla de usuario en una base de datos.

Algún tiempo después de la creación de la cuenta de usuario, es posible que deseemos crear una cuenta de Windows en nuestro dominio, y queremos poder establecer la contraseña del usuario de dominio para que sea la misma que la que usa el usuario para iniciar sesión en la aplicación web. . Como no guardamos la versión de texto sin formato de la contraseña, no tenemos forma de enviarla a AD cuando la creamos.

Una manera en que estaba pensando en solucionar este problema sería calcular todos los hash de contraseñas diferentes que utiliza AD cuando el usuario establece su contraseña por primera vez, y luego establecer de alguna manera los registros en AD más adelante cuando creamos el usuario.

1. ¿Cómo crearías los hashes (creo que son MD4, MD5 y DES) usando .Net?
2. ¿Puede eludir la creación de contraseñas en UserPrincpal.SetPassword y hacer alguna otra llamada para establecer directamente los hashes almacenados por AD?

Parece que debería haber una forma de hacerlo, ya que MS tiene herramientas para sincronizar contraseñas desde AD a usuarios de Azure.

Answer 1

Intentar mantener sincronizada una contraseña de AD con una contraseña de base de datos es una mala idea por dos motivos:

• Es una debilidad de seguridad (los comentarios ya lo han señalado al mencionar la sal)
• Es un problema de mantenimiento. Un cambio de contraseña iniciado por la PC de Windows dejaría sin cambios la contraseña de DB.

En lugar de crear una cuenta de Windows con la misma contraseña, modifique la autenticación de su aplicación web para usar la autenticación AD y la autenticación de Windows Forms. De esta forma, sus credenciales de AD (si las tienen) reemplazarán el indicador de nombre de usuario / contraseña.

Answer 2

Evitando mantener a) una contraseña encriptada puede obtener un texto claro, b) un algoritmo hash débil, ambas son malas ideas en caso de que un atacante interno / externo comprometa la DB.

Podría considerar un enfoque diferente: * crear la cuenta de AD para el usuario con una contraseña larga, aleatoria y desconocida. Coloque una marca de tiempo ''ADPasswordLastSet = null'' en la cuenta. * la próxima vez que el usuario inicie sesión en su aplicación web, después de autenticarla, tendrá la contraseña en claro, de modo que configure la contraseña del usuario de AD en la misma. No olvide actualizar el indicador ADPasswordLastSet.

Por lo tanto, no tiene que escribir la contraseña en ningún lugar si puede configurarla de forma síncrona.

Una cosa para recordar: políticas de complejidad de contraseña: desea asegurarse de que la política presente en la interfaz de usuario con la que el usuario interactúa tenga la política más estricta.