Не удается связаться с сервером LDAP удаленно с Mac
Я пытаюсь настроить сервер LDAP с некоторыми основными параметрами безопасности, включая TLS и обязательную проверку подлинности.
Я запустил сервер и могу получить к нему доступ с localhost с помощью команды:
ldapsearch -x -b 'dc=server,dc=com' 'objectclass=*' -W -D 'cn=manager,dc=server,dc=com' -H ldaps://server.com:389
Когда я удаленно пытаюсь выполнить ту же команду с моего компьютера, я получаю следующее сообщение об ошибке:
ldap_sasl_bind (SIMPLE): не удается связаться с сервером LDAP (-1)
Я не знаю, почему это происходит, я могу пропинговать свой сервер, и в настоящее время нет брандмауэра.
slapd
запускается с -h ldaps://server.com:389/
DNS-сервер настраивается в основном на том же сервере, только с записью A.
Есть ли у вас какие-либо идеи?
РЕДАКТИРОВАТЬ
Я тестировал с другой рабочей станции, на arch-linux, и это работает! На обоих компьютерах у меня TLS_REQCERT allow
в /etc/openldap/ldap.conf
, так что не должно быть проблемы с сертификатом нет?
Рабочая станция, на которой не работает запрос ldap, находится в Mac OS X, если это имеет какое-либо значение.
Некоторый вывод:
Telnet:
telnet server.com 389
Trying w.x.y.z...
Connected to server.com.
Escape character is '^]'.
Iptables:
sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Netstat:
sudo netstat -lnt | grep 389
tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN
tcp6 0 0 :::389 :::* LISTEN
Я протестировал без каких-либо параметров безопасности, и у меня тот же результат.
2 ответа
Я хотел бы рассмотреть возможность использования стандартного порта. Начать с -h ldap:///
, LDAP поддерживает startTLS и может быть легко настроен на требование TLS перед передачей конфиденциальной информации.
С помощью Telnet можно определить, можете ли вы связаться с сервером. Попробуйте команду telnet server.com ldap
, Это должно подключиться, если адрес сервера правильный.
На сервере вы можете проверить, что LDAP привязан к внешнему адресу, используя команду netstat -lnt | grep 389
, Это покажет, какой адрес вы слушаете.
После того, как у вас работает LDAP без TLS, включите startTLS и / или добавьте ldaps:///
на ваш стартап.
Вы можете использовать опцию security update_ssf=16 simple_bind=16
требовать TLS для этих операций. Клиенты могут подключиться к LDAP
порт и свист к TLS
используя операцию startTLS.
РЕДАКТИРОВАТЬ: Использование отладки на клиенте и / или сервере может быть полезно при определении, где происходит сбой соединения. добавлять -d -1
в командной строке, чтобы отладить все. Переключатель отладки принимает битовую карту флагов отладки для различных подсистем. -d ?
перечислю их и их значения. Как только вы узнаете, что подсистема работает, вы можете прекратить отладку и сосредоточиться на других подсистемах.
Начинать отладку с клиента проще всего, но может потребоваться отладка на сервере. Если вы регистрируетесь через системный журнал, полезно иметь файл журнала отладки, в котором вы можете просмотреть выходные данные отладки.
Когда вы используете LDAP URL в формеldaps://server.com:389
, сервер будет ожидать, что согласование SSL будет иметь место, когда клиент подключится к порту389
, StartTLS не может использоваться в существующем соединении SSL: StartTLS "конвертирует" (возможно, " продвигает" - более подходящее слово) в незащищенное соединение в безопасное соединение, поэтому, поскольку ldaps://server.com:389
это уже безопасное соединение, StartTLS не может быть использован. Ваш сервер должен принимать соединения от клиентов с открытым текстом на ldap://server.com:389
и отклонить любые клиентские подключения, которые не продвигаются немедленно с использованием StartTLS - если ваш серверный продукт не может немедленно отклонить незащищенные клиентские подключения, вам следует выбрать продукт, который cat. Если также требуется конечная точка SSL, сервер должен прослушивать безопасные клиентские соединения на ldap://server.com:636
,