Samba 4 в роли контроллера домена: развертывание AD на Linux

Samba AD DC: что ломается в домене без собственного контроллера

Учётные записи сотрудников без домена расползаются: локальные пользователи на файловом сервере, отдельные базы в сервисах, логины сервисных задач с паролями прямо в конфигурациях. Пока команда небольшая, это держится на памяти администратора — на десятом сервере и тридцатом сотруднике появляется класс сбоев, который лечится не настройкой, а переделкой схемы.

Права выдают руками и держат в таблице, живущей отдельно от групп на диске. Один и тот же человек входит в разные наборы групп на разных узлах, и никто не отвечает точно, у кого есть доступ к каталогу с договорами. Единой политики паролей нет: сложность и срок жизни задаются там, где о них вспомнили.

Самое дорогое — единственный узел аутентификации. Пока он жив, вход в сервисы незаметен; когда он недоступен, встаёт работа целиком, включая системы, к учётным записям отношения не имеющие. Реплики нет, поэтому подъём идёт из резервной копии с ручной сверкой записей после восстановления.

Развёртывание контроллера домена на Linux, где эту роль берёт на себя Samba AD DC, даёт один источник учётных записей, единую аутентификацию для сервисов и реплику, на которую домен переключается без ручного вмешательства. Ниже разбираем, как это устроено и что ломается, если оставить как есть.

Что даёт домен на Linux: единый вход, права и отказоустойчивость

Когда учётные записи, группы и права собраны в одном каталоге, а не размазаны по десятку панелей, эффект виден в измеримых величинах: сколько времени уходит на рутину и как быстро инфраструктура возвращается в строй после сбоя. Домен на Samba даёт это без смены привычных сотрудникам рабочих систем.

• Единый вход сотрудников. Один набор учётных данных на все подключённые сервисы: сброс пароля и блокировка — одна операция вместо обхода десятка интерфейсов, за счёт чего у администратора освобождаются часы в неделю на развитие, а не на однотипные заявки.
• Централизация прав доступа. Права выдаются группами и политиками: подключение нового сотрудника и отзыв доступов при увольнении отражаются во всех системах сразу, поэтому закрытый доступ не «оживает» при следующем входе.
• Отказоустойчивость домена. Второй контроллер и репликация каталога убирают единую точку отказа: сбой узла не прерывает вход сотрудников, а восстановление занимает минуты вместо часов ручной сборки.
• Машины и сервисы под общим управлением. Рабочие станции входят в домен и получают общие политики, внутренние сервисы — единые учётные данные, доступ к общим ресурсам — по роли, а не по личной договорённости.
• Прозрачный аудит. Журналы входов и изменений показывают, кто и когда обращался к ресурсам: инцидент разбирается по фактам, а не по воспоминаниям участников.

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

Варианты развёртывания: отдельный сервер, Samba или облачный домен

Выбор между выделенным контроллером домена, Samba AD DC и облачным доменом решается условиями, а не предпочтениями: есть ли площадка под сервер, насколько смешан парк машин, нужны ли групповые политики и кто дежурит ночью. Ниже — границы применимости каждого варианта.

Репликация между площадками обычно всплывает на этапе запуска второго офиса. У Samba контроллера домена она встроена и работает поверх штатных механизмов, но при разрыве канала важно заранее решить, какие записи считаются приоритетными после слияния, иначе учётные записи разъезжаются. В облачном домене репликацию берёт на себя провайдер, зато вход на площадке зависит от канала.

Этапы внедрения: от аудита сети до передачи в сопровождение

Домен не разворачивают поверх работающей сети: сначала фиксируем текущее состояние, затем проектируем схему и только потом настраиваем службу каталога. Порядок этапов принципиален — пропущенный аудит всплывает уже на вводе в эксплуатацию, когда менять топологию дороже и рискованнее.

1. Аудит инфраструктуры. Собираем схему сети, перечень серверов и служб, существующие зоны DNS, учётные записи, требования сервисов к аутентификации. На выходе — список ограничений и узлов, которые трогать нельзя.
2. Схема домена. Определяем имя домена, число контроллеров, топологию репликации между площадками, порядок синхронизации времени и правила разрешения имён. Схему согласуем с вами до начала настройки.
3. Настройка службы каталога. Разворачиваем контроллер домена на Linux, поднимаем DNS и аутентификацию, распределяем роли хозяев операций, задаём политики паролей и структуру подразделений.
4. Перенос данных и ввод клиентов. Переносим пользователей, группы и компьютеры, вводим машины в домен, настраиваем сопоставление прав на файловых ресурсах, чтобы доступы не расширились.
5. Проверка сценариев входа. Тестируем вход с рабочих станций и из сервисов, смену и срок действия паролей, блокировки, доверие между доменами и поведение при отказе одного контроллера.
6. Резервное копирование и восстановление. Проверяем на стенде восстановление каталога целиком и отдельного объекта — регламент без проверки считается нерабочим.
7. Передача в сопровождение. Отдаём доступы, документацию и регламенты, обучаем администраторов, фиксируем план развития домена.

Каждый этап закрывается артефактом: схемой, конфигурацией, отчётом проверки. Это позволяет передать систему вашей команде без устных договорённостей.

Что передаём на руки: конфигурации, схемы и регламенты

Домен продолжает работать без нас только тогда, когда знания зафиксированы в артефактах, а не в переписке с инженером. Поэтому приёмка — это не «сервер отвечает», а комплект, по которому штатная команда сама проводит изменения, восстанавливается после сбоя и проходит проверку. Ниже — что именно остаётся у заказчика.

• Схемы инфраструктуры — контроллеры и их реплики, зоны прямого и обратного разрешения имён, доверенные сегменты, точки выхода в другие сети. По ним видно, что упадёт вместе с узлом.
• Политики доступа — привязка групповых политик к подразделениям и узлам, матрица прав на файловые ресурсы, порядок выдачи привилегий и их отзыва.
• Роли и права — перечень встроенных и собственных ролей, кому делегировано управление подразделениями, кто владелец каждой группы и куда идти за расширением.
• Регламент резервного копирования — что попадает в копию (состояние каталога, конфигурации, ключи), с какой периодичностью, где хранится, как проверяется восстановление и за какое время домен поднимается на чистом узле.
• Документация домена — топология, состав объектов, служебные учётные записи, порядок их ротации, журнал изменений и точки, где правки уже вносились вручную.
• Инструкции по типовым операциям — ввод и вывод контроллера, перевод ролей, смена пароля служебной учётки, подключение нового подразделения.
• Порядок обновлений и мониторинга — какие проверки выполняются регулярно, на какие события настроены оповещения, что считается поводом для вмешательства.

Кейс: домен на 300 сотрудников без выделенного сервера под каталог

Каталог на 300 человек жил на одном физическом сервере с контроллером домена под Windows: одна точка отказа, копия раз в сутки, восстановление — переустановка и ручной разбор учётных записей. Нового сотрудника заводили два-три дня: заявка, очередь, ручное создание учётки и прав. Обращения по доступам шли потоком — забытые пароли, расхождения в группах, «не пускает в общую папку».

Развернули Samba AD DC на двух уже существующих узлах виртуализации — отдельный сервер под каталог не выделяли вообще. Настроили репликацию между контроллерами, интегрированный DNS и роли хозяина операций так, чтобы падение любого узла не ломало домен. Учётные записи создаются из кадровой системы по регламенту, права и сетевые ресурсы выдаются группами через политики.

Миграция без простоя

Между старым и новым доменом подняли доверительные отношения, рабочие станции переводили волнами по подразделениям, профили и данные переносили заранее. Прежний контроллер держали в режиме чтения, пока на нём не осталось активных входов — рабочий день не останавливался ни разу.

Ввод сотрудника сократился до 15–20 минут вместо двух-трёх дней. Восстановление каталога — переключение на второй узел за минуты, а не полдня простоя всего офиса. Доля инцидентов с доступом упала примерно вчетверо, а копии теперь снимаются чаще и проверяются восстановлением на тестовом контуре: откат не описан в инструкции, а отработан.

Что делать, если домен уже развёрнут на другом решении?

Развёрнутый домен не переключают одним вечером — сначала он сосуществует с новым. Рядом поднимают отдельный лес на Samba AD DC, а между старым и новым доменом настраивают доверительные отношения на уровне леса: двусторонние, если ресурсы должны быть доступны в обе стороны. Пока доверие действует, сотрудники работают под прежними учётными записями, а параллельно создаются новые.

Доверие опирается на взаимное разрешение имён: зоны старого домена прописываются на новом контроллере как условная пересылка, иначе ресурсы соседнего леса просто не находятся. Уровень леса нужен ещё и потому, что только он позволяет перенести историю идентификаторов безопасности — без неё права на файловых ресурсах пришлось бы выставлять заново вручную.

Миграция учётных записей идёт порциями: сначала небольшая группа, затем отдел, затем остальные. Вместе с записью переносят пароль, членство в группах и идентификатор из истории — сотрудник входит уже в новый домен и видит те же сетевые папки с теми же правами. Профиль и закреплённые настройки переносят отдельно, чтобы после перехода люди не собирали рабочее окружение заново.

Переход без простоя держится на порядке шагов: доверие, учётные записи, затем серверы и рабочие станции. Компьютеры вводят в новый домен по одному, в согласованное время, а старый домен остаётся рабочим до последнего перенесённого ресурса — это же и точка отката: если на середине что-то вскрылось, учётные записи по-прежнему в прежнем домене и работа не останавливается.

Технические сомнения перед переносом домена на Linux

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

Как делать резервную копию домена?

Каталог нельзя копировать на горячую обычным архиватором — снимок выйдет несогласованным. Снимаем состояние базы штатным способом, храним копии на отдельном носителе и разворачиваем снимок на изолированном стенде, чтобы убедиться: восстановление действительно проходит.

Что будет при отказе узла?

Домен поднимаем минимум на двух узлах с репликацией: выход одного не прерывает вход пользователей и доступ к общим ресурсам. Роли, которые нельзя дублировать, переносятся одной командой, а порядок восстановления узла описан и проверен на стенде.

Сохранятся ли права доступа к файлам?

Права на папки и сетевые ресурсы переносятся вместе с данными — включая наследование и точечные разрешения для групп. Перед вводом в работу сверяем матрицу доступа по ключевым каталогам: кто читает, кто пишет, у кого расширенные права.

Сможет ли наша команда администрировать такой домен?

Управление идёт привычными оснастками и консольными утилитами. Сценарии массового создания учётных записей и настройки политик переносятся почти без изменений; документацию и передачу знаний отдаём вашим администраторам.

Обсудим задачу: что потребуется с вашей стороны и с чего начнём

Контроллер домена на Samba AD DC — не отдельный сервер, а часть сети: он держит разрешение имён, синхронизацию времени, права на файловые ресурсы и вход сотрудников. Поэтому оценка работ строится не на «средней цене за контроллер», а на вашей фактуре. Ниже — исходные данные, которые мы просим на первом разговоре; если чего-то нет, поможем собрать.

• сколько пользователей, рабочих станций и серверов войдут в домен и какой рост ожидается;
• как учётные записи устроены сейчас: рабочая группа, прежний контроллер на Windows или отдельный каталог;
• какие службы завязаны на аутентификацию — файловые ресурсы, почта, удалённый доступ, внутренние приложения;
• требования к правилам паролей, ограничениям на рабочие станции и автоматическому подключению сетевых дисков;
• имя домена, зоны разрешения имён и кто управляет адресацией;
• как устроено резервное копирование и какие окна обслуживания допустимы;
• доступы для наших инженеров и ваши требования по безопасности.

Первый шаг за нами: разбираем данные и собираем план внедрения — сколько контроллеров нужно, как разложить роли, как настроить репликацию и восстановление, в каком порядке переводить службы. В плане фиксируем этапы, окна работ и критерии приёмки, чтобы было видно, на каком шаге что проверяется.

Отдельным блоком описываем поддержку домена после запуска: реакция на сбой входа, восстановление контроллера, порядок изменений в правилах. Опишите задачу — вернёмся с оценкой работ и планом первого этапа.