Контроллер домена на Ubuntu 18.04 — Ubuntu 18.04 AD-DC


24.12.2018

Начнем с установки статического адреса!

sudo nano /etc/netplan/*.yaml

Приступаем к редактированию файла 50-cloud-init.yaml:

ВНИМАНИЕ! Отступы слева в конфигурациях должны быть ОБЯЗАТЕЛЬНО и поставлены они должны быть ПРОБЕЛАМИ! В конфигурациях, представленных в этой статье количество пробелов правильное, считайте или копируйте:)

Если вы поставите отступы клавишей "TAB", то на этапе проверки конфигурации на ошибки, вылезет ошибка - " Error while loading /etc/netplan/50-cloud-init.yaml, aborting. / Ошибка при загрузке ".

Если же вы решите написать всё в столбик без отступов, получите ошибку - " An error occured: the configuration could not be generated / Произошла ошибка: конфигурация не может быть сгенерирована ".

Конфигурация для указания настроек сети вручную. (Пример):


network:
  renderer: networkd
  ethernets:
    eth0:
      addresses: [192.168.1.10/24]
      gateway4: 192.168.1.1
      dhcp4: no
      dhcp6: no
      nameservers:
       addresses: [192.168.1.1,8.8.8.8]
  version: 2


Конфигурация для указания настроек сети вручную.(Пример c двумя сетевыми интерфейсами, причём первый (eth0) использует DHCP):


network:
    renderer: networkd
    ethernets:
        eth0:
            addresses: []
            dhcp4: true
        eth1:
            dhcp4: no
            dhcp6: no
            addresses: [192.168.1.10/24]
            gateway4: 192.168.1.1
            nameservers:
             addresses: [192.168.1.1,8.8.8.8]
    version: 2


Главным ДНС сервером на данный момент должен быть указан локальный роутер, или любой другой днс сервер, например 8.8.8.8, способный выполнять эти функции.

Проверим конфигурацию на наличие ошибок и применим изменения.

sudo netplan try

Если ошибок нет, то вы получите сообщение: "Вы хотите сохранить эти настройки?" Нажмите ENTER.

Применяем конфигурацию.
sudo netplan apply
Проверим вступили ли изменения в силу:
ifconfig
Проверим доступен ли внешний ресурс.

ping ya.ru

Важно понимать, что после того, как вы настроите контроллер домена на Ubuntu, смена имени его сервера приведет к непредвиденным последствиям.

Обновляем систему:

sudo apt update && apt upgrade

Останавливаем сервис systemd-resolved:

sudo service systemd-resolved stop

Убираем systemd-resolved из автозапуска:

sudo systemctl disable systemd-resolved.service

Удаляем ссылку /etc/resolv.conf:

sudo rm /etc/resolv.conf

Открываем на редактирование файл /etc/resolv.conf:

sudo nano /etc/resolv.conf

По факту, на данный момент этого файла еще не существует, он будет создан при сохранении изменений.

Добавляем переадресацию на наш днс сервер и указываем search домен в resolv.conf .

nameserver 192.168.1.1
search ub.loc

На данном этапе, nameserver должен указывать на тот же адрес, что и в настройках /etc/netplan/50-cloud-init.yaml. В "search" указывается имя нашего будущего домена Active Directory.

Сохраняем изменения нажав Ctrl+O и выходим Ctrl+x.

Настраиваем файл /etc/hosts

Приводим файл hosts к следующему виду:

127.0.0.1 localhost.localdomain localhost
192.168.1.10 dc.ub.loc dc

Сохраняем изменения нажав Ctrl+O и выходим Ctrl+x.

Проверяем что не запущено никаких процессов самбы - для этого понадобится следующая команда:

ps ax | egrep "samba|smbd|nmbd|winbindd"

Если есть хоть один процесс и вы его видите, то возможно вы настраиваете AD-DC не на новом сервере или на сервере развернутом не из оригинального образа. Если вы решите продолжить установку, то вам необходимо убить все процессы с именами samba, smbd, nmbd, winbindd. Чтобы убить процесс, надо использовать команду:

sudo kill :

Устанавливаем Samba

На этом этапе так же важно знать, что после того как вы инициализируете контроллер домена на Ubuntu, вы не сможете изменить его название. Если вы называете свой домен UB.LOC, он на веки вечные останется доменом UB.LOC . Самба не поддерживает изменение имени домена. После его инициализации, чтобы изменить название, вам придется вывести из него все машины что вы успели зарегистрировать в нем, удалить старый домен, инициализировать новый и зарегистрировать машины повторно.

Устанавливаем samba и все необходимые пакеты командой:

sudo apt -y install samba smbclient krb5-user krb5-config winbind

Область по умолчанию для Kerberos версии 5

Указываем UB.LOC (!!!!ТОЛЬКО В ВЕРХНЕМ РЕГИСТРЕ!!!)

Серверы Kerberos для вашей области
Указываем dc.ub.loc
Управляющий сервер вашей области Kerberos
Так же указываем dc.ub.loc
Ожидаем окончание установки


Бэкапим стандартную конфигурацию Samba:

sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp

Инициируем контроллер домена на Ubuntu 18.04

Запускаем инициализацию в интерактивном режиме

Из своего домена, мы так же будем управлять пользователями и группами линуксовых машин. Поэтому нам нужно заранее включить поддержку NIS, с помощью команды —use-rfc2307:

sudo samba-tool domain provision --use-rfc2307 --interactive

Включение поддержки NIS, не имеет никаких противопоказаний к применению, даже если ваш домен никогда не будет обслуживать линуксовые машины. В то же время, если инициализировать домен без поддержки NIS, и когда-нибудь в него войдут линуксовые машины и захочется управлять их учётками, расширять схему Active Directory и добавлять поддержку NIS, придётся уже ручками на свой страх и риск.

Указываем параметры домена:

Если в процессе настройки не было допущено ошибок, все необходимые данные установщик поместит в квадратные скобки в виде стандартных значений:


Realm [UB.LOC]:
Domain [UB]:
Server Role (dc, member, standalone) [dc]:
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]:
DNS forwarder IP address (write 'none' to disable forwarding) [192.168.1.1]: (ЭТО ПЕРЕАДРЕСАЦИЯ ДЛЯ РАЗРЕШЕНИЯ ВНЕШНИХ ИМЁН)
Administrator password:
Retype password:

Когда установщик запросит пароль, рекомендую указать пароль понадежнее. Это будет пароль от учетной записи администратора домена.

Если на этом этапе в квадратных скобках у вас указано не то значение которое вам бы хотелось, значит вероятнее всего в настройках ранее вы допустили серьезный косяк.


Смотрим результаты инициализации

Следующие строки возвестят о том, что контроллер домена на Ubuntu успешно завершил инициализацию:


A Kerberos configuration suitable for Samba AD has been generated at /var/lib/samba/private/krb5.conf

Setting up fake yp server settings

Once the above files are installed, your Samba AD server will be ready to use

Server Role:             active directory domain controller

Hostname:               dc

NetBIOS Domain:      UB

DNS Domain:            ub.loc

DOMAIN SID:            S-1-5-21-4033150357-3109693390-3173112578 (ЭТО ПРИМЕР В ВАШЕМ СЛУЧАЕ DOMAIN SID БУДЕТ СВОЙ)


Но радоваться еще слишком рано. Если вы видите нечто кардинально другое, значит вы допустили какую-то ошибку выше, либо прервали инициализацию, запущенную ранее, либо инициализация вывалилась с ошибкой и сейчас вы пытаетесь инициализировать домен повторно. Если упереться рогом, можно вычистить все данные и записи сгенерированные в процессе инициализации и запустить её повторно. Это даже может привести к её успешному окончанию. НЕ ПЫТАЙТЕСЬ ЭТОГО ДЕЛАТЬ. Инициализируйте домен на новом чистом сервере. Если в процессе подготовки к инициализации, вы допустили косяк, и на момент запуска инициализации вы его не устранили и она завершилось ошибкой — просто удалите текущую инсталяцию сервера и начните сначала. Если вы настраиваете контроллер домена на виртуальной машине, сделайте снапшот выключенного сервера прежде чем приступать к этому пункту. В будущем в случае какого-то косяка на этапе инициализации, возвращайтесь к этому снапшоту и перепроверяйте всё \ исправляйте ошибки.

Настройка DC

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

sudo systemctl stop smbd nmbd winbind
sudo systemctl disable smbd nmbd winbind
sudo systemctl mask smbd nmbd winbind

Делаем samba-ad-dc доступным для запуска, включаем сервис и включаем его автозапуск:

sudo systemctl unmask samba-ad-dc
sudo systemctl start samba-ad-dc
sudo systemctl enable samba-ad-dc

Настройка DNS

Изменяем dns сервер в настройках сети на IP настраиваемого сервера. По факту он будет ссылаться на себя же как на днс сервер 192.168.1.10

Приводим настройки параметров сети к следующему виду:

            dhcp4: no
            dhcp6: no
            addresses: [192.168.1.10/24, ]
            gateway4: 192.168.1.1
            nameservers:
                    addresses: [192.168.1.10, ]

Изменяем dns сервер в resolv.conf, так же указывая там IP своего сервера, приводя его к следующему виду:

nameserver 192.168.1.10
search ub.loc

Настройка Kerberos

В процессе инициализации домена, создается файл krb5.conf, путь к нему указывается в последних строках отчета об успешной инициализации. Поэтому чтобы избежать ручной настройки файла /etc/krb5.conf, нам нужно заменить его только что сгенерированным.

sudo cp /var/lib/samba/private/krb5.conf /etc/

Проверяем результаты своей работы:

Смотрим все шары файл сервера DC:

smbclient -L localhost -U%

Они создаются в процессе инициализации домена и должны присутствовать для его правильного функционирования, проверяем подключение к ним.

Подключаемся к папке netlogon от имени администратора домена

smbclient //localhost/netlogon -UAdministrator -c 'ls'

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

Проверяем правильность настройки DNS:

Без правильно функционирующей службы DNS, AD DC не сможет функционировать как запланировано. Главное, нам необходимо убедиться, что SAMBA_INTERNAL dns настроен правильно и работает. Для этого попытаемся извлечь из него необходимые записи:

Смотрим SRV запись _ldap:

host -t SRV _ldap._tcp.ub.loc.

Смотрим SRV запись _kerberos:

host -t SRV _kerberos._udp.ub.loc.

Проверяем A запись контроллера домена:

host -t A dc.ub.loc

Проверяем работоспособность Kerberos:

kinit administrator

Смотрим кеш авторизационных тикетов Kerberos:

klist

Всё, дальше загоняем в домен компьютер желательно с Win 10, скачиваем и устанавливаем на неё с правами доменадмина последний RSAT и управляем нашим доменом привычными инструментами Windows Server.


Резервный Контроллер домена на Ubuntu 18.04 — Ubuntu 18.04 AD-DC

Не буду повторяться, делаем всё тоже что и на первом DC, но задаем имя нашего сервера "DC01" и DNS сервер указываем адрес основного DC.

Конфигурация для указания настроек сети вручную. (Пример):


network:
  renderer: networkd
  ethernets:
    eth0:
      addresses: [192.168.1.20/24]
      gateway4: 192.168.1.1
      dhcp4: no
      dhcp6: no
      nameservers:
        addresses: [192.168.1.10,8.8.8.8]
  version: 2


В файле "hosts" добавляем основной DC:

Приводим файл hosts к следующему виду:

127.0.0.1 localhost.localdomain localhost

192.168.1.10 dc.ub.loc dc

192.168.1.20 dc01.ub.loc dc01

Отключаем systemd-resolved:

Останавливаем сервис systemd-resolved

sudo service systemd-resolved stop

Убираем systemd-resolved из автозапуска

sudo systemctl disable systemd-resolved.service

Удаляем ссылку /etc/resolv.conf

sudo rm /etc/resolv.conf

Открываем на редактирование файл /etc/resolv.conf

sudo nano /etc/resolv.conf

По факту, на данный момент этого файла еще не существует, он будет создан при сохранении изменений.

Добавляем переадресацию на наш днс сервер и указываем search домен в resolv.conf

nameserver 192.168.1.10

search ub.loc

На данном этапе, nameserver должен указывать на тот же адрес, что и в настройках /etc/netplan/50-cloud-init.yaml

В search указывается имя нашего уже существующего домена Active Directory

Последний дополнительный шаг, который необходимо предпринять, - это синхронизация времени с основным контроллером домена. Это можно сделать, установив клиентскую утилиту NTP в вашей системе (предварительно на основном DC поднимаем NTP server:


Установка сервера


Устанавливаем ntp сервер следующей командой:

apt-get install ntp

Разрешаем автозапуск и стартуем сервис:

systemctl enable ntp || update-rc.d ntp defaults

systemctl start ntp || service ntp start

Настройка NTP

Открываем файл с настройками:

nano /etc/ntp.conf

Настраиваем серверы, с которых наш NTP будет брать эталонное время. Например:

pool ru.pool.ntp.org iburst
server ntp2.vniiftri.ru iburst prefer
pool 0.ubuntu.pool.ntp.org iburst
pool 1.ubuntu.pool.ntp.org iburst
server 127.127.1.0

* iburst — отправлять несколько пакетов (повышает точность); ru.pool.ntp.org / 0.ubuntu.pool.ntp.org / 1.ubuntu.pool.ntp.org — адреса серверов, с которыми наш сервер будет сверять время; server — указывает на выполнение синхронизации с сервером, а не пулом серверов; prefer — указывает на предпочитаемый сервер. server 127.127.1.0 — позволит в случае отказа сети Интернет брать время из своих системных часов.

Настраиваем безопасность:

restrict default kod notrap nomodify nopeer noquery
restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap
restrict 127.0.0.1
restrict ::1

* где:

restrict default — задает значение по умолчанию для всех рестриктов.
kod — узлам, которые часто отправляют запросы сначала отправить поцелуй смерти (kiss of death), затем отключить от сервера.
notrap — не принимать управляющие команды.
nomodify — запрещает команды, которые могут вносить изменения состояния.
nopeer — не синхронизироваться с хостом.
noquery — не принимать запросы.
restrict 192.168.0.0 mask 255.255.255.0 — разрешить синхронизацию для узлов в сети 192.168.0.0/24.
IP адреса 127.0.0.1 и ::1 позволяют обмен данные серверу с самим собой.
Настройки по умолчанию могут быть разные для IPv4 и IPv6:

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

Перезапускаем сервис:

systemctl restart ntp || service restart ntp

Если используется брандмауэр, добавляем правило:

iptables -I INPUT 1 -p udp --dport 123 -j ACCEPT

или с помощью ufw:

ufw allow in on enp2s0 to any port 123 proto udp

* где enp2s0 — сетевой интерфейс, на котором слушает наш сервер.

Дополнительные настройки

Настройка файла хранения логов:

logfile /var/log/ntp.log

Тестирование

Проверить состояние получения эталонного времени можно командой:

ntpq -p

Мы должны увидеть, примерно, следующее:

     remote           refid                 st        t   when poll   reach   delay   offset  jitter
=====================================================
 ru.pool.ntp.org   .POOL.               16 p    -   64    0      0.000    0.000   0.000
 ntp.ubuntu.com  .POOL.               16 p    -   64    0      0.000      0.000   0.000
*91.189.94.4       17.253.34.253    2 u    58  64  377   55.802    3.790   0.412
-91.189.91.157    132.246.11.231   2 u   56  64  377  113.456   -1.746   0.334
+91.189.89.198   192.53.103.108   2 u    1   64  377   54.595    4.229   0.608
+91.189.89.199   17.253.34.253    2 u     61  64  377   54.061    2.637   0.557

* где:

remote — адрес сервера времени, с которым синхронизируется наш сервер;
refid — вышестоящий сервер (с которым сервер из графы выше получает время);
st — уровень сервера (stratum);
t — пир (unicast или multicast);
when — когда последний раз сверялось время;
poll — периодичность синхронизации с этим сервером;
reach — состояние работоспособности. Если удалось произвести синхронизации восемь раз в подряд становится равным 377;
delay — время задержки;
offset — разница между нашим временем и временем на сервере; положительное — наши часы спешат, отрицательное — отстают;
jitter — смещение времени на удаленном сервере;
* — с этим сервером синхронизирует время наш ntpd;
+ — сервер можно использовать для сверки часов;
- — не рекомендован для синхронизации;
x — не доступен.

Проверить отдачу времени сервером можно введя команду на другом Linux:

ntpdate 192.168.0.15

Правильный ответ имеет следующий вид:

ntpdate[3576]: adjust time server 192.168.0.15 offset 0.017657 sec

* время было рассинхронизировано на 0.017657 секунд.

Отобразить текущее время можно командой:

date

Если после синхронизации время некорректно, настраиваем правильный часовой пояс:

cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

* московское время (GMT+3).

Настройка клиента Linux

Для клиентов можно выбрать 2 стратегии настройки — с помощью ntp или утилиты ntpdate.

NTP


Устанавливаем ntp:

Ubuntu / Debian:

apt-get install ntp

CentOS / Red Hat:

yum install ntp

В настройка /etc/ntp.conf в качестве сервера оставляем только наш локальный сервер, например:

server 192.168.0.15

Остальные pool и server удаляем или комментируем.

Перезапускаем NTP:

systemctl restart ntp || service restart ntp

ntpdate


Утилита командной строки выполняет разовую синхронизацию. Чтобы автоматизировать процесс, добавляем задание в cron:

crontab -e

0 0 * * * /usr/sbin/ntpdate 192.168.0.15

* в данном примере задание будет выполняться раз в день в 00:00. /usr/sbin/ntpdate — полный путь расположения утилиты, в разных системах может быть разным — проверить стоит командой which ntpdate.

Настройка клиента Windows

В командной строке выполняем:

w32tm /config /manualpeerlist:"192.168.0.15,0x8" /syncfromflags:manual /update

Некоторые ошибки

1. the NTP socket is in use, exiting

Как правило, данная ошибка возникает при попытке синхронизировать время с помощью ntpdate, когда в системе работает демон ntp.

Причина: NTP сокет в системе уже занят, как правило, ntpd.

Решение: либо не использовать ntpdate, так как ntp умеет сверять время, либо отключить сервис ntpd командой service ntp stop.

2. Connection refused

Возникает при попытке выполнить команду ntpq -p.

Причина: нет разрешения на обращение к серверу.

Решение: проверьте, удастся ли выполнить запрос командой ntpq -pn 127.0.0.1 или ntpq -pn ::1. Также убедитесь, что настройка restrict позволяет серверу подключаться к самому себе по нужному протоколу.

3. no server suitable for synchronization found

Ошибка появляется при попытке синхронизировать время с другим сервером синхронизации.

Причина: сервер синхронизации не доступен по одной из причин: 1) не работает или выключен, 2) установлен restrict, 3) на сервере не запущен ntpd, 4) нет сетевой доступности из-за проблем на сети или брандмауэра.


Решение:

Убедиться, что сервер доступен по сети.
Проверить настройки ntp.conf — наличие соответствующего restrict.
Проверить состояние сервиса командой service ntp status.
Проверить настройки брандмауэра — убедиться в наличие правила, которое разрешает UDP порт 123.

https://www.dmosk.ru/miniinstruktions.php?mini=ntp-server-ubuntu) , выполнив следующую команду:

sudo apt install ntpdate

Предполагая, что вы хотите вручную принудительно синхронизировать время с samba4 AD DC , выполните команду ntpdate для основного DC, введя следующую команду:

sudo ntpdate dc

Устанавливаем samba и все необходимые пакеты командой:

sudo apt install samba krb5-user krb5-config winbind libpam-winbind libnss-winbind

Область по умолчанию для Kerberos версии 5

Указываем UB.LOC (!!!!ТОЛЬКО В ВЕРХНЕМ РЕГИСТРЕ!!!)

После завершения установки пакетов проверьте параметры, запросив билет Kerberos для администратора домена с помощью команды kinit . Используйте команду klist для просмотра списка разрешенных билетов Kerberos: sudo kinit Administrator@UB.LOC


sudo klist

Присоединитесь к Samba4 AD DC в роли контроллера домена

10. Прежде чем интегрировать вашу машину в Samba4 DC , сначала убедитесь, что все работающие в вашей системе демоны Samba4 остановлены, а также переименуйте файл конфигурации Samba по умолчанию, чтобы начать очистку. При подготовке контроллера домена samba создаст новый файл конфигурации с нуля.

sudo systemctl stop samba-ad-dc smbd nmbd winbind

sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.bak

Чтобы начать процесс присоединения к домену, сначала запустите только демон samba-ad-dc , после чего вы запустите команду samba-tool, чтобы присоединиться к области, используя учетную запись с правами администратора в вашем домене.

sudo samba-tool domain join ub.loc DC -U"Administrator"

После того, как Ubuntu с программным обеспечением samba4 будет интегрировано в домен, откройте основной файл конфигурации samba и добавьте следующие строки:

sudo nano /etc/samba/smb.conf

Приведите файл smb.conf к следующему виду:


[global]
        dns forwarder = 192.168.10.254
        idmap_ldb:use rfc2307 = yes
        template shell = /bin/bash
        winbind use default domain = true
        winbind offline logon = false
        winbind nss info = rfc2307
        winbind enum users = yes
        winbind enum groups = yes
        netbios name = DC01
        realm = UB.LOC
        server role = active directory domain controller
        workgroup = UB


[netlogon]
        path = /var/lib/samba/sysvol/ub.loc/scripts
        read only = No


[sysvol]
        path = /var/lib/samba/sysvol
        read only = No


Замените IP-адрес сервера пересылки DNS своим IP- адресом сервера пересылки DNS. Samba будет пересылать все запросы разрешения DNS, которые находятся за пределами зоны вашего домена, на этот IP-адрес.

Включите службу Samba4 AD DC.

Чтобы включить службы samba4 AD DC в масштабе всей системы, сначала отключите некоторые старые и неиспользуемые демоны Samba и включите только службу samba-ad-dc , выполнив следующие команды:


sudo systemctl disable smbd nmbd winbind
sudo systemctl unmask samba-ad-dc
sudo systemctl enable samba-ad-dc

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

sudo systemctl restart samba-ad-dc
sudo samba-tool drs showrepl

Приведите файл /etc/krb5.conf к следующему виду:
[libdefaults]
        default_realm = UB.LOC
        dns_lookup_realm = false
        dns_lookup_kdc = true

Дополнительные проверки доменных служб


Первый тест, который вам нужно выполнить, - это разрешение DNS Samba4 DC . Чтобы проверить разрешение DNS вашего домена, запросите имя домена с помощью команды host для нескольких важных записей DNS AD, как показано ниже. DNS-сервер должен теперь воспроизвести пару с двумя IP-адресами для каждого запроса.


sudo host ub.loc
sudo host -t SRV _kerberos._udp.ub.loc
sudo host -t SRV _ldap._tcp.ub.loc

Теоретически связка из PDC и SDC готова к работе, но есть одно "НО", если мы собираемся использовать оснастку "Управление групповыми политиками" в нашем домене, то нам необходимо настроить синхронизацию SysVol между контроллерами домена, так как SAMBA сама этого делать не умеет, а именно она не умеет синхронизировать файлы политик и скриптов между DC домена.

Синхронизацию будем настраивать однонаправленную с PDC на все остальные DC домена. Соответственно это накладывает свои коррективы на создание групповых политик. Конкретизирую - политики мы создаём только на PDC и реплицируем на все остальные DC домена, и ни как не наоборот.

Приступим:

Настройка на контроллере домена с ролью PDC

Про RSYNC можно почитать здесь: https://www.dmosk.ru/instruktions.php?object=rsync-server

Установим rsync с помощью нашего менеджера пакетов или путем компиляции из исходного кода. Убедимся, что мы используемверсию, которая поддерживает расширенные ACL! Зпускаем rsync-сервер через xinetd (необходимо сначала установить), используем следующий файл конфигурации ( /etc/xinetd.d/rsync ):


service rsync


{
   disable = no
   only_from = 10.99.1.0/24 # Ограничьте ваши адреса или диапазоны DC, чтобы другие хосты не могли получать контент.
   socket_type = stream
   wait = no
   user = root
   server = /usr/bin/rsync
   server_args = --daemon
   log_on_failure += USERID
}


Создайте файл /etc/rsyncd.conf (адаптируйте переменную пути к пути SysVol вашего PDC):

[SysVol]
path = /var/lib/samba/sysvol/
comment = Samba Sysvol Share
uid = root
gid = root
read only = yes
auth users = sysvol-replication
secrets file = /var/lib/samba/rsyncd.secret

Создайте файл /var/lib/samba/rsyncd.secret (каталог хранения файла с паролем на ваше усмотрение, права на данный файл не должны быть общедоступными!) Со следующим содержимым:

sysvol-replication:Pa $$ w0rd # измените пароль на свой

Меняем права на файл (ЕСЛИ ЭТОГО НЕ СДЕЛАТЬ РАБОТАТЬ СИНХРОНИЗАЦИЯ НЕ БУДЕТ):

chmod 600 /var/lib/samba/rsyncd.secret

Перезапустите xinetd.

Настройка на всех других контроллерах домена


Убедитесь, что у вас одинаковые идентификаторы встроенных групп на всех контроллерах домена.

Установите rsync с помощью менеджера пакетов или скомпилируйте из исходного кода. Убедитесь, что вы используете версию, которая поддерживает расширенные списки ACL!

Создайте файл паролей /etc/samba/rsync-sysvol.secret и заполните его паролем, установленным на PDC для учетной записи sysvol-replication (права доступа к этому файлу не должны быть доступны для чтения всем!):

Pa $$ w0rd # измените пароль на свой

Меняем права на файл (ЕСЛИ ЭТОГО НЕ СДЕЛАТЬ РАБОТАТЬ СИНХРОНИЗАЦИЯ НЕ БУДЕТ):

chmod 600 /etc/samba/rsync-sysvol.secret

Для репликации папки SysVol выполните следующую команду ( --dry-run означает, что никаких изменений фактически не производится):

rsync --dry-run -XAavz --delete-after --password-file=/etc/samba/rsync-sysvol.secret rsync://sysvol-replication@dc.ub.loc/SysVol/ /var/lib/samba/sysvol/

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

Если все выглядит нормально, выполните команду без опции --dry-run и позвольте rsync выполнить репликацию.

Чтобы автоматизировать синхронизацию, вы можете запустить команду через CRON.

Про CRON можно почитать здесь: https://losst.ru/kak-dobavit-komandu-v-cron

Создадим задание для планировщика(например, каждые 15 минут):

sudo crontab -e

*/15 * * * * rsync -XAavz --delete-after --password-file=/etc/samba/rsync-sysvol.secret rsync://sysvol-replication@dc.ub.loc/SysVol/ /var/lib/samba/sysvol/

Можно прям так, а можно для CRON создать отдельный файл скрипта.

Повторите эти шаги для каждого DC (кроме вашего PDC!).

Всё проверяем и работаем.


Навигация: