Каково общее мнение в 2014 году об аутентификации / интеграции Active Directory для серверов Linux и современных операционных систем Windows Server (ориентированных на CentOS / RHEL)?
За годы, прошедшие с моих первых попыток интеграции в 2004 году, похоже, что передовые практики вокруг этого изменились. Я не совсем уверен, какой метод в настоящее время имеет наибольшую динамику.
В поле я видел:
Winbind / Samba
Straight-вверх LDAP
Иногда LDAP + Kerberos
Microsoft Windows Services для Unix (SFU)
Microsoft управления идентификацией для Unix
NSLCD
SSSD
FreeIPA
Centrify
PowerBroker ( урожденная Аналогично )
Winbind всегда казался ужасным и ненадежным. Коммерческие решения, такие как Centrify и Likewise, всегда работали, но казались ненужными, поскольку эта возможность встроена в ОС.
В последних нескольких установках я добавил функцию роли Microsoft Identity Management для Unix на сервер Windows 2008 R2 и NSLCD на стороне Linux (для RHEL5). Это работало до RHEL6, где отсутствие обслуживания NSLCD и проблемы управления ресурсами памяти вынудили изменить SSSD. Red Hat также, похоже, поддерживает подход SSSD, так что это было хорошо для моего использования.
Я работаю с новой установкой, в которой контроллеры домена являются системами Windows 2008 R2 Core и не имеют возможности добавлять функцию управления удостоверениями для Unix. И мне сказали, что эта функция устарела и больше не присутствует в Windows Server 2012 R2 .
Преимущество установки этой роли заключается в наличии этого графического интерфейса, который позволяет легко и быстро выполнять администрирование пользовательских атрибутов.
Но...
Параметр Средства сервера для информационной службы сети (NIS) в средствах удаленного администрирования сервера (RSAT) устарел. Используйте собственные параметры LDAP, Samba Client, Kerberos или других производителей.
Это делает действительно трудным полагаться, если это может сломать прямую совместимость. Заказчик хочет использовать Winbind, но все, что я вижу от Red Hat, указывает на использование SSSD.
Какой правильный подход?
Как вы справляетесь с этим в вашей среде?
источник
Ответы:
В марте 2014 года Red Hat опубликовала эталонную архитектуру для интеграции Red Hat Enterprise Server с Active Directory . (Этот материал, безусловно, должен быть актуальным и актуальным.) Я ненавижу публиковать это как ответ, но на самом деле это слишком много материала для передачи в поле для ответов.
Этот документ (с исправлениями) находится под пристальным вниманием прессы и, похоже, посвящен новым возможностям Red Hat Enterprise Linux (RHEL) 7. Он был опубликован для саммита на прошлой неделе.
Если эта ссылка устарела, пожалуйста, дайте мне знать, и я обновлю ответ соответственно.
Я лично достаточно надежно использовал WinBind для аутентификации. Очень редко происходит сбой службы, который требует, чтобы кто-то с учетной записью root или другой локальной учетной записью зашел и отскочил от winbindd. Вероятно, это можно решить с помощью надлежащего мониторинга, если вы хотите приложить к этому усилия.
Стоит отметить, что Centrify обладает дополнительными функциями, хотя это может быть обеспечено отдельным управлением конфигурацией. (Кукольный и т. Д.)
Изменить 16/16/14:
Red Hat Enterprise Linux 7 Руководство по интеграции с Windows
источник
Ну, я думаю, что многие из нас годами слышали, что операционная система XYZ наконец-то взломала загадку интеграции AD. ИМХО проблема в том, что для поставщика ОС интеграция с AD является функцией флажка, то есть они должны предоставить что-то, что вроде как работает, чтобы получить этот флажок, и этот флажок обычно работает только на ...
Реальность такова, что большинство сред не являются монолитными с точки зрения поставщика ОС и версии ОС и будут иметь более старые версии 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 свидетельствует о том, что Sun ненавидела нас и хотела, чтобы мы были несчастными.
Это хороший совет. Учитывая варианты, которые я бы сказал «Использовать собственный 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, не уверен, откуда этот комментарий. Посмотрите на это, и вы увидите, что есть множество функций, которые вы не получаете с помощью инструмента config mgmt ala Puppet. Например, поддержка сопоставления нескольких идентификаторов UID одной учетной записи AD (зоны), поддержка полных доверительных отношений домена Active Directory (что решение Red Hat описывает на странице 3, которые оно не поддерживает) и т. Д.
Но вернемся к этому руководству Red Hat. Здорово, что Red Hat публикует это, варианты хороши. Обратите внимание, что это дает клиенту 10 вариантов базовой интеграции AD. Большинство опций являются вариациями Winbind, и на странице 15 перечислены преимущества и недостатки каждого из них, и для каждого из них необходимо выполнить множество ручных шагов (с соответствующими недостатками / отсутствием функциональности, как указано выше). Преимущество Centrify Express состоит в том, что согласно другим комментариям выше:
В конце концов, все сводится к тому, что вы хотите сами сделать это или воспользоваться коммерческим решением. Действительно дело в том, где ты и как проводишь время.
источник