Назад | Перейти на главную страницу

LDAPS высокой доступности с Fedora Directory Server

Меня попросили настроить архитектуру HA LDAP с использованием Fedora Directory Server - компания в настоящее время использует Sun DS, но хочет отказаться от Sun.

Я хочу использовать сетевой аппаратный балансировщик нагрузки (Cisco), чтобы клиенты могли просто использовать ldap.business.com в качестве имени сервера LDAP, при этом реальные IP-адреса 4-х серверов за ним скрыты.

Для простого LDAP это хорошо работает, но теперь я хочу добавить LDAPS с использованием TLS. Кажется, что процесс установки сертификата хорошо документирован на сайте Fedora, но я не уверен, как настроить LDAPS, чтобы он был высокодоступным, поскольку я думаю, что звездный сертификат не разрешен.

Циклический DNS не будет достаточно надежным, поскольку он зависит от TTL - все еще возможно отключение LDAP.

Мы обрабатываем HA LDAPS в Novell eDirectory, но проблема аналогична. Нам удалось решить проблему с альтернативными именами субъектов в сертификатах. Альтернативные имена субъектов - это просто альтернативные субъекты, которые вы можете поместить в сертификат, чтобы дать ему более одного имени. Таким образом вы можете (теоретически) иметь единый сертификат, действительный для pop3.organisation.org, imap.organisation.org и webmail.organisation.org. Они довольно новые, но не такие новые, как сертификаты расширенной проверки.

Большинство современных клиентов LDAP достаточно умны, чтобы правильно обращаться с SAN. Кроме того, мы управляем центром сертификации, который выпустил сертификаты, поэтому получить SAN для нас просто. Это не так просто, если вы собираетесь платить за сертификат, ЦС предпочтет, чтобы вы приобрели несколько сертификатов. К сожалению для многих, некоторые программные пакеты могут загружать только один сертификат. Вот где на помощь приходит SAN.

Мы используем аппаратный балансировщик нагрузки (F5 BiP) и три сервера LDAPS. При первой настройке мы создали сертификаты, содержащие только сетевое имя IP / DNS балансировщика нагрузки. Клиенты, подключающиеся напрямую к серверам LDAP, получали ошибки сертификатов, что оказалось стимулом для того, чтобы заставить людей использовать IP-адрес балансировщика нагрузки, как они должны были делать все это время.

С тех пор мы перешли к использованию альтернативных имен субъектов, поскольку это имело некоторые отрицательные побочные эффекты при работе программного обеспечения Novell на этих серверах. Но какое-то время мы запускали его без SAN. На каждом сертификате есть три имени:

  • IP-адрес IP-адреса балансировщика нагрузки
  • DNS-имя IP-адреса балансировщика нагрузки
  • DNS-имя прямого хоста

Это открывает доступ к внутреннему имени хоста тем, кто отслеживает, но мы не считаем это уязвимостью. Другие могут.

Это то, что мы делаем, и это работает для нас.

Вы можете выполнить загрузку SSL-off на вашем балансировщике нагрузки. Можно использовать оборудование, но часто за разгрузку приходится платить за лицензию. Или вы можете попробовать haproxy, бесплатный балансировщик нагрузки, который поддерживает разгрузку SSL (версия для разработчиков)>. Другой вариант действительно использовать альтернативные имена субъектов в сертификатах, но затем, если вы хотите увеличить масштаб, вам нужно повторно выпустить все сертификаты.

Поэтому я бы выбрал вариант разгрузки SSL с балансировкой нагрузки. Либо аппаратный (стоит уточнить стоимость лицензии), либо программный. Затем убедитесь, что LB подключается через обычный HTTP, и поместите его в сегмент сети, к которому пользователи не могут подключиться. Возможно, haproxy не поддерживает загрузку ldap ssl, и вам нужно другое решение. Вы также можете использовать corosync / pacemaker и использовать сертификаты.