Я уверен, что некоторые из вас уже сталкивались с этой проблемой. Я надеюсь, что у кого-то есть лучший ответ, чем то, что я делаю сейчас.
Итак, у вас есть несколько пользователей в каталоге LDAP, и однажды вы говорите: «Эй! Я могу пройти аутентификацию по этой штуке для SSH!» И это хорошо.
Затем в один прекрасный день вы понимаете, что хотите, чтобы только определенные пользователи могли получить доступ к машине. Скажем, разработчики должны иметь доступ только к разработчикам, но не к продуктам. Вы погуглите и найдете pam_groupdn который входит в вашу конфигурацию LDAP (/etc/ldap.conf) вот так:
pam_groupdn CN=developers,OU=groups,DC=yourcompany
И, опять же, хорошо. Вы создаете еще одну группу для продуктов, другую для QA и т. Д. Может быть, однажды у вас появится вторая группа разработчиков продукта, и они получат свою собственную группу. Без разницы.
Затем в один прекрасный день у вас есть сервер, на который должны войти и разработчики, и QA. Эээ ... Оказывается, pam_groupdn не принимает несколько значений. Чем ты занимаешься? Что ж, если вы мало думаете, вы говорите: «О, я просто создам группу разработчиков и QA!».
pam_groupdn CN=developers-and-QA,OU=groups,DC=yourcompany
Это ... нехорошо, но все в порядке, правда?
Затем в один прекрасный день у вас появляется другой разработчик, и вы понимаете, что вам нужно добавить его в 15 групп, потому что есть developers-and-QA, product1-and-product2, developers-who-have-access-to-prod и так далее. Дерьмо.
Должен быть способ сделать это лучше, верно? Я написал разработчикам pam_ldap, и они сказали, что, к сожалению, нет возможности сделать pam_groupdn принимать несколько значений (без взлома кода).
Кто-нибудь хочет поделиться тем, как они управляют группами групп в LDAP, не прибегая к копированию / вставке?
Рабочее решение - применить pam_filter вместо того pam_groupdn в /etc/ldap.conf:
# Filter to AND with uid=%s
pam_filter |(member=CN=developers,OU=groups,DC=yourcompany)(member=CN=QA,OU=groups,DC=yourcompany)
«Фильтровать по И с uid =% s» означает, что фильтр, отправленный на LDAP-сервер, будет иметь следующий вид: &(uid=<your username>)(<your pam_filter>)
Пользователь должен быть членом developers или QA. Если он не является членом одной из этих групп, в ответе сервера LDAP будет сообщение об ошибке, и пароль даже не будет отправлен на сервер LDAP.
Работает для моей среды RHEL 5.8.
Чтобы узнать о различных вариантах фильтра, поищите в Google "синтаксис фильтра ldap" ...
Если вы используете NSS, вы можете установить AllowGroups параметр в /etc/ssh/sshd_config. Если нет, вам следует изучить динамические списки:
dn: cn=devandqa,ou=groups,dc=company,dc=com
cn: devandqa
objectClass: groupOfNames
labeledURI: ldap:///ou=groups,dc=company,dc=com?memberUid?one?(|(cn=developers)(cn=qa))
Что-то такое. Вам также необходимо включить схему и наложение и т. Д. Итак, это начало.
Предполагая, что у вас есть некоторая система управления конфигурацией, такая как марионетка, вы можете разработать решение на основе PAM (так что оно более общее, чем AllowGroups в sshd_config) с помощью pam_listfile. Пусть марионетка управляет чем-то вроде /etc/allowed_groups для каждой группы серверов / серверов и добавьте в конфигурацию PAM:
required pam_listfile.so onerr=fail item=group sense=allow file=/etc/allowed_groups
Как и решение SSH, здесь предполагается, что LDAP подключен к NSS.
Мое решение здесь довольно уродливое, но немного менее уродливое, чем то, что вы описали выше: группа, которую я указываю в pam_groupdn группа "машинного класса", например cn=database,ou=NY,dc=mydomain,dc=com
Группы определяют, кто должен иметь доступ к определенному классу систем на определенном сайте (в приведенном выше примере, database серверы в NY).
Это действительно работает только благодаря тому факту, что в моей среде предоставление пользователю доступа к одной машине в определенном классе практически бессмысленно (потому что все они фактически идентичны), поэтому, если я разрешаю кому-то войти в db01 нет причин, по которым им не следует также входить в систему db02. (Квалификация "сайта" проистекает из логики, согласно которой я могу нанять кого-нибудь для управления Калифорнией, но я не хочу, чтобы они входили в систему на машинах Нью-Йорка.)
Этот дизайн действительно предполагает некоторое дублирование в группах, что затрудняет глобальный отзыв доступа (например, моя учетная запись указана в каждой группе на каждом сайте: чтобы заблокировать моего пользователя, вам придется отредактировать каждую группу и отозвать мое членство), но это дает Группы - это логическая / управляемая структура, которая растет только при добавлении новых узлов / машинных классов.
Если вы используете RHEL6 +, файл conf находится по адресу /etc/pam_ldap.conf и нет /etc/openldap/ldap.conf. Если поставить pam_groupdn войдите туда, тогда он будет работать как задумано. Лучший способ сделать это - скопировать ваш ldap.conf к pam_ldap.conf или создайте символическую ссылку.