Разверни домен на SAMBA 4 ! (Убей в себе Windows)

Наш ответ санкциям США+Microsoft. Снеси Windows! Разверни домен на SAMBA 4

Дави Империализма Гиену,

         Могучий Сисадминов Класс!

                  Вчера были ОСи лишь у Чемберлена,

                              А нынче есть и у нас!

  Перед системными администраторами небольших организаций (примерно до 80-100 пользователей) частенько возникает вопрос о централизованной аутентификации. И если у их коллег в более крупных конторах вопросов по поводу на чем и чем огораживать пользователей практически не возникает, то у админов обычных ООО и ИП вариантов может несколько. Помимо вышесказанного обратим внимание на то, что админам небольших контор в основном не требуются изощренные политики управления собственной сетью, т.е. возможны некие усеченные варианты. Итак, представим небольшой обзорчик доступных средств и методов вооруженной борьбы за централизованную аутентификацию.    Самый простой вариант — запросить финансирование на покупку MS Windows Server (с каким-то порядковым номером), учитывая тот факт, что большинство пользователей работают на компьютерах под управлением различных настольных версий MS Windows, этот путь наиболее простой и достаточно эффективный. Active Directory решает проблему централизованной аутентификации, внедрения политик и т.д. Решение достаточно масштабируемо, гибко и легко управляемо. Причем в AD возможно интегрировать сервера и рабочие станции на базе ОС Linux. Всем хорошо данное решение, кроме одного — цены. На текущий момент сервер-контроллер домена AD фактически безболезненно может держать только одну могучую роль — роль файлового сервера. Но чаще всего контроллеры доменов оставляют в покое и они занимаются решением только своих активдиректорских проблем. Так как служба AD крайне важна в сети предприятия, то для повышения производительности и файловера контроллеров домена требуется несколько (минимум пара). Также желателен контроллер в каждом из удаленных (обособленных) подразделениях (в терминах M$ - сайтах). А это все лицензии, лицензии, лицензии...

   Следующий вариант по списку, но не по значению, предполагает использование альтернативных служб каталогов или LDAP-серверов. Данные решения качественно срабатывают при использовании клиентов на ОС Linux для централизованной аутентификации. Многие вещи, к каким привыкли администраторы AD, при таком подходе не доступны, напр. политики. Аутентифицировать таким образом можно и клиентов на ОС Windows, используя механизм pgina. Данный вариант активно реализуется компанией Linsoft в гетерогенных средах с использованием такого решения, как 389 Directory Server (ранее Fedora Directory Server)[см.скриншот]. Естественно, вариант дает огромные преимущества в управлении учетными записями пользователей, но требует первоначально хорошего планирования и последующей высокой админской дисциплины при эксплуатации.

  И, наконец, герой нашего повествования — SAMBA 4 в роли контроллера домена AD. Вариант этот самоограничительный. Это надо изначально понимать и принимать. Также как и в случае с альтернативными службами каталогов требуется серьезный подход и первоначальное планирование. Но дальнейшая эксплуатация достаточна проста, особенно в небольших сетях. Планирование однозначно сделает работу комфортнее, если предполагается использование файловых серверов на ОС Linux (а так оно в основном и бывает). Предлагаю остановится на методологических основах развертывания SAMBA 4 в роли контроллера домена AD. В обязательном порядке развертывание контроллера домена на SAMBA 4 следует выполнять с поддержкой дополнительных UNIX-атрибутов по rfc2307. В оригинальном домене AD эта вещь ранее называлась SFU и требовала дополнительной установки. На текущий момент (с Win2K8r2) нужно просто добавить сервис Identity Management for UNIX. Все эти манипуляции добавляют специальные атрибуты типа msSFU30MaxUidNumber в схему AD. Визуально это выглядит как появление специальной вкладки UNUX Attributes [см.скриншот]. Вот тут то и возникает потребность в в планировании и фиксации данных по пользователям и группам. При использовании нескольких файловых Linux-серверов в домене очень желательно, чтобы SIDы «правильно» отображались (маппились) на UIDы и GIDы. Причем на все файловые сервера одинаково, т.е. пользователи и группы на всех доменных файловых серверах получали одинаковые UIDы и GIDы. Это невероятно облегчает жизнь при раздаче прав на файлы-каталоги. При развертывании также следует обратить внимание на варианты использования DNS сервера. Он может быть внутренним (реализуется механизмами SAMBA 4) и внешним, в качестве которого выступает BIND 9. На текущий момент рекомендуется использовать именно штатный, внутренний DNS сервер.    После развертывания контроллера домена AD на SAMBA 4 следует использовать реальную или виртуальную машину на Windows 7. Машина вводится в домен штатным образом. Далее на нее устанавливается такой продукт как Remote Server Administration Tools. После его установки получаем привычные оснастки типа Active Directory Users and Computers или даже DNS (ограниченно работающая, но все же работающая оснастка).

  P.S. Использование такое замечательного продукта как eDirectory не вошло в обзор, т.к. развертывать продукт умирающей компании наверно неправильно. Хотя сам продукт могуч. Причем могучесть пропорциональна цене