Как настроить в ldap-e два samba-домена?

Чудо начинает получаться, но дельному совету всегда рад :))

У меня еще не продакшн, но рабочая схема.


А зачем простите второй домен?
И зачем тогда репликация??

dn= sambaDomainName=SERVER2,dc=ldap,dc=mycompany,dc=ru
____

Откуда DN? его тут не должно быть! Чем вы пытаетесь домен добавить?

Хотел бы я тогда узнать как Вы собираетель заводить машины и пользователей в домен, если для удаленного офиса будит только реплицированная база ldap, без настроеннго внутреннего samba-домена?

Лично как я это вижу, то это одна ldap-база и свои samba-домены в каждом офисе с одинаковыми SID-ми, для того что бы если раз в samba завел пользователя, то послепрохождения репликаций, из любой точки без доп. настроек можно было бы им же и воспользоваться.

Или я не прав?

по поводу заведения samba у меня все верно - во время заведения пользователя в sambу (через smbpasswd -a xxxx), при правильной ее настройке, она сама регестриться в ldap и сответственно имет запись:
dn: sambaDomainName=MYCOMPANY dc=ldap,dc=mycompany,dc=ru
С проблемой описвной выше я уже разобрался убив и сделав все за ново.

1. В вашей схеме будет больше одного MASTER ldap сервера, как вы собираетесь их синхронизировать? если ссылаться друг на друга (для репликации), то это будет кольцо (я уже пробовал так года 2 назад), там могут такие баги выплыть, что мало не покажется.


Исходя из этого пункта, и решив что 2 мастер-лдап сервера - некорректно:

2. Нужно определиться, есть ли необходимость свободной (читай - прозрачной) миграции пользователей с одного домена в другой и, если есть, то нужна ли эта миграция в случае отсутствия связи между удаленным и главным офисом? (наверняка да, иначе зачем вам 2 домена с единой базой?)

У меня ответ на этот вопрос - да, миграция нужна, и она должна быть максимально независимой от состояния связи.

А сама схема такая:

Головной офис:

MASTER-ldap, PDC, чтение-запись. репликация на:

1) SLAVE-ldap, BDC, чтение.

Удаленный офис:

2) SLAVE-ldap, _PDC_, чтение. репликация на:

SLAVE-ldap, BDC, чтение.

2Удаленный офис:

3) SLAVE-ldap, PDC, чтение. репликация на:

SLAVE-ldap, BDC, чтение.


При этом это ОДИН домен, с единым пространством, филиал разворачивается довольно просто - база одна. Как только машина пытается добавится в домен - она обращается к своему, локальному PDC, тот во всей уверенности желает добавить machine account в свой, локальный LDAP, на что ldap сервер отвечает, ro, ref://master.ldap, и samba открывает SSL конекшн к MASTER-ldap и добавляет туда аккаунт, который тут же расходится по всем филиалам.

Плюсы:

Распределенная схема без организации VPN, все посредством SSL.
Прозрачная авторизация для пользователя.
Типовая схема.

Минусы:

В случае отсутствия связи, невозможно добававить машину в домен.


Во второй же схеме, когда домена 2, то авторизация пользователей будет (если будет) организована через доверительные отношения (т.н. trust account), что в свою очередь требует пользовательского доступа до PDC родного филиала для каждого входа, точнее, при каждом изменении записи пользователя в LDAP. Иначе он все время будет входить используя локальный кэш с отключенной на момент входа сетью (если бы PDC не был бы доступен вообще, тогда бы сеть можно было бы не выключать, но локальный PDC доступен и запрос будет обрабатывать он, в попытке авторизовать пользователя через trust account, а вот "родной" PDC может быть и не доступен => ответ будет отрицательным => пользователь не войдет)

>и свои samba-домены в каждом офисе с _одинаковыми SID-ми_,
За это вы вообще жестоко поплатитесь. :). Я не вижу смысла городить разные домены с одинаковыми сидами.

Не могу не согласиться.
Каковы при этом должны быть настройки BDC?

Вобщем-то все нашел, единственно не пойму как BDC понимает, где находится PDC и что именно этому серверу надо отдать все данные на новые изменения?

Вобщем-то все нашел, единственно не пойму как BDC понимает, где находится PDC и что именно этому серверу надо отдать все данные на новые изменения?

вы невнимательно читали. В стандартном варианте (1 pdc и 1 bdc only) BDC вообще не нужно ничего знать про PDC, он с ним не работает, база у него своя собственная. Он обрабатывает запросы на авторизацию. Для всех изменений (ключи machine account, смены паролей и прочего) в сети win клиентами всегда используется PDC, если по какой-то причинам PDC в данный момент недоступен - то пароль и прочее изменить не удастся.

В нашем случае (мы ведь хотим менять пароли? ;)) в каждом филиале есть PDC. Но ключевой момент - под ним реплицированная база в R/O режиме. Согласно документации к OpenLDAP - есть параметр ref, который есть ссылка возвращаемая SLAVE'ом на попытку что-то записать (на самом деле просто всегда возвращаемая т.к есть вариант с размазанным деревом), если клиент правильно написан, он перейдет по ссылке и запишет изменения туда. Так вот samba3 - "правильный" клиент. Она идет по ссылке и пишет то, что хочет в MASTER-ldap, ну а дальше стандартно изменения разлетаются репликацией.

У меня как я уже сказал не продакшн, но это работает (на тестовом стенде), там есть свои нюансы типа учета задержек - т.к с момента внесения изменений до момента появления их в локальной базе может пройти секунда-2-3, а samba хочет их сразу, но все это решаемо, причем стандартными путями.