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 або окремий каталог;
• які служби зав’язані на автентифікацію — файлові ресурси, пошта, віддалений доступ, внутрішні застосунки;
• вимоги до правил паролів, обмежень на робочі станції й автоматичного підключення мережевих дисків;
• ім’я домену, зони розв’язання імен і хто керує адресацією;
• як влаштовано резервне копіювання і які вікна обслуговування допустимі;
• доступи для наших інженерів і ваші вимоги з безпеки.

Перший крок за нами: розбираємо дані й збираємо план впровадження — скільки контролерів потрібно, як розкласти ролі, як налаштувати реплікацію й відновлення, у якому порядку переводити служби.

У плані фіксуємо етапи, вікна робіт і критерії приймання, щоб було видно, на якому кроці що перевіряється.

Окремим блоком описуємо підтримку домену після запуску: реакція на збій входу, відновлення контролера, порядок змін у правилах. Опишіть завдання — повернемося з оцінкою робіт і планом першого етапу.