У компании работают несколько контроллеров домена, но VPN и ERP обращаются к одному серверу LDAPS. Когда он недоступен, каталог остаётся цел, однако пользователи не проходят проверку учётных данных. Такой случай описал системный администратор Тим Атли: все контроллеры хранили один каталог, а внешние службы зависели от единственного адреса LDAPS.
Бэкап здесь не поможет. Данные не потеряны, восстанавливать нечего. Нужно направить запросы на два контроллера и автоматически исключать тот, который перестал отвечать.
Для этого потребуются два контура защиты:
- несколько контроллеров домена поддерживают доступ к каталогу;
- балансировщик даёт приложению единый адрес и выбирает доступный контроллер;
- резервная копия возвращает каталог после повреждения или ошибочного изменения.
Балансировщик не заменяет второй контроллер. Он лишь распределяет подключения между уже работающими узлами.
Сначала найдите единственную точку отказа
Active Directory обычно не требует балансировщика для доменных компьютеров. Клиент сам находит контроллер через DNS и служебные записи каталога. Это отметил инженер Microsoft Прабхаш Шарма в разборе вариантов балансировки Active Directory.
Проблема начинается с приложений, которые принимают только один адрес LDAP или LDAPS. К ним могут относиться VPN-шлюзы, ERP-системы, сетевые хранилища и внутренние веб-сервисы.
Проверьте настройки каждого такого приложения. Если там записано имя конкретного контроллера, отказоустойчивость каталога до приложения не доходит.
Рабочая схема для одного домена выглядит так:
Приложение → единый адрес LDAPS → балансировщик → DC1
↘ DC2Citrix-инженер Карл Сталхуд рекомендует подключать к балансировке не меньше двух контроллеров каждого домена. Оба узла должны обслуживать один каталог и принимать LDAPS-подключения.
Один общий HAProxy тоже может остановить вход пользователей. В руководстве Тайлера Варна HAProxy работает локально, на том же сервере, что и приложение. При такой схеме отказ прокси затрагивает одного потребителя, а не весь контур.
Если нужен общий виртуальный адрес, дублируйте сам балансировщик. Второй вариант — ставьте локальный прокси рядом с каждым приложением.
| Что отказало | Что сохранит доступ | Что нужно проверить |
|---|---|---|
| Один контроллер домена | Второй контроллер и исправное переключение | Приложение повторяет запрос через единый адрес |
| Общий экземпляр HAProxy | Второй прокси или виртуальный адрес двух прокси | Адрес остаётся доступен после остановки первого экземпляра |
| Каталог повреждён или ошибочно изменён | Проверенная резервная копия | Копия разворачивается отдельно и содержит нужные объекты |
| Сервер приложений 1С или СУБД | Резервирование контура 1С | Вход и рабочие сеансы переходят на резервный узел |
Вывод: два контроллера закрывают отказ одного DC, но не отказ прокси, СУБД или сервера 1С.
Балансировку каталога стоит проверять вместе с отказоустойчивым кластером 1С. Доступный LDAPS не спасёт пользователей, если остановились ragent, rmngr, rphost или СУБД.
Не путайте доступность с восстановлением
Балансировка отвечает на вопрос: куда отправить новый запрос, если один узел недоступен. Резервная копия отвечает на другой: откуда вернуть данные после повреждения.
AWS Directory Service разводит эти задачи тем же способом. Сервис распределяет каталог между зонами доступности, а ручные снимки хранит для восстановления данных. Одна мера не подменяет другую.
Для локального Active Directory логика та же. Репликация переносит изменения между контроллерами, включая ошибочные. Если администратор удалил нужный объект, второй DC не станет независимой копией прошлого состояния.
Поэтому настройка балансировщика не отменяет резервное копирование 1С и каталога. Проверяйте восстановление отдельно от испытания отказа.
Рабочий контур ведите через LDAPS
LDAPS шифрует LDAP-трафик с помощью TLS. Для него используют TCP-порт 636. На контроллерах домена должны стоять подходящие сертификаты.
Открытый LDAP обычно работает через порт 389. Переводить на него рабочий контур ради простой настройки не стоит. Active Directory не принимает смену истёкшего пароля через незашифрованное LDAP-соединение, о чём пишет Карл Сталхуд в руководстве по Citrix ADC.
У балансировщика есть два способа передать LDAPS-трафик.
| Режим | Где завершается TLS | Как проверяется сертификат | Что видит балансировщик |
|---|---|---|---|
| TCP pass-through | На контроллере домена | Клиент проверяет сертификат DC | Зашифрованный TCP-поток |
| SSL_TCP | На балансировщике, затем TLS создаётся заново до DC | Клиент проверяет сертификат виртуального сервера | Расшифрованный запрос внутри прокси |
| Открытый LDAP | TLS не используется | Сертификата нет | Незашифрованный LDAP-запрос |
Вывод: TCP pass-through оставляет сертификаты на контроллерах, а SSL_TCP переносит часть управления TLS на балансировщик.
Для простой схемы с HAProxy подходит TCP pass-through. Тим Атли использовал mode tcp, чтобы передавать LDAPS до контроллеров без завершения TLS на прокси.
Не копируйте из его примера настройку ssl-server-verify none. Сам автор предупреждает: отключённая проверка сертификата открывает путь атаке посредника.
Если HAProxy сам подключается к контроллерам через TLS, укажите доверенный центр сертификации через ca-file. Тайлер Варн отдельно описывает такую проверку в своём руководстве по LDAP-бэкенду HAProxy.
Сертификат должен совпадать со способом подключения
При TCP pass-through клиент получает сертификат контроллера домена. Имя в сертификате должно соответствовать имени, которое клиент проверяет при TLS-соединении.
При SSL_TCP клиент получает сертификат виртуального сервера. Сертификаты контроллеров проверяет уже балансировщик.
Из-за этой разницы нельзя механически переключить режим с TCP на SSL_TCP. Сначала определите, кто завершает TLS и какую цепочку доверия проверяет каждая сторона.
Проверьте три соединения:
- приложение подключается к единому имени LDAPS;
- балансировщик достигает обоих контроллеров по порту 636;
- сертификатная цепочка проходит проверку без отключения контроля.
Если проверка работает только после отключения сертификатов, схема ещё не готова. Исправьте имя, цепочку или набор доверенных центров.
Открытый порт не доказывает работу каталога
TCP-проверка отвечает лишь на один вопрос: принимает ли сервер соединение на порту 636. Контроллер может открыть порт, но не выполнить LDAP-запрос.
Citrix ADC применяет LDAPS-monitor глубже. Монитор входит под служебной учётной записью, выполняет LDAP-запрос и проверяет ответ каталога. Для каждого домена Карл Сталхуд настраивает отдельный монитор.
Такую же логику стоит сохранить при другом балансировщике. Проверка должна повторять минимальную полезную операцию приложения:
- установить TLS-соединение;
- выполнить bind под отдельной учётной записью;
- отправить короткий LDAP-запрос;
- получить ожидаемый ответ;
- исключить узел после неудачи.
Служебной учётной записи хватает прав обычного пользователя домена. Её пароль не должен истекать, иначе монитор одновременно пометит недоступными все исправные контроллеры.
Пароль храните в защищённом хранилище балансировщика. Не вставляйте его в команду проверки, журнал или открытый файл конфигурации.
ldap-check HAProxy не подходит Active Directory без проверки
В примере Тайлера Варна параметр ldap-check выполняет анонимный bind. Для OpenLDAP такая проверка может пройти.
Active Directory по умолчанию запрещает анонимный bind. Тим Атли столкнулся с этим ограничением и заменил штатный ldap-check проверкой, совместимой с AD.
Здесь легко получить ложную аварию. Контроллер отвечает настоящим пользователям, но HAProxy считает его недоступным из-за запрещённого анонимного входа.
Перед переносом конфигурации в рабочий контур выясните, какой bind выполняет установленная версия HAProxy. Затем проверьте его на обоих контроллерах.
Версия тоже имеет значение. Тим Атли описал ошибки проверки LDAPS в HAProxy 1.8 из репозитория Debian. Его экземпляр сообщал Not LDAPv3 protocol, хотя контроллеры обслуживали LDAPS.
Это не основание переносить HAProxy в контейнер при любой ошибке. Сначала зафиксируйте версию, текст сообщения и тип проверки. Затем сверяйте поведение с документацией именно этой версии.
| Результат проверки | Вероятная причина | Что проверить | Что изменить |
|---|---|---|---|
| TCP проходит, LDAP-запрос не выполняется | Служба принимает соединение, но каталог не отвечает | Bind и короткий поисковый запрос | Использовать прикладную LDAPS-проверку |
| Оба DC помечены недоступными одновременно | Истёк пароль служебной записи | Вход этой записью на каждом DC | Заменить пароль и обновить монитор |
| AD отклоняет проверку, пользователи входят | Монитор делает анонимный bind | Способ работы ldap-check | Настроить bind, совместимый с AD |
Проверка сообщает Not LDAPv3 protocol | Версия HAProxy неверно проверяет LDAPS | Версию пакета и известные ошибки | Обновить пакет или сменить тип проверки |
| Один DC не проходит TLS | Ошибка сертификата или цепочки доверия | Имя, срок, издателя и ca-file | Исправить сертификат, не отключать проверку |
Вывод: монитор должен подтверждать LDAP-ответ, иначе балансировщик принимает открытый порт за исправный каталог.
Не начинайте с выбора продукта
Azure Load Balancer, Citrix ADC, F5, Kemp и HAProxy могут передавать TCP-трафик к контроллерам. Название продукта не исправляет ошибочную схему.
Azure Load Balancer работает на четвёртом сетевом уровне и может распределять подключения между DC в Azure. Azure Application Gateway ориентирован прежде всего на веб-приложения. Для LDAPS его расширенные функции не дают автоматического преимущества.
Сначала зафиксируйте требования:
- приложение принимает один адрес каталога;
- за адресом работают минимум два DC;
- трафик идёт через LDAPS;
- проверка выполняет AD-совместимый bind;
- сертификаты проверяются на каждом участке;
- отказ балансировщика тоже учтён.
После этого выбирайте инструмент, который закрывает эту схему. Для одного локального приложения может хватить HAProxy рядом с ним. Для общего адреса нескольких систем потребуется резервирование прокси.
Проверьте переключение настоящим входом
Испытание должно показать, что пользователь проходит проверку после отказа каждого контроллера. Зелёного статуса на панели балансировщика недостаточно.
Тайлер Варн проверял LDAP-бэкенд командой ldapsearch, затем останавливал службу на серверах по очереди. Для Active Directory используйте запрос с обычным bind и настройками своего домена.
Порядок проверки:
- Подключите тестовое приложение к единому имени LDAPS.
- Выполните вход при работающих DC1 и DC2.
- Остановите службу каталога на DC1.
- Дождитесь, пока монитор исключит DC1.
- Повторите вход через тот же адрес.
- Верните DC1 и дождитесь успешной проверки.
- Повторите испытание с остановкой DC2.
- Просмотрите журналы прокси и события контроллеров.
Не меняйте адрес приложения между попытками. Иначе вы проверите ручное переключение, а не работу балансировщика.
Во время испытания следите за временем исключения узла. Слишком редкая проверка задержит переход. Слишком частая создаст лишние входы служебной записи и заполнит журналы.
Готового интервала для любого контура нет. Выберите его по допустимой паузе входа, затем подтвердите результат остановкой каждого DC.
Что должно работать после настройки
Для одного домена минимальная схема включает два контроллера, LDAPS на порту 636 и единый адрес для приложения. Монитор выполняет AD-совместимый запрос, а резервная копия хранится отдельно.
Работу можно принять по пяти признакам:
- приложение знает только единый адрес LDAPS;
- каждый контроллер отдельно проходит LDAP-проверку;
- вход продолжается после остановки любого DC;
- сертификаты проверяются без
ssl-server-verify none; - каталог и базы 1С восстанавливаются из копий отдельно от проверки переключения.
Остановите ещё и HAProxy. Если вход оборвался, единственная точка отказа лишь сменила адрес. Дублируйте прокси либо размещайте локальный экземпляр рядом с каждым потребителем.