Я знаю, что балансировка нагрузки или отработка отказа LDAP на контроллере домена Windows, как правило, не очень хорошая идея из-за проблем с Kerberos и SPN.
НО, у меня есть много приложений, отличных от Windows, которые используют LDAP для аутентификации и авторизации. Они просто указывают на один контроллер домена прямо сейчас, было бы неплохо иметь VIP и пул со всеми моими контроллерами домена за ним.
Так в чем же дело, когда я это вижу ?:
https://devcentral.f5.com/questions/ad-dcs-behind-f5
Есть ли у F5 что-то особенное? Он просто возвращается к NTLM? Или он просто использует простую привязку LDAP к AD? (или привязка SLDAP).
Как лучше всего использовать LDAP для клиентов, отличных от Windows? Должны ли они просто быть разработаны из коробки для использования записей SRV локатора DNS? Следует ли развертывать AD-LDS и при этом балансировать нагрузку?
Что-то мне не хватает?
Да, приложения, которые действительно хотят взаимодействовать с Active Directory должен быть спроектированным для использования надлежащих процедур определения местоположения постоянного тока (которые хорошо документированы); к сожалению, довольно часто это не так.
Обычно это можно обойти, указав в приложении LDAP имя домена Active Directory, а не конкретный контроллер домена, потому что каждый контроллер домена автоматически регистрирует запись AN A для доменного имени, указывающего на его IP-адрес, поэтому это будет работать как циклический перебор DNS. ; однако это может вызвать и вызовет две важные проблемы:
Немного лучшим решением является создание собственной записи DNS для приложений LDAP в виде записи CNAME, указывающей на конкретный контроллер домена, например ldap.example.com указывает на dc1.example.com, и установите для него медленный TTL (например, 60 секунд); затем вы можете настроить свое приложение для использования ldap.example.com для всех его потребностей LDAP. Если / когда DC1 выйдет из строя, вы можете переназначить ldap.example.com к dc2.example.com, а медленный TTL гарантирует, что приложение узнает об изменении как можно скорее, что минимизирует время простоя.
В любом случае, действительно лучше избегать решения для балансировки нагрузки, потому что LDAP просто не предназначен для работы с ними, и они могут загружать любые проблемы.
Одна из проблем с использованием балансировщика нагрузки заключается в том, что в зависимости от активности некоторые приложения могут запрашивать дескриптор DirectoryEntry. DirectoryEntry включает имя сервера. Это чаще встречается при обновлениях, но также может происходить при чтении / запросах. Очевидно, что в этом случае вы не используете балансировщик нагрузки. Достаточно ли этого для аутентификации? Может быть.
Я узнал, что если вы сделаете услугу доступной, люди могут использовать ее не по назначению. Значит, вы настроили VIP "только аутентификацию"? Может, кто-то решит использовать его для чего-то другого. Это действительно важно. Что будет, если он взорвется?
Другой вопрос, что такое проверки работоспособности? Контроллер домена нередко подключается к порту 389/636, но работает некорректно. Так что прямой проверки порта может быть недостаточно.
Обычно отказоустойчивость подключения Active Directory (процесс DC Locator) передается клиенту. Когда вы начинаете возиться с ним, чтобы сделать его «высокодоступным», вы берете на себя ответственность за проблемы. И некоторые из этих проблем может быть трудно диагностировать и решить. Кто вас поддержит? F5? Microsoft? Удачи с этим.
Почти все продукты аутентификации LDAP, отличные от Windows, которые я видел, могут использовать запись DNS. Вместо того, чтобы указывать на конкретный сервер, вы можете указать на корень своего домена. Это должно работать в подавляющем большинстве ситуаций.
Это тот случай, потому что, если вы выполните поиск в корне своего домена, например example.com он должен вернуться со всеми IP-адресами контроллеров домена. Это позволяет использовать стандартный циклический DNS без какой-либо специальной настройки.
Это больше о высокой доступности или производительности?
Для производительности хочу выделить это:
У меня есть много приложений, отличных от Windows, которые используют LDAP для аутентификации и авторизации. Сейчас они просто указывают на один контроллер домена.
Очевидное быстрое решение здесь - направить некоторые из ваших приложений на дополнительные контроллеры домена. Конечно, это не идеально, потому что оставляет приложения уязвимыми в случае отказа контроллера домена, но это любой простой способ помочь распределить нагрузку сразу.
Для обеспечения высокой доступности вы можете указать приложениям на доменное имя или (что еще лучше) на имя домена. Это не очень хорошо, потому что это означает ручную настройку DNS, если что-то пойдет не так, но это облегчит реакцию.
Вы можете комбинировать эти методы, используя записи cname для нескольких контроллеров домена. Нагрузка распределена, и вы можете легко настроить запись cname для отдельного DC в случае сбоя.
На этот случай у меня есть 3 сервера в VIP.
Кроме того, использование доменного имени часто является плохим, потому что оно попадет в первый DC в возвращаемом списке, если приложение не поддерживает сайт (в большинстве случаев нет). Это может быть где угодно в стране, и это плохо сказывается на нагрузке и задержке WAN.
Мы также пробовали использовать циклический перебор DNS. Проблема заключается в следующем: большинство приложений просматривают настроенное имя хоста LDAP один раз, захватывают первый возвращаемый IP-адрес и затем кэшируют этот IP-адрес. Это означает, что все запросы LDAP из этого приложения в конечном итоге каждый раз отправляются на один и тот же сервер LDAP, что противоречит цели циклического перебора. Мы попробовали несколько различных настроек балансировщика нагрузки, но дали неоднозначные результаты. В настоящее время мы пробуем бесплатную версию Kemp LoadMaster. Пока что это, похоже, неплохо работает с нашими внутренними приложениями, но одно конкретное приложение (JAMF) столкнулось с множеством проблем при попытке передать запросы LDAP через наш брандмауэр, даже если брандмауэр настроен правильно.