В настоящее время у нас есть много веб-приложений, которые используют LDAP для аутентификации. Для этого мы указываем веб-приложение на один из наших контроллеров домена AD, используя порт LDAPS (636).
Когда нам нужно обновить контроллер домена, это вызывает у нас проблемы, потому что еще одно веб-приложение может зависеть от любого контроллера домена.
Мы хотели бы указать нашим веб-приложениям на «виртуальный» IP-адрес кластера. Этот кластер будет состоять как минимум из двух серверов (чтобы каждый сервер кластера мог быть заменен и обновлен). Затем серверы кластера будут проксировать LDAPS-соединения с контроллерами домена и смогут определить, какой из них доступен.
Для всех, кто имел опыт создания кластера высокой доступности для интерфейса LDAP AD:
Возможно, мой вопрос изначально был недостаточно ясен. Мои извинения за это.
Эти веб-приложения не разрабатываются нами и не поддерживают AD. Они запрашивают только имя хоста / IP-адрес LDAP-сервера. К сожалению, с этим ограничением приходится работать. Я понимаю как SRV records работают, но, поскольку это не наши приложения, в этом случае нам не помогает.
Для нас также нереально заставлять разработчиков модифицировать свои приложения, чтобы они знали AD.
Единственный вариант - решить эту проблему в рамках инфраструктуры, а не программного обеспечения. Мои вопросы адресованы всем, кто этим занимался.
Вы должны иметь возможность просто указать серверам своих веб-приложений на полное доменное имя домена Active Directory. Это должно подключить их к доступному DC.
Например, в вашем домене может быть несколько контроллеров домена:
dc1.example.com
dc2.example.com
Вместо того, чтобы явно указывать свои веб-серверы на dc1 или dc2, просто укажите их на example.com (попробуйте телнетинг на example.com через порт 636 - вы получите соединение с DC). Я думаю, что это в основном круговой DNS.
Должен признаться, я не знаю, что случилось бы, если бы DC был отключен. Для того чтобы отразить это в записях DNS, может потребоваться некоторое время, если это вообще произойдет. Возможно, стоит протестировать вместо того, чтобы ставить балансировщик нагрузки между ними.
Правильный способ сделать это - использовать DNS SRV записи, чтобы найти имена и порты контроллеров домена, а также выяснить, какие серверы использовать в каком порядке. К сожалению, не многие приложения LDAP поддерживают поиск записей SRV.
Запись SRV для контроллеров домена Active Directory: _ldap._tcp.domain.tld. Это вернет список хостов и портов, а также приоритет и вес для каждого (эти значения можно установить с помощью групповой политики), которые вместе указывают, какой сервер использовать.
Мы используем Балансировщик нагрузки сервера Cisco IOS (SLB) для этого против наших серверов OpenLDAP.
LDAP, будучи LDAP, должен работать и для Microsoft Active Directory.
Другие производители предлагают аналогичные продукты / возможности. Балансировка tcp 389/636 такая же, как балансировка tcp 80/443 (или любого другого tcp в этом отношении).
Однако у вас могут возникнуть проблемы с сертификатом. Вы могли бы указать приложению, чтобы оно было менее бдительным. (Возможно, вы уже не знаете, как подписаны ваши сертификаты AD или каким центрам сертификации вы доверяете.) Или пусть ваши серверы AD используют сертификаты с соответствующими subjectAlternativeName поля.
Возможное решение - прокси-сервер LDAP. Их не так много, но они определенно помогут. Вот один, немного перебор - http://www.unboundid.com/products/directory-proxy-server.php. Я уверен, что есть гораздо более дешевые альтернативы этому прокси-серверу с открытым исходным кодом.
РЕДАКТИРОВАТЬ: просто подумайте, в вашем приложении есть ли у вас место для ввода URI LDAP? В таком случае нельзя вводить последовательность серверов, разделенных пробелом, например: ldap: //123..456.789.111 ldap: //123.456.789.222 ldap: //123.456.789.444
Приложение должно быть достаточно надежным, чтобы делать то, что клиенты Windows делают внутри, если один контроллер домена недоступен - он пытается подключиться к другому контроллеру домена.
Это будет работать следующим образом: при запуске приложения компонент доступа к службе каталогов приложения будет выполнять следующие действия:
Затем вы используете эти заведомо исправные серверы при выполнении привязки, встраивая сервер в путь привязки. Если возникает исключение одного из типов, указывающих на проблему с постоянным током (сервер не работает, занят, тайм-аут и т. Д.), Вы добавляете этот постоянный ток в автономный список и пытаетесь выполнить операцию, используя один из других постоянного тока.
Поскольку сертификаты станут основной проблемой после того, как вы либо решите использовать балансировщик нагрузки, либо полагаться на циклический перебор DNS (т.е. ldap.contoso.com будет разрешать несколько IP-адресов), Рассел Томкинс (MSFT) опубликовал руководство для эти варианты использования здесь: Создание настраиваемых безопасных сертификатов LDAP для контроллеров домена с автоматическим продлением
Он также отмечает, что эта конфигурация не поддерживается. Как отмечается в других ответах, приложения должны использовать записи SRV, но часто этого не делают.
По сути, вам нужно добавить новый шаблон для выдачи сертификатов, в котором вы переключаетесь на «Поставка в запросе» на вкладке свойств «Имя субъекта». Вам нужно будет выпустить первый сертификат самостоятельно, указав имя балансировщика нагрузки (ldap.contoso.com) в качестве дополнительного SN, и с этого момента автоматическая регистрация вступит во владение.