Resumen

  • RFC 3062 separó el cambio de contraseña tanto de la forma DN de la identidad como de que el secreto estuviera guardado en una entrada del directorio.
  • El servidor solo debía responder con éxito tras cambiar la contraseña y tenía que conservarla intacta si fallaba; esa respuesta no demostraba un inicio de sesión posterior ni la propagación a todos los servicios.

Una modificación sin atributo al que apuntar

La operación Modify de LDAP cambia atributos de una entrada identificada. Encaja cuando el usuario tiene un Nombre Distinguido (DN) y la contraseña figura allí como atributo userPassword. Pero la integración con servicios de autenticación externos hizo insuficiente esa suposición: la identidad podía no ser un DN y el servicio podía guardar la contraseña fuera del directorio. Modificar la entrada LDAP ya no implicaba necesariamente cambiar el secreto que se usaría al iniciar sesión.

Kurt Zeilenga publicó RFC 3062 en febrero de 2001 para ofrecer otra operación, en vez de fingir que toda contraseña era un atributo. Password Modify es una operación extendida identificada por el OID 1.3.6.1.4.1.4203.1.11.1. La solicitud puede llevar userIdentity, oldPasswd y newPasswd, todos opcionales. El protocolo define cómo pedir el cambio, no un diseño universal para almacenar el secreto.

Dos formas de señalar a quién

Cuando aparece userIdentity, es una cadena de octetos que puede ser un DN, aunque no es obligatorio. Si falta, la operación se aplica al usuario asociado con la sesión LDAP actual. El cliente puede apoyarse en la identidad ya autenticada o enviar otra forma que el servidor sepa resolver. Ninguna opción revela dónde está la contraseña ni cómo se traduce esa identidad al secreto que el servidor puede modificar.

Ese fue el movimiento arquitectónico: LDAP ofrecía una frontera común para la solicitud, sin exigir que la contraseña viviera como atributo del directorio. El servidor podía usar un atributo, otro almacén o un servicio externo de autenticación. RFC 3062 permite esas posibilidades; no documenta una implementación concreta ni garantiza que todos los servidores resuelvan identidades igual.

Un éxito acotado

El servidor solo puede responder con éxito después de cambiar la contraseña. Si no lo consigue, debe dejarla sin modificar y responder con un resultado distinto de éxito. Una contraseña antigua incorrecta que se haya proporcionado tampoco puede provocar un cambio. Si el cliente omite newPasswd, el servidor tiene que generar una contraseña y devolverla en genPasswd al responder con éxito, o bien fallar. Cuando falta oldPasswd, otra política del servidor puede determinar si autoriza el cambio; los administradores también pueden restringir la operación.

La regla establece un límite de confirmación valioso: la respuesta debe distinguir el cambio completado del intento fallido. Pero no es un comprobante de autenticación de extremo a extremo. No demuestra que luego funcione un Bind, que todas las réplicas de un servicio externo hayan recibido el nuevo valor, que el usuario haya recibido la contraseña generada ni que la identidad corresponda a una persona real concreta. Esas afirmaciones requieren evidencia aparte.

Descubrimiento condicionado por la sesión

RFC 3062 recomienda anunciar el OID en supportedExtension, atributo del Root DSE, y aconseja al cliente comprobarlo antes de enviar la solicitud. Hay un matiz importante: el servidor puede anunciar la extensión solo cuando el cliente esté autorizado y/o ya exista protección de seguridad suficiente. Por tanto, descubrir la capacidad puede depender de la sesión. Que el OID no aparezca en una respuesta describe ese contexto, no necesariamente todos los usuarios o caminos de acceso posibles.

La operación no aporta confidencialidad ni integridad. RFC 3062 prohíbe su uso anónimo y exige protección de confidencialidad, como TLS. La petición puede contener la contraseña antigua y la nueva; la respuesta puede transportar una contraseña generada. Un mecanismo para cambiar un secreto en un servicio remoto pierde su sentido si el propio trayecto lo expone.

RFC 3062 definió la operación extendida sobre RFC 2251. RFC 4511 sustituyó después a RFC 2251 y describe la estructura general de ExtendedRequest y ExtendedResponse. Esa evolución aclara el marco de extensiones; no prueba que un servidor específico implementara Password Modify ni que dos servidores se comportaran igual.

El RFC Editor muestra dos erratas verificadas: una cambia “where” por “were” en el contexto histórico y otra añade las comas que faltaban en la lista ASN.1 de campos. La corrección formal hace más clara la notación, pero no modifica el límite central entre identidad, directorio y almacenamiento de contraseñas.

RFC 3062 hizo posible solicitar desde LDAP un cambio de contraseña sin exigir que el secreto tuviera una entrada en el directorio o que la identidad fuera un DN. Aún correspondía al servidor conectar la solicitud con la autoridad que realmente controlaba la credencial. La respuesta solo describía el resultado que el protocolo promete en ese límite.

Fuentes