Я работаю в большой компании и могу удаленно использовать ее центральный LDAP-сервер, доступный только для чтения. Сервер LDAP делает не разрешить анонимную привязку. Чтобы использовать этот сервер для аутентификации пользователей на моем небольшом сервере с модулем pam, мне нужна учетная запись, которая предоставляет мне данные о LDAP. Данные аккаунта обычно заполняются binddn
и bindpw
поля конфигурации. Как я понял модуль pam обычно входит в систему с binddn
и bindpw
, затем выполняет поиск и привязку для каждого пользователя, желающего войти в систему.
Однако администраторам сервера не нравится раскрывать мне все данные. Итак, мой вопрос:
Как я могу настроить pam без учетной записи binddn? В идеале прямая привязка для каждого пользователя должна выполняться без предварительного входа в систему с учетной записью binddn.
Я не мог придумать, как это сделать с уже существующими модулями PAM, поэтому написал один. На данный момент он поддерживает только простую аутентификацию. Обязательно укажите такие параметры шаблона uri и binddn:
auth sufficient pam_ldapdb.so uri=ldap://example.com binddn=uid=%s,dc=example,dc=com
% s будет заменен подключенным пользователем.
Для этого требуются g ++, pam devel и ldap devel. Он был протестирован на CentOS 6 и 7, 64 бит.
Проблема в том, что аутентификация пользователя в UNIX работает с использованием простой строки имени пользователя, такой как 'usera'.
LDAP не работает таким образом, вместо этого требуется полное DN имени пользователя, например uid=mruser,cn=users,dc=ibm,dc=com
.
Таким образом, причина, по которой вам нужно разрешить привязку anon или иметь действительный binddn, заключается в том, чтобы ваша система аутентификации могла подключиться к серверу LDAP и выполнить поиск для перевода usera
-> uid=mruser,cn=users,dc=ibm,dc=com
. Без этой возможности он не знал бы, что проверять пароль в каталоге.
Администраторы LDAP обычно не хотят разрешать анонимную привязку, но они должны иметь возможность создать для вас конкретного пользователя, который позволяет получить доступ только к конкретным деталям, которые необходимы для аутентификации LDAP для работы в UNIX. т.е. доступ только для чтения к пользовательским и групповым областям иерархии LDAP.
Вы не упоминаете, о какой ОС вы на самом деле говорите, но помните, что PAM предназначен для аутентификации - вам также необходимо, чтобы служба NSS также разрешала имена пользователей и идентификаторы пользователей. В зависимости от реализации это может быть другая часть работы по настройке, которую вам необходимо выполнить.
Думаю, я понимаю, что вы хотите сделать, а именно:
Пользователь представляет вам учетные данные для проверки.
Вместо привязки к серверу LDAP через анонимный доступ или со стандартным набором учетных данных привязки, вы хотите использовать учетные данные, только что представленные вам пользователем, каждый раз для аутентификации на сервере LDAP, чтобы попросить его проверить эти полномочия.
Это оно?
Если так, то для того, чтобы это имело смысл, учетные данные каждого пользователя должны быть действительными LDAP только для аутентификации его или ее собственных учетных данных; в противном случае вы могли бы выполнить явно опасный широкий поиск с первым представленным таким образом набором учетных данных. И если администраторы LDAP-сервера могут так плотно связать объем набора учетных данных, то они должны иметь возможность предоставить вам стандартный набор привязанных учетных данных, которые действительны только для выполнения поиска в отношении тех пользователей, на которых вы уполномочены. видеть.
Вы понимаете мою точку зрения? Если администраторы вашего LDAP-сервера настолько хорошо разбираются в поиске, который могут выполнять учетные данные, у них есть навыки, необходимые для предоставления вам подходящего набора учетных данных для привязки. И если они не так хороши, нет смысла просить вас делать то, что они хотят, потому что вы уже обладаете достаточными полномочиями, чтобы делать то, что они не хотят, чтобы вы делали.
Двумя стандартными способами доступа к серверу LDAP являются (1) анонимный и (2) использование набора учетных данных, выданных администраторами сервера, которые подходят только для выполнения того, что вам нужно от них. Если администраторам сервера не нравится (1), то их задача - предоставить вам подходящие учетные данные для выполнения (2).