Мудрость в отношении аутентификации Active Directory для серверов Linux?

re: "Коммерческие решения, такие как Centrify и Likewise, всегда работали, но казались ненужными, поскольку эта возможность встроена в ОС".

Ну, я думаю, что многие из нас годами слышали, что операционная система XYZ наконец-то взломала загадку интеграции AD. ИМХО проблема в том, что для поставщика ОС интеграция с AD является функцией флажка, то есть они должны предоставить что-то, что вроде как работает, чтобы получить этот флажок, и этот флажок обычно работает только на...

1. их платформа ОС и
2. текущая версия этой платформы и
3. против более поздней версии Active Directory.

Реальность такова, что большинство сред не являются монолитными с точки зрения поставщика ОС и версии ОС и будут иметь более старые версии AD. Вот почему такой поставщик, как Centrify, должен поддерживать более 450 версий UNIX/Linux/Mac/etc. против Windows 2000 до Windows 2012 R2, а не только RHEL 7 снова Windows 2012 R2.

Кроме того, вам необходимо учитывать способ развертывания AD, а также то, что интеграция AD поставщика ОС поддерживает контроллеры домена только для чтения (RODC), односторонние доверительные отношения, поддержку нескольких лесов и т. Д. А что, если у вас Существующее пространство UID (которое у вас будет), существуют ли инструменты миграции для переноса UID в AD. Поддерживает ли поддержка AD поставщика ОС возможность сопоставления нескольких UID с одним AD в ситуациях, когда пространство UID не является плоским. А как насчет... ну, вы поняли.

Тогда есть вопрос поддержки...

Дело в том, что интеграция с AD может показаться легкой в ​​концептуальном плане и может быть "бесплатной" с последней ОС поставщика, и, вероятно, может работать, если у вас есть только одна версия ОС от одного поставщика и у вас есть vanilla AD, которая является последней версией, и у вас есть контракт на премиум-поддержку с поставщиком ОС, который сделает все возможное, чтобы устранить возникшие проблемы. В противном случае вы можете рассмотреть вопрос о специализированном решении третьей стороны.

Параметр Средства сервера для информационной службы сети (NIS) в средствах удаленного администрирования сервера (RSAT) устарел.

Это неудивительно для меня - NIS свидетельствует о том, что Sun ненавидела нас и хотела, чтобы мы были несчастными.

Используйте собственные параметры LDAP, Samba Client, Kerberos или других производителей.

Это хороший совет. Учитывая варианты, которые я бы сказал "Использовать собственный LDAP (через SSL, пожалуйста)") - для этого есть много вариантов, два из которых мне больше всего знакомы: pam_ldap + nss_ldap (из PADL) или комбинированный nss-pam- ldapd (который возник как форк и постоянно совершенствуется).

Поскольку вы спрашиваете о RedHat конкретно, стоит отметить, что RedHat предоставляет вам другие альтернативы, использующие SSSD.
Если ваша среда полностью-RedHat (или просто имеет большое количество систем RedHat), то изучение официально поддерживаемого "способа ведения дел RedHat", безусловно, стоит вашего времени.

Поскольку у меня нет опыта работы с RedHat / SSSD, я просто использую документы, но они выглядят достаточно надежными и хорошо продуманными.

Из предложенных методов, позвольте мне дать вам список плюсов / минусов:

Прямо вверх Kerberos/LDAP

Плюсы: отлично работает при правильной настройке. Редко ломается, отказоустойчива, переживет глюки сети. Никаких изменений в AD, изменений схемы, доступа AD к администратору не требуется. Свободно.

Минусы: относительно сложно настроить. Несколько файлов должны быть изменены. Не будет работать, если сервер аутентификации (Kerberos/LDAP) недоступен.

Winbind

Плюсы: простота настройки. Базовая функциональность sudo. Свободно.

Минусы: поддержка интенсивная. Не устойчивый к сети. Если есть проблема с сетью, машины Linux могут быть исключены из AD, требуя перерегистрации сервера, задача поддержки. Требуется доступ к учетной записи администратора AD. Может потребоваться внести изменения в схему в AD.

Центрифугировать / и т. Д.

Плюсы: относительно прост в настройке.

Минусы: Изменяет функциональность sudo на проприетарную, сложнее в поддержке. Стоимость лицензии на сервер. Нужны дополнительные навыки для управления.

SSSD

Плюсы: один конфигурационный файл, прост в настройке. Работает со всеми настоящими и будущими методами аутентификации. Масштабируется, растет вместе с системой. Будет работать в отключенном режиме. Сеть устойчива. Нет необходимости вносить какие-либо изменения в схему AD. Нет необходимости в учетных данных администратора AD. Бесплатно, поддерживается.

Минусы: нет сервисов win, таких как автоматическое обновление DNS. Необходимо настроить общие ресурсы CIFS.

Резюме

Глядя на преимущества и недостатки, SSSD является явным победителем. Если это новая система, нет никаких оснований использовать что-либо, кроме SSSD. Это интегратор, который работает со всеми существующими методами аутентификации и может расти вместе с системой, потому что новые методы могут быть добавлены при их наличии. Он использует родные методы Linux и является гораздо более надежным и быстрым. Если кэширование включено, системы будут работать даже в полностью отключенных системах с полным отказом сети.

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

У Centrify были проблемы с интеграцией, которые могли быть дорогостоящими. Большинство ошибок исправлено в новой версии, но есть и такие, которые вызывают головные боли.

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

Должен прокомментировать это:

Стоит отметить, что Centrify обладает дополнительными функциями, хотя это может быть обеспечено отдельным управлением конфигурацией. (Кукольный и т. Д.)

Как человек, который работает с Centrify, не уверен, откуда этот комментарий. Посмотрите на это, и вы увидите, что есть множество функций, которые вы не получаете с помощью инструмента config mgmt ala Puppet. Например, поддержка сопоставления нескольких идентификаторов UID одной учетной записи AD (зон), поддержка полных доверительных отношений домена Active Directory (что решение Red Hat описывает на странице 3, которые оно не поддерживает) и т. Д.

Но вернемся к этому руководству Red Hat. Здорово, что Red Hat публикует это, варианты хороши. Обратите внимание, что это дает клиенту 10 вариантов базовой интеграции AD. Большинство опций являются вариациями Winbind, и на странице 15 перечислены преимущества и недостатки каждого из них, и для каждого из них необходимо выполнить множество ручных шагов (с соответствующими недостатками / отсутствием функциональности, как указано выше). Преимущество Centrify Express состоит в том, что согласно другим комментариям выше:

1. это просто установить без всех ручных шагов и...
2. бесплатно и...
3. не ограничивается Red Hat V7, что важно, поскольку вопрос касался Linux, а не только одного варианта - Centrify поддерживает более 300 разновидностей *nix и...
4. поддерживает все варианты Windows AD, не только Windows 2008. Они опубликовали сравнение Centrify и Winbind здесь, но это не с открытым исходным кодом.

В конце концов, все сводится к тому, что вы хотите сами сделать это или воспользоваться коммерческим решением. Действительно дело в том, где ты и как проводишь время.