Управление входами в систему LDAP на машине без pam_groupdn: разрешено несколько групп
Я уверен, что некоторые из вас имели дело с этой же проблемой. Я надеюсь, что у кого-то есть лучший ответ, чем то, что я делаю сейчас.
Итак, у вас есть несколько пользователей в каталоге LDAP, и однажды вы скажете: "Привет! Я могу пройти проверку подлинности по этой вещи для SSH!" И это хорошо.
Затем однажды вы понимаете, что хотите, чтобы только некоторые пользователи могли войти в компьютер. Скажем, разработчики должны иметь возможность входить только в коробки разработчиков, а не в prod. Вы гугляете и находите pam_groupdn который идет в вашем конфиге LDAP (/etc/ldap.conf) вот так:
pam_groupdn CN=developers,OU=groups,DC=yourcompany
И, опять же, это хорошо. Вы создаете другую группу для prod, другую для 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, не прибегая к копированию / вставке?
5 ответов
Если вы используете 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_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)
"Filter to AND with uid =% s" означает, что фильтр, отправленный на LDAP-сервер, будет выглядеть следующим образом: &(uid=<your username>)(<your pam_filter>)
Пользователь должен быть участником developers или же QA, Если он не является членом одной из этих групп, в ответе от сервера LDAP появляется сообщение об ошибке, и пароль даже не будет отправлен на сервер LDAP.
Работает для моей среды RHEL 5.8.
Для различных вариантов фильтров, проверьте в Google "синтаксис фильтра ldap"...
Мое решение здесь довольно уродливо, но чуть менее уродливо, чем то, что вы описали выше: группа, в которой я указываю pam_groupdn группа "машинного класса", например cn=database,ou=NY,dc=mydomain,dc=com
Группы определяют, кто должен иметь доступ к определенному классу систем на определенном сайте (в приведенном выше примере database серверы в NY).
Это действительно работает только благодаря тому факту, что в моей среде предоставление пользователю доступа к одной машине в определенном классе в значительной степени бессмысленно (потому что все они фактически идентичны), поэтому, если я позволю кому-то войти в систему db01 нет никаких причин, по которым им не следует разрешать входить в db02, (Квалификация "сайта" основана на логике, согласно которой я могу нанять кого-то для управления Калифорнией, но я не хочу, чтобы они входили в машины Нью-Йорка.)
Этот дизайн предполагает некоторое дублирование в группах, что затрудняет глобальный отзыв доступа (например, моя учетная запись указана в каждой группе на каждом сайте: чтобы заблокировать моего пользователя, вам придется отредактировать каждую группу и отозвать мое членство), но это дает группирует логическую / управляемую структуру, которая растет только при добавлении новых сайтов / классов компьютеров.
Предполагая, что у вас есть какая-то система управления конфигурацией, например, puppet, вы можете разработать решение на основе 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.
Если вы используете RHEL6+, файл conf находится по адресу /etc/pam_ldap.conf и не /etc/openldap/ldap.conf, Если вы положите pam_groupdn вход туда, тогда он будет работать как задумано. Лучший способ сделать это - скопировать ldap.conf в pam_ldap.conf или создайте символическую ссылку.