Я могу просматривать пользовательские данные существующего каталога LDAP, используя DN привязки и пароль привязки. Я не могу найти запись, хранящую пароль пользователя. Возможно ли, что атрибуты пароля скрыты от учетной записи bind, которую я использовал для подключения к MSAD LDAP? Если нет, то хранит ли LDAP пароли отдельно в другом месте?
Я планирую настроить свое приложение для аутентификации пользователей на основе этого LDAP.
Я планирую настроить свое приложение для аутентификации пользователей на основе этого LDAP.
Правильный способ аутентификации учетной записи ldap - просто попытаться привязаться к серверу ldap с помощью учетных данных. Для некоторых серверов вам необходимо указать полное отличительное имя для входа в систему. Таким образом, вам нужно будет настроить учетную запись для поиска DN по другому идентификатору.
Где хранятся учетные данные
Большинство серверов хранят хэш в атрибуте с именем «пароль». Но ACL установлены для этого атрибута, поэтому никто не может его прочитать. Microsoft просто не разрешает чтение хэша пароля через LDAP в качестве функции безопасности. Он может быть установлен только через соединение LDAPS, то есть LDAP в SSL. Настройка окон для поддержки LDAPS требует создания CA или покупки сертификатов.
В общем, хотя атрибуты могут выглядеть как атрибуты в любой системе LDAP, атрибут пароля почти всегда является особым случаем. Возможно, это ограничено сервером LDAP как особый случай. Возможно, ACL защитят его. Возможно, оно доступно для записи, но не для чтения.
Часто на самом деле есть несколько атрибутов пароля (в AD есть unicodePassword и userPassword), и это зависит от того, какой из них использовать. В Novell/NetIQ eDirectory есть userPassword, который зависит от того, как вы сконфигурированы, от того, какое значение находится под ним (пары ключей RSA, nspmPassword или простой пароль, что является еще более странным случаем, чем простой атрибут, так как он хранится по частям через несколько атрибутов)
Некоторые серверы LDAP позволяют связывать с хеш-значением, которое соответствует сохраненному хеш-значению, и хеш-значение может быть восстановлено, но не обратимо.
Но ключ в том, что это не должно иметь значения. Поскольку каждый сервер LDAP отличается от других, вам необходимо использовать стандартный подход к паролям LDAP, который заключается в том, чтобы попытаться выполнить привязку как пользователь с предоставленными DN и паролем. И если они не предоставляют DN, выполните поиск uid = Username или cn = username или любого другого атрибута именования, чтобы найти полное DN.
Наконец, имейте в виду, что стандарт LDAP говорит, что связывание с пустым паролем будет успешным, но как анонимное соединение. Поэтому вы должны быть уверены, что пароли, которые вы разрешаете, не являются пустыми, иначе вы получите успешное связывание и, возможно, невольно впустите кого-то.
