OpenLDAP TLS Аутентификация

Я пытаюсь реализовать TLS согласно https://help.ubuntu.com/lts/serverguide/openldap-server.html Когда я пытаюсь изменить базу данных cn = config с помощью этого файла ldif:

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/test-ldap-server_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/test-ldap-server_key.pem

Я получаю следующую ошибку:

ldapmodify -Y EXTERNAL -H ldapi:/// -f certinfo.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)

Что я делаю неправильно?

РЕДАКТИРОВАТЬ: Когда я пытаюсь использовать простой аутентификации, я получил следующую ошибку:

ldapmodify -x -D cn=admin,dc=example,dc=com -W -f certinfo.ldif
Enter LDAP Password:
ldap_bind: Invalid DN syntax (34)
        additional info: invalid DN

Я следовал тому же руководству и имел ту же проблему. Это сработает, если вы сначала выполните шаги для «Подтверждения прав собственности и прав доступа», перечисленные после команды ldapmodify, а именно:

sudo adduser openldap ssl-cert
sudo chgrp ssl-cert /etc/ssl/private
sudo chgrp ssl-cert /etc/ssl/private/ldap01_slapd_key.pem
sudo chmod g+X /etc/ssl/private
sudo chmod g+r /etc/ssl/private/ldap01_slapd_key.pem

и

sudo systemctl restart slapd.service

Ну, я не знаю, если это решение или просто обходной путь, но мне удалось заставить его работать.

Сначала я остановил slapd с помощью:

service slapd stop

Затем я запустил его в режиме отладки:

slapd -h ldapi:/// -u openldap -g openldap -d 65 -F /etc/ldap/slapd.d/ -d 65

Важно запустить его ТОЛЬКО с URL-адреса ldapi: ///. После его запуска я выполнил команду ldapmodify, и атрибуты были импортированы.

В конце я остановил режим отладки и запустил slapd нормально.

В продолжение ответа А. Гутьерреса , лучший способ проверить доступ к каждому файлу - запустить sudo -u openldap cat <filename>. Я просматривал все файлы несколько раз, и они смотрели, чтобы права доступа были установлены правильно. Оказалось, что это групповая проблема для openldap. Как только я наконец понял это, простой sudo usermod -a -G ssl-cert openldapрешил это для меня.

Иногда проблема в профиле apparmor для службы slapd. Убедитесь, что в профиле apparmor разрешены пути сертификатов для демона.

Это довольно визуально в /etc/apparmor.d/usr.sbin.slapd. По умолчанию этот профиль позволяет читать сертификаты в расположениях по умолчанию.

Apparmor должен предотвращать неопределенные действия для исполняемого файла демона, несмотря на надлежащие разрешения Unix.

Как я уже сообщал в этой ошибке на Ubuntu Launchpad , эта проблема также может быть вызвана apparmor. Обычно это отображается в системном журнале как отказ в доступе.

Исправление вставляет следующую строку в /etc/apparmor.d/usr.sbin.slapd:

/etc/letsencrypt/** r,

а затем обновите профиль:

# apparmor_parser -vr usr.sbin.slapd
# service apparmor restart

У меня тоже есть эта проблема. Проблема в том, что пользователь, работающий с slapd, не имеет доступа к файлам сертификатов. Убедитесь, что владельцем этих файлов является пользователь openldap.

Для меня проблема была в неправильном порядке записей - вот тот, который работал:

dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cm_ca_cert.pem
-
# This never worked for me, no idea why
#add: olcTLSCipherSuite
#olcTLSCipherSuite: TLSv1+RSA:!NULL
#-
replace: olcTLSVerifyClient
olcTLSVerifyClient: never
-
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/cm_server.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/cm_server.key

К сожалению, это ошибка по умолчанию, которую вы получаете практически для всего. Ответчик @ wulfsdad обычно исправляет это.

Еще одна вещь, которую я всегда забываю, это то, что по умолчанию в Ubuntu slapd хочет ключ в формате openssl. Я регулярно, но PCKS # 8 вводит в него ключ и ожидаю, что он просто сработает (что будет справедливо, если так). Если вы перепробовали все вышеописанные инструменты, убедитесь, что ключ имеет правильный формат. При поиске ошибки вы обычно читаете о неправильных разрешениях и размышляете, почему apache работает с тем ключом, который не нравится slapd.