Последние сообщения

91

Общий раздел / Re: Postfix + ldap

« Последний ответ от egor 19 Май 2020, 03:15:52 »

Здравствуйте! Не люблю давать гипотетических советов (которые сам не опробовал), но в данном случае придётся так сделать, поскольку связки AD+Exchange у меня нет (атрибуты proxyAddress и homeMTA относятся к Exchanhe), а разворачивать её ради эксперимента слишком долго и накладно.

Postfix позволяет в настройках указывать несколько карт, поэтому в virtual_transport можно указать две карты:

Код: [Выделить]

virtual_transport = ldap:/usr/local/etc/postfix/transport/ldap_transport_map.cf, hash:/usr/local/etc/postfix/transport
Понятно, что если LDAP-карта что-то вернёт, то транспорт письма будет осуществляться в соответствии с полученным ответом, если же она ничего не вернёт, то ответ должен быть получен из второй карты (типа, по умолчанию). Причём LDAP-карта должна вернуть ответ, сформированный как описано в разделе "RESULT FORMAT" man-страницы transport(5), то есть:

Код: [Выделить]

smtp:[172.16.40.12]или

Код: [Выделить]

smtp:[dom4-msg-01.dom4.domain.ru]
Это исходные данные. Теперь что касается самой LDAP-карты. Тут можно пойти двумя путями. "Простой" путь заключается в том, чтобы назначить в учётке пользователя некий свободный текстовый атрибут, который будет содержать IP-адрес (или DNS-имя) требуемого сервера. Для примера я возьму атрибут postOfficeBox. В записи пользователя с нестандартной маршрутизацией почты он будет заполнен так:

Код: [Выделить]

postOfficeBox: 172.16.40.12или

Код: [Выделить]

postOfficeBox: dom4-msg-01.dom4.domain.ru
Тогда LDAP-карта будет выглядеть примерно так:

Код: [Выделить]

server_host = 172.16.32.10, 172.16.32.11
server_port = 3268
domain = dom3.domain.ru
timeout = 60
scope = sub
bind_dn = CN=postfix,OU=Service_Accounts,OU=DOM3,DC=dom3,DC=corp,DC=local
bind_pw = Passw0rd
version = 3
search_base = DC=dom3,DC=corp,DC=local
query_filter = (&(proxyAddresses=smtp:%s)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(objectClass=user)(objectClass=group)))
result_attribute = postOfficeBox
result_format = smpt:[%s]

Проверить можно так:

Код: [Выделить]

postmap -q familia-io@dom3.domain.ru ldap:/usr/local/etc/postfix/transport/ldap_transport_map.cf
Должна вернуться строка:

Код: [Выделить]

smtp:[dom4-msg-01.dom4.domain.ru]

Второй, "сложный" способ: попробовать с помощью рекурсивных LDAP-запросов "поймать" DNS-имя Exchange-сервера на основе атрибута homeMTA записи пользователя. Сложность в том, что средствами LDAP-карты мы можем только получить что-то из значения конкретного атрибута записи, удовлетворившей заданным критериям поиска в каталоге, "вырезать" что-то из DN-имени записи не получится. То есть если в записи сервиса, на которую ссылается атрибут homeMTA записи пользователя, есть атрибут, в котором указано DNS-имя (IP-адрес) сервера Exchange, то можно попытаться добыть это значение такой LDAP-картой:

Код: [Выделить]

server_host = 172.16.32.10, 172.16.32.11
server_port = 3268
domain = dom3.domain.ru
timeout = 60
scope = sub
bind_dn = CN=postfix,OU=Service_Accounts,OU=DOM3,DC=dom3,DC=corp,DC=local
bind_pw = Passw0rd
version = 3
search_base = DC=dom3,DC=corp,DC=local
query_filter = (&(proxyAddresses=smtp:%s)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(objectClass=user)(objectClass=group)))
special_result_attribute = homeMTA
result_attribute = someAttributeWithExchageServerAddress
result_format = smpt:[%s]

Параметр special_result_attribute используется для организации рекурсивного поиска в записи, на которую указывает атрибут homeMTA, а в параметре result_attribute указывается тот атрибут, значением которого является имя Exchange-сервера (в примере я привёл фиктивное имя атрибута, его нужно заменить актуальным). Теоретически, рекурсия может быть многоступенчатой, но чтобы её грамотно организовать, нужно знать, как устроена сервисная запись "Microsoft MTA" (у меня её, повторюсь, нет). Про организацию рекурсивного поиска можно почитать в документации Postfix http://www.postfix.org/LDAP_README.html#example_group, конкретно второй случай с special.cf. О параметрах настройки LDAP-карт в man-странице ldap_table(5).

Надеюсь, мои гипотетические умозаключения наведут вас на правильные мысли и решения =) .

Егор

92

Общий раздел / Re: Postfix + ldap

« Последний ответ от JohnRD 17 Май 2020, 16:38:11 »

Егор Спасибо что ответ.
Когда я это строил, разделения на почтовые домены по 3му уровню мне казалось самым простым, я не мог предположить передвижения такого рода, это как правило объединение филиалов в одно юридическое лицо, упразднение начальства, и иногда переезд 1го директора в другой город.
Работа в домене 4, человеку из домена 3, возможна, домены друг друга знают через днс, если это на время то нет проблем, особенно если он со своим ПК приехал, пк и пользователь аунтифицируются в своем родном домене, но есть нюансы, все политики на пк и юзера прилетают с того родного домена, такие как агент касперского отчитывается в тот домен и тащит обновления от туда, настройки прокси сервера указывают на свой родной прокси, клиент 1с который лежит в сети того города и домена, и все это человек тащит с другого города по ведомственному каналу, включая почту, это терпимо и можно отключить на время политики для него, для программ типа клиента 1с, можно переписать путь на клиента в местной сети, прокси переписать на местный итд.
Но когда человек приезжает и сам не знает на сколько, это схоже с переводом военного в другую воинскую часть, то логичнее перевести его пк в местный домен, или выдать ему местный пк, завести новую учетку в этом домене и все ярлыки на программы, прокси  и тд будут ссылаться и будут привязаны к местной сети, вопрос остается с почтой, его почту знают многие контрагенты и понятно то что он ее хочет оставить за собой,
Поступить можно так, в местном Exchange добавить почтовый домен dom3.domain.ru в дополнение к родному dom4.domain.ru для приема человеку его родной почты, а в его родном постфиксе в транспорте дописать строку с IP адресом Exchange который сейчас его обслуживает, и это будет приоритетом.

Код: [Выделить]

dom3. domain.ru     smtp:[172.16.32.12]
familia-io@dom3.domain.ru smtp:[172.16.40.12]
и его почта будет приходить к нему через ведомственный канал, в Exchange нового домена с постфикса на который указывает MX, для dom3. domain.ru, так сейчас работает около года один человек.
Иногда получается договориться с человеком, выдать ему новую почту в новом домене, и настроить пересылку всей входящей почты со старого ящика прямо в Exchange, но отправлять он уже будет с новой почты, в надежде что через время все его контакты перейдут на его новый адрес.
В связи с этим в  голове вертится мысль об одном почтовом домене domain.ru
В каждом филиале на каждом Exchange делаю этот домен accepted, как родной
осталось научить постфикс определять где находится почтовый адрес в данный момент чтобы переслать именно в тот город в его домен на Exchange в котором живет его ящик.
И продумать как прописать MX ы в каждом городе, не гнать же всю почту через центр.
Хотя сейчас мобильные клиенты идут именно через центральный офис, через https, у Exchange есть понятие проксирование, центральный Exchange авторизует и конектит к своему серверу уже через ведомственные каналы.

Настройки postfix филиала

main.cf

Код: [Выделить]

virtual_mailbox_domains =
        dom3.domain.ru
virtual_mailbox_maps =
        ldap:/usr/local/etc/postfix/ldap_dom3.corp.local.cf
virtual_transport = hash:/usr/local/etc/postfix/transport

transport

Код: [Выделить]

dom3.domain.ru     smtp:[172.16.32.12]

ldap_dom3.corp.local.cf

Код: [Выделить]

server_host =
        172.16.32.10,
        172.16.32.11
server_port = 3268
timeout = 60
search_base = DC=dom3,DC=corp,DC=local
query_filter = (&(proxyAddresses=smtp:%s)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(objectClass=user)(objectClass=group)))
result_format = %s
domain = dom3.domain.ru
result_attribute = cn
scope = sub
bind_dn = CN=postfix,OU=Service_Accounts,OU=DOM3,DC=dom3,DC=corp,DC=local
bind_pw = Passw0rd
version = 3

поскольку рутовый домен corp.local содержит копии всех ldap дочерних доменов, то в центральном офисе postfix делает запрос в ldap контроллера домена corp.local
также существует MX для каждого потового домена филиала с меньшим приоритетом и указывает на IP сервер postfix центрального офиса, то центральный postfix может получить для всех дочерних доменов почту проверить в корневом ldap на предмет наличия и отослать в exchange родного домена,
также Exchange любого филиала может и отослать почту через центральный postfix, в случае проблем со своим, через внутренний MX с меньшим приоритетом, прописанный в локальном DNS

настройки postfix центрального офиса

main.cf

Код: [Выделить]

virtual_mailbox_domains =
        domain.ru,
        dom2.domain.ru,
        dom3.domain.ru,
        dom4.domain.ru,
        dom5.domain.ru,
        dom6.domain.ru,
        dom7.domain.ru,
        dom8.domain.ru,
        dom9.domain.ru,
        dom10.domain.ru
 virtual_mailbox_maps =
        ldap:/usr/local/etc/postfix/ldap_corp.local.cf
 virtual_transport = hash:/usr/local/etc/postfix/transport

ldap_corp.local.cf

Код: [Выделить]

server_host =
        172.16.10.10,
        172.16.10.11
server_port = 3268
timeout = 60
search_base = DC=corp,DC=local
query_filter = (&(proxyAddresses=smtp:%s)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(objectClass=user)(objectClass=group)))
result_format = %s
domain =
        domain.ru,
        dom2.domain.ru,
        dom3.domain.ru,
        dom4.domain.ru,
        dom5.domain.ru,
        dom6.domain.ru,
        dom7.domain.ru,
        dom8.domain.ru,
        dom9.domain.ru,
        dom10.domain.ru
result_attribute = cn
scope = sub
bind_dn = CN=postfix,OU=Service_Accounts,OU=CORP,DC=corp,DC=local
bind_pw = Passw0rd
version = 3

transport

Код: [Выделить]

domain.ru     smtp:[172.16.194.47]
dom2.domain.ru     smtp:[172.16.20.12]
dom3.domain.ru     smtp:[172.16.32.12]
dom4.domain.ru     smtp:[172.16.40.12]
dom5.domain.ru     smtp:[172.16.52.12]
dom6.domain.ru     smtp:[172.16.60.12]
dom7.domain.ru     smtp:[172.16.72.12]
dom8.domain.ru     smtp:[172.16.80.12]
dom9.domain.ru     smtp:[172.16.92.12]
dom10.domain.ru    smtp:[172.16.100.12]

в дополнение
каждый дочерний домен уникальный и у объекта юзер уже есть поля его принадлежности к своему серверу Exchange например запрос поля
homeMTA
выдаст
CN=Microsoft MTA,CN=DOM3-MSG-01,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=CORP,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=corp,DC=local

CN=DOM3-MSG-01   вот это сервер Exchange в этом филиале

93

Общий раздел / Re: Postfix + ldap

« Последний ответ от egor 17 Май 2020, 03:34:44 »

Здравствуйте!
Транспортные карты postfix через LDAP настраивать не приходилось, но попытаться можно. Но первым делом у меня возник вопрос, зачем такие сложности? Если человек из филиала 3 приехал работать в филиал 4, что мешает ему подключаться к своему почтовому серверу в филиале 3 и принимать/отправлять почту через него?

Потому что если пойти по тому пути, что Вы предлагаете, то кроме проблем с транспортом на почтовом сервере филиала 4 должны возникнуть проблемы в доставкой письма в почтовый ящик "неродного" пользователя (хотя, может для Exchange это не проблема, не приходилось с ним сталкиваться, поэтому не знаю).

Мне кажется, Вы чересчур усложните систему, в AD придётся для каждого пользователя вести данные о том, в каком филиале он сейчас находится. Рано или поздно кто-то что-то забудет изменить и почта будет ходить как попало.

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

Егор

94

Общий раздел / Re: Postfix + ldap

« Последний ответ от JohnRD 16 Май 2020, 00:56:32 »

Егор добрый день, вечер, а также уважаемые Гуру Postfix

вопрос если можно
у меня сейчас такая конструкция, 10 почтовых доменов в разных городах
центральный domain.ru
филиалы dom2.domain.ru, dom3.domain.ru, dom4.domain.ru, … dom10.domain.ru
В центральном офисе корневой Windows домен corp.local и 1 дочерний dom1.corp.local
В Остальных городах dom2.corp.local … dom10.corp.local
Между центральным офисом и филиалами есть ведомственные каналы,
Между всеми LDAP есть репликация.
Есть общая организация MS Exchange, тоесть все контакты компании доступны каждому работнику в global address list, но в каждом филиале свой Exchange сервер где живут ящики своего филиала.
Почта внутри компании ходит по ведомственным каналам не выходя наружу.
В каждом городе свой postfix является релеем для своего MS Exchange,
Почта с наружи принимается на postfix и проверяется на наличие активного ящика в своем LDAP и пересылается в свой MS Exchange согласно транспорту.
MX записи для доменов филиалов dom2.domain.ru, dom3.domain.ru, dom4.domain.ru, … dom10.domain.ru имеют приоритет 10,
для каждого почтового домена филиала есть MX с приоритетом 20 указывающий на сервер postfix в центральном офисе, чтобы принять почту и отправить ее по ведомственному каналу в филиал.
В центральном офисе postfix проверяет наличие ящика в корневом домене corp.local поскольку этот домен содержит копию всех дочерних LDAP, и далее согласно своему транспорту отправляет на сервер Exchange IP которого там указан.
Проблема начала появляться когда люди начали переезжать из филиала в филиал и работать там.
К примеру: у человека родной почтовый домен dom4.domain.ru он уехал в другой филиал на неизвестное время где свой почтовый домен dom3.domain.ru, он хочет продолжать получать почту  на свой почтовый домен dom4.domain.ru.
Если это временно со своим ноутбуком проблем нет, входит аунтифицируется и работает все идет через внутренний канал, но если надолго логичнее ему дать пк из местного Windows домена, но приходиться делать костыли такие как: разрешать местному Exchange принимать почту для домена другого филиала, править транспорт родного Postfix указывая его родной email и новый сервер Exchange для пересылки
Вот так

Код: [Выделить]

domain.ru     smtp:[172.16.194.47]
dom2. domain.ru     smtp:[172.16.20.12]
dom3. domain.ru     smtp:[172.16.32.12]
dom4. domain.ru     smtp:[172.16.40.12]
dom5. domain.ru     smtp:[172.16.52.12]
dom6. domain.ru     smtp:[172.16.60.12]
dom7. domain.ru     smtp:[172.16.72.12]
dom8. domain.ru     smtp:[172.16.80.12]
dom9. domain.ru     smtp:[172.16.92.12]
dom10. domain.ru    smtp:[172.16.100.12]

familia-io@domain.ru smtp:[172.16.72.12]
получается внешняя почта все равно идет через MX родного города и пересылается по внутренним сетям на другой Exchange

от сюда возникает вопрос, можно ли сделать проверку в LDAP не только на наличие ящика но и проверку на предмет где он сейчас находится, в каком LDAP какого домена после чего эту переменную использовать для транспорта чтобы переслать в нужный Exchange того города где он поселился.
И если такое будет возможно можно ли будет отказаться от доменов 3го уровня, выдавая всем domain.ru используя  geo-location?
Заранее благодарен за ответ

95

Конфигурация через cn=config / Re: различия в базах, проблема с репликацией?

« Последний ответ от egor 14 Март 2020, 12:40:35 »

Какой шанс, что при смене пароля, что-то пойдет не так что даже не поможет возвращение обратно, забекапленного файла /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif ?
Просто оч.стрёмно, у нас на этом авторизация пользователей завязана и черт его знает какие еще сервисы через него могут авторизироваться.

Еще раз проверил свою инструкцию по замене пароля -- если всё сделать по ней, ничего не умрёт. По сути, LDIF-файл (в виде которого представлены настройки slapd) -- это обычный текстовый файл, в котором имена атрибутов ассоциируются со значениями. Меняя значение атрибута olcRootPW, Вы всего лишь заменяете одно тектовое значение на другое. Максимум, что может пойти не так -- это Вы получите ещё один неработающий пароль для olcRootDN (если неправильно сгенерируете его утилитой slappasswd), все остальные настройки slapd останутся без изменений. В общем, здесь нет никакой магии, обычный текстовый файл с настройками, вот и всё. Тем более изменение настроечного каталога не повлияет на рабочую БД с учётками пользователей.

Естественно, как и перед любыми изменениями настроек, нужно сделать резерную копию и директории /etc/openldap/slapd.d , и рабочей БД (при остановленном slapd). Если случится страшное и slapd не запустится, просто вернёте /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif обратно, для этого и делается бэкап.

Если уж делать совсем правильно, то нужно протестировать изменения конфигурационного каталога на макете, а потом воспроизвести эти изменения в продакшн. В принципе, так должно происходить всегда, потому что экспериментировать на продакшн-системе, по меньшей мере, самонадеянно и непрофессионально -- всегда можно нарваться на неожиданные последствия.

И еще, для подификации схемы, мне полюбому нужен именно этот пароль?
И если да, то по логике вещей сотрудник который правил схему, тоже должен был пользоатся именно этим паролем?

или это не считается модификацией схемы?

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapmodify -x -H ldaps://ldap-server01.com -D cn=admin,cn=config -W -f ./add_limits.ldif

Современный способ настройки slapd -- это конфигурационный каталог cn=config. Разработчики OpenLDAP отказались от плоского конфигурационного файла slapd.conf в пользу конфигурационного каталога в первую очередь потому, что можно, не останавливая работу slapd (что очень важно в нагруженных системах), внести изменения, которые сразу же будут приняты и отразятся на работе сервиса. То, что Вы называете "модификацией схемы", как мне кажется, относится именно к внесению изменений в настройки slapd посредством модификации конфигурационного каталога cn=config. В мире LDAP-каталогов термин "схема" имеет другое значение и относится к схеме данных каталога, так что фраза "модифицировать схему без перезагрузки" может несколько дезориентировать собеседника. Если я правильно Вас понял, и Вы имели ввиду именно изменение настроек slapd, то давайте впредь будем использовать такую терминологию.

По сути, конфигурационный каталог cn=config ничем не отличается от других LDAP-каталогов, изменения в него вносятся с помощью стандартных запросов Modify протокола LDAP (это можно сделать через LDAP-браузер типа phpldapadmin или применением LDIF-файлов с помощью консольных утилит типа ldapmofify). Важный момент -- для модификации данных любого каталога нужно иметь соответствующие права на выполнение модификации. Пользователь, DN которого указано в значении атрибута olcRootDN в настройках каталога, получает неограниченные права на доступ к этому каталогу (по аналогии с учёткой root в Unix-системах). Для Вашего рабочего каталога это будет пользователь cn=admin,dc=hc,dc=com , для каталога cn=config -- пользователь cn=admin,cn=config , каждый из них может выполнять любые действия, но именно со своим каталогом. Для того, чтобы пользователь авторизовался в системе, ему нужно пройти аутентификацию, для этого и задаётся пароль в атрибуте olcRootPW.

Резюме: Внести изменения в настройки slapd путём модификации каталога cn=config можно (и нужно) без остановки сервера slapd -- для этого данный каталог и был разработан. Чтобы внести изменения в cn=config нужно обладать правами для модификации этого каталога, чаще всего для этих целей применяют аутентификацию от имени пользователя, указанного в атрибуте olcRootDN, с паролем из атрибута olcRootPW.

Надеюсь, стало понятнее. Егор

96

Конфигурация через cn=config / Re: различия в базах, проблема с репликацией?

« Последний ответ от sfmc 13 Март 2020, 16:26:42 »

Пароль я еще не менял, по вашей же рекомендации, о бессмысленном движении дальше, пока эти запросы не отработают без ошибок и превышения лимитов.

Хочу уточнить.
Какой шанс, что при смене пароля, что-то пойдет не так что даже не поможет возвращение обратно, забекапленного файла /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif ?
Просто оч.стрёмно, у нас на этом авторизация пользователей завязана и черт его знает какие еще сервисы через него могут авторизироваться.

И еще, для подификации схемы, мне полюбому нужен именно этот пароль?
И если да, то по логике вещей сотрудник который правил схему, тоже должен был пользоатся именно этим паролем?

или это не считается модификацией схемы?

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapmodify -x -H ldaps://ldap-server01.com -D cn=admin,cn=config -W -f ./add_limits.ldif

97

Конфигурация через cn=config / Re: различия в базах, проблема с репликацией?

« Последний ответ от egor 13 Март 2020, 00:30:52 »

Ну да, это довольно распространённый недочёт при настройке репликации: администраторы забывают про установленные по умолчанию ограничения на количество возвращаемых записей. Если Вы сменили пароль у пользователя cn=admin,dc=config , то можно сделать такой LDIF-файл:

Код: [Выделить]

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcLimits
olcLimits: dn.exact="cn=ldapreader,dc=hc,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

и применить его на всех трёх серверах командой типа:

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapmodify -x -H ldaps://ldap-server01.com -D cn=admin,cn=config -W -f ./add_limits.ldif

После этого ещё раз протестировать поисковый запрос с помощью ldapsearch.

Егор

98

Конфигурация через cn=config / Re: различия в базах, проблема с репликацией?

« Последний ответ от sfmc 12 Март 2020, 14:10:20 »

Все три комманды

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapsearch -xLLL -H ldaps://ldap-server0X.com:636 -D cn=ldapreader,dc=hc,dc=com -w VeryXXXXXXXXX -b dc=hc,dc=com dnна всех трех серверах
выдают 1199 dn записей из LDAP базы и завершаются так

Код: [Выделить]

Size limit exceeded (4)

99

Конфигурация через cn=config / Re: различия в базах, проблема с репликацией?

« Последний ответ от egor 12 Март 2020, 12:51:49 »

Здравствуйте!

1. Если я правильно понимаю, сейчас самые актуальные данные на ldap-server01.com и не рабочая репликация.
То если бы она заработала, какой шанс, что сервер ldap-server01.com подтянет данные из ldap-server02.com и
тем самым затрет данные, которые добавлялись в базу при не рабочей репликации?
Вообще не сильно понимаю как они не затерают друг друга...

Добавленные данные не сотрутся, но могут (и должны) стереться записи, которые были удалены со второго сервера в период отсутствия репликации. Репликация в OpenLDAP происходит по методу LDAP Content Synchronization protocol (SyncRepl) (RFC 4533), там довольно сложный алгоритм обмена данными, чтобы не пересказывать, могу посоветовать грамотное описание.

2. что делает эта команда ?

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapsearch -xLLL -H ldaps://ldap-server02.com:636 -D cn=ldapreader,dc=hc,dc=com -w VeryXXXXXXXXX -b dc=hc,dc=com dn
Она должна также выполниться и на любом компьютере, лишь бы были наместе сертификаты и стояли openldap-utils?

SyncRepl -- это расширение обычного поискового запроса Search протокола LDAP. Поэтому пока поисковый запрос, на котором основана синхронизация, не выполнится без ошибок, не заработает и сама синхронизация. В данной команде я сэмулировал тот поисковый запрос, который прописан у Вас в директиве olcSyncrepl в настройках slapd. Если запрос в таком виде не исполняется или исполняется с ошибками (например, часто при настройке репликации не учитываются лимиты на количество запрашиваемых записей), то репликация работать не будет. Надеюсь, я понятно объяснил.

Да, это обычная команда ldapsearch, выполняющая стандартный поисковый запрос. Её можно выполнить откуда угодно. Но если она не отработает корректно на сервере 1, то этот сервер будет не в состоянии синхронизироваться с сервером 2. Всё просто.

3. По поводу наведения порядка в настройках каталога в целом и репликации в частности, руководство оставляет выбор за мной. А я еще сам не особо понимаю, что для нас лучше.

Надеюсь, прочтение материал по ссылке, которую я привёл выше, поможет разобраться с репликацией и принять осмысленное решение.

Егор

100

Конфигурация через cn=config / Re: различия в базах, проблема с репликацией?

« Последний ответ от sfmc 11 Март 2020, 17:21:15 »

И снова здравствуйте!
Приношу извенения за паузу, был занят другими вопросами.

1. Если я правильно понимаю, сейчас самые актуальные данные на ldap-server01.com и не рабочая репликация.
То если бы она заработала, какой шанс, что сервер ldap-server01.com подтянет данные из ldap-server02.com и
тем самым затрет данные, которые добавлялись в базу при не рабочей репликации?
Вообще не сильно понимаю как они не затерают друг друга...

2. что делает эта команда ?

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapsearch -xLLL -H ldaps://ldap-server02.com:636 -D cn=ldapreader,dc=hc,dc=com -w VeryXXXXXXXXX -b dc=hc,dc=com dn
Она должна также выполниться и на любом компьютере, лишь бы были наместе сертификаты и стояли openldap-utils?

3. По поводу наведения порядка в настройках каталога в целом и репликации в частности, руководство оставляет выбор за мной. А я еще сам не особо понимаю, что для нас лучше.