Пишите нам!
Архитектурная мастерская.
Продвижение сайтов от optimism.ru
Page generation time: 0.3171s (PHP: 15% — SQL: 85%) — SQL queries: 39 — GZIP disabled — Debug off
- организация, использующая в качестве базы данных сотрудников Microsoft Active Directory, базирующуюся на Windows Server 2008 R2 контроллере домена;
- написанная на php информационная система, поддерживающую протокол LDAP для взаимодействия с MS AD (например, Moodle).
Проблема: при соединении с 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 (Прочитано 3461 раз)
0 Пользователей и 1 Гость просматривают эту тему.
это единственный сервер dns?Updated: 23 October 2020, 08:26:29Время верное везде?Updated: 23 October 2020, 08:27:32И netdom query fsmo с контроллера или контроллеров.Тетрис научил нас жизненно важному пониманию, успехи исчезают, ошибки накапливаются.
Сравнил разрешения с другим контроллером, никак не связанным с этим
Так у вас там всё таки один контроллер или несколько? Это лес или одиночный домен?
Перечитал и подумал что я зря это написал. Контроллер один. Леса нет.Это я сравнивал AD, который находится в другой организации.
Все восстановилось само собой О_о. В чем было дело, так и не поняли
ПричинаЭто происходит, когда конкретный сервер DC/DNS потерял безопасный канал с самим собой или PDC.
Это также может произойти в одной среде постоянного тока, где сервер DC/DNS содержит все роли FSMO и указывает на себя как на основной DNS-сервер.
РешениеНа случай, если в среде имеется другой контроллер домена или DNS-сервер, настройте сервер, на котором возникла проблема, чтобы указать другой активный DNS-сервер в свойствах TCP/IP.
Остановите службу KDC на контроллере домена, где возникла проблема.
Выполните следующую команду с повышенными правами:
После выполнения команды перезагрузите сервер.
Теперь необходимо загрузить зоны DNS.
ничоси приколы, потеря безопасного канала с самим собой, оно вот даже так оказывается бывает.
В этой статье я расскажу вам о сервере службы каталогов 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, чтобы исключить простои в работе сервиса.
Проверяем наличие сертификата
Для начала будет полезно проверить наличие сертификата в вашем домене, для этого запустим на нашем ПК утилиту ldp.exe.
Она не поставляется с Windows 10, чтобы использовать её, вам придется установить компоненты администрирования RSAT.
Нажмите Подключение — подключить, заполните окно аналогично рисунку.
Используйте имя домена, не сервера — тогда сервер для подключения будет выбран автоматически.
Если в ответ вы получили сообщение:
Это означает, что либо недоступен ни один контролер домена, либо неправильно настроен DNS, либо ПК не является членом домена, либо не установлен SSL сертификат на контролере домена.
Если сообщение похоже на такое:
Это значит, что SSL сертификат уже установлен посредством Службы сертификатов Active Directory и дальнейших действий не потребуется.
Создаем локальный центр сертификации
Создадим папку и назовем её 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.
Установка OpenSSL
В этой статье я буду использовать виртуальный сервер, созданный для цикла статей.
Имя домена —
Имя контролера домена –
Виртуальная организация —
Я рекомендую все команды выполнять сразу на сервере, но вы можете так же работать и на вашем ПК, если используете MSYS2.
Те, кто использует, как и я, MSYS2, могут ввести в консоли:
pacman -Sy openssl
Заключение
Сегодня мы рассмотрели подключение к контролеру домена AD с использованием протокола LDAP по SSL.
Мы создали свой локальный центр сертификации CA с помощью OpenSSL.
Был выпущен сертификат и установлен на контролере домена.
С помощью утилиты было осуществлено подключение к контролеру домена по SSL.