Samba DC в якості другого контролера в домені AD Windows 2012R2 і переміщувані папки для клієнтів на Windows і Linux
Responsive image

Усвідомлення того, що я потрапив в імпортозамес прийшло не відразу. Тільки коли з вищестоящої організації свіжі поставки ПК стали стабільно приїжджати з дистрибутивом «Альт Лінукс» на борту, я запідозрив недобре.

Однак в процесі проходження по стадіях прийняття неминучого я втягнувся і навіть трохи почав отримувати задоволення від процесу. А в якийсь момент подумав, що такими темпами рано чи пізно мені доведеться розлучатися з рішеннями по організації служби каталогів від Microsoft і рухатися в бік чогось більш екзотичного. Тому, щоб заздалегідь підготуватися до неминучого, і по можливості виловити більше підводних каменів, було вирішено розгорнути тестовий стенд, що включає в себе:

  • DC1 — Windows Server 2012R2
  • DC2 — Альт Сервер 8.2
  • File Server — Windows Server 2012R2
  • PC1 — Windows 7
  • PC2 — Альт Робоча станція 8.2

    • Завдання стенду:

    1. Розгорнути домен на базі w2k12r2. Створити мінімальний набір групових політик (аналогічно використовується в робочій інфраструктурі), включаючи політику перенесення робочих папок користувачів (Завантаження / Документи / Робочий стіл). В кінцевому підсумку хочеться, щоб при зміні користувачем робочого місця з Windows на Linux і назад він мав комфортний доступ до своїх робочих документів.
    2. Введення Samba DC другим контролером. Перевірка реплікації служби каталогів і DNS.
    3. Налаштування клієнтів Linux на роботу з переміщуваними папками.

    Реалізація:

    Установка і введення нового контролера З установкою MS Windows 2012R2 все просто і більш менш зрозуміло. В інтернеті є тисяча один мануал по розгортанню домену на Windows як за допомогою GUI так і засобами Powershell, тому повторювати зайвий раз не буду, залишу тільки посилання на офф. документацію, для цікавих і тих хто захоче освіжити память.Однако один важливий момент в даному пункті все таки є. На сьогоднішній день Samba не вміє працювати зі схемами каталогу вище 2008R2.

    Проблема в тому, що Windows 2012 і 2012R2 використовують інструменти WMI для роботи з доменами і лісами, стабільна підтримка яких анонсована тільки до версії Samba 4.11, яка повинна вийти до кінця цього року.
    З цього випливає, що єдиним варіантом для введення самби в домен AD, розгорнутий на 2012R2 сервері, є зниження схеми з 69 до 47. Зрозуміло на робочій інфраструктурі без вагомих причин цього робити не треба, але у нас тут тестовий стенд, так що чому б власне і немає.

    Ставимо Альт Сервер 8.2. Під час установки вибираємо профіль «Сервер Samba-DC (контролер AD)». На розгорнутому сервері виробляємо повне оновлення системи, і встановлюємо пакет task-samba-dc, який потягне за собою все необхідне

    # apt-get install task-samba-dc
    Якщо раптом task-samba-dc, всупереч запевненням документації Альта відмовиться ставити все необхідне сам.

    Далі переходимо до налаштування Kerberos і отримання тікета. Відкриваємо файл krb5.conf, переходимо в розділ [libdefaults], і приводимо до наступного вигляду:

    # vim /etc/krb5.conf
     dns_lookup_kdc = true
 dns_lookup_realm = true
 default_realm = TEST.LOCAL

    Запитуємо квиток

    # kinit administrator
Password for administrator@TEST.LOCAL:

    Перевіряємо список отриманих тікетів Kerberos

    # klist
Ticket cache: KEYRING:persistent:0:0
Default principal: administrator@TEST.LOCAL

Valid starting       Expires              Service principal
16.05.2019 11:51:38  16.05.2019 21:51:38  krbtgt/TEST.LOCAL@TEST.LOCAL
        renew until 23.05.2019 11:51:35

    Тепер видаляємо або перейменовуємо існуючий конфиг самби.

    # mv smb.conf smb.conf.bak1

    І нарешті вводимо в домен AD другим контролером:

    # samba-tool domain join test.local DC -U"TEST\administrator"
    Успішний введення буде супроводжуватися наступним логом

    В оснащенні ADUC повинна з’явитися запис про новий DC в домені TEST.LOCAL, а в диспетчері DNS – нова А запис, відповідна DC2.

    • Реплікація між контролерами Для початку перевіримо роботу служби реплікації каталогів (DRS)
      # samba-tool drs showrepl
      Всі спроби реплікації у висновку повинні бути успішними. У списку об’єктів KCC, протягом 15 хвилин після введення, повинен з’явиться наш DC1 на Windows

      Попередження «No NC replicated for Connection!» можна сміливо ігнорувати. Воно з’являється через те, що при реєстрації нового DC самба невірно встановлює деякі прапори реплікації.

      Так само непогано буде перевірити реплікацію LDAP.

      # samba-tool ldapcmp ldap://dc1.test.local ldap://dc2.test.local -Uadministrator

      Зазначена вище команда порівняє значення атрибутів об’єктів всього каталогу на DC1 і DC2.

      Приклад успішної реплікації

      У ряді випадків атрибути об’єктів на різних контролерах можуть відрізнятися, і висновок команди дасть про це знати. Але далеко не у всіх випадках це буде ознакою проблеми з реплікацією.

      Наступним етапом необхідно вручну налаштувати стабільну реплікацію каталогу SysVol.
      Справа в тому, що самба поки не підтримує DFS-R, втім як не підтримувала більш ранню FRS. Тому для реплікації між DC Samba і Windows єдиним на сьогоднішній день робочим рішенням є одностороння реплікація засобами утиліти Robocopy з комплекту Windows Server 2003 Resource Kit Tools.

      Розробники самби, щоб уникнути проблем з сумісністю, рекомендують спочатку встановити комплект утиліт на звичайну робочу станцію, і після цього скопіювати Robocopy на контролер в папку «C:\Program Files (x86)\Windows Resource Kits\Tools\»

      Після установки, в планувальнику завдань на контролері з Windows створюємо завдання на виконання реплікації з наступними параметрами:

      — Виконувати для всіх користувачів
      — Тригер на виконання Щодня кожні 5 хвилин протягом дня
      — В діях прописуємо шлях до утиліти robocopy, в якості аргументів вказуємо:

      \\DC1\SYSVOL\test.local\ \\DC2\SYSVOL\test.local\ /mir /sec

      У конкретному випадку копіюємо вміст каталогу SysVol с DC1 на DC2.

    • Переносяться папки користувачів за допомогою конфігурації pam_mount Дослідним шляхом я намацав два життєздатних варіанти вирішення цього завдання з його допомогою.
      1. Повний монтування папки з профілем з мережі в розділ /home Простий варіант. Відмінно відпрацьовує, якщо назви папок Мої документи, Завантаження та Робочий стіл збігаються в обох операційних системах. Мається на увазі, що ПК на Linux вже введений в домен і користувачі Логін під своїми доменними обліковими записами, використовуючи в якості механізму аутентифікації і авторизації sssd.
        # vim /etc/security/pam_mount.conf.xml
        <volume uid="100000000-2000000000" fstype="cifs" server="dfs" path="Profile_Users/%(USER)" mountpoint="~" options="sec=krb5,cruid=%(USERUID),nounix,uid=%(USERUID),gid=%(USERGID),file_mode=0664,dir_mode=0775"/>

        где:

        • uid=«100000000-2000000000» — діапазон UID, який присвоюється доменним користувачам від SSSD
        • server=«dfs» — ім’я файлового сервера
        • path=«Profile_Users/%(USER)» — ресурс на файловому сервері, з розміщеним профілем користувача
        • mountpoint=”~” — шлях монтування в домашню папку користувача

        Логін користувача передається в макропеременную “%(USER)”, яка використовується pam_mount, для підключення нашого мережевого ресурсу, в тому вигляді, в якому він введений в дисплейному менеджері. Тому важливо, щоб в ДМ логін вводився без явної вказівки доменного імені.

        В sssd.conf це вирішується коментуванням, або виставлянням значення False в опцію use_fully_qualified_names, яка включає режим повних імен (включаючи домен) для користувачів і груп.

      2. Другий спосіб менш прямолінійний і сокирний, і на мій погляд більш зручний і кращий. Відмінність від першого тільки в конфігурації pam_mount
        # vim /etc/security/pam_mount.conf.xml
        <volume uid="100000000-2000200000" fstype="cifs" server="dfs" path="Profile_Users/%(USER)/Робочий стіл" mountpoint="~/Робочий стіл" options="sec=krb5,cruid=%(USERUID),nounix,uid=%(USERUID),gid=%(USERGID),file_mode=0664,dir_mode=0775"/>
<volume uid="100000000-2000200000" fstype="cifs" server="dfs" path="Profile_Users/%(USER)/Downloads" mountpoint="~/Завантаження" options="sec=krb5,cruid=%(USERUID),nounix,uid=%(USERUID),gid=%(USERGID),file_mode=0664,dir_mode=0775"/>
<volume uid="100000000-2000200000" fstype="cifs" server="dfs" path="Profile_Users/%(USER)/Мої документи" mountpoint="~/Документи" options="sec=krb5,cruid=%(USERUID),nounix,uid=%(USERUID),gid=%(USERGID),file_mode=0664,dir_mode=0775"/>

        Тобто просто окремо монтуємо кожну нашу папку в відповідний їй каталог

     

    Висновки

    За півмісяця роботи на тестовому стенді дана зв’язка успішно пережила кілька поперемінних довготривалих і короткочасних відключень обох контролерів, практично без наслідків для клієнтів (один раз клієнт на Windows7 втратив довірчі відносини).

    В цілому у мене залишилися досить приємні враження від роботи з цим продуктом, навіть незважаючи на всі нюанси, з якими довелося зіткнутися як в статті, так і «за лаштунками».

    Підводні камені є, їх багато, і по ходу роботи з само собою їх доведеться виловлювати у великій кількості. Проте на сьогоднішній день немає інших рішень, що дозволяють організовувати гібридну середу, з використанням служби каталогів і без використання Windows.

    Джерело статті: https://habr.com/ru/post/450572/