Статус документа
В этом документе определяется предложенный стандарт протокола Internet для сообщества Internet, а также принимаются обсуждения и предложения по его улучшению. Пожалуйста, отслеживайте текущую редакцию "Internet Official Protocol Standards" (STD 1) на предмет состояния стандартизации и статуса данного протокола. Ограничений на распространение этого документа не накладывается.
Уведомление об авторских правах
Copyright (C) Internet Society (2001). Все права защищены.
Тезисы
В результате интеграции протокола Lightweight Directory Access Protocol (LDAP) и внешних сервисов аутентификации были введены в обращение аутентификационные идентификационные сущности, не являющиеся DN, а также разрешено хранение паролей вне каталога. В этих случаях механизмы обновления каталога (такие как Modify) не могут быть использованы для изменения пароля пользователя. В этом документе описывается расширенная операция LDAP, позволяющая модифицировать пароли пользователя вне зависимости от формы аутентификационной идентификационной сущности и используемого механизма хранения паролей.
В этом документе ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется) и "MAY" (возможно) интерпретируются так, как описано в RFC 2119.
1. Предпосылки и предназначение
Протокол Lightweight Directory Access Protocol (LDAP) [RFC2251] поддерживает несколько механизмов аутентификации, в том числе аутентификацию по простым парам имя пользователя/пароль. Традиционно пользователи LDAP идентифицировались по DN [RFC2253] записи каталога, и эта запись содержала атрибут userPassword [RFC2256], в котором хранились один или несколько паролей.
Протокол не устанавливает жёсткого требования, чтобы ассоциированные с пользователем пароли хранились в каталоге. Сервер может использовать любой подходящий атрибут для хранения пароля (например, userPassword), либо использовать отдельное от каталога хранилище.
В результате интеграции протокола [RFC2829] с независимыми от приложения сервисами SASL [RFC2222], поддерживающими простые механизмы аутентификации по имени пользователя/паролю (такие как DIGEST-MD5), были введены в употребление отличные от LDAP DN формы аутентификационных идентификационных сущностей и хранение паролей возложено на поставщика услуг SASL.
Операции обновления LDAP разработаны так, чтобы выполнять действия над атрибутами записи в каталоге. Операции обновления LDAP не могут быть использованы для модификации пароля пользователя, когда пользователь не представлен DN, не имеет записи, или когда используемый сервером пароль не хранится в качестве атрибута записи. Требовался альтернативный механизм.
В этом документе описывается расширенная операция LDAP, предназначение которой — позволить клиентам каталога обновлять свои пароли. Пользователь может быть, а может и не быть ассоциирован с записью каталога. Пользователь может быть, а может и не быть представлен в качестве LDAP DN. Пароль пользователя может храниться, а может и не храниться в каталоге.
Данную операцию не следует (SHOULD NOT) использовать без адекватного обеспечения безопасности, поскольку сама по себе она не обеспечивает никакой защиты конфиденциальности и целостности. Эту оперцию не следует (SHALL NOT) использовать анонимно.