Прежде чем вы посмеетесь надо мной и скажете: «Если вы хотите Active Directory, используйте Windows» или скажите мне использовать Google, выслушайте меня.
Моя компания очень сильно полагается на AD. Нет, на данный момент мы с ней связаны, и как компания из списка Fortune 10 это не меняется. Однако в нашей среде много систем * nix (в основном RHEL и SLES), и мне еще предстоит найти хороший механизм для интеграции с Active Directory в качестве источника идентификации. По крайней мере, мне нужно что-то, чтобы предоставить следующее:
Лучшие решения, которые я нашел, следующие:
Центрифуги. . . просто некрасиво. Я никогда не был настоящим фанатом. Кроме того, для нужд моей компании мы не можем использовать Centrify-Express, так что это не бесплатно и без неограниченной лицензии. Однако это лучшее решение, которое мы нашли, и я отчаянно пытаюсь найти что-то еще.
PBIS Open - это то, к чему я склоняюсь. Это то, что VMware использует в серверной части vShield, и работает очень хорошо. Для настройки требуется всего несколько команд, он поддерживает группы AD и нет вторичной системы управления идентификацией - он напрямую общается с AD. Единственная причина, по которой я не иду по этому пути, заключается в том, что мне нравятся нативные решения, и если есть лучший способ сделать это, который уже включен в современные дистрибутивы, я полностью за него.
SSSD + SELinux отлично звучал. Его неприятно настраивать, но он гибкий, нативный и поддерживается большинством современных дистрибутивов. Единственное, чего ему не хватает (насколько я понимаю), так это поддержки групп AD. Во многих статьях предлагается использовать FreeIPA или что-то подобное для добавления этой функциональности, но при дальнейшем чтении это нарушает требование 5 и в основном создает службу идентификации посредника. Меня не интересует в основном дублирование AD или настройка доверия к вторичной службе идентификации.
Другие варианты kludge, которые я использовал, включают использование Puppet (который мы используем) для выталкивания / etc / password, shadow, group files на конечные точки, но это требует разработки, это невероятно косвенно, и я мог видеть, что что-то идет плохо. Лучшим вариантом было бы добавить SSSD + SELinux к идее Puppet. Хотя это упростило бы катастрофу, это все же катастрофа.
Что мне не хватает, что вы используете и что это за «новая горячность», которую я не учел для решения головной боли интеграции Linux AD?
Ваши решения здесь: FreeIPA или Centrify / PowerBroker. FreeIPA является частью вашей стандартной подписки RHEL, поэтому уже есть некоторая экономия.
FreeIPA можно запускать в режиме, в котором все пользователи и группы могут поступать из Active Directory. В FreeIPA вы могли бы только отображать этих пользователей и группы в специфичные для POSIX среды, такие как правила SUDO, общедоступные ключи SSH, определения управления доступом на основе хоста, назначения контекста SE Linux и так далее. Для этого вам необходимо сопоставить некоторых из ваших пользователей / групп AD с некоторыми группами в FreeIPA, но это не дублирование информации, а изменение ее частями, не относящимися к AD.
Способ, которым FreeIPA реализует совместимость с Active Directory, заключается в том, что он представляет собой своего рода лес, совместимый с Active Directory. Этого достаточно, чтобы позволить пользователям AD использовать ресурсы FreeIPA через доверительные отношения между лесами, но недостаточно, чтобы пользователи FreeIPA могли получать доступ к системам Windows на другой стороне доверия. Кажется, вам интересна первая часть, так что это должно быть нормально.
Благодаря FreeIPA 4.1, который уже является частью бета-версии RHEL 7.1 (надеюсь, RHEL 7.1 выйдет «скоро»), у нас есть мощный механизм для сохранения переопределений для пользователей и групп AD в FreeIPA, а SSSD способен обнаруживать их все на гранулярность по серверу.
Я действительно хотел бы услышать, что вы подразумеваете под «настоящими группами AD», когда говорите о SSSD. Более новые версии SSSD не требуют, чтобы группы имели атрибуты POSIX и в основном считывают членство в группах из TokenGroups, если используется поставщик AD.
Кроме того, в RHEL-7.1 (восходящий поток 1.12+) SSSD получил возможность выполнять проверки контроля доступа с использованием политик GPO.
Не стесняйтесь приходить и писать в список sssd-users, если у вас есть конкретный вопрос.
Предложение Redhat хорошо освещено здесь:
Распространенная мудрость об аутентификации Active Directory для серверов Linux?
В моих недавних установках это было сделано через SSSD (встроенный) и групповые фильтры ldap или sssd.conf.
Что именно нужно вашим пользователям Linux делать в системах?
Я использую версию PBIS с открытым исходным кодом. В версии 6 я обнаружил, что если я не входил в систему какое-то время (например, месяцы), когда я входил в систему, время ожидания истекало. По крайней мере, так было для многих машин. У меня не было такой проблемы с версией 8.
Я нашел PBIS достаточно хорошим. Это позволило мне установить параметры, о которых я заботился (домашний каталог по умолчанию, предположить домен для входа в систему, установить группу с доступом и т. Д.).
Больше ничего не пробовал. Но могу сказать, что доволен PBIS.
Для его установки есть модуль Puppet (моя версия: https://github.com/etlweather/puppet-pbis ).
как насчет winbind + samba + kerberos?
проверил
проверил
/ var / log / secure? проверил
он позволяет как группы объявлений, так и пользователей объявлений в локальных группах, проверено
freeipa не требуется, проверено
Я тоже использую Winbind + Kerberose и отлично работаю в течение многих лет, но теперь я все переношу на Pbis, так как уже много лет использую его на некоторых машинах, и меня это устраивает. но, поскольку вам также нравятся собственные решения, я начну тестирование интеграции sssd, как указано в этом документе от RedHat. https://www.redhat.com/en/files/resources/en-rhel-intergrating-rhel-6-active-directory.pdf
он имеет разные сценарии интеграции AD.