Назад | Перейти на главную страницу

Управление пользователями и разрешениями Linux в среде AD

Проблема: Централизованное управление пользователями и управление разрешениями пользователей для потребностей пользователей в доступе к ресурсам (доступ к службам, домашним каталогам, присоединение к локальным группам пользователей, разрешения файловой системы и т. Д.) На серверах Linux посредством членства в группах в Active Directory.

Задний план: У нас есть несколько серверов Linux, некоторые CentOS и другие Ubuntu, которые используются для разработки, веб-хостинга, хостинга баз данных, обслуживания PXE и ​​т. Д. У нас также есть централизованная среда Active Directory, где все пользователи добавляются в группы и получают членство в группах. на момент присоединения к организации.

Пример: Боб и Алиса присоединяются к организации, их добавляют в соответствующие группы в AD, и теперь у них есть доступ к SSH или MySQL на одном или нескольких наших серверах Linux. После ухода Боба мы удаляем его из группы (групп) AD, и он больше не имеет доступа к серверам Linux для SSH, MySQL и т. Д.

Ноты: Как подойти к такой задаче? Есть ли в Linux уже доступный набор утилит, позволяющих выполнять этот тип операций? Доступ, который нам нужно предоставить пользователю, будет зависеть от членства в группе пользователей, членом которой он является, из Active Directory. Например, всем участникам группы разработки AD потребуется доступ по SSH, MySQL и домашний каталог на серверах управления версиями Linux 1 и 2. Каждый, кто входит в группу системных администраторов AD, должен иметь доступ по SSH и Разрешения SU для всех серверов Linux и т. Д. Я просмотрел ряд существующих статей о serverfault и не нашел ничего, что соответствовало бы перечисленным здесь потребностям.

Я знаю два основных метода:

Метод первый: Microsoft Управление идентификацией для UNIX - Это позволяет вам использовать ActiveDirectory как сервер NIS.
Это работает практически с любыми вариантами * NIX (все они поддерживают NIS) и имеет все преимущества (и недостатки) NIS. Он также официально поддерживается Microsoft, а это значит, что вам есть кому позвонить, если что-то сломается.

Метод второй: pam_ldap/nss_ldap (или аналогичные, более новые системы).
Это работает с любым современным вариантом * NIX, способным аутентифицироваться по каталогам LDAP, и в наши дни может быть включен по умолчанию в Ubuntu и CentOS. Он немного более надежен / современен, чем хакерская программа в стиле NIS в Method One, но с меньшей вероятностью будет официально поддерживаться Microsoft.

Оба эти метода требуют, чтобы вы расширили пользователей и группы AD до пользователей и групп POSIX соответственно, чтобы для ваших систем * NIX были пригодные для использования POSIX UID и GID - Microsoft предоставляет эту возможность в Active Directory.
Дополнительным преимуществом второго метода, описанного выше, является то, что вы можете дополнительно расширить количество пользователей, чтобы вы могли использовать Открытый ключ OpenSSH LDAP патч, который позволяет хранить ключи SSH в LDAP и устраняет задачу синхронизации. authorized_keys файлы в вашей сети.

Судя по тому, что я здесь читаю, вы хотите, чтобы все остальные типичные для Linux вещи хранились в типичном для Linux стиле, а членство в группах просто исходило от AD?

Большинство примеров, которые вы можете найти, будут говорить о выполнении извлечения из AD / LDAP (возможно, Kerberos auth и LDAP для всех пользователей), похоже, вам просто нужен LDAP для групповых вещей. Если я ошибаюсь, вам также нужно будет сделать кое-что из PAM.

В зависимости от того, какая именно версия (она была изменена с CentOS / RHEL между версиями 5 и 6), вы можете использовать для этого «nss_ldap» или «sssd». sssd новее. Трудно сказать, что более гибко, поскольку они кажутся гибкими по-разному. sssd кажется более гибким в настройке определенных частей для получения из определенных источников, в то время как nss_ldap кажется более гибким в отношении используемой схемы LDAP. Вам потребуются установленные соответствующие пакеты. sssd-client, sssd-tools, sssd, libnss-sss, libnss-ldap и / или nss_ldap. (аутентификационный материал - pam_ldap или sssd)

Группы в AD должны иметь уникальный числовой идентификатор. По сути, вам нужно получить полное определение группы из AD через LDAP, а не только членство в группе (полное определение группы - это в основном имя, уникальный числовой идентификатор и членство). Возможно, этого удастся избежать с помощью sssd и настроить его для поиска идентификаторов групп в файлах и членства в группах из LDAP. На самом деле правильным является расширение схемы AD соответствующими расширениями UNIX, чтобы в ней были данные пользователя / группы RFC2307 или RFC2307bis.

В /etc/nsswitch.conf вам понадобится group: files ldap или group: files sss. Вы можете поместить "файлы" вторыми, а не первыми.

nss_ldap («ldap» в nsswitch.conf) настраивается через /etc/ldap.conf и задокументирован в пакете nss_ldap. Вам нужно будет установить uri, binddn, bindpw, nss_base_group, pam_member_attribute, nss_map_objectclass group, nss_map_attribute.

sssd настраивается через /etc/sssd/sssd.conf. Сконцентрируйтесь на материалах nss и id_provider, а не на материалах pam и auth_provider. Прочтите справочные страницы sssd.conf, sssd-ldap и sssd. Вам нужно будет настроить «домен» и настроить некоторые элементы «ldap_group» вместо него вместе с базовыми элементами типа id_provider и ldap_uri.

Примечание: в настоящее время я запускаю как nss_ldap, так и sssd в среде OpenLDAP. Прошел год с тех пор, как я использовал nss_ldap / pam_ldap в среде AD.

Возможно, стоит также изучить возможности Samba. Обычно он используется d для общего доступа к файлам / принтерам, но материалы для входа в систему и контроллеры домена могут быть настроены так, как вам нужно.

Взгляни на Аналогично Open (или теперь называется PowerBroker Identity Services Open Edition). Я использовал Likewise open в предыдущей работе и отлично работал с Samba и нашими разработчиками.