LINUX.ORG.RU
ФорумAdmin

[samba][ssl][openldap] Как заставить samba шифровать по-человечески?

 , ,


0

1

Здравствуйте.

Пытаюсь найти, как отключить нахрен starttls и заставить samba подключаться к openldap, используя указанные сертификаты и только их.

Сперва цитатка с сайта самбы http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#LDAPSSL :

This option is used to define whether or not Samba should use SSL when connecting to the ldap server This is NOT related to Samba's previous SSL support which was enabled by specifying the --with-ssl option to the configure script.

LDAP connections should be secured where possible. This may be done setting either this parameter to Start_tls or by specifying ldaps:// in the URL argument of passdb backend.

The ldap ssl can be set to one of two values:

Off = Never use SSL when querying the directory.

start tls = Use the LDAPv3 StartTLS extended operation (RFC2830) for communicating with the directory server.

Please note that this parameter does only affect rpc methods. To enable the LDAPv3 StartTLS extended operation (RFC2830) for ads, set ldap ssl = yes and ldap ssl ads = yes. See smb.conf(5) for more information on ldap ssl ads.

Default: ldap ssl = start tls

Как написано здесь, самба не умеет работать ни с чем, кроме starttls.

Ок, не вопрос. Указываем.

# testparm 
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[printers]"
Processing section "[print$]"
Loaded services file OK.
Server role: ROLE_DOMAIN_BDC
Press enter to see a dump of your service definitions

Сам openldap-сервер находится на другой машине. На машине с самбой — только клиентская часть.

Где-то проскакивала информация, что samba использует /etc/openldap/ldap.conf:

BASE    dc=test,dc=local
URI     ldaps://ldaps.test.local ldaps://ldapm.test.local

DEREF           never

TLS_CACERT /etc/openldap/ssl/test-cacert.pem
TLS_CERT /etc/openldap/ssl/sampdc-cl.test.local-cert.pem
TLS_KEY /etc/openldap/ssl/sampdc-cl.test.local-key.pem

TLS_REQCERT hard

В качестве теста, указанные сертификаты с ключом доступны на чтение всем. На сервере, соответственно, обязательно требуются сертификаты.

Шифрование, разумеется, работает прекрасно, pam_ldap и nss_ldap в соответствующем конфиге настроенные аналогично, соединяются с любым из указанных серверов, используя указанные сертификаты, если подложить левый, не подписанный нужным CA, то соединение отбивается.

Так вот, пробуем самбу, получаем отлуп, в логах:

2011-06-18T01:32:00+04:00 ldaps slapd[3589] conn=1279 fd=27 ACCEPT from IP=192.168.1.216:57716 (IP=0.0.0.0:636) 
2011-06-18T01:32:00+04:00 ldaps slapd[3589] conn=1279 fd=27 closed (TLS negotiation failure) 
и
2011-06-18T01:32:25+04:00 sampdc smbd[5537] [2011/06/18 01:32:25.640160,  0] lib/smbldap.c:731(smb_ldap_start_tls) 
2011-06-18T01:32:25+04:00 sampdc smbd[5537]   Failed to issue the StartTLS instruction: Can't contact LDAP server

Если же на сервере openldap смягчить требования в параметре olcTLSVerifyClient с hard на allow, то сервер перестаёт ругаться, а вот самба — продолжает. Если поставить параметру ldap ssl значение yes, то оно игнорируется как неверное.

Итак, вопрос: умеет ли самба, как прочие нормальные программы, соединяться с openldap по шифрованному каналу на 636 порт, с использованием только тех сертификатов и ключа, которые указывает администратор?



Последнее исправление: HolyBoy (всего исправлений: 2)

Если кто-то кроме DRVTiny может навскидку сказать в чём трабла, так это гугл. Запроси результаты по списку рассылки, высока вероятность что найдёшь ответ
google://site:lists.samba.org «Failed to issue the StartTLS instruction: Can't contact LDAP server»
например, вот результат http://lists.samba.org/archive/samba/2009-February/146730.html

adriano32 ★★★
()

Как написано здесь, самба не умеет работать ни с чем, кроме starttls.

Всё она умеет.

ldap ssl = off
passdb backend = ldapsam:ldaps://localhost


И, как любой другой (!) софт использующий библиотеки ldap-client параметры шифрования и прочего задаются именно в /etc/openldap/ldap.conf, пути ессно зависят от дистра.

zgen ★★★★★
()
Ответ на: ldap ssl = off от HolyBoy

Очевидно же!

Да, мне тоже было не по себе.

Пожалуйста!

zgen ★★★★★
()
Ответ на: комментарий от zgen

Тогда, пользуясь случаем, задам ещё один вопрос, если не возражаешь. :)

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

HolyBoy
() автор топика
Ответ на: комментарий от HolyBoy

в первую очередь нужно смотреть, что за проблемы. Тогда будет понятно, использовать gnutls или нет. Лично я не использую - я очень консервативен.

zgen ★★★★★
()
Ответ на: комментарий от zgen

Например, такие проблемы.

Сервер запущен с таким параметром

olcTLSVerifyClient: hard
и использует сертификаты, указанные ниже (0400 назначено только для теста):

# ls /etc/openldap/ssl/ -l
total 10
-r--r--r-- 1 ldap ldap 2569 Jun 14 11:17 test-cacert.pem
-r--r--r-- 1 ldap ldap 2476 Jun 14 11:17 ldaps.test.local-cert.pem
-r--r--r-- 1 ldap ldap 3247 Jun 14 11:17 ldaps.test.local-key.pem

На том же сервере настроена клиентская часть:

# cat /etc/openldap/ldap.conf
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

BASE    dc=test,dc=local
URI     ldaps://ldaps.test.local ldaps://ldapm.ph.local

#SIZELIMIT      12
#TIMELIMIT      15
DEREF           never


TLS_CACERT /etc/openldap/ssl/test.pem
TLS_CERT /etc/openldap/ssl/ldaps.test.local-cert.pem
TLS_KEY /etc/openlap/ssl/ldaps.test.local-key.pem

TLS_REQCERT hard

Проверяем с этой машины:

# ldapsearch -v -H ldaps://ldaps.test.local -b 'ou=mail,dc=test,dc=local' -d 127
ldap_url_parse_ext(ldaps://ldaps.test.local)
ldap_initialize( ldaps://ldaps.test.local:636/??base )
ldap_create
ldap_url_parse_ext(ldaps://ldaps.test.local:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldaps.test.local:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.1.212:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0

… тут обмениваются сертификатами…

tls_read: want=5, got=5
  0000:  16 03 03 00 b2                                     .....             
tls_read: want=178, got=178 …и т.д.…

в конце

tls_write: want=6 error=Broken pipe
TLS: can't connect: Error in the push function..
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

В логах сервера

2011-06-18T16:56:30+04:00 ldaps slapd[3589] conn=1892 fd=26 ACCEPT from IP=192.168.1.212:60670 (IP=0.0.0.0:636) 
2011-06-18T16:56:30+04:00 ldaps slapd[3589] conn=1892 fd=26 closed (TLS negotiation failure)

Чтобы убедиться в использовании ldapsearch'ем ldap.conf'а, поменяем, к примеру, путь до CA сертификата и снова попытаемся сделать запрос:

# ldapsearch -v -H ldaps://ldaps.ph.local -b 'ou=mail,dc=ph,dc=local' -d 127
ldap_url_parse_ext(ldaps://ldaps.test.local)
ldap_initialize( ldaps://ldaps.test.local:636/??base )
ldap_create
ldap_url_parse_ext(ldaps://ldaps.test.local:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldaps.test.local:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.1.212:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

А вот если мы поменяем, скажем, только путь для клиентского сертификата, то получим то, что выше написано.

Пробую с помощью ssl подключиться:

# openssl s_client -connect ldaps.test.local:636 -CAfile /etc/openldap/ssl/test-cacert.pem -showcerts -cert /etc/openldap/ssl/ldaps.test.local-cert.pem -key /etc/openldap/ssl/ldaps.test.local-key.pem

…выводит информацию о сертификатах…

SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: ##################
    Session-ID-ctx: 
    Master-Key: #################
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1308403603
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

Вот, как-то так.

HolyBoy
() автор топика
Ответ на: комментарий от HolyBoy

очепятка, млин

Вместо

0400 назначено только для теста

0444 назначено только для теста

HolyBoy
() автор топика
Ответ на: комментарий от HolyBoy

Например, такие проблемы.

Сервер:

test-cacert.pem


Клиент:

TLS_CACERT ...test.pem


openssl check:

...test-cacert.pem


Проверять как-то надо с одними и теми же сертификатами, иначе можно до такого допроверяться.

zgen ★★★★★
()

Во-первых, LDAP over SSL - это костыль, не стандартизованный и не рекомендованный к использованию. Во-вторых, механизмы проверки сертификатов в SSL и TLS используются одни и те же, так как libldap/slapd просто используют какую-то стороннюю библиотеку для этого (openssl или gnutls).

TLS_REQCERT hard

С такой настройкой клиент (в твоём случае - smbd) запросит сертификат сервера и будет его проверять. Если проверка не будет пройдена, то клиент не будет работать с сервером.

Если же на сервере openldap смягчить требования в параметре olcTLSVerifyClient с hard на allow, то сервер перестаёт ругаться, а вот самба — продолжает.

Вот об этом я и говорю.

Проверь свои сертификаты. У тебя скорее всего имя сервера в сертификате сервера не совпадает с тем именем, на которое коннектится самба (ldaps.test.local).

Deleted
()

И попробуй с самбовой машины «потыкать» сервер стандартными утилитами openldap (например ldapsearch). Только не забудь указать ключ "-ZZ", чтобы утилита обязательно требовала TLS.

Deleted
()
Ответ на: комментарий от Deleted

Проверь свои сертификаты.

У него CA сертификаты разные как минимум. Выше я написал уже.

zgen ★★★★★
()
Ответ на: комментарий от Deleted

Во-первых, LDAP over SSL - это костыль, не стандартизованный и не рекомендованный к использованию.

Кем не рекомендованный?

zgen ★★★★★
()
Ответ на: комментарий от zgen

Кем не рекомендованный?

Ни кем не рекомендованный =). Просто протокол LDAP и его расширения стандартизованы. Это очень важно для интероперабельности между грудой разнообразного софта, который прикручивают к LDAP. Насчёт LDAP over SSL никаких стандартов не существует. По этому использовать лучше TLS, если такая возможность есть.

Хотя да, IRL бывает софт который работает только с TLS (openssh-lpk), либо только с SSL (ejabberd) =).

Deleted
()
Ответ на: комментарий от zgen

SSL меня привлекает только тем, что я в любой момент могу быть уверен, что там только encrypted data.

Можно же со стороны сервера запретить нешифрованные соединения. Либо в настройки бэкэнда (security или olcSecurity), либо ACL'и изменить примерно таким образом:

...
by ssf=128 dn="cn=foo,dc=example" write
by ssf=128 dn="cn=boo,dc=example" read
by * none
...
И всё, без шифрования (SSL или TLS) никто даже не авторизуется.

Документация: http://www.openldap.org/doc/admin23/security.html.

Deleted
()
Ответ на: комментарий от Deleted

Кстати, если я не ошибаюсь, то само по себе наличие SSL не гарантирует наличия шифрования. Так что дополнительно требовать шифрования со стороны сервера не помешает даже при использовании только LDAPS.

Deleted
()
Ответ на: комментарий от zgen

Да не, не, сертификаты как раз одни и те же. Просто там вбито слишком много говорящее имя, потому и меняю на «test» в выхлопе.

Ведь что странно: репликация между двумя LDAP-серверами как раз настроена нормально. Указал сертификаты и поехало. Используются те же самые сертификаты, что выше показано.

Подозрения на gnuTLS пали из-за того, что в одной из рассылок про это разговор шёл. Именно ldapsearch не работал.

HolyBoy
() автор топика
Ответ на: комментарий от Deleted

[qupte]Если проверка не будет пройдена, то клиент не будет работать с сервером.

Это нормально. Я потому и включил.

У тебя скорее всего имя сервера в сертификате сервера не совпадает с тем именем, на которое коннектится самба (ldaps.test.local).

См. предыдущий ответ. У меня на двух серверах настроены взаимно реплицирующиеся openldap-сервера через SSL/TLS. С самыми жёсткими настройками. Всё ок.

Имена файлов не особо важны, важнее в показанном выхлопе сообщения о невозможности и т.д.

HolyBoy
() автор топика
Ответ на: комментарий от HolyBoy

Это нормально. Я потому и включил.

Что ты включил? Вот это в _клиентском_ конфиге:

TLS_REQCERT hard
Пробовал менять на allow?

И повторю ещё раз: попробуй использовать ldapsearch с ключами -ZZ и коннектом к ldap:// (_не_ ldaps://) на машине с самбой. Результат сообщи.

Deleted
()

И выложи куда-нибудь все используемые сертификаты. Без ключей естественно 8).

Deleted
()
Ответ на: комментарий от Deleted

Пробовал менять на allow?

Пробовал. Безрезультатно.

Ещё разок попробую объяснить.

Сперва я пытался подключиться к серверу openldap на машине с самбой. Требовалось, чтобы самба читала конфигурацию из ldap.conf. STARTTLS мне не нужен был, т.к. я собирался выключить прослушивание 389 порта вообще. Товарищ zgen подсказал, что для этого надо, это помогло и самба стала читать нужный конфиг. К сожалению, после закручивания гаек на сервере, появились проблемы, теперь уже с клиентской частью openldap.

На той же машине, что самба находится, уже настроен nss_ldap, который использует клиентский (не серверный) сертификат для подключения. Использует без проблем, всё отлично работает. Соединение точно шифрованное, смотрел tcpdump'ом. Эти же сертификаты я пытался использовать в ldap.conf. Результат нулевой.

После этого, я решил перейти временно на сервер с openldap, т.е. на ldaps.test.local. Что у меня там получилось, можно посмотреть в 9 сообщении темы. Замечу, что на этот раз, я в ldap.conf указал серверные сертификаты, которые уже slapd использовал. Результат там и ниже описан.

И повторю ещё раз: попробуй использовать ldapsearch с ключами -ZZ…

Хорошо, хотя, как я сказал, это в работу не пойдёт.

# ldapsearch -v -H ldap://ldaps.test.local -b 'ou=mail,dc=test,dc=local' -ZZ -d 127
ldap_url_parse_ext(ldap://ldaps.test.local)
ldap_initialize( ldap://ldaps.test.local:389/??base )
ldap_create
ldap_url_parse_ext(ldap://ldaps.test.local:389/??base)
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldaps.test.local:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.1.212:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_dump:…
…
ldap_result ld 0x21fd5f0 msgid 1
wait4msg ld 0x21fd5f0 msgid 1 (infinite timeout)
wait4msg continue ld 0x21fd5f0 msgid 1 all 1
** ld 0x21fd5f0 Connections:
* host: ldaps.test.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Sun Jun 19 11:32:15 2011
…

…меняются сертификатами…

…и, снова, примерно в том же месте…

tls_write: want=6 error=Broken pipe
TLS: can't connect: Error in the push function..
ldap_err2string
ldap_start_tls: Connect error (-11)
        additional info: Error in the push function.

Лог сервера:

2011-06-19T11:40:01+04:00 ldaps slapd[3589] conn=2407 fd=29 ACCEPT from IP=192.168.1.216:50274 (IP=0.0.0.0:389) 
2011-06-19T11:40:01+04:00 ldaps slapd[3589] conn=2407 op=0 EXT oid=1.3.6.1.4.1.1466.20037 
2011-06-19T11:40:01+04:00 ldaps slapd[3589] conn=2407 op=0 STARTTLS 
2011-06-19T11:40:01+04:00 ldaps slapd[3589] conn=2407 op=0 RESULT oid= err=0 text= 
2011-06-19T11:40:01+04:00 ldaps slapd[3589] conn=2407 fd=29 closed (TLS negotiation failure) 
2011-06-19T11:40:02+04:00 ldaps slapd[3589] conn=2405 op=2 UNBIND 
2011-06-19T11:40:02+04:00 ldaps slapd[3589] conn=2405 fd=24 closed 
2011-06-19T11:40:02+04:00 ldaps slapd[3589] conn=2406 fd=26 closed (connection lost)

HolyBoy
() автор топика
Ответ на: комментарий от HolyBoy

…меняются сертификатами…

…и, снова, примерно в том же месте…

Следует читать как «после завершения обмена сертификатами, когда начинают, кажется, о шифровании договариваться, снова, на том же месте…»

Вот потому я и грешу на gnutls.

HolyBoy
() автор топика
Ответ на: комментарий от Deleted

Да я и тут могу, после удаления циферок они вполне умещаются в пост.

CA:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ff:0d:16:84:27:bd:2c:dd
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=RU, ST=Moscow region, L=Moscow, O=somebody Ltd., OU=IT, CN=somebody CA/emailAddress=postmaster@somebody.ru
        Validity
            Not Before: Jun  7 06:22:12 2011 GMT
            Not After : Jun  4 06:22:12 2021 GMT
        Subject: C=RU, ST=Moscow region, L=Moscow, O=somebody Ltd., OU=IT, CN=somebody CA/emailAddress=postmaster@somebody.ru
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:…
		…
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                58:57:8F:8E:ED:0B:A8:D1:C2:53:45:26:28:B3:71:88:96:C7:15:4F
            X509v3 Authority Key Identifier: 
                keyid:58:57:8F:8E:ED:0B:A8:D1:C2:53:45:26:28:B3:71:88:96:C7:15:4F
                DirName:/C=RU/ST=Moscow region/L=Moscow/O=somebody Ltd./OU=IT/CN=somebody CA/emailAddress=postmaster@somebody.ru
                serial:FF:0D:16:84:27:BD:2C:DD

            X509v3 Basic Constraints: critical
                CA:TRUE
            Netscape Cert Type: 
                SSL CA, S/MIME CA
            X509v3 Issuer Alternative Name: 
                <EMPTY>

            Netscape Comment: 
                TinyCA Generated Certificate
            X509v3 Subject Alternative Name: 
                email:postmaster@somebody.ru
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
    Signature Algorithm: sha1WithRSAEncryption…

Серверный, используемый на ldaps.test.local:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=RU, ST=Moscow region, L=Moscow, O=somebody Ltd., OU=IT, CN=somebody CA/emailAddress=postmaster@somebody.ru
        Validity
            Not Before: Jun  7 06:25:00 2011 GMT
            Not After : Jun  6 06:25:00 2012 GMT
        Subject: C=RU, ST=Moscow region, L=Moscow, O=somebody Ltd., OU=IT, CN=ldaps.test.local
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:…
		…
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Cert Type: 
                SSL Server
            Netscape Comment: 
                TinyCA Generated Certificate
            X509v3 Subject Key Identifier: 
                10:A2:CC:91:56:E6:DB:C9:F5:C7:93:91:E6:BE:A1:F4:9E:42:77:27
            X509v3 Authority Key Identifier: 
                keyid:58:57:8F:8E:ED:0B:A8:D1:C2:53:45:26:28:B3:71:88:96:C7:15:4F
                DirName:/C=RU/ST=Moscow region/L=Moscow/O=somebody Ltd./OU=IT/CN=somebody CA/emailAddress=postmaster@somebody.ru
                serial:FF:0D:16:84:27:BD:2C:DD

            X509v3 Issuer Alternative Name: 
                email:postmaster@somebody.ru
            X509v3 Subject Alternative Name: 
                <EMPTY>

    Signature Algorithm: sha1WithRSAEncryption…

Ну и клиентский, который используется для подключения к серверу openldap с сервера с samba:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 7 (0x7)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=RU, ST=Moscow region, L=Moscow, O=somebody Ltd., OU=IT, CN=somebody CA/emailAddress=postmaster@somebody.ru
        Validity
            Not Before: Jun 15 14:37:25 2011 GMT
            Not After : Jun 14 14:37:25 2012 GMT
        Subject: C=RU, ST=Moscow region, L=Moscow, O=somebody Ltd., OU=IT, CN=sampdc-cl.test.local
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:…
		…
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Cert Type: 
                SSL Client, S/MIME, Object Signing
            Netscape Comment: 
                TinyCA Generated Certificate
            X509v3 Subject Key Identifier: 
                83:E0:2D:E2:FB:94:A2:FA:4A:6A:15:05:F1:04:F2:79:5B:92:EC:99
            X509v3 Authority Key Identifier: 
                keyid:58:57:8F:8E:ED:0B:A8:D1:C2:53:45:26:28:B3:71:88:96:C7:15:4F
                DirName:/C=RU/ST=Moscow region/L=Moscow/O=somebody Ltd./OU=IT/CN=somebody CA/emailAddress=postmaster@somebody.ru
                serial:FF:0D:16:84:27:BD:2C:DD

            X509v3 Issuer Alternative Name: 
                email:postmaster@somebody.ru
            X509v3 Subject Alternative Name: 
                <EMPTY>

            X509v3 Key Usage: 
                Digital Signature, Key Encipherment
    Signature Algorithm: sha1WithRSAEncryption…

Поскольку, в клиентском CN не обязан совпадать с именем хоста, то тут тоже всё ок, что и показали те же nss_ldap и rsyslog.

HolyBoy
() автор топика
Ответ на: комментарий от HolyBoy

Клиентский используется на sampdc.test.local.

HolyBoy
() автор топика
Ответ на: комментарий от HolyBoy

Зря грешил.

Проблема, оказывается, что ldapsearch и, вообще, клиентская часть openldap чихает и плюёт на значения TLS_CERT и TLS_KEY в /etc/openldap/ldap.conf, но только на них.

Обнаружил так: поставил на домашнем компьютере openldap без gnutls, всё настроил как положено, сгенерировал сертификаты, задал жёсткие проверки. Сделал запрос и получил такое:

# ldapsearch -H ldaps://homepc -b 'dc=ph,dc=local' -xLL  -v -d 1
ldap_url_parse_ext(ldaps://homepc)
ldap_initialize( ldaps://homepc:636/??base )
ldap_create
ldap_url_parse_ext(ldaps://homepc:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP homepc:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.10.2:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 1, err: 0, subject: /C=RU/ST=Moscow/L=Moscow/O=Home/OU=IT/CN=Home/emailAddress=mail@home.local, issuer: /C=RU/ST=Moscow/L=Moscow/O=Home/OU=IT/CN=Home/emailAddress=mail@home.local
TLS certificate verification: depth: 0, err: 0, subject: /C=RU/ST=Moscow/L=Moscow/O=Home/OU=IT/CN=homepc, issuer: /C=RU/ST=Moscow/L=Moscow/O=Home/OU=IT/CN=Home/emailAddress=mail@home.local
TLS trace: SSL_connect:SSLv3 read server certificate A
TLS trace: SSL_connect:SSLv3 read server certificate request A
TLS trace: SSL_connect:SSLv3 read server done A
TLS trace: SSL_connect:SSLv3 write client certificate A
TLS trace: SSL_connect:SSLv3 write client key exchange A
TLS trace: SSL_connect:SSLv3 write change cipher spec A
TLS trace: SSL_connect:SSLv3 write finished A
TLS trace: SSL_connect:SSLv3 flush data
TLS trace: SSL3 alert read:fatal:handshake failure
TLS trace: SSL_connect:failed in SSLv3 read server session ticket A
TLS: can't connect: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Поскольку, выхлоп отличался большей детальностью, порылся по интернетам, нашёл, в числе прочего, и вот это: Openldap tls

Проверил у себя, переместив вышеуказанные две опции в /root/.ldaprc. Заработало!

Залез на сервер с samba. Сделал аналогичные настройки, использовал только клиентский сертификат и… заработало! Заработал ldapsearch и samba. Т.о., нынче на samba-хосте /etc/openldap/ldap.conf:

BASE    dc=test,dc=local
URI     ldaps://ldaps.test.local ldaps://ldapm.test.local
DEREF           never
TLS_CACERT /etc/ssl/test-cacert.pem
TLS_REQCERT hard
, а /root/.ldaprc:
TLS_CERT /etc/ssl/rsyslog/sampdc-cl.test.local-cert.pem
TLS_KEY /etc/ssl/rsyslog/sampdc-cl.test.local-key.pem

Вот интересно, почему оно так? Вроде, в мануале написано, что .ldaprc в домашнем каталоге пользователя используется для задания значений, отличных от тех, что в основном ldap.conf лежат. Это логично и нормально. Но в чём проблема с TLS_CERT и TLS_KEY в ldap.conf? Странно.

HolyBoy
() автор топика
Ответ на: комментарий от HolyBoy

Но в чём проблема с TLS_CERT и TLS_KEY в ldap.conf? Странно.

OH SHI~! Что-то я тоже тормознул. Читаем man ldap.conf:

       Some  options are user-only.  Such options are ignored if present in the ldap.conf (or file speci‐
       fied by LDAPCONF).

       Thus the following files and variables are read, in order:
           variable     $LDAPNOINIT, and if that is not set:
           system file  /etc/openldap/ldap.conf,
           user files   $HOME/ldaprc,  $HOME/.ldaprc,  ./ldaprc,
           system file  $LDAPCONF,
           user files   $HOME/$LDAPRC, $HOME/.$LDAPRC, ./$LDAPRC,
           variables    $LDAP<uppercase option name>.
       Settings late in the list override earlier ones.

...

       TLS_CERT <filename>
              Specifies  the  file  that  contains  the  client  certificate.  This is a user-only <<<<<<<<<<<<<<<<
              option.

              When using Mozilla NSS, if using a cert/key database (specified with TLS_CACERTDIR),
              TLS_CERT specifies the name of the certificate to use:
                   TLS_CERT Certificate for Sam Carter
              If  using  a  token  other  than the internal built in token, specify the token name
              first, followed by a colon:
                   TLS_CERT my hardware device:Certificate for Sam Carter
              Use certutil -L to list the certificates by name:
                   certutil -d /path/to/certdbdir -L

       TLS_KEY <filename>
              Specifies the file that contains the private key that matches the certificate stored
              in  the TLS_CERT file. Currently, the private key must not be protected with a pass‐
              word, so it is of critical importance that the  key  file  is  protected  carefully.
              This is a user-only option. <<<<<<<<<<<<<<<<

              When using Mozilla NSS, TLS_KEY specifies the name of a file that contains the pass‐
              word for the key for the certificate specified with TLS_CERT.  The  modutil  command
              can be used to turn off password protection for the cert/key database.  For example,
              if TLS_CACERTDIR specifes /home/scarter/.moznss as  the  location  of  the  cert/key
              database, use modutil to change the password to the empty string:
                   modutil -dbdir ~/.moznss -changepw 'NSS Certificate DB'
              You  must  have  the  old  password,  if  any.  Ignore the WARNING about the running
              browser.  Press 'Enter' for the new password.

...
=)

Deleted
()
Ответ на: комментарий от HolyBoy

Проверил tcpdump'ом, шифрование идёт.

Для уверенности лучше вообще запретить нешифрованные соединения. Я выше написал как.

Deleted
()
Ответ на: комментарий от Deleted

OH SHI~! Что-то я тоже тормознул.

Блин, а!

Действительно, надо отдыхать чаще! :)

HolyBoy
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.