DirectoryServices.AccountManagement “viejo” contraseña valida aún después de cambio de contraseña

Question

Después de restablecer una contraseña a los usuarios en Active Directory, si el usuario intenta iniciar sesión con su contraseña anterior, el siguiente código valida como verdadera:

Dim up As UserPrincipal = GetAdUser(objContext, arg_strBA, arg_strUsername)

If up IsNot Nothing Then

    Dim valid As Boolean = up.Context.ValidateCredentials(
    up.UserPrincipalName, arg_strPassword, ContextOptions.Negotiate)


    If (valid) Then strReturn = up.SamAccountName

End If

Estamos restablecer la contraseña usando el siguiente código:

Dim objUser As New DirectoryEntry(arg_strLDAPPath)

If Not objUser Is Nothing Then
    objUser.AuthenticationType = AuthenticationTypes.Secure


    objUser.Invoke("SetPassword", arg_strNewPW)
    objUser.CommitChanges()
end if

El restablecimiento de contraseña funciona bien y el usuario puede iniciar sesión con su nueva contraseña, pero su antigua contraseña no debe validar todavía.

Cuando los ValidateCredentials anterior funciona para la antigua contraseña, estamos asignando las credenciales para una llamada de servicio web, que a su vez produce un error con un "401: no autorizado". Error

Alguien ha visto algo como esto?

Answer 1

Aquí

Desde el enlace ...

"Sin embargo, lo que cuenta es que ContextOption hace no garantizar el uso de solamente Kerberos. Resulta que en determinadas situaciones (como si especifica AD en lugar de locales, y tiene una suficientemente hasta el servidor fecha), el código elige hacer Negociar no importa qué. En ese sentido, la especificación de sellado probablemente significa que va a utilizar Kerberos, pero no necesariamente de forma exclusiva. la bandera que realmente importa es enterrado varias capas debajo de eso. debajo de las sábanas , este método termina el establecimiento de un LdapConnection, el establecimiento de las credenciales de red para la conexión, estableciendo que TipoAut (la bandera real que importa!), y, finalmente, una llamada al método bind (). el método LdapConnection.Bind () establece una conexión autenticada uno de los servidores de anuncios utilizando las credenciales especificadas. el problema es que cuando se pone en marcha PrincipalContext.ValidateCredentials esta llamada (en el escenario), que siempre establece el TipoAut = Negociar. en este caso, Kerberos hace en hecho llegar utiliza, y acaba fracasando, pero el sistema se cae a NTLM. "

Answer 2

Este problema no está relacionado con el Código, pero el culpable más de escuchar es el directorio activo ...

Por favor, consulte http://support.microsoft.com/kb/906305 para la solución. ..

Answer 3

Esto funciona - Véase la solución por debajo de -. Por favor, hágamelo saber si usted ha resultado útil como nuestra tienda está dividida sobre si esta es una solución Aceptar

La siguiente es una solución a Active Directory permitiendo Contraseña anterior a trabajar después de haber sido cambiado. Me gustaría mucho que la retroalimentación sobre la aceptación de esta solución, ya que utiliza el ChangePassword durante el acceso a la autenticación. Esto es una cosa extraña que hacer, pero funciona. Actualmente nuestra tienda no está utilizando esta solución por lo que si alguien me puede decir si están utilizando o no que sería apreciada.

Gracias Ch

Active Directory y contraseñas antiguas regresar válidos (15 minutos a + - hora). Esto ocurre cuando SetPassword o ChangePassword se invocan.

Historia:

Me parece que esto se llama una “característica” de la EA y es por diseño integrado en AD para que cuando un usuario cambia las contraseñas que hay una especie de período de gracia que permite a todos los recursos que utilizan esas contraseñas para transferir a la nueva .

Un ejemplo de AD que apoya el concepto de que AD conoce la contraseña más reciente es el de cambiar una contraseña de inicio de sesión en un PC - en este caso el equipo no va a permitir que la antigua contraseña para iniciar sesión. Si bien no tengo la respuesta a esta (que no sea Microsoft tenía que conseguir que esto funcione) es mi opinión que esto no es tan simple como puede parecer que el PC está implicado y que tiene contraseñas en él también.

Un ejemplo que muestra cómo los cambios de contraseña en AD duran por un período de tiempo puede ser:

El uso de Escritorio remoto desde un PC con Windows 7 a una caja de Windows Server 2008 R2. Iniciar sesión desde la caja de seguridad de Windows entonces la, haga clic en Aceptar aparece el cuadro, haga clic en Aceptar y que está conectado. Ahora cambia la contraseña para el usuario que utilizó para remoto en la caja con (diferente de su usuario Kirkman ??), cierre de sesión y de inicio de sesión de nuevo con la contraseña anterior (dentro de marco de tiempo de 15 minutos a una hora + -). La contraseña antigua le conseguirá más allá de la caja de seguridad de Windows y para la caja OK. Al hacer clic en OK, entonces se producirá un error. Si comienza de nuevo desde el escritorio remoto y tratar una contraseña incorrecta se le detuvo en la caja de seguridad de Windows con el mensaje “El intento de inicio de sesión no se pudo”. Después de que expire el plazo no se va a más allá de la caja de seguridad de Windows con la contraseña anterior. (Asegúrese de iniciar desde el escritorio remoto cada vez NO cambiar los usuarios que actuarán como se espera que también muestra que el PC en participar de alguna manera). Al menos no lo hace la conexión del usuario - pero esto hace demostrar que (lo que parece ser AD) en algún nivel permite antiguas contraseñas para autenticar a un nivel

.

Investigación: He encontrado muchas referencias a este problema y sólo una solución potencial que a este punto no he sido capaz de determinar si podemos ponerlo en práctica (esta es la referencia a llamar estrictamente a través de Kerberos y no NTLM que no es tan simple como puede aparecerá de acuerdo a la documentación y mi investigación). He encontrado muchos enlaces a cómo interactuar con AD en .NET pero ningún manual AD real.

Solución Solución SOLUCIÓN - Lea esta parte si desea que el SOLUCIÓN !!! Presente: He encontrado (por accidente durante las pruebas) que la llamada ChangePassword a AD no permitirá que el contraseñaAntigua pasó a que tenga éxito en el cambio de la contraseña de la nueva contraseña. Es mi opinión que esta prueba hace que el trabajo no se conoce realmente como no he encontrado ninguna referencia a que se utilice. En realidad no he encontrado ninguna solución a este problema. Una mañana a las 3:00 am me di cuenta de que podía explotar este uso de ChangePassword para proporcionar una solución a este problema -., Al menos, una solución alternativa que se puede utilizar de inmediato hasta que podamos determinar un mejor enfoque

En primer lugar puedo comprobar que todo es válido y vuelve AD que la contraseña es válida. A continuación se hace una llamada a ChangePassword (nombre de usuario, contraseñaantigua, newpassword) con el contraseñaantigua y newpassword como contraseña proporcionada por el usuario (tanto de la misma). Sé que uno de dos (posiblemente tres, pero los pasespada violación de la política lo para de tener éxito) los resultados van a suceder. O bien el contraseñaAntigua es bueno y que falle debido a la política de contraseña no se cumple (la historia, la nueva contraseña no puede ser una de las últimas contraseñas N) o que fallan debido a la antigua contraseña es incorrecta (ambos regresaron como error de excepción con el texto en el mensaje). Comprobamos de esta última condición y si el contraseñaantigua no es válido no dejamos que el usuario se conecte.

Futuro: Tal vez un segundo par de ojos ayudará.
Creo que la solución está en la suplantación o Kerberos. No he tenido éxito en la búsqueda de lo suficiente en cualquiera de éstos como soluciones. Es obvio que la EA puede diferenciar entre las contraseñas de edad debido a que el ChangePassword lo hace. Lo que estamos haciendo está en el corazón de la seguridad por lo que no todo está abierto (como la capacidad de ver el historial de contraseñas en el año, no he encontrado una manera de acceder a él).

Answer 4

¿Tomó el hasta 15 minutos de tiempo en cuenta que la EA requiere para propagar cambios como el que a través de la red ??

Marc

Answer 5

Asumo que estás ValidateCredentials ejecuta en una máquina cliente. Si ese es el caso, entonces se tiene la edad (con éxito) en caché contraseña. Esto se hace para permitir a los usuarios iniciar sesión si el Active Directory está desconectado o fuera de cobertura. Propagación de los cambios lleva algún tiempo.

Si quieres evitar esto, usted debe autenticarse con el servidor sirviendo al servicio web en el momento de la autenticación en lugar de la máquina cliente local.