Pull to refresh

Comments 15

Расскажите зачем использовать Active Directory в инфраструктуре с Линуксами? Все равно ведь большая часть функционала AD недоступна на Линуксах. Есть же нативные решения типа FreeIPA или 389ds.
Есть же AD Samba 4, вполне себе нативное решение. Уже 2 года пользуемся и не жалуемся.
Даже достаточно одного OpenLDAP. Active Directory тут абсолютно избыточен.
Я прошу пардону, не уточнил в начале статьи. Общая структура такова:
Есть парк клиентских машин на Windows. Соответственно, имеется и инфраструктура Active Directory. Linux хосты — это сервера, выполняющие те или иные роли.
Стандартная ситуация для среднего и крупного бизнеса: инфраструктура на Windows/AD, но есть виртуальные сервера с Linux. В такой ситуации AD-аутентификация для администрирования Linux-серверов — насущная необходимость. Наконец-то, не прошло и двух десятков лет, как это стало относительно легко сделать, благодаря sssd.
В целом уже ответили, но добавлю свои 5 копеек. 100-150 виндовых серверов и 15-20 линуксовых. Городить freeipa — вот это точно будет оверхедрм, а вот ренение автора прям огонь! Жаль что мне это уже не актуально, а то точно бы внедрил =)
Одно плохо, в linux нет других способов повысить права кроме как через suid бит. Что не безопасно.
dizaar Подскажите. Сейчас есть ограничение на длину имени Linux хоста при вводе в домен Active Directory в 16 символов. В существующем домене Active Directory с windows и Linux хостами можно ли как-нибудь обойти это ограничение?
Сам с таким столкнулся при первичной настройке sssd. Решается довольно просто — в секции [sssd] добавляется переменная ad_hostname. В нее нужно вписать сокращенное имя рабочей станции, которое можно посмотреть через klist -tke, либо в свойствах учетной записи рабочей станции в домене. Главное, знак доллара в конце не забыть.
Из плюсов вижу только хранение ключей в АДэ и то если есть доступ к контроллерам домена.
В большой сложившейся инфраструктуре расширять схему АДэ админы просто так не дадут, да и близко не подпустят, потому что чревато.
Из минусов:
— полуподпольный скрипт и хранение пароля на диске, т.е. предполагается что его регулярно менять нельзя, иначе всё развалится
— sssd это конечно последний новый писк моды, но вот нарвался на две неприятности которые никак не победить:
1. если в имени группы есть пробелы и символы "_" sssd делает лапки кверху при разборе имени группы.
2. на учётке пользователя порядка 400 групп (не задавайте вопросы «зачем»), id -a вытягивает список групп пользователя около 1,5 — 4 минут независимо от того что там закешировал sssd (winbind от samba3 делает так же)

Если не заморачиваться на хранение ключей и ролей в АДэ, то всё вполне решается подключением линукс хоста к домену в качестве рабочей станции через winbind samba4. Работает быстро, прозрачная авторизация через kerberos. Для ssh,sudo достатчно один раз прописать доменную группу.
По поводу полуподпольного скрипта — ничего критичного в нем нет — обычный ldapsearch. Пробовал найти вариант бинда от имени рабочей станции, но — увы.
Пункт 1 — по последнему разбору пришлось долго читать километровые логи sssd — там все красиво и логично — и пробелы, и нижний слэш отлично разбираются. Кстати, если Вы внимательно посмотрите на скрины в статье — обе группы с нижним слэшем — и все работает тип-топ.
По поводу второго пункта — ничего не могу сказать, поскольку с такой ситуацией не сталкивался. А насчет «зачем» — всякое бывает) Надо, значит надо)
За winbind думал. Надо будет попробовать снова, не помню, почему данный вариант был отвергнут.
Насчет расширения схемы — согласен, дело опасное. Но данное расширение занимается исключительно добавлением новых атрибутов, а не изменением существующих атрибутов и класов. Опять же, повторюсь, тестовую среду никто не отменял.
по п.1 возможно у меня старая версия sssd
Например, на такую группу «р1 отдел разработки_5» он начинал ставить "_" вместо пробелов.
Увидев в конце "_5" он говорил «Ой, а тут _ уже есть» и, в итоге, представлял эту группу как несколько групп.
В общем, сколько ни есть историй про АДэ и линукс, у каждого свой уникальный случай. :)
Если есть немного денег можно купить продукт Centrify который интегрируется и в AD и в линукс и хорошо справляется с авторизацией и управлением sudo. Однако в реальной пользовательской среде это слегка утопично думать что вы сможете кому-то что-то запретить при их физическом доступе к машине. Элементарно винда не являющаяся частью домена просто ничего не может делать, а линукс вполне себе работоспособен. Как решение для серверной инфраструктуры еще есть смысл внедрять интеграцию с AD, для рабочих станций сомнительно.
Очень рекомендую pbis-open, делает аналогичные штуки, но работает чуть стабильнее чем sssd.
Самое интересное, что решение кроссплатформенное и на яблочных машинах работает идентично.

Ссылка на продукт:
github.com/BeyondTrust/pbis-open/wiki
Спасибо большое. Будем посмотреть.
Sign up to leave a comment.

Articles