Конфигурация — кто-то использует tls, кто-то — нет
В данном случае выдвигается требование, что некоторые пользователи будут использовать TLS, а другие — нет. Например, политика может быть следующей:
Настройка sasl tls/ssl в openldap
В руководстве администратора OpenLDAP утверждается, что при использовании TLS с механизмом EXTERNAL SASL и клиенту, и серверу необходимо иметь действительный сертификат X.509. Если это правда, то мы получаем излишне сложную конфигурацию, а уровень безопасности повышается незначительно, и потому в большинстве случаев её использование представляется сомнительным (но есть заметные исключения, такие как репликация). В настоящее время подробно обсуждать это мы не будем.
Настройка sasl в openldap
Мы закончим этот раздел уже совсем скоро (one day real soon now ™)
Настройка сервера tls
LDAP-серверу требуется принимать только защищённые TLS-соединения от клиентов с проверкой подлинности LDAP. Поддерживается единственное пользовательское DIT с включённой службой репликации — то есть данный сервер использует наложение syncprov, кроме того, требуется доступ к сервисам cn=monitor и cn=config.
Настройка смешанного доступа tls/ssl в openldap
Если Вы сразу перешли к этому разделу, минуя описание нормальной конфигурации TLS, пожалуйста, найдите время ознакомиться как минимум с вводными замечаниями, а желательно и со всем разделом, поскольку в противном случае Вы можете очень быстро прийти в замешательство (хотя после прочтения Вы можете прийти в замешательство еще быстрее). Надеемся, однако, что некоторое просветление настанет.
Обзор
TLS (Transport Level Security) — это просто название стандартизированной IETF версии Secure Sockets Layer (SSL) от Netscape. Практически нет никаких различий между SSL(v3) и TLS(v1), и в этой документации данные термины считаются синонимами. TLS/SSL поддерживается OpenLDAP начиная с версии 2.1.
Обычно для работы TLS/SSL требуется сертификат X.509 (более известный как сертификат SSL), который можно приобрести в коммерческом центре сертификации или удостоверяющем центре (Certificate Authority, CA), либо это может быть самоподписанный сертификат.
Сессия TLS/SSL начинается с переговоров о выборе набора шифров, включающего в себя шифр обмена ключами, шифр для шифрования данных и алгоритм MAC (Message Authentication Code, представляет собой хэш). Шифр для шифрования данных или массового шифрования (который всегда является симметричным шифром, использующим вычисленный ключ сессии)
и MAC используются при передаче данных и потребляют значительно меньше ресурсов CPU, чем шифр обмена ключами (асимметричный шифр, например RSA или DSA/DSS), применение которого ограничивается посылкой ключа pre-master (на основании которого вычисляется ключ сессии) в начале обмена.
При использовании с контекстом TLS термин аутентификация указывает только на аутентификацию сервера (с помощью сертификата X.509), его не следует путать с аутентификацией LDAP, используемой для контроля доступа к DIT. При защите сессии с помощью TLS/SSL аутентификация LDAP с использованием простого (simple) механизма подсоединения становится полностью безопасной, поскольку, не смотря на то, что пароли отправляются открытым текстом, они инкапсулируются в шифрованный поток данных, таким образом, при пересылке как по доверенным, так и по недоверенным сетям, перехват (прослушивание) данных становится невозможным.
Приводимые ниже конфигурации не дают исчерпывающего описания всех возможностей использования TLS с LDAP. Скорее, они представляют собой те варианты конфигурации, которые охватывают наиболее часто встречающиеся ситуации, и, надеемся, поддаются относительно простому внедрению даже со скромным уровнем знаний в области TLS/SSL и сертификатов X.509.
Однако, если пользовательские требования выдвигают какие-то специфические условия, могут понадобиться более глубокие знания. Тогда Вам может быть полезно это руководство по выживанию, дающее жуткие подробности протокола TLS/SSL, форматов сертификатов X.509 и генерации самоподписанных сертификатов для использования в различных условиях.
Процесс инициации сессии TLS может происходить одним из двух способов:
Автоматически: Если клиент использует LDAP URL в форме ldaps://hostname/, то диалог TLS инициируется автоматически (обе стороны ожидают элементов протокола TLS/SSL) на порту по умолчанию для ldaps 636. Порт по умолчанию для ldaps может быть изменён на альтернативный путём использования URL в форме ldaps://hostname:port/, при этом сервер должен быть настроен на приём соединений на этом альтернативном порту (с помощью параметра -h при запуске slapd). Чтобы окончательно всех запутать, можно даже указать в качестве альтернативного ldaps порта 389-й (то есть нормальный порт ldap), при этом даже не придётся перенастраивать фаервол. Даже в этом случае диалог TLS будет по-прежнему инициироваться автоматически благодаря использованию схемы ldaps в URL.
Согласно определению: LDAP также может быть настроен на приём соединений TLS/SSL на стандартном порту LDAP при использовании URL ldap://hostname (порт по умолчанию — 389, но это можно изменить). В этом случае клиент должен быть явно запрограммирован (или ему должно быть указано) использовать последовательность StartTLS (сообщение с запросом расширенной операции с OID элемента управления StartTLS 1.3.6.1.4.1.1466.20037). Например, при использовании syncrepl с TLS и URL в форме ldap://hostname/ ДОЛЖЕН быть задан параметр starttls=yes или starttls=critical (если же используется URL в форме ldaps://hostname/, задавать его не обязательно).
Хотя OpenLDAP, в соответствии со своей обычной философией, позволяет производить множество разнообразных вариантов настройки, все описанные ниже конфигурации TLS схожи по характеристикам и используют лишь некоторый набор из доступных опций настройки.
Обзор безопасности ldap
У LDAP, и особенно у OpenLDAP, есть ряд возможностей обеспечения безопасности, которые на первый (да и на второй и третий) взгляд могут показаться немного сложными. Рисунок 15-1 показывает общую картину проблемы, перед тем как углубиться в детали. Далее демонстрируются различные методы доступа и интерфейсы к LDAP-системе, а затем описываются проблемные вопросы безопасности и доступные методы управления рисками. Цель данного упражнения — либо определиться с набором политик безопасности, либо выделить приоритеты реализации.
Рисунок 15-1. Общая картина вопросов обеспечения безопасности
Все номера, встречающиеся в описании ниже, ссылаются на рисунок 15-1.
Шаг 2, запрос на сертификат.
Создаём файл request.inf с текстом:
Шаг 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», которую обойти никаким способом так и не удалось. Зато сработала выдача сертификата через веб.
Заходим на
и вставляем в первое поле код из файла request.req; в поле Certificate Template выбираем Web Server. Скачиваем получившийся сертификат по ссылке Download certificate.
Шаг 4, импорт сертификата.
Winkey R — mmc; нажимаем Ctrl M, Certificates — Add — Computer Account — Next — Local Computer — Finish — OK. Certificates (local computer) — Personal — Certificates (правой кнопкой) — All Tasks — Import. Указываем файл, сделанный на шаге 3.