Прежде чем Вы будете смеяться надо мной и говорить, "Если Вы хотите Active Directory, используйте Windows" или скажите мне использовать Google, выслушивать меня.
Моя компания полагается очень в большой степени на AD. Нет, мы замужем за ним в этой точке, и как компания Fortune 10, это не изменяется. Однако у нас есть много из *, отклоняют системы в нашей среде (главным образом RHEL и SLES), и я должен все же найти хороший механизм для интеграции с Active Directory как источник идентификационных данных. По крайней мере мне нужно что-то для обеспечения следующего:
Главные решения, которые я нашел, следующие:
Centrify... просто ужасно. Я никогда не был настоящим поклонником. Кроме того, для потребностей моей компании мы не можем использовать Centrify-экспресс, таким образом, это не свободно, и нет никакой неограниченной лицензии. Однако это - лучшее решение, которое мы нашли, и я отчаянно пытаюсь находить что-то еще.
Открытый PBIS - то, к чему я склоняюсь. Это - то, что VMware использует в бэкенде vShield, и это работает вполне прилично. Это только требует, чтобы несколько команд разбудили набор, это поддерживает AD группы, и нет никакой вторичной системы управления идентификационных данных - это говорит непосредственно с AD. Единственная причина для меня не хождение, которое путь - то, что мне нравятся встроенные решения, и если существует лучший способ сделать это, который уже включен в современные дистрибутивы, я - все для него.
SSSD+SELinux звучал великолепно. Это противно для установки, но это является гибким, собственным, и поддерживаемое большинством современных дистрибутивов. Единственной вещью, в которой это испытывает недостаток (от того, что я понимаю) является поддержка AD групп. Много статей предлагают усилить FreeIPA или что-то подобное для добавления этой функциональности, но на дополнительные материалы для чтения, это нарушает требование 5 и в основном создает сервис идентификационных данных посредника. Я не интересуюсь в основном дублированием AD, или установка доверяют вторичному сервису идентификационных данных.
Другие опции клуджа, которые я бросил вокруг, включают Марионетку использования (который мы используем) выставить/etc/password, тень, файлы группы к конечным точкам, но это требует разработки, это является невероятно косвенным, и я видел, что что-то шло на юг плохо. Более оптимальный вариант добавил бы SSSD+SELinux к Марионеточной идее. В то время как это упростило бы аварию, это - все еще авария.
Что я пропускаю, что Вы используете, и какова "новая жаркость", которую я не объяснил для решения головной боли интеграции AD Linux?
Здесь вы можете найти решения 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 (upstream 1.12+), SSSD получил возможность выполнять проверки контроля доступа с использованием политик GPO.
Не стесняйтесь приходить и писать в список sssd-users, если у вас есть конкретный вопрос.
а что насчет 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-интеграции.