LDAP по SSL/TLS, работающему на все кроме входа в систему на Ubuntu

squillman дает корректный ответ.

Однако, Вы будете иметь те старые в запасе. Если Вы хотите избавиться от них, сделайте это в поле Windows Command:

C:\> del /s /q /f Thumbs.db

то единственное получает видимые

C:\> del /s /q /f /a:h Thumbs.db

получает невидимые также

Можно сделать то же самое с.DS_STORE

4
задан 1 July 2013 в 16:15
4 ответа

Я подозреваю, что Вы используете "ldaps://сервер /" для Вашего URI при необходимости в чем-то как "ldaps://server:636 /".

Не указывая порт, его попытка попробовать TLS по порту 389.

2
ответ дан 3 December 2019 в 04:35
  • 1
    Я попробовал это. Это didn' t справка. Я использовал, dpkg-реконфигурировали ldap-auth-config для установки его. Когда it' s набор к ldap://myserver это работает. Когда его набор к ldaps://myserver:636, это doesn' t работа. Но поскольку я заявил прежде, я могу открыть соединение SSL с сервером с помощью браузера LDAP без проблемы. Спасибо за предложение. Какие-либо другие идеи, каково это могло быть? I' m вид размышления, что это связано с сертификатом, не принимаемым ldap клиентскими компонентами. –  Oliver Nelson 17 September 2009 в 07:34
  • 2
    Все еще необходимо указать порт, но да, сертификат мог вызывать проблему. Если это так, в/etc/libnss-ldap.conf и/etc/pam_ldap.conf, попытайтесь добавить " tls_checkpeer no". –  hexmode 20 September 2009 в 22:16
  • 3
    tls_checkpeer didn' t помогают также. Этот shouldn' t быть этим трудно. Интересно почему документы OpenLDAP don' t имеют лучшую информацию об установке различных общих установок. –  Oliver Nelson 23 September 2009 в 18:08
  • 4
    Когда все остальное перестало работать, я пробую strace. Вы говорите you' ve попробовал браузер LDAP, но имейте Вас, попробовал инструмент CLI " ldapsearch"? если можно добраться, это для работы (прочитайте страницу справочника для опций), то необходимо смочь получить работу материала pam/libnss. Кроме того, проверьте страницу справочника на pam_ldap.conf - существует параметрический усилитель отладки, который должен извергнуть много из отладочной информации. Если Вы нуждаетесь в большем количестве помощи, можно послать мне по электронной почте или оставить анонимный комментарий к моему блогу w/электронной почтой (I' ll удаляют комментарий & это никогда не будут показывать), –  hexmode 24 September 2009 в 22:43
  • 5
    ldaps://автоматически устанавливает правильный порт в клиентских библиотеках. Можно подтвердить это с ldapsearch-ZZ-H ldaps://..., когда Вы видите тот TLS can' t быть настроенным, потому что it' s уже на месте.-Z с ldap://, чтобы заставить TLS по обычному порту или ldaps://использовать ldaps порт и SSL на подключении. –  Phil P 16 December 2009 в 01:31

sshd использует разделение полномочия и chroots. Это может взаимодействовать плохо с чем-то в стеке, требуемом включать сертификаты проверки и SSL.

Попытайтесь отключить PrivilegeSeparation временно; это - плохая идея работать как этот, но если это решает проблему затем, Вы знаете что область заняться расследованиями.

1
ответ дан 3 December 2019 в 04:35

Ну, это - проблема TLS. Просто отключите сертификат slapd's проверки на стороне клиента. TLS_ReqCert набором по умолчанию, чтобы "потребовать" на клиенте; измените его на "никогда". Это заставляет Ваш клиент доверять slapd, и в свою очередь, установить связь после квитирования tsl.

-1
ответ дан 3 December 2019 в 04:35

Привет Хотя ваша система работает с портом 389, TLS все еще может работать, потому что openLDAP может шифровать данные и отправив их по 389. Вы можете это проверить.

-3
ответ дан 3 December 2019 в 04:35

Теги

Похожие вопросы