Вопрос: Настройка SSL с 389 сервером каталогов для проверки подлинности LDAP


У меня есть 389 Directory Server, работающий на RHEL 5 с группами, пользователями, posix и т. Д. Клиенты RHEL проверяют пользователей с помощью LDAP - никаких проблем, все работает отлично, но пароли отправляются в виде открытого текста и отображаются с сетевым снифером. Итак, решил работать с SSL:

  1. Созданный CA - получил как частные, так и государственные сертификаты CA
  2. Использование сертификатов CA: создание как частных, так и публичных сертификатов и комбинированных (1-й файл) для 389DS в соответствии с запросом сертификата 389DS, импортированным с сертификатом CA CA на 389DS с графической консоли (Второй файл).
  3. Включенный SSL в 389DS
  4. На клиенте, используя SSL-протокол authconfig-gtk для LDAP, указан только сертификат CA 

Не работает. 

Как? Каков наилучший способ безопасного интегрирования?


7
2017-07-04 13:41


Источник


Обычно LDAP через SSL выполняется через порт 636, к какому порту ваш клиент пытается? - SpacemanSpiff
Уверен, что это 636. Вопрос в том, почему SSL-квитирование не будет работать, что не так, как это должно быть сделано и почему CA-ключа достаточно. - GioMac
Вы можете проверить свою конфигурацию ssl следующим образом: openssl s_client -connect fqdn.of.the.ldap.server.or.ip:636, Сервер должен отвечать сертификатами. В противном случае возникает проблема с конфигурацией вашего сервера. Обновите свой вопрос с результатами. - ixe013
Надеюсь, кто-то, знакомый с 389DS, может перезвонить, но наверняка оба сервера и клиент сохраняют журналы? - SpacemanSpiff
ixe013: 389 выглядит отлично: сервер отвечает публичным сертификатом и предлагает TLSv1 - GioMac


Ответы:


Первое, что вы можете сделать, это проверить, что ваш сервер правильно представляет свои сертификаты. Вы можете сделать это, пытаясь подключиться к вашему серверу с помощью OpenSSL. На клиентской машине с доступом выполните:

openssl s_client –connect target_server_fqdn:636

Это должно вернуть хороший отпечаток из сертификата сервера. Ключевым моментом здесь является проверка «Подтвердить код возврата», напечатанный в конце. Вы можете получить разные коды, но, как правило, вы должны получить 0 для действительного сертификата и, возможно, 19, если вы самоподписываетесь.

Если это не удается, вернитесь и проверьте, чтобы убедиться, что вы правильно импортировали сертификаты на стороне сервера.

Если вы прошли этот тест, перейдите к тестированию своих TLS-соединений с клиентской стороны.

На клиентской машине запустите

ldapsearch -z -ZZ '(uid=<testusername>)'

Это заставит поиск LDAP по зашифрованному соединению. Если это будет успешным, вы должны вернуть некоторую пользовательскую информацию, и проверка в журналах DS должна привести к следующему:

[23 / Sep / 2011: 07: 48: 57 -0500] conn = 1631 op = 0 EXT oid = "X.X.X.X.XX.X.XX" name = "startTLS"   [23 / Sep / 2011: 07: 48: 57 -0500] conn = 1631 op = 0 RESULT err = 0 tag = 120 nentries = 0 etime = 0   [23 / Sep / 2011: 07: 48: 57 -0500] conn = 1631 SSL 256-бит AES

Если это не удается, вы должны убедиться, что сертификаты были правильно импортированы на стороне клиента.

При устранении неполадок некоторые общие области, которые я обнаружил, часто видят:

1.) В некоторых случаях (в некоторых случаях кто-то может лучше объяснить) клиенты могут попытаться выполнить подписание, отредактировав ldap.conf и включив строку

TLS_REQCERT allow

2.) Если графический интерфейс аутентификации дает вам проблемы, вы можете попытаться просто явно включить TLS для LDAP с

authconfig --enableldaptls --update 

Раньше у меня были проблемы с графическим интерфейсом, поэтому я стараюсь использовать команды CLI.

3.) И последнее, что вы можете попробовать (опять же, просто для тестирования), вызывает

cacertdir_rehash <dir where certs are stored>

Обновить

Если вы ищете дополнительную помощь в создании собственных сертификатов, попробуйте следующее:

1.) Создайте свой собственный самоподписанный сертификат CA:

certutil -S -n "<CA Certificate Name Here>" -s "cn=<CN Name Here>, dc=<Your DC's FQDN>" -2 -x -t "CT,," -m 1000 -v 120 -d . -k rsa

2.) Создайте сертификат сервера для сервера каталогов

certutil -S -n "Cert-Name" -s "cn=<Server FQDN>" -c "<Name of CA Certificate>" -t "u,u,u" -m 1001 -v 120 -d . -k rsa 

3.) Импортируйте оба этих сертификата в сервер каталогов в разделе «Управление сертификатами», выбранном в разделе «Задачи»,

4.) Включить шифрование TLS

5.) Создайте экспортируемый сертификат для клиентов и выведите его в файл .pem.

certutil -d . -L -n "<CA Certificate Name>" -a > cacert.pem

6.) По вашему выбору - загрузить клиентский сертификат на каждого клиента.

7.) Переориентируйте сертификаты, используя ранее упомянутую команду

cacertdir_rehash <dir where certs are stored>

7
2017-07-09 18:34



Похоже, что сертификаты сервера все еще не созданы должным образом, также похоже, что формат изменился. Я пытался создать и импортировать сертификаты с помощью howto, которые я нашел, но не успел. - GioMac
Прохладный, сужающийся - Итак, вы пытаетесь создать самозаверяющие сертификаты? Или вы купили его у большего CA? - Univ426
Если вы хотите, я могу обновить свой ответ с помощью процесса, который я использовал для создания сертификатов с помощью CertUtil, надеюсь, это поможет. - Univ426
Разве это не парень на Fedora или что-то еще, и certutil проприетарный инструмент MS? - Ram
Думаю, он сказал, что он на RHEL5. Я думаю, что MS имеет сборку certutil тоже, может быть, то же самое, может быть иная, но я знаю, что certutil поставляется в комплекте с Directory Server, и мы используем его на наших RHEL-системах. docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.1/html/... - Univ426


Мне не повезло настроить SSL для серверов 389 или серверов администратора, следуя инструкциям, которые я нашел (я понял, что это потому, что я использовал Centos 6, и большинство из хаотов предназначалось именно для Redhat).

Наконец, для меня было инициировать запросы на сертификаты с интерфейсов сервера 389-console (admin | dir), подписать эти требования с помощью установки tinyCA (просто интерфейс для opensl, я ленив), экспортировать подписанные сертификаты PEM и CA сертификаты и импортировать их обратно с помощью 389-консоли.

389 -> Серверная группа -> (сервер admin / directory) -> Открыть -> Управление сертификатами

Надеюсь это поможет...


2
2017-07-10 15:39



Спасибо за сообщение: То же самое здесь ... Я пробовал все инструкции и руководства, но они нацелены на RHDS, а не 389 (есть разница). Я постараюсь завтра создать сертификаты таким же образом и ответить. - GioMac
tinyCA - хорошая вещь (c). Я создал CA, экспортировал сертификат CA, импортировал в 389DS, создал запрос с 389DS, импортировал сертификат запроса в tinyCA, подписали запрос с tinyCA, создал сертификат сервера с помощью этого запроса, экспортировал, а затем импортировал в 389DS, создал сертификат клиента, экспортировал и скопированный в каталог сертификатов клиента, также скопированный cacert. Не повезло. Все параметры были по умолчанию. Итак, у меня есть сертификат cacert и server в 389DS, а также сертификат cacert и client в openldap. Любой отзыв? - GioMac


Вероятно, лучший способ - использовать FreeIPA.


1
2017-07-16 08:41



Сделано с FreeIPA. - GioMac
FreeIPA хорош, пока вы не захотите добавить собственную схему. Добавление пользовательской схемы не поддерживается сообществом FreeIPA и Red Hat. - atolani
Скалы FreeIPA. Причуды ушли, отлично работают на 95% случаев использования, большинство других - в дорожной карте. - Brian Topping


Не могли бы вы использовать ссылку ниже для настройки RHDS / 389-ds на SSL.

http://lists.fedoraproject.org/pipermail/389-users/2012-March/014200.html

Надеюсь, это поможет.


0
2017-08-24 13:23



Спасибо, проверит для LDAP в следующий раз. Цель была достигнута с FreeIPA, но для 389 я все еще не мог запустить LDAPS. - GioMac


Проект 389 Directory Server поддерживает руководство по TLS / SSL здесь http://www.port389.org/docs/389ds/howto/howto-ssl.html

Это охватывает администрирование сертификатов сервера без консоли администратора. Надеюсь, это поможет,


0
2018-04-24 00:01



Добро пожаловать в ServerFault. meta.stackexchange.com/questions/8231/...  Можете ли вы сделать свой ответ самостоятельно? - chicks