usuarios - c#Cambiar la contraseña de AD Directoryservices

single sign on c# active directory

Question

Estoy tratando de hacer funcionar el siguiente código, el problema es que a veces sucede, a veces no funciona. cuando falla, da el error 0x800704F1 "el sistema no puede contactar a un controlador de dominio para atender la solicitud de autenticación" Diría que el 90% del tiempo falla. Intenté darle una CC estática añadiéndola detrás del contexto. Esto no ayudó. En un usuario administrador funciona siempre ... sin embargo, creo que se supone que los usuarios pueden cambiar su propia contraseña. El error se desencadena en la línea user.changepassword

Espero que alguien más tenga una idea brillante.

        using (var context = new PrincipalContext(ContextType.Domain))
        {
            using (var user = UserPrincipal.Current)
            {
                try
                {
                    user.ChangePassword(txt_old.Text, txt_new.Text);
                    user.Save();

                }
                catch(Exception p)
                {
                    if (p.HResult.Equals("0x800708C5"))//Not secure enough according to password policy
                    {
                        MessageBox.Show("Volgens het systeem is uw nieuwe wachtwoord niet veilig genoeg, voldoet het aan alle eisen?", "Niet gelukt", MessageBoxButtons.OK, MessageBoxIcon.Warning);
                        return;
                    }
                    else if (p.HResult.Equals("0x80070056")) //Wrong current password
                    {
                        MessageBox.Show("U heeft een verkeerd huidig wachtwoord ingevult, probeer het nogmaals", "Verkeerd wachtwoord", MessageBoxButtons.OK, MessageBoxIcon.Warning);
                        return;
                    }
                    else if (p.InnerException.ToString().Contains("0x80070775")) //Temporarly locked out.
                    {
                        MessageBox.Show("Uw account is tijdelijk vergrendeld door te veel pogingen tot in te loggen met een foutief wachtwoord. Probeer het over 15minuten nogmaals of neem contact op met de helpdesk.", "vergrendeld.", MessageBoxButtons.OK, MessageBoxIcon.Warning);
                        return;
                    }
                    else
                    {
                        MessageBox.Show(System.Security.Principal.WindowsIdentity.GetCurrent().Name + Environment.NewLine + p.HResult + Environment.NewLine + p.Message);
                        return;
                    }
                }
            }
        }

Answer 1

Su problema puede ser que se haya producido una violación de la política de contraseñas. Es decir, por ejemplo, si tiene una política de contraseñas implementada donde los usuarios no pueden cambiar sus contraseñas para que sea una de sus últimas 5, como ejemplo, si intentan cambiar a uno de sus últimos 5, verá esto error lanzado en mi experiencia.

El error justo antes de la excepción que informa (en mi caso) tiene este aspecto: TargetInvocationException: COM error al intentar cambiar una contraseña de Active Directory.

Así que verificaría sus políticas de contraseña y me aseguraré de que sus usuarios en estos casos no lo violen.

Answer 2

Fui testigo de esto desde el lado de los administradores de sistemas en dos ocasiones diferentes: dos aplicaciones con funciones de administración de contraseñas tuvieron que instalarse en dos servidores recién implementados, que por supuesto habían sido completamente actualizados; en ambos casos, el cambio de contraseñas falló con un error acerca de que la aplicación no podía contactar a un controlador de dominio (que, por supuesto, estaba realmente disponible).

Una aplicación era una de proveedor de fuente cerrada ( Gerente de sesión privilegiado de CyberArk ), mientras que la otra era una aplicación interna desarrollada por el cliente donde estoy trabajando; en el segundo caso, pude echar un vistazo al código, que de hecho era similar al utilizado en la pregunta original.

Lamentablemente, en realidad, corregir el código no era una opción en ambos casos: para la primera aplicación tuvimos que informar un error al proveedor de la aplicación, mientras que para el segundo tuvimos que informar un error al equipo de desarrollo interno que trabajaba en la aplicación, ya que no pudimos obtener una solución inmediata en ninguno de los casos. La gerencia quería que ambas aplicaciones funcionaran ahora , así que tuvimos que eliminar las actualizaciones ofensivas (lo sé, esto es malo y no una solución, sino una solución lenta y peligrosa, e intenté todo lo posible para evitar eso, pero la gestión es la gestión, entonces. .. meh).

De todos modos, la razón por la que estoy saltando con esta respuesta: además de eliminar KB3177108 y KB3167679 , en mi caso (en ambos casos) también tuvimos que eliminar KB3175024 y KB3174644 ; Mientras se instalaron esas dos actualizaciones, la función de cambio de contraseña aún se negó a funcionar, incluso después de eliminar las dos primeras.

Por lo tanto, si se encuentra en una situación en la que no puede reparar el código, y la eliminación de KB3177108 y KB3167679 no resuelve el problema, entonces puede intentar eliminar también KB3175024 y KB3174644.

Answer 3

Las dos actualizaciones de Windows 3177108 y 3167679 han cambiado el comportamiento de ChangePassword.

Aquí hay un hilo sobre el problema: https://social.msdn.microsoft.com/Forums/vstudio/en-US/77dc733e-a13d-4349-9088-8065b85d5c3f/userprincipalchangepassword-stops-working-after-windows-updates -3177108-and-3167679? Forum = netfxbcl

Parece que ahora debe especificar un UPN válido al crear el PrincipalContext.

Antes de poder usar una IP como punto final al crear el contexto, ahora parece que también tiene que ser un nombre de dominio correcto.

Además, ahora siempre recibe la misma excepción cuando se produce un error: solíamos recibir la excepción de política de contraseñas para los usuarios que eligen contraseñas insuficientes, ahora obtenemos:

System.DirectoryServices.AccountManagement.PrincipalOperationException: el sistema no puede ponerse en contacto con un controlador de dominio para atender la solicitud de autenticación. Por favor, inténtelo de nuevo más tarde. (Excepción de HRESULT: 0x800704F1)

ACTUALIZACIÓN 04-10-2016: La excepción que se muestra arriba es realmente el error general / genérico recibido para casi todo cuando se llama a ChangePassword después de las actualizaciones. Si, por ejemplo, algunos de los puertos implicados en el protocolo están bloqueados por un cortafuegos, usted también obtendrá este (aplicable si llama desde un servidor / máquina que no está unido al dominio).

Buen recurso para los puertos requeridos: https://technet.microsoft.com/en-us/library/dd772723(v=ws.10).aspx Tenga en cuenta que también se requiere el rango dinámico.

Si el usuario no puede cambiar la contraseña (política de dominio, eludir mediante la configuración DEBE CAMBIAR A LA SIGUIENTE BANDA DE INICIO DE SESIÓN) también recibirá esta excepción.

Answer 4

ACTUALIZACIÓN: 10/12/2016: Microsoft ha actualizado este artículo: https://support.microsoft.com/en-us/kb/3177108 . Aquí nos han dado problemas creados por las "correcciones" originales, así como algunos consejos para trabajar con Kerberos y el restablecimiento de contraseña de autoservicio.

A partir del 11 de octubre de 2016, Microsoft volvió a publicar los parches asociados con https://technet.microsoft.com/en-us/library/security/ms16-101.aspx para resolver los problemas causados ​​por las actualizaciones originales (que puede leer en https://support.microsoft.com/en-us/kb/3177108, incluido el hecho de que ya no puede cambiar las contraseñas en las cuentas locales).

Creo que tengo la respuesta. Microsoft parchó recientemente Windows para que NTLM ya no se pueda usar para cambiar contraseñas.

Solución n. ° 1 (el "martillo"): intente eliminar una o ambas actualizaciones de KB en su servidor que ejecuta el código.

https://support.microsoft.com/en-us/kb/3177108

https://support.microsoft.com/en-us/kb/3167679

Cuando dice que puede cambiar la contraseña como administrador, ¿quiere decir solo cuando la aplicación de formularios se ejecuta en la máquina de un administrador? ¿Es el desafío cuando la aplicación se ejecuta en una máquina que no es del administrador?

Pude tomar su código y hacer que funcione así como también cambiar lo siguiente:

using (var user = UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, "test.user0001"))

y

using (var user = UserPrincipal.FindByIdentity(context, IdentityType.UserPrincipalName, "[email protected]"))

Usando cualquiera de estas líneas, así como la suya (obteniendo el usuario actual), pude cambiar las contraseñas de administrador y no de administrador por igual. Mi pregunta es si su error ocurre cuando la aplicación de formularios se ejecuta en un equipo que no es administrador.