LDAP и pam без binddn и анонимного доступа
Просто мысль, но удостоверяются servername параметр устанавливается на допустимый контроллер домена домена. Если Вы указываете на неDC затем, вызов API возвращает результаты от локальных пользователей сервера.
Вы могли бы также рассмотреть использование ADSI вместо этого для сцепления в AD.
The problem is that user authentication on UNIX works by taking a simple username string, such as 'usera'.
LDAP does not work like this, but instead needs a full username DN, such as uid=mruser,cn=users,dc=ibm,dc=com.
So the reason you need to allow anon binding or have a valid binddn is so that your authentication system can bind to the LDAP server and perform a search to translate usera -> uid=mruser,cn=users,dc=ibm,dc=com. Without this ability, it wouldn't know what to test the password against in the directory.
It's usual for LDAP admins to not want to allow anonymous binding, but they should be able to create a specific user for you which is only allows to access the specific details you require for LDAP authentication to work on UNIX. ie. read-only access on the user and group areas of the LDAP hierarchy.
You don't mention what OS you're actually talking about, but remember that PAM is for authentication - you also need to be able to have the NSS service also resolve usernames and userids. Depending on the implementation, this may be a different part of the configuration work you need to do.
Думаю, я понимаю, что вы хотите сделать, а именно:
Пользователь представляет вам учетные данные для проверки.
Вместо привязки к серверу LDAP через анонимный доступ , или со стандартным набором учетных данных привязки, вы хотите использовать учетные данные, только что представленные вам пользователем, каждый раз для аутентификации на сервере LDAP, чтобы просить его проверить эти учетные данные.
Это все?
Если это так, то для того, чтобы это имело смысл, учетные данные каждого пользователя должны быть LDAP-действительными только для аутентификации его или ее собственных учетных данных; в противном случае вы могли бы выполнить явно опасный широкий поиск с первым представленным таким образом набором учетных данных. И если администраторы сервера LDAP могут так плотно связать объем набора учетных данных, тогда они должны иметь возможность предоставить вам стандартный набор учетных данных для привязки, которые действительны только для выполнения поиска в отношении тех пользователей, которых вы уполномочены видеть.
Вы понимаете мою точку зрения? Если администраторы вашего LDAP-сервера настолько хорошо разбираются в поиске, который могут выполнять учетные данные, они обладают необходимыми навыками, чтобы предоставить вам подходящий набор учетных данных для привязки. И если они не так хороши, нет смысла просить вас делать то, что они хотят, потому что у вас уже есть учетные данные, достаточно мощные, чтобы делать то, что они не хотят, чтобы вы делали.
Два стандартных способа доступа к Сервер LDAP работает (1) анонимно и (2) использует набор учетных данных, выданных администраторами сервера, которые подходят только для того, чтобы делать то, что вам нужно. Если администраторам сервера не нравится (1), то это '
Я не мог придумать способ сделать это с уже существующими модулями 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-разрядная версия.