Я изо всех сил пытаюсь найти простое объяснение того, как настроить машину CentOS 6.8 для использования LDAPS для запроса Active Directory, работающего на контроллере домена Windows 2012 R2.
Я присоединил клиент Linux к домену и настроил контроллер домена как центр сертификации. С DC я могу использовать LDP и подключиться к localhost через порт 636. Поэтому я считаю, что DC должен поддерживать LDAPS на данном этапе.
На клиенте я сгенерировал сертификат, используя: openssl req -nodes -newkey rsa: 2048 -keyout domain.key -out domain.csr
Итак, он создал эти два файла. Насколько я понимаю, мне нужно отправить запрос от клиента на DC, чтобы зарегистрировать клиента в CA. Понятия не имею, как это сделать. Я считаю, что как только я это сделаю, я смогу использовать ldapsearch для запроса активного каталога у клиента.
Итак, как мне настроить клиента для взаимодействия с контроллером домена с помощью доверенного сертификата?
Итак, я наконец смог понять, как это сделать.
Первой задачей, чтобы заставить это работать, было настроить контроллер домена как центр сертификации. Для этого я просмотрел это видео: https://www.youtube.com/watch?v=JFPa_uY8NhY
После того, как я смог подключиться к AD через порт 636, мне пришлось настроить openldap на машине CentOS для использования этого порта. Я подумал, что если я смогу заставить ldapsearch запрашивать AD на порту 636, то последним шагом будет заставить tac_plus сделать то же самое. Для настройки openldap все, что мне нужно было сделать, это отредактировать /etc/openldap/ldap.conf файл.
Я изменил три поля; BASE, URI и добавил строку "TLS_REQCERT allow".
В ОСНОВАНИЕ поле было важно получить правильно. Это должен быть правильный формат и указывать, где ваши учетные записи пользователей находятся в AD. Мой был: "CN=users, DC=ent, DC=local".
Поле URI также важно было правильно указать. Я использовал полное доменное имя для сервера и номер порта. В итоге получилось: "ldaps://dc1-ent.ent.local:636".
В "TLS_REQCERT allow" Линия позволяет машине CentOS запрашивать сертификат у контроллера домена как часть процесса установления сеанса с сервером. Это похоже на то, как SSH реализует свой алгоритм обмена ключами при установлении сеанса SSH с удаленным хостом.
Затем я использовал следующую команду ldapsearch, чтобы убедиться, что она работает:
ldapsearch -D "myusername@ent.local" -W -p 636 -h ldaps://dc1-ent.ent.local -b "CN=users, DC=ent, DC=local" -s Sub -x -ZZ "(objectclass=*)" -d1
В -d1 опция в приведенной выше команде позволяет выводить подробный отладочный вывод, чтобы я мог видеть обмен открытым ключом сервера, который будет использоваться для шифрования сеанса.
Оттуда все заработало. Я смог использовать wirehark для захвата трафика и подтверждения того, что во время аутентификации был установлен зашифрованный сеанс TLS. Я считаю, что этот метод аутентификации с помощью AD известен как PEAP. Я не удосужился заставить работать EAP-TLS или EAP-TTLS.