Реализация и отладка механизмов репликации в Samba 4 (Евгений Синельников, OSSDEVCONF-2016)

Короткая ссылка: 20161001D

Содержание

1 Аннотация
2 Видео
3 Слайды
4 Расширенные тезисы
- 4.1 Репликация в SambaAD и проблемы реализации мультимастерной архитектуры
5 Примечания и отзывы

Аннотация

Докладчик: Евгений Синельников

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

Видео

on youtube

Слайды

Расширенные тезисы

Репликация в SambaAD и проблемы реализации мультимастерной архитектуры

В минимальном объёме проект Samba представляет собой целостный набор сервисов для SMB/CIFS-клиентов. При этом проект нацелен на реализацию полноценной альтернативы для доменных служб Active Directory (AD) компании Microsoft. Архитектура проекта Samba включает в себя целый ряд подсистем, среди которых одной из сложнейших и критичных в реализации является подсистема механизмов мультимастерной репликации.

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

Владелец схемы (уникален в рамках леса доменов);
Владелец инфраструктуры (уникален в рамках домена);
Владелец относительных идентификаторов (уникален в рамках домена);
Владелец доменных имён (уникален в рамках леса доменов);
Эмулятор основного контроллера домена (уникален в рамках домена).

Стоит отметить, что роли владельца доменных имён и зоны DNS в реализации Samba формально разделены, несмотря на то, что в оригинальной реализации AD такое разделение не предусмотрено.

# samba-tool fsmo show
SchemaMasterRole owner: CN=NTDS Settings,CN=W2K8R2-DC,\\CN=Servers,CN=SDC,CN=Sites,CN=Configuration,DC=example,DC=ru
InfrastructureMasterRole owner: CN=NTDS Settings,CN=W2K-DC,\\CN=Servers,CN=SDC,CN=Sites,CN=Configuration,DC=example,DC=ru
RidAllocationMasterRole owner: CN=NTDS Settings,CN=KDC-01,\\CN=Servers,CN=KRDC,CN=Sites,CN=Configuration,DC=example,DC=ru
PdcEmulationMasterRole owner: CN=NTDS Settings,CN=KDC-01,\\CN=Servers,CN=KRDC,CN=Sites,CN=Configuration,DC=example,DC=ru
DomainNamingMasterRole owner: CN=NTDS Settings,CN=KDC-01,\\CN=Servers,CN=KRDC,CN=Sites,CN=Configuration,DC=example,DC=ru
DomainDnsZonesMasterRole owner: CN=NTDS Settings,CN=KDC-01,\\CN=Servers,CN=KRDC,CN=Sites,CN=Configuration,DC=example,DC=ru
ForestDnsZonesMasterRole owner: CN=NTDS Settings,CN=KDC-03,\\CN=Servers,CN=KRDC,CN=Sites,CN=Configuration,DC=example,DC=ru

Данная особенность разделения ролей между контроллерами домена существенным образом влияет на особенности первичного включения и встраивания контроллеров домена на базе Samba (SambaAD) в инфраструктуру AD. Кроме того, важным моментом при встраивании SambaAD является так называемый максимальный уровень схемы, который определяется для всего леса доменов контроллером-владельцем схемы.

На текущий момент Samba поддерживает уровень схемы не выше 2008 R2^[1]. Соответственно, для корректного подключения SambaAD к домену необходимо, чтобы владельцем схемы, а также владельцем инфраструктуры, были контроллеры домена с уровнем леса версии не старше Windows Server 2008 R2. При этом стоит иметь в виду, что в подобном режиме могут работать и более старшие версии серверов, например Windows Server 2012 R2.

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

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

Механизмы основной (выполняемой во время работы сервера) и первичной (выполняемой при подключении контроллера к домену) репликации в Samba реализованы по-разному. Механизмы первичной репликации имеют существенные проблемы в производительности — время репликации для данных в несколько гигабайт достигает более 30 часов в противовес десяткам минут в оригинальной реализации контроллеров AD на базе Microsoft Windows Server;
Одним из неочевидных ограничений, которое не относится к основным механизмам репликации, но требует, тем не менее, поддержания во взаимосогласованном состоянии, является содержимое скрытого системного каталога, доступного через общий каталог Sysvol. В данном каталоге, в частности, размещаются файлы с настройками групповых политик безопасности;
Основной и главной проблемой в реализации механизмов репликации в текущей реализации Samba является корректная реализация протокола DRSUAPI^[2]. Эта проблема, прежде всего, связана с устаревшими (по отношению к новым версиям серверов) спецификациями, опубликованными компанией Microsoft, а также с их сложностью и неполнотой^[3];
Второй, не менее важной проблемой реализации Samba, является неполнота соответствия внутренней логики работы со схемой для объектов и атрибутов, которые хранятся в дереве каталогов и доступны по протоколу LDAP, оригинальной логике. В частности, логике обработки типов атрибутов из расширенной схемы, для которых используется дополнительный атрибут msDS-IntId.

В связи со сложностью воспроизведения конкретных сценариев в проекте Samba предусмотрен специальный набор утилит тестирования и выявления регрессий — Samba Torture. Тем не менее, конкретные сценарии в комплексном окружении управляемых сервисов выявляются только на реальных стендах и только уже потом воспроизводятся в системе тестирования.

В результате методика отладки проблем, связанных с репликацией, предполагает необходимость воспроизведения достаточно сложных конфигураций и последующего детального анализа протоколов удалённого вызова процедур (RPC). Основным инструментом для точного выявления порядка выполнения DCERPC-вызовов в процессе работы в проекте Samba является специально изменённый (для расшифровки payload-данных «на лету») Wireshark^[4]. Кроме того, одним из возможных вариантов является методика сохранения записей о DCERPC-пакетах на уровне Samba-сервера.

Таким образом, относительно подхода к отладке SambaAD, следует подчеркнуть важность подготовки типовых воспроизводимых конфигураций, отсутствие отладки в которых на текущий момент приводит к значительному разрыву между реально необходимым уровнем поддержки механизмов репликации и возможностями разработчиков по анализу воспроизводимых проблем.

Примечания и отзывы

↑ Samba Community. Joining a Windows Server 2012 / 2012 R2 DC to a Samba AD, 2016. [1]
↑ Samba Community. DRSUAPI on Samba wiki, 2015. [2]
↑ Microsoft. Directory Replication Service (DRS) Remote Protocol Specification, 2016. [3]
↑ Stefan Metzmacher. DRSUAPI Replication. [4]

Реализация и отладка механизмов репликации в Samba 4 (Евгений Синельников, OSSDEVCONF-2016)!.jpg

Plays:74 Comments:0

[cite-3-1] Samba Community. Joining a Windows Server 2012 / 2012 R2 DC to a Samba AD, 2016. [1]

[cite-2-2] Samba Community. DRSUAPI on Samba wiki, 2015. [2]

[cite-1-3] Microsoft. Directory Replication Service (DRS) Remote Protocol Specification, 2016. [3]

[cite-4-4] Stefan Metzmacher. DRSUAPI Replication. [4]

[1]

[2]

[3]

[4]