Samba AD DC – ожидания и реальность
 
Каждый раз обращаясь к этому вопросу можно услышать, что Samba AD DC в целом дорос до продуктивного уровня и если не фонтан, то все основные задачи закрывает примерно как на уровне Windows Server 2008 R2.
 
В общем и целом, это так, Samba предоставляет стабильные возможности домена уровня 2008 R2, поддерживает групповые политики и управляется стандартными Windows оснастками, на первый взгляд – отличная замена Windows AD и хорошая экономия на лицензиях, но это только на первый взгляд.
 
В качестве одиночного контроллера Samba AD DC действительно смотрится неплохо, но как мы помним, базовые правила построения Active Directory требуют наличия минимум двух контроллеров.
 
И это даже не вопрос высокой доступности, это базовый вопрос элементарной устойчивости, если что-то случилось с основным контроллером, скажем физически и невосстановимо вышел из строя, то его функции подхватит второй контроллер, так что даже никто ничего не заметит.
 
Напоминаем, что в современной AD все контроллеры равны, а роли FSMO не нужны для повседневной работы домена (некоторые вообще нужны один два раза в его жизни).
 
А что у нас предлагает Samba, а предлагает она нам интересные моменты – штатной репликации SYSVOL нет и не будет, потому как реализация закрытого протокола DFS-R сопряжена как с техническими, так и с юридическими сложностями.
 
Взамен предлагается ручная репликация любым доступным способом, скажем через rsync, но репликацией это можно назвать с большой натяжкой, так как транзакционная целостность процесса отсутствует, что серьезно осложняет дело.
 
Что это значит? Когда мы создаем новую политику – метаданные от нее записываются в базу AD и штатно реплицируются между контроллерами, а файлы остаются в SYSVOL контроллера и ждут пока мы их не синхронизируем руками.

В итоге получаем, что на каком-то контроллере политика есть, а файлов нет. А у клиента политика то применяется, то не применяется, смотря к какому контроллеру он подключился.
 
Если файлы были изменены сразу в двух местах, то просто наступает ад, какую версию считать главной? В Samba эту проблему решили костылем – контроллер с ролью PDC не может быть целью rsync-синхронизации, только источником и все изменения в AD следует вносить только на нем.
 
Но это только надводная часть айсберга, под водой у нас остался механизм трансляции SID Windows в Linux UID, для этого он на каждом контроллере хранит локальную базу сопоставлений idmap.ldb, которая также не реплицируется.
 
После того, как мы добавили в AD новые объекты, которые являются субъектами безопасности и имеют свой SID нам нужно обновить эту базу на всех контроллерах домена. Причем сделать это можно только с остановкой службы контроллера и потом обязательно перечитать права на SYSVOL.
 
Фактически у нас появляется три отдельных процесса:
 
🔹 Репликация базы AD (автоматически)
🔹 Синхронизация SYSVOL (руками, в одну сторону)
🔹 Синхронизация idmap.ldb (руками, с остановкой службы)
 
Про транзакционную целостность мы даже речи не ведем, нам бы тут ничего не сломать. Поэтому все многоконтроллерные и многосайтовые конфигурации тут же разбиваются об этот кошмар.
 
По сути, Samba предоставляет нам только две более-менее рабочие конфигурации AD.
 
🔸 Один контроллер + бекап (холодный резерв)
🔸 Два контроллера с постоянным ручным контролем процесса
 
Это даже не уровень PDC/BDC NT4, там хотя бы репликация на вторичный контроллер была автоматической. Это история про один контроллер в нетребовательной среде, не более.
 
Хотя каждый может принимать решение самостоятельно, главное осознавать риски и представлять в чем заключается суть проблемы.