Как администраторы поддерживают учетные записи пользователей на сотнях серверов Linux?
Имея дело с сотнями серверов RHEL, как мы можем поддерживать локальные корневые учетные записи и учетные записи пользователей сети? Есть ли активное решение типа каталога, которое управляет ими из центрального местоположения?
5 ответов
Одним из центральных компонентов Active Directory является LDAP, который доступен в Linux в форме OpenLDAP и 389DS (и некоторых других). Кроме того, другой основной компонент Kerberos доступен в форме MIT Kerberos и Heimdal. Наконец, вы даже можете подключить свои машины к AD.
Вы можете попробовать с Puppet для управления пользователем:
Зачем использовать Puppet для управления учетными записями пользователей? (а не NIS, LDAP и т. д.)
Одним из преимуществ управления учетными записями пользователей в puppet является то, что он децентрализован. Каждая учетная запись пользователя - это обычная учетная запись пользователя на управляемом сервере. Ничего особенного в пользовательских учетных записях, создаваемых puppet, нет, кроме того факта, что они были созданы puppet, а не администратором. Приятно то, что если основной хост умирает, мы не теряем аутентификацию. Это означает, что нашему серверу puppetmaster (или серверу NIS/LDAP) не нужно предъявлять какие-либо особые требования к работоспособности. В случае возникновения чрезвычайной ситуации мы можем сосредоточиться на том, чтобы запустить наши производственные серверы, и сосредоточиться на том, чтобы поднять Puppetmaster по мере необходимости. Недостатком этого является то, что марионетка не обязательно предназначена для управления "обычными" учетными записями пользователей (в отличие от системных учетных записей). Самый важный способ - это то, что, хотя вы можете установить пароль в Puppet, Puppet постоянно следит за настройками системы (хорошо) и, если обнаружит, что пароль изменился, сбросит его. (плохо) Я не хочу отслеживать пароли пользователей в нашей сети, поэтому должен быть способ установить пароль и сделать так, чтобы марионетка перестала контролировать этот пароль. К счастью, как только вы поймете хитрость, это на самом деле довольно легко. Но сначала давайте разберемся с некоторыми определениями.
Как упоминает SvenW, есть 389DS и Kerberos. Начиная с RHEL 6.2, Red Hat включила IPA в дистрибутив (и, следовательно, также в CentOS). Это полный пакет управления идентификацией, который включает 389DS и Kerberos, с контролем на основе политик аутентификации и авторизации, а также, при необходимости, DNS. Его можно даже настроить для односторонней или двусторонней синхронизации с Active Directory.
IPA в значительной степени требует SSSD на хостах RHEL, но работает без него. Я даже тестировал подключение Solaris 10 к IPA (работает, но немного сложновато). IPA довольно прост в настройке для RHEL-хостов.
Это основано на проекте FreeIPA.
Для ваших учетных записей пользователей сети OpenLDAP, как SvW упоминается.
Вам также следует обратиться к "Системам управления конфигурациями" для управления локальными учетными записями и всем остальным на ваших серверах. Взгляните на CFEngine, Bcfg2, Puppet и Chef. Если вы используете AWS, у них есть шеф-повар с OpsWorks.
Если вам действительно нужно управлять более чем 100 серверами, у вас есть 10 системных администраторов или вы используете программное обеспечение для управления конфигурацией.
Это может быть очевидным ответом, но "использовать активный каталог". Вам нужно немного изменить нашу схему AD, чтобы включить специфичные для Unix поля, но как только вы это сделаете, у вас будет единый каталог всех ваших учетных записей пользователей, который работает на разных платформах.
Возможно, менее полезно, если вы работаете в Unix-магазине - но я не видел многих из них. Но AD на самом деле является довольно хорошей связью ключевых элементов LDAP и Kerberos. Я нахожу это немного ироничным на самом деле.
Но то, что вы получите "бесплатно", - это кроссплатформенные учетные записи и интеграция с Kerberos, так что вы можете выполнять экспорт NFSv4 с использованием "распознанных CIFS" списков ACL и монтирования krb5i/p NFS с надежной (er) аутентификацией пользователя.
Как упоминал @Sven, LDAP является основным компонентом аутентификации.
Мы даже можем рассмотреть следующие инструменты для централизованного управления пользователями в Linux SSSD, FreeIPA, Identity manager by redhat, Centrify Zero trust, Jumpcloud и т. Д. Если у вас более 100 серверов , выберите решение Redhat ( Identity Manager) и если серверов меньше 100 мы можем выбрать FreeIPA.
Мы даже можем выполнить настройку доверия с AD, используя FreeIPA (https://www.freeipa.org/page/Main_Page) или IDM, с помощью которого мы можем рассматривать присутствующих пользователей, если AD может войти на ваши серверы.
Как вы упомянули, у вас есть серверы RHEL, только тогда вы можете продолжить работу с IDM и для поддержки учетной записи root отключите прямой вход для root, и ни один пользователь не должен переключаться на root. Для управления паролями пользователей root рассмотрите менеджер паролей.