Управление учетными данными сервера для Linux и Windows

12

Мы являемся относительно небольшим магазином (по количеству системных администраторов) с набором серверов RHEL, Solaris, Windows 2003 и Windows 2008; всего около 200 серверов.

Для наших учетных записей администраторов ( rootв Linux и admnistratorв Windows) у нас есть схема паролей, которая зависит от расположения центра обработки данных и нескольких других задокументированных свойств сервера.

В Linux наша текущая практика - создавать общую непривилегированную учетную запись, где мы могли suбы root. В системах на базе Windows мы создаем дополнительную учетную запись с правами администратора. Обе эти учетные записи имеют один и тот же пароль.

Это оказалось очень неэффективным. Когда кто-то покидает наш магазин, мы должны:

  1. Изменить схему пароля для учетных записей администратора
  2. Создайте новый пароль администратора для каждого сервера
  3. Придумайте новый пароль учетной записи не администратора
  4. Коснитесь каждого сервера и измените пароли

Я хотел знать, может ли кто-нибудь в аналогичной среде предложить более разумный способ управления этими учетными данными. Некоторая важная информация:

  • Хотя большинство наших серверов являются частью нашего домена AD, не все.
  • Мы управляем всеми нашими Linux-серверами с помощью Puppet (аутентификация по ключу была вариантом, о котором я думал, но он решит только проблему № 3 сверху).
  • Мы предоставляем серверы Linux с Cobbler.
  • Около 10% нашего оборудования предназначено для VMWare. В этих случаях мы используем шаблоны VMWare для серверных сборок.

Любые идеи или предложения будут с благодарностью. Это проблема, которая существует в течение некоторого времени, и я, наконец, хочу ее решить.

Бельмин Фернандес
источник

Ответы:

10

Вот несколько предложений:

  • На серверах, подключенных к Windows AD, пароли локальных администраторов могут быть установлены с помощью групповой политики с помощью параметров групповой политики (GPP) или сценария запуска компьютера. См. Http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/b1e94909-bb0b-4e10-83a0-cd7812dfe073/

  • Ограничьте создание локальных учетных записей на серверах Windows, если это не требуется. Используйте учетные записи AD, когда это возможно.

  • Используйте компьютер LDAP для Linux для аутентификации учетных записей администратора в AD. Это несколько упрощает управление аккаунтом. А когда администратор просто отключил в одном месте и без доступа, то вы можете очистить сторону Linux на досуге.

  • Используйте файл / etc / sudoers для конкретной учетной записи администратора в linux, тогда администраторам не нужен пароль root. Это может быть хорошо в вашем случае, потому что тогда им редко понадобится пароль root, чтобы его можно было заблокировать. обновленный

  • Храните пароли root и локального администратора в пароле, а не в общих знаниях. Некоторые сейфы с паролями имеют делегирование и регистрацию, поэтому вам может даже не потребоваться сбросить пароль, если у человека никогда не было к нему доступа.

  • Автоматизируйте процесс сброса пароля для учетных записей root и admin. Для этого могут быть написаны сценарии как для Linux, так и для Windows, так что это может сэкономить вам время и не обременительно.

Надеюсь, это поможет.

Берни Уайт
источник
Моя проблема с LDAP - единственная точка отказа. Я бы предпочел управлять счетами через Puppet. И ценю ваши предложения. Спасибо @ Берни!
Бельмин Фернандес
1
@Beaming Если вы используете Active Directory, у вас может быть более одного контроллера домена (без единой точки отказа), а затем укажите имя домена DNS, например domain.com, чтобы получить все контроллеры домена для запроса LDAP. Или вы можете настроить запись DNS для указания на определенные контроллеры домена, если вы хотите, чтобы два или три отвечали на LDAP, как ldap.domain.com. Я не использовал Puppet, но ключ к легкому администрированию пользователей не в том, где это возможно. Вполне вероятно, что Puppet в любом случае сможет подключиться к внутреннему LDAP-серверу, если вы предпочтете его таким образом.
Берни Уайт
Договорились, что AD это путь сюда. С 2+ контроллерами домена вероятность полного падения AD невелика, но также, если это произойдет, у вас, вероятно, будут гораздо большие проблемы. Поддерживайте локальные корневые учетные записи на ваших серверах linux, которые будут использоваться в качестве крайней меры, если ничего не поможет.
EEAA
2
@ Берни - относительно твоего третьего пункта. При использовании sudo никому не нужно знать пароль пользователя root. Указывая «NOPASSWD» в записи sudo, пользователю не нужно вводить свой собственный пароль. Это не имеет ничего общего с паролем root.
EEAA
@ErikA +1 Очень верно. Удалена ссылка на NOPASSWD, так как это не помогает ответить на вопрос /
Берни Уайт
2

Вы можете попробовать и посмотреть, работает ли FreeIPA на вас.

Вы можете управлять доступом пользователей к хостам из центрального расположения. Как подсказывают другие, вы можете увидеть, подходит ли вам sudo для доступа на уровне root. Freeipa поддерживает sudoers в LDAP, поэтому вам не нужно поддерживать его на каждом сервере, через марионетку и т. Д.

Freeipa поддерживает клиенты Linux, Solaris и Windows. Вы можете потерять определенные функции AD, и я не уверен, какие другие ограничения будут иметь клиент Windows.

Он имеет функции репликации, поэтому вы можете избежать SPOF. Бэкэнд - это LDAP, так что вы можете повторно использовать многие инструменты, которые люди используют для LDAP, такие как сценарии резервного копирования.

Он поддерживает управление доступом на основе хоста, поэтому вы можете сказать «пользователь X может входить только на Y-серверы».

Он также предлагает синхронизацию AD . Я не человек Windows, поэтому я понятия не имею, что это вообще значит.

Не сейчас
источник
1

Не используйте стандартную учетную запись администратора. Со стороны Windows создайте учетную запись пользователя и учетную запись администратора для каждого пользователя, которому необходим доступ администратора. Вы можете использовать любой инструмент для синхронизации с UNIX.

Если кто-то уходит, то вам просто нужно удалить его учетные записи пользователей и администраторов.

Чтобы защитить стандартную учетную запись администратора, дайте ей действительно длинный и сложный пароль, а затем убедитесь, что у любого человека есть только половина. Если им нужно использовать весь аккаунт, им нужно найти кого-то, у кого есть другая половина.

Это настолько безопасно, насколько я могу думать.

mauvedeity
источник