Кратко

  • RFC 3062 отделил смену пароля и от представления пользователя в виде DN, и от требования хранить пароль в записи LDAP-каталога.
  • Сервер мог ответить успехом только после смены и обязан был сохранить прежний пароль при неудаче. Такой ответ не доказывает успешный последующий вход или распространение нового значения по внешним сервисам.

Изменять было нечего — по крайней мере в каталоге

Операция Modify в LDAP меняет атрибуты конкретной записи каталога. Это подходит, если у пользователя есть отличительное имя (DN), а пароль хранится, например, в атрибуте userPassword. Но интеграция с внешними службами аутентификации разрушила это простое допущение: идентификатор пользователя мог быть не DN, а пароль мог находиться за пределами каталога. Тогда изменение записи LDAP не обязательно меняло секрет, который проверялся при входе.

В феврале 2001 года Kurt Zeilenga опубликовал RFC 3062 с отдельной операцией вместо попытки представить каждый пароль как атрибут. Расширенная операция Password Modify получила OID 1.3.6.1.4.1.4203.1.11.1. Запрос может содержать userIdentity, oldPasswd и newPasswd; каждое поле необязательно. Протокол определяет запрос на смену, но не универсальную схему хранения.

Идентификатор сеанса или явное значение

Поле userIdentity, если оно присутствует, содержит строку октетов, которая может быть DN, но не обязана им быть. Если поле опущено, запрос относится к пользователю, связанному с текущим LDAP-сеансом. Клиент может использовать уже установленную идентичность сеанса либо передать форму, которую сервер умеет разрешить. Ни один вариант не сообщает клиенту, где хранится пароль и как сервер сопоставляет идентификатор с изменяемым секретом.

В этом и состоял архитектурный сдвиг: LDAP предоставил общий интерфейс запроса, не требуя делать пароль атрибутом каталога. Сервер мог обращаться к атрибуту, отдельному хранилищу или внешней службе аутентификации. RFC 3062 допускает такие варианты, но не описывает конкретную реализацию и не гарантирует одинаковое разрешение идентификаторов на разных серверах.

Что означает успех

Сервер вправе вернуть успех только после фактической смены пароля. Иначе он обязан оставить пароль без изменений и вернуть неуспешный результат. Если передан неверный старый пароль, смена также запрещена. Когда клиент опускает newPasswd, сервер должен сгенерировать пароль и вернуть его в genPasswd при успехе либо отказать. Если oldPasswd отсутствует, другая политика сервера может определять допустимость смены; администраторы тоже могут ограничить операцию.

Так возникает полезная граница подтверждения: ответ должен различать завершённую смену и неудачную попытку. Но это не подтверждение аутентификации от начала до конца. Ответ не доказывает, что последующий Bind будет успешен, что все реплики внешней службы получили новое значение, что пользователь безопасно получил сгенерированный пароль или что идентификатор принадлежит конкретному реальному человеку. Для этого нужны отдельные свидетельства.

Обнаружение возможностей зависит от сеанса

RFC 3062 рекомендует объявлять OID в атрибуте supportedExtension корневого DSE и рекомендует клиенту проверять его до отправки операции. Однако сервер может показывать расширение только тогда, когда клиент авторизован и/или установлена необходимая защита. Обнаружение возможности зависит от контекста сеанса. Отсутствие OID в одном ответе характеризует этот контекст, но не обязательно все учётные записи и пути подключения.

Сама операция не обеспечивает ни конфиденциальности, ни целостности. RFC запрещает анонимное использование и требует защиты конфиденциальности, например TLS. В запросе могут идти старый и новый пароли, а в ответе — сгенерированный. Нет смысла обращаться к удалённому хранилищу, если сам путь раскрывает секрет.

RFC 3062 определил операцию расширения в рамках LDAPv3 из RFC 2251. Позднее RFC 4511 заменил RFC 2251 и описал общий формат ExtendedRequest и ExtendedResponse. Эта эволюция показывает, как расширения вписываются в протокол, но не доказывает поддержку Password Modify конкретным сервером или одинаковое поведение разных реализаций.

RFC Editor указывает две проверенные поправки. Erratum 340 заменяет “where” на “were” в историческом описании; Erratum 4899 добавляет запятые в список полей ASN.1. Формальная запись стала точнее, но границы между формой идентификатора, каталогом и хранилищем пароля не изменились.

RFC 3062 позволил LDAP передавать запрос на смену пароля без предположения, что пароль находится в записи каталога или что пользователь представлен DN. Серверу всё равно требовалось связать запрос с системой, фактически контролирующей учётные данные. Ответ протокола описывал лишь результат, обещанный на границе операции.

Источники