Résumé

  • La RFC 3062 dissocie le changement de mot de passe de la forme DN de l’identité et de la présence du secret dans une entrée LDAP.
  • Le serveur ne peut annoncer un succès qu’après le changement et doit préserver l’ancien mot de passe en cas d’échec ; cette réponse ne prouve ni une connexion ultérieure ni la propagation vers tous les systèmes.

Modifier une entrée qui n’existe pas

L’opération LDAP Modify agit sur les attributs d’une entrée désignée. Elle convient lorsque l’utilisateur possède un nom distinctif (DN) et que son mot de passe figure, par exemple, dans userPassword. Mais l’intégration de LDAP avec des services d’authentification externes a rendu cette hypothèse fragile : une identité pouvait ne pas être un DN et le service pouvait conserver le mot de passe en dehors de l’annuaire. Modifier une entrée LDAP ne changeait alors pas forcément le secret utilisé à la connexion.

Publiée en février 2001 et signée par Kurt Zeilenga, la RFC 3062 propose une autre voie : l’opération étendue Password Modify, identifiée par l’OID 1.3.6.1.4.1.4203.1.11.1. La requête peut inclure userIdentity, oldPasswd et newPasswd. Aucun de ces champs n’est obligatoire à lui seul. Le protocole transporte une demande de changement ; il ne prescrit pas où le secret doit être conservé.

Une identité de session ou une identité explicite

Le champ userIdentity, s’il existe, contient une chaîne d’octets qui peut être un DN, sans devoir l’être. En son absence, l’opération vise l’utilisateur associé à la session LDAP en cours. Le client peut donc s’appuyer sur l’identité déjà liée à la session ou transmettre une forme que le serveur sait interpréter. Dans les deux cas, le protocole ne révèle ni le magasin du mot de passe ni la façon dont le serveur relie cette identité au secret modifiable.

C’est le déplacement architectural important : LDAP offre une frontière de requête commune, sans imposer que le mot de passe soit une propriété de l’annuaire. Un serveur peut utiliser un attribut, un stockage séparé ou un service d’authentification externe. La RFC autorise ces configurations, mais ne décrit aucune implémentation particulière et ne garantit pas que les serveurs résolvent les identités de la même manière.

Un succès encadré, pas universel

Le serveur ne peut renvoyer un code de succès qu’après avoir effectivement changé le mot de passe. Sinon, il doit le laisser intact et renvoyer un échec. Un ancien mot de passe erroné fourni par le client interdit également le changement. Si le client omet newPasswd, le serveur doit soit en générer un et le rendre dans genPasswd en cas de succès, soit échouer. Si oldPasswd manque, une autre politique locale peut décider de l’autorisation ; les administrateurs peuvent aussi restreindre l’opération.

Cette règle crée une frontière d’engagement utile : la réponse doit distinguer le changement accompli de la tentative échouée. Elle ne constitue pourtant pas un reçu de connexion de bout en bout. Elle ne prouve pas qu’un Bind ultérieur réussira, que toutes les répliques d’un service externe ont reçu la nouvelle valeur, que l’utilisateur a récupéré un mot de passe généré, ni que l’identité désigne une personne réelle précise. Il faut des éléments séparés pour établir ces faits.

La découverte de capacité dépend du contexte

La RFC recommande que le serveur annonce l’OID dans l’attribut supportedExtension du Root DSE et que le client vérifie sa présence avant d’agir. Mais un serveur peut choisir de n’annoncer l’extension que si le client est autorisé et/ou si la protection requise est en place. La découverte dépend donc de la session. L’absence de l’OID dans une réponse indique ce qui est annoncé dans ce contexte, pas nécessairement ce qui est possible pour tout autre principal ou chemin d’accès.

L’opération n’apporte elle-même ni confidentialité ni intégrité. La RFC interdit l’usage anonyme et exige une protection de confidentialité, telle que TLS : ancien et nouveau mots de passe peuvent voyager dans la requête, et un secret généré peut revenir dans la réponse. Une voie vers un magasin distant ne sert à rien si elle expose le secret durant le trajet.

Définie sous RFC 2251, l’opération s’inscrivait dans les messages ExtendedRequest/ExtendedResponse d’LDAPv3. La RFC 4511 a ensuite remplacé RFC 2251 et décrit le cadre général des opérations étendues. Cette évolution éclaire la structure du protocole, mais ne prouve ni l’implémentation de Password Modify sur un serveur particulier ni un comportement uniforme.

Les deux errata vérifiés par l’éditeur de RFC sont limités : le premier corrige « where » en « were » dans le texte historique ; le second ajoute les virgules manquantes dans la séquence ASN.1 de la requête. La correction de ponctuation rend la notation formelle plus nette, sans changer la séparation entre identité, annuaire et stockage du mot de passe.

La RFC 3062 a donc relié LDAP à un changement de mot de passe sans obliger le secret à avoir une entrée dans l’annuaire ni l’identité à prendre la forme d’un DN. Il restait au serveur de relier cette requête à l’autorité réelle sur les identifiants. La réponse du protocole ne décrivait que le résultat promis à cette frontière.

Sources