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

Пытаюсь запустить аутентификацию клиента через LDAP посредством SASLMechanismus EXTERNAL.
Для этого установил сервера с дистибутивами Debian 'Etch', Ubuntu 8.04 и Ubuntu 8.10-beta
Подробности систем ниже в "исходных данных".

Проблема: при запросе поддерживаемых механизмов аутентификации командой

ldapsearch -x -H ldaps:/// -b "" -s base supportedSASLMechanisms -d 1

на Debian Etch выходит список:

supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: EXTERNAL

а на обеих версиях Ubuntu то же самое, но без supportedSASLMechanisms: EXTERNAL.
Без опции "-x" соответственно у Debian проходит успешно аутентификация:

SASL/EXTERNAL authentication started
SASL username: CN=tux,O=Organisation,L=City,ST=Germany,C=DE
SASL SSF: 0

...а под Ubuntu естесственно с ошибкой, что
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)

Раз нет поддержки EXTERNAL, то понятно, что дальше работать не будет.

Тогда стал сравнивать логи работающей Etch и неработающей Ubuntu (в дальнейшем остановился на дистрибутиве 8.10, поскольку проблема где-то общая).
Нашёл следующие различия, на которые не могу найти объяснения:

Вывод команды через TLS (порт 389)
ldapsearch -H ldap:/// -ZZ -d1
или то же самое непосредственно через SSL по порту 636
ldapsearch -H ldaps:/// -d1
на Ubuntu показывает:
...
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_int_sasl_open: host=intrepid.sbs.intese
...

То же самое на Etch между такими же двумя строчками включает целую кучу записей с TLS trace:

...
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
...
ldap_int_sasl_open: host=etch.sbs.intese
...

Далее, на Ubuntu /var/log/debug показывает:
Oct 17 19:43:40 intrepid slapd[4069]: connection_read(17): unable to get TLS client DN, error=-4 id=0
Oct 17 19:43:40 intrepid slapd[4069]: conn=0 fd=17 TLS established tls_ssf=128 ssf=128
Обратите внимание на error=-4: при проблемах с сертификатом сервера, sldap вообще не запускается, а при неверном CN клиентского сертификата такая ошибка возникает обычно под номером 49, но не -4!
Если проверить подключение командой
openssl s_client -connect localhost:636 -showcerts -CAfile /etc/ssl/certs/ca.crt -cert /home/tux/.mycerts/client.crt -key /home/tux/.mycerts/private/client.pem
то возвращается:
...
Verify return code: 0 (ok)

но при этом в логе пишется:
Oct 17 20:29:26 intrepid slapd[4069]: connection_read(18): unable to get TLS client DN, error=-4 id=1
Oct 17 20:29:26 intrepid slapd[4069]: conn=1 fd=18 TLS established tls_ssf=256 ssf=256

Непонятно также, почему в первом случае tls_ssf=128, а во втором tls_ssf=256.

Подскажите, пожалуйста, кто с этим сталкивался, где не стыкуется. Все аналогичные проблемы, которые нашёл в сети, находятся где-то в сообщениях TLS trace. А у меня сами эти сообщения начисто отсутствуют в обеих версиях Ubuntu.

---
Исходные данные: На сервере установлен XEN-хост на базе Ubuntu 8.04 LTS. Gast-системы: Debian "Etch" с OpenLDAP-сервером из пакета (slapd 2.3.30), Ubuntu 8.04 со slapd версии 2.4.9 и бета-версия Ubuntu 8.10 со slapd версии 2.4.11.
Все сервера сконфигурированы почти одинаково, за исключением того, что 2.3.30 работает на bdb, а остальные на hdb.
Сертификаты для серверов и клиентов/пользователей (включая self-signed CA) генерировались для чистоты эксперимента на машине системного администратора. Настройки libnss-ldap у Debian находятся в файле /etc/libnss-ldap.conf, а у обеих Ubuntu-дистрибутивов соответственно в /etc/ldap.conf. Но опции одни и те же.

На всех машинах:
~/.ldaprc:
TLS_CACERT /etc/ssl/certs/ca.crt
TLS_CERT /home/aha/.mycerts/client.crt
TLS_KEY /home/aha/.mycerts/private/client.key
TLS_REQCERT demand
SASL_MECH EXTERNAL

/etc/ldap/ldap.conf:
base    dc=sbs,dc=intese
uri     ldap:///
tls_cacert      /etc/ssl/certs/ca.crt
tls_reqcert     demand

На Etch
/etc/libnss-ldap.conf:
base dc=sbs,dc=intese
uri ldap:///
ldap_version 3
rootbinddn cn=admin,dc=sbs,dc=intese
ssl start_tls
tls_cacertfile /etc/ssl/certs/ca.crt

/etc/ldap/slapd.conf
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args
loglevel        261
modulepath      /usr/lib/ldap
moduleload      back_bdb
sizelimit 500
tool-threads 1
backend         bdb
checkpoint 512 30
database        bdb
suffix          "dc=sbs,dc=intese"
TLSCACertificateFile /etc/ssl/certs/ca.crt
TLSCertificateFile /etc/ssl/certs/server.crt
TLSCertificateKeyFile /etc/ssl/private/server.key
TLSVerifyClient demand
directory       "/var/lib/ldap"
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
index           objectClass eq
lastmod         on
access to attrs=userPassword,shadowLastChange
        by dn="cn=admin,dc=sbs,dc=intese" write
        by anonymous auth
        by self write
        by * none
access to dn.base="" by * read
access to *
        by dn="cn=admin,dc=sbs,dc=intese" write
        by * read

На Ubuntu 8.10

/etc/ldap.conf
base dc=sbs,dc=intese
uri ldap:///
ldap_version 3
ssl start_tls
tls_cacertfile /etc/ssl/certs/ca.crt

Сервер сконфигурирован динамически через cn=config, параметры и пути к сертификатам те же, что у Etch в /etc/ldap/slapd.conf