Проблема: при соединении с AD по протоколу LDAP (порт 389) не работает функция php для смены пароля пользователю AD. Решением является переход на SSL-версию протокола — LDAPS (порт 636). На поиск способа включить поддержку LDAPS на контроллере домена было потрачено приличное количество времени, сэкономить которое может помочь данная статья.
Шаг 1, установка служб сертификатов на контроллер домена.
certreq -new request.inf request.req
Шаг 3, получение сертификата у CA.
Вот тут самое интересное. Если попробовать разместить запрос на сертификат штатным способом, т.е. через MMC snap-in «Certification Authority» или командой
certreq -attrib «CertificateTemplate:DomainController» request.req, получаем ошибку «The DNS name is unavailable and cannot be added to the Subject Alternate name. 0x8009480f», которую обойти никаким способом так и не удалось. Зато сработала выдача сертификата через веб.
Заходим на localhost/certsrv/certrqxt.asp и вставляем в первое поле код из файла request.req; в поле Certificate Template выбираем Web Server. Скачиваем получившийся сертификат по ссылке Download certificate.
Шаг 4, импорт сертификата.
Тема: Не открывается оснастка DNS Windows Server 2008R2 (Прочитано 3783 раз)
0 Пользователей и 1 Гость просматривают эту тему.
Добрый день! С сегодняшнего утра пользователи не смогли открыть расшаренные папки на сервере:
«Вход в систему не произведен: конечная учетная запись указана неверно».
В диспетчере сервера DNS под знаком «Кирпич» активно меню только «Запустить NSLOOKUP». В журнале DNS:
DNS-серверу не удалось открыть Active Directory. Этот DNS-сервер настроен для получения и использования данных из каталога для указанной зоны и без них не может загрузить зону. Проверьте, нормально ли работает Active Directory, и перезагрузите зону. Данными о событии является код ошибки.
Доменным службам Active Directory не удается подключиться к глобальному каталогу. Дополнительные данные Значение ошибки:8430 Внутренняя ошибка службы каталогов. Внутренний идентификатор:3200db0 Действие пользователя: Убедитесь, что глобальный каталог находится в лесу и доступен для контроллера домена. Для диагностики можно использовать программу NLTEST.
Попытка зайти в оснастку DNS:
Не удалось подкючиться к серверу ServerName. Произошла следующая ошибка: «Отказано в доступе». Продолжить добавление в любом случае?
На другом форуме посоветовали выполнить команду: dcdiag /test:dns и после этого ничего не советовали. Результат:
nslookup на AD c клиентскоuj ПК:
Получается он не видит DNS и поэтому подставляет DNS провайдера? Может здесь что посоветуют? Спасибо
это единственный сервер dns?
Время верное везде?
И netdom query fsmo с контроллера или контроллеров.
Тетрис научил нас жизненно важному пониманию, успехи исчезают, ошибки накапливаются.
Сравнил разрешения с другим контроллером, никак не связанным с этим
Так у вас там всё таки один контроллер или несколько? Это лес или одиночный домен?
Перечитал и подумал что я зря это написал. Контроллер один. Леса нет.Это я сравнивал AD, который находится в другой организации.
Все восстановилось само собой О_о. В чем было дело, так и не поняли
С журнала: «Служба каталогов»1:
Доменным службами Active Directory найден глобальный каталог в следующем сайте.
Попытки обращения доменных служб Active Directory к следующему глобальному каталогу завершились неудачно. Продолжение выполнения текущей операции невозможно. Доменные службы Active Directory при помощи локатора контроллеров домена попытаются найти сервер глобального каталога. Дополнительные данные Значение ошибки:5 Отказано в доступе.
LDAP через SSL будет недоступен, поскольку этот сервер не смог получить сертификат. Дополнительные данные Значение ошибки:8009030e В пакете безопасности отсутствуют учетные данные
И по кругу.
С журнала: «Веб-службы Active Directory»
На данном компьютере теперь расположен указанный экземпляр Active Directory, но веб-службам Active Directory не удалось обработать его запросы. Веб-службы Active Directory будут периодически пытаться повторить эту операцию. Экземпляр Active Directory: NTDS LDAP-порт экземпляра Active Directory: 389 SSL-порт экземпляра Active Directory: 636
Во время инициализации DNS-сервер не определил ни одной зоны основного или вспомогательного типа. Он не будет полномочным ни для одной из зон и будет работать в качестве сервера кэширования до тех пор, пока зона не будет загружена вручную или репликацией Active Directory. Более подробную информацию смотрите во встроенной справке.
« Последнее редактирование: 04 Ноября 2020, 06:48:19 от Leaves »
ПричинаЭто происходит, когда конкретный сервер DC/DNS потерял безопасный канал с самим собой или PDC.
Это также может произойти в одной среде постоянного тока, где сервер DC/DNS содержит все роли FSMO и указывает на себя как на основной DNS-сервер.
РешениеНа случай, если в среде имеется другой контроллер домена или DNS-сервер, настройте сервер, на котором возникла проблема, чтобы указать другой активный DNS-сервер в свойствах TCP/IP.
Остановите службу KDC на контроллере домена, где возникла проблема.
Выполните следующую команду с повышенными правами:
После выполнения команды перезагрузите сервер.
Теперь необходимо загрузить зоны DNS.
ничоси приколы, потеря безопасного канала с самим собой, оно вот даже так оказывается бывает.
Особенности аутентификации контроллера домена с использованием двух разных сертификатов
Как правило, аутентификация контроллера домена в среде Windows представляет собой стандартную задачу. Однако, в некоторых ситуациях эта типовая процедура может быть осложнена необходимостью одновременного использования двух сертификатов для различных сервисов. Данная проблема может возникать, к примеру, если сервер должен предоставлять один сертификат пользователям домена, а другой – для сервисов.
Схожая проблема возникла в одном из наших проектов, где заказчику необходимо было организовать аутентификацию пользователей в домене Microsoft Windows по сертификатам ГОСТ. Обычно подобные задачи решаются путем использования специализированного средства компании «КРИПТО-ПРО», а именно «КриптоПро Winlogon». Данный продукт существует на рынке достаточно давно и максимально проработан, но иногда могут возникать непредвиденные сложности при его внедрении, с которыми нашей компании и пришлось столкнуться. Для его функционирования необходимо соответствующим образом настроить рабочую станцию, домен и контроллеры домена. Одним из требований при настройке контроллера домена в данном случае является выпуск сертификата на ГОСТ.
В случае с нашим заказчиком возникла ситуация, при которой для доступа к контроллеру домена используется, кроме протокола LDAP, еще и LDAP через SSL (LDAPS) с использованием уже установленного на контроллере сертификата RSA.
Небольшое отступление: по умолчанию трафик LDAP не защищен, что предоставляет возможность осуществлять мониторинг трафика между LDAP–клиентом и сервером. Чтобы обеспечить передачу трафика LDAP в безопасном режиме, необходимо использовать технологию SSL/TLS, сокращенно такая технология называется LDAPS.
LDAPS рекомендуется использовать в следующих случаях:
- если приложения используют аутентификацию Active Directory Domain Services через простое связывание (simple bind). Simple bind передает данные пользователя в открытом виде, поэтому рекомендуется использовать шифрование данных при аутентификации;
- если используется аутентификация через прокси-связывание;
- если приложения требуют защиты данных при интеграции с LDAP.
Таким образом, в нашей ситуации для работы LDAP over SSL/TLS (LDAPS) требуется установить сертификат на контроллер домена. Для активации LDAPS необходимо установить доверенный сертификат, выданный центром сертификации (которому доверяют контроллер домена и клиенты LDAPS) в хранилище сертификатов локального компьютера.
В связи с этим и возник вопрос совместного использования двух сертификатов, причем на различных криптографических алгоритмах при условии использования решения КриптоПро Winlogon, которое не предполагает одновременного использования двух сертификатов на контроллере домена.
Так как данная проблема не является распространенной, и, учитывая, что добавляется российская криптография, то для ее решения пришлось искать новые подходы. Изучение инструкций и тематических форумов ответа не дало. В итоге, чтобы решить данную задачу, пришлось углубиться в ее изучение и разобраться, каким именно образом контроллер домена использует сертификаты.
Итак, как же работает выбор сертификата контроллером домена?
При необходимости выбрать сертификат, контроллер обращается к хранилищу сертификатов локального компьютера и использует сертификат из этого хранилища. В большинстве случаев там будет один сертификат, и тогда проблем не возникнет. Если же в хранилище находится больше одного сертификата, то контроллер возьмет первый валидный сертификат для аутентификации сервера. Таким образом, использование одновременно двух (или более) сертификатов для различных целей в хранилище нежелательно.
Однако в Windows Server существует возможность легитимного использования нескольких сертификатов. Для этого используется отдельное хранилище Active Directory Domain Services (NTDSPersonal), в котором хранится сертификат для доступа по LDAPS.
В таком случае процесс выбора сертификата можно описать более подробно: контроллер домена сначала обращается за сертификатом к специализированному хранилищу, а в случае неудачной попытки уже обращается к хранилищу локальной машины.
Чтобы просмотреть хранилище сертификатов сервисов на контролере домена, необходимо запустить консоль управления (MMC) и добавить оснастку «Сертификаты». Далее с помощью диспетчера сертификатов следует выбрать тип управления сертификатами.
Затем необходимо выбрать учетную запись Active Directory Domain Services.
Такой тип использования имеет ряд ограничений, накладываемых Windows. К примеру, невозможность автоматического обновления таких сертификатов для сервисов или управления сертификатами из данного хранилища через командную строку.
Возвращаясь к нашей проблеме, далее для ее решения нам оставалось только создать стенд с использованием двух сертификатов на основе отечественного и западного криптографических алгоритмов.
В ходе стендирования были сделаны следующие шаги:
- в хранилище сертификатов локальной машины добавлен сертификат ГОСТ для аутентификации сервера при входе пользователей в домен;
- в хранилище сертификатов NTDSPersonal — сертификат RSA контроллера;
- проверено подключение по LDAPS (оно оказалось успешным);
- аналогично проверен процесс аутентификации пользователей в домене с помощью сертификата (на этом этапе проблем тоже не возникло).
После успешно проведенного стендирования, вооружившись данным решением, наша компания отправилась к заказчику и в нерабочие часы провела аналогичные испытания уже на «боевой схеме», которые также оказались успешными. С момента внедрения прошло достаточно времени, предложенное нами решение оказалось «рабочим», никаких проблем при его функционировании у заказчика не возникло.
Microsoft Active Directory поддерживает протокол LDAPv3. С его помощью можно авторизовать пользователей из сторонних приложений. Чтобы обеспечить безопасность при передаче учетной информации серверу необходимо использовать LDAPS (SSL). В этой статье мы рассмотрим настройку контролера доме, для обеспечения поддержки SSL.
Для того, чтобы SSL нормально функционировал нам потребуются сертификат.
Проверяем наличие сертификата
Для начала будет полезно проверить наличие сертификата в вашем домене, для этого запустим на нашем ПК утилиту ldp.exe.
Она не поставляется с Windows 10, чтобы использовать её, вам придется установить компоненты администрирования RSAT.
Нажмите Подключение — подключить, заполните окно аналогично рисунку.
Используйте имя домена, не сервера — тогда сервер для подключения будет выбран автоматически.
Если в ответ вы получили сообщение:
Это означает, что либо недоступен ни один контролер домена, либо неправильно настроен DNS, либо ПК не является членом домена, либо не установлен SSL сертификат на контролере домена.
Если сообщение похоже на такое:
Это значит, что SSL сертификат уже установлен посредством Службы сертификатов Active Directory и дальнейших действий не потребуется.
Установка OpenSSL
В этой статье я буду использовать виртуальный сервер, созданный для цикла статей.
Имя домена —
Имя контролера домена –
Виртуальная организация —
Я рекомендую все команды выполнять сразу на сервере, но вы можете так же работать и на вашем ПК, если используете MSYS2.
Те, кто использует, как и я, MSYS2, могут ввести в консоли:
pacman -Sy openssl
Создаем локальный центр сертификации
Создадим папку и назовем её CA.
Создадим в ней файл ca.conf с содержимым:
Сгенерируем приватный ключ для CA
openssl genrsa -des3 -out ca.key 4096
Укажите пароль для ключа, в нашем случае это будет :
Создадим сертификат для нашего CA:
openssl req -new -x509 -extensions v3_ca -days 3659 -key ca.key -out ca.crt -config ca.conf
Просто нажимайте Enter все поля будут заполнены автоматически!
Теперь нужно импортировать созданный сертификат в хранилище доверенных CA на нашем контролере домена.
Скопируем файл на контролер домена. Откроем PowerShell от имени администратора, перейдем в папку с файлом и введем команду:
Import-Certificate –Verbose -FilePath ca.crt -CertStoreLocation ‘Cert:LocalMachineRoot’
VERBOSE: Performing the operation «Import certificate» on target «Item: C:caca.crt Destination: Root».
PSParentPath: Microsoft.PowerShell.SecurityCertificate::LocalMachineRoot
Thumbprint Subject
———- ——-
D5D1306CFFDAF63EDA10710F13F69C0228005350 CN=altuninvv.local, O=IT, O=Altunin Soft, L=Magadan, S=Magadan region, C=RU
Сертификат успешно добавлен.
Теперь пришло время создать запрос на клиентский сертификат, который будет использовать контролер домена.
На контролере домена создадим текстовый файл —
Выполним запрос на сертификат:
certreq -new req.txt addc1.csr
CertReq: Request Created
Скопируем созданный файл на свой ПК в папку нашего CA
В папке CA создадим файл v3ext.txt с содержимым:
Сгенерируем сертификат для
openssl x509 -req -days 825 -in addc1.csr -CA ca.crt -CAkey ca.key -extfile v3ext.txt -set_serial 01 -out addc1-server.crt
Signature ok
subject=CN = altuninvv.local
Getting CA Private Key
Enter pass phrase for ca.key:
Введите пароль закрытого ключа:
Скопируем файл с сертификатом addc1-server.crt обратно на контролер домена addc1 и применим сертификат:
certreq -accept addc1-server.crt
Installed Certificate:
Serial Number: 01
Subject: CN=altuninvv.local (DNS Name=*.altuninvv.local, DNS Name=altuninvv.local)
NotBefore: 2/18/2021 5:37 PM
NotAfter: 5/24/2023 5:37 PM
Thumbprint: 4721d27e9fe34aaa672d20d68c0ec01fd9f7a82c
Из PowerShell проверим наличие сертификата:
Теперь вы должны перегрузить контролер домена, чтобы все настройки вступили в силу.
Обратите внимание, чтобы подключиться к серверу вы должны указать его полное доменное имя, в нашем случае:
Если ПК входит в состав домена altuninvv.local, вы можете использовать для подключение его имя:
Тогда контролер домена для подключения будет выбран автоматически из списка доступных, возможно, это будет работать только, при наличии Службы сертификатов на одном из серверов в AD!
Так как мой ПК не входит в домен и не использует его DNS-сервера, я прописал в файле
Проверяем подключение
Для проверки подключения мы будет использовать утилиту ldp.exe.
Запустим ldp.exe, откроется окно:
В этом окне выберите подключение – подключить
Установим галочку SSL
Нажмем Ок, будет осуществлено подключение и выведена дополнительная информация:
Теперь мы может сделать bind к серверу
Выберите Подключение – Привязка
Установите: Простая привязка
Будет выведено сообщение:
Это означает, что подключение прошло успешно.
Далее выберем пункт меню Вид – Дерево
И в окне выберем —
Откроется дерево с разделами домена,
Таким образом вы можете просматривать каталог AD через LDAP по SSL.
Заключение
Сегодня мы рассмотрели подключение к контролеру домена AD с использованием протокола LDAP по SSL.
Мы создали свой локальный центр сертификации CA с помощью OpenSSL.
Был выпущен сертификат и установлен на контролере домена.
С помощью утилиты было осуществлено подключение к контролеру домена по SSL.
В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).
Итак, сначала кратко о том, зачем же вообще использовать сервер службы каталогов (далее — LDAP-сервер). LDAP-сервера, в основном, применяются для централизованного хранения учетных записей, и всего, что с ними связано. LDAP-сервер представляет собой иерархическую БД, а значит в нем можно хранить любые данные.
Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)
Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:
- Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
- Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
- Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback’ов, репликация работает без проблем, которые присущи RDBMS;
- Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.
Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).
Ключевые особенности этого LDAP-сервера:
- Мультимастер репликация. На все сервера, участники MM-репликации, можно записывать данные одновременно, причем конфликты репликации разрешаются автоматически благодаря ведению changelog базы и системе автоматического разрешения конфликтов. MM-репликацию можно комбинировать с master-slave и каскадной репликацией, благодаря чему можно получить гибкий и масштабируемый сервис. Так же поддерживается частичная репликация, что крайне полезно, если мы не хотим, чтобы некоторые данные присутствовали на реплике;
- Мощный механизм ACL. С помощью ACL можно указать кому, когда, на каком LDAP-сервере, с каким атрибутом и какое действие выполнять. ACL хранится вместе с данными как операционные атрибуты, благодаря этому для них, как и для других данных, работают операции репликации и резервного копирования.
- Синхронизация с Microsoft Active Directory. Поддерживается двунаправленная синхронизация пользователей, групп и паролей (для синхронизации паролей из AD в 389-ds необходимо поставить специальный софт на каждый контроллер домена)
- SSL/TLS. Простой поддержкой SSL/TLS сейчас никого не удивишь. 389-ds поддерживает аутентификацию/авторизацию на основании SSL-сертификатов. Так же есть возможность шифрования атрибутов при записи на диск. При ручном вводе ключа при запуске сервера это может защитить от утечки данных путем копирования файлов с БД.
- Управление сервером через протокол LDAP. Сервер поддерживает конфигурацию путем изменения атрибутов в cn=config, большинство параметров применяются без перезагрузки сервера. Так же на сервере можно запускать резервное копирование/восстановление и другие task-и путем добавления новой записи в cn=tasks,cn=config.
- Plugins. Весь функционал реализован в виде plugin-ов (MM-репликация, синхронизация с AD, ACL, и т.п.). Написать и добавить свой plugin довольно легко, т.к. имеется хорошая документация с примерами.
После обзора возможностей 389 Directory Server познакомимся поближе с его структурой.
Общая структура 389 Directory Server
389 DS состоит из нескольких компонентов.
- Сам сервер каталогов. Это приложение ns-slapd, именно этот процесс принимает и обрабатывает запросы от клиента, производит репликацию, читает и записывает данные в базу, передает управление плагинам, и т.д.
- Консоль администрирования. Java-приложение, которое подключается к серверу администрирования и позволяет настраивать сервер каталогов через удобный интерфейс. Есть версия под windows и linux, под mac os работает через проброс X-сессии с linux-машины.
Сначала я хотел написать теоретическую и практическую части отдельно, но потом стало ясно, что первая часть стала бы слишком скучной, а вторая слишком сухой. Поэтому сразу за куском теории будет идти практическое применение.
Если один из серверов станет недоступен, другой возьмет на себя этот IP и сервис продолжит работу.
- Установка первого сервера на ldap00;
- Настройка репликации на ldap00;
- Установка и настройка ldap инстанса на ldap01;
- Установка и настройка ldap инстансов для хранения пользовательских данных.
Установка первого сервера на ldap00
Готовые rpm собраны в репозитории EPEL для Centos, RHEL и Fedora Core. Если у вас одна из этих систем — подключите репозиторий EPEL и выполните установку через yum.
Мы используем SLES, поэтому нам пришлось собирать все пакеты под эту систему в нашем OpenSUSE Build Service. Если у вас debian/ubuntu — прочтите этот документ.
Вместе с 389 DS идет набор perl скриптов, которые используются для установки инстансов сервера.
Вот некоторые из них:
- remove-ds.pl — удаляет инстанс;
- dsktune — выводит параметры системы, которые нужно изменить, чтобы добиться большей производительности.
Для начала запустим dsktune:
ldap00:~ # dsktune
389 Directory Server system tuning analysis version 10-AUGUST-2007.
NOTICE: System is x86_64-unknown-linux2.6.27.42-0.1-xen (1 processor).
NOTICE: The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds
(120 minutes). This may cause temporary server congestion from lost
client connections.
WARNING: There are only 1024 file descriptors (hard limit) available, which
limit the number of simultaneous connections.
WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.
Утилита написала о системных параметрах, которые нужно подкрутить. В моем случае это net.ipv4.tcp_keepalive_time и лимит открытых файлов.
tcp_keepalive_time — это время от последнего посланного пакета до первой посылки keepalive. При большом значении, если клиент «умер», соединение останется открытым долгое время (по умолчанию 120 минут). Установим это значение в 10 минут.
Добавим в /etc/sysctl.conf:
net.ipv4.tcp_keepalive_time = 600
для увеличения лимита открытых файлов добавляем в /etc/security/limits.conf:
запускаем еще раз dsktune и убедимся, что у нас все готово для установки.
Choose a setup type:
1. Express
Allows you to quickly set up the servers using the most
common options and pre-defined defaults. Useful for quick
evaluation of the products.
2. Typical
Allows you to specify common defaults and options.
To accept the default shown in brackets, press the Enter key.
Далее будет предложено указать FQDN и имя/группу, от которого(ой) будет запускаться LDAP-сервер.
If you do not yet have a configuration directory server, enter ‘No’ to
be prompted to set up one.
Тут нас спрашивают, хотим ли мы использовать существующий сервер каталогов для сохранения информации о сервере. Так как это наш первый сервер, отвечаем No.
Затем нас ждет вопрос о Directory Manager DN.
Directory Manager — это пользователь с правами root-а в LDAP-сервере. У каждого инстанса есть свой локальный Directory Manager.
Настройка репликации на ldap00
Для подключения к серверу нужно поставить и запустить консоль управления 389-console.
Далее мы попадаем в панель управления серверами. У нас сейчас только один инстанс, выберем его.
Из консоли управления удаляем суффикс dc=edu,dc=scalaxy,dc=local
Теперь немного теории о принципах репликации.
В репликации участвуют два типа серверов, supplier и consumer.
supplier — сервер, который копирует реплику на другой сервер.
обязанности supplier сервера:
- отвечать на запросы клиентов на чтение и запись;
- поддержание информации о состоянии изменений реплики;
- инициализация репликации на consumer сервера.
supplier сервер должен быть всегда доступен, поскольку запись производится только на этом сервере, а потом реплицируется на другие севера.
Если связь с supplier сервером будет потеряна, то запись в каталог станет невозможна.
consumer — сервер, который сохраняет реплику с другого сервера. В случае с мультимастер репликацией, два сервера одновременно являются supplier-ом и consumer-ом.
- отвечать на read запросы клиентов;
- пересылать запросы на обновления данных на сервер;
- при получении запроса на добавление, удаление или обновления записи, запрос пересылается на supplier сервер.
Каждый supplier сервер имеет свой changelog, в котором хранится информация обо всех изменениях, которые произошли на реплике.
Supplier сервер повторяет эти изменения на каждом consumer сервере.
Теперь, когда мы немного подкованы теоретически, можно настраивать мультимастер репликацию инстанса с конфигурацией.
Ведение changelog-а изменений по умолчанию выключено, включается он во вкладке Replication. Changelog включается для всех баз одновременно.
Дальше включаем репликацию для базы NetscapeRoot. Необходимо указать Replica ID и Supplier DNs.
Supplier DN — это имя пользователя, которому разрешено выполнять репликацию на LDAP-сервере. Такого пользователя нужно создать на всех LDAP-серверах, которые участвуют в мультимастер репликации.
Быстрее всего это сделать через утилиту ldapmodify. Эта утилита позволяет модифицировать данные в LDAP в интерактивном режиме или брать команды из ldif файла.
Ответ должен быть
adding new entry «cn=replication manager,cn=config»
Итого, у нас получилось:
Сразу же создадим Replication Agreement для второго сервера. В контекстном меню для базы NetscapeRoot выбираем New Replication Agreement и заполняем аналогичным образом:
Нас предупредят, что подключение к серверу невозможно (так как его еще нет), доходим до последнего пункта, ставим Do not initialize consumer.
Установка и настройка ldap инстанса на ldap01
Ответы на вопросы скрипта аналогичны предыдущим.
После установки LDAP-сервера подключаемся к нему через ldapmodify и настраиваем.
Подключение производится примерно так:
ldapmodify -h 127.0.0.1 -p 6389 -D «cn=root» -W
1) Включаем changelog:
dn: cn=changelog5,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /var/lib/dirsrv/slapd-ldap01/changelogdb
changelogdir должен указывать на директорию с названием вашего инстанса.
2) добавляем пользователя replication manager:
20380119031407Z означает, что срок действия пароля не ограничен.
3) Создаем суффикс netscaperoot:
dn: cn=»o=netscaperoot»,cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: NetscapeRoot
cn: «o=netscaperoot»
4) Создаем базу для суффикса netscaperoot:
dn: cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
changetype: add
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: o=netscaperoot
Кстати, 389 DS по умолчанию для хранения записей каталога использует модифицированную версию нереляционной базы данных Berkeley DB. Если есть желание, подробнее вы можете прочитать тут.
5) Создаем корневой o=NetScapeRoot:
dn: o=NetscapeRoot
changetype: add
objectClass: organization
objectClass: top
o: NetscapeRoot
6) Разрешаем репликацию для o=netscaperoot:
dn: cn=replica,cn=»o=netscaperoot», cn=mapping tree, cn=config
changetype: add
objectClass: nsDS5Replica
objectClass: top
nsDS5ReplicaId: 2
nsDS5ReplicaRoot: o=netscaperoot
cn: replica
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsds5ReplicaChangeCount: 0
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaType: 3
Не забываем изменить nsDS5ReplicaId на номер вашего сервера (nsDS5ReplicaType — тип репликации, 3 — multimaster).
На данном этапе у нас уже есть настроенная репликация в одну сторону с ldap00 на ldap01.
Последним этапом будет:
7) Настройка репликации от ldap01 на ldap00:
nsDS5ReplicaBindDN — имя пользователя, от имени которого будет производится репликация
nsDS5ReplicaCredentials — пароль
8) Первичная инициилизация репликации с ldap00 на ldap01:
На первом сервере выполняем эту команду:
dn: cn=Multimaster replication,cn=replica,cn=»o=netscaperoot»,cn=mapping tree,cn=config
changetype: modify
replace: nsds5beginreplicarefresh
nsds5beginreplicarefresh: start
Эта команда реплицирует данные с ldap00 на ldap01, эта операция обязательна, тк на втором сервер сейчас пустой o=netscaperoot.
Установка admin server-а на ldap01
Когда нам предложат указать Configuration directory server URL, вводим LDAP URL второго сервера ldap://ldap01.edu.scalaxy.local:6389/o=NetscapeRoot
Дальнейшая настройка тривиальна, следуем указаниям скрипта.
Установка и настройка ldap инстансов для хранения пользовательских данных
На каждом из серверов в Server Group создаем новый инстанс LDAP server-а, это будет LDAP-server, в котором мы будем хранить наши данные.
Настраиваем мультимастер репликацию между двумя инстансами по тому же принципу (теперь вы можете настроить репликацию как через GUI, так и через консоль).
Поздравляю! Вы настроили отказоустойчивый сервис службы каталогов! Далее нужно настроить openais+pacemaker, чтобы исключить простои в работе сервиса.