Как администраторы поддерживают учетные записи пользователей на сотнях серверов Linux?

Имея дело с сотнями серверов RHEL, как мы можем поддерживать локальные корневые учетные записи и учетные записи пользователей сети? Есть ли активное решение типа каталога, которое управляет ими из центрального местоположения?

Одним из центральных компонентов Active Directory является LDAP, который доступен в Linux в форме OpenLDAP и 389DS (и некоторых других). Кроме того, другой основной компонент Kerberos доступен в форме MIT Kerberos и Heimdal . Наконец, вы даже можете подключить свои машины к AD.

Вы можете попробовать с Puppet для управления пользователем:

Зачем использовать Puppet для управления учетными записями пользователей? (а не NIS, LDAP и т. д.)

Одним из преимуществ управления учетными записями пользователей в puppet является то, что он децентрализован. Каждая учетная запись пользователя - это обычная учетная запись пользователя на управляемом сервере. Ничего особенного в пользовательских учетных записях, создаваемых puppet, нет, кроме того факта, что они были созданы puppet, а не администратором. Приятно то, что если основной хост умирает, мы не теряем аутентификацию. Это означает, что нашему серверу puppetmaster (или серверу NIS / LDAP) не нужно предъявлять какие-либо особые требования к времени безотказной работы. В случае возникновения чрезвычайной ситуации мы можем сосредоточиться на том, чтобы запустить наши производственные серверы, и сосредоточиться на том, чтобы поднять Puppetmaster по мере необходимости. Недостатком этого является то, что марионетка не обязательно предназначена для управления «обычными» учетными записями пользователей (в отличие от системных учетных записей). Самый большой способ это придумать, это то, что хотя вы можете установить пароль в Puppet, Puppet постоянно следит за настройками системы (хорошо) и, если обнаружит, что пароль изменился, сбросит его. (плохо) Я не хочу отслеживать пароли пользователей в нашей сети, поэтому должен быть способ установить пароль и сделать так, чтобы марионетка перестала контролировать этот пароль. К счастью, как только вы поймете хитрость, это на самом деле довольно легко. Но сначала давайте разберемся с некоторыми определениями.

http://docs.puppetlabs.com/pe/2.5/console_auth.html

Как упоминает 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 при строгой (э) аутентификации пользователя.