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


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

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

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

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

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

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

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

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


12
2017-09-15 08:53


Источник




Ответы:


Несколько предложений, которые у меня были бы:

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

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

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

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

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

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

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


10
2017-09-15 14:04



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


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

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

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

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

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

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


2
2017-09-21 04:09





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

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

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

Это примерно так же безопасно, как я могу себе представить.


1
2017-09-23 19:45