Autenticação OpenLDAP TLS

10

Estou tentando implementar o TLS conforme https://help.ubuntu.com/lts/serverguide/openldap-server.html Quando tento modificar o banco de dados cn = config com este arquivo 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

Eu obtenho o seguinte erro:

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)

O que estou fazendo errado?

Edição: Quando tento usar autenticação simples, recebi o seguinte erro:

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

openldap tls

— Amar Prasovic
fonte

Verifique as permissões nos arquivos de certificado. E também remova a senha, se estiver definida.

— Zeridon

Obrigado pela resposta rápida. As permissões são definidas para 644, exceto no arquivo .key, que está em 600 Como faço para verificar / remover a senha? Não me lembro de definir qualquer senha para cn = configuração ..

— Amar Prasovic

2

Quero dizer senha no próprio certificado (não em cn = config). Verifique: mnx.io/blog/removing-a-passphrase-from-an-ssl-key

— zeridon

Não, não foi esse o caso. O arquivo de chave foi criado sem senha.

— Amar Prasovic 10/07/2015

você pode tentar carregar o ldiff com auth simples (não-Y EXTERNO)

— zeridon

17

Eu estava seguindo o mesmo guia e tive o mesmo problema. Funcionará se você executar as etapas para "Apertar a propriedade e as permissões" listadas após o comando ldapmodify ofensivo primeiro - a saber:

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

e

sudo systemctl restart slapd.service

— Hildigerr
fonte

1

Isso funcionou para mim também!

— sonicwave

2

No meu caso, eu tive que usar chgrp openldap. Enfim, é uma questão de permissão. 1

— xonya

também o diretório privado também deve ser executável para percorrer. sudo chgrp ssl-cert /etc/ssl/private && sudo chmod g+X /etc/ssl/private

— Jeff Puckett

3

Bem, não sei se isso é uma solução ou apenas uma solução alternativa, mas consegui fazê-lo funcionar.

Parei o slapd pela primeira vez com:

service slapd stop

Então eu iniciei no modo de depuração:

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

Importante é iniciá-lo SOMENTE com ldapi: /// URL. Após o início, executei o comando ldapmodify e os atributos foram importados.

No final, parei o modo de depuração e iniciei o slapd normalmente.

— Amar Prasovic
fonte

2

Como acompanhamento da resposta de A. Gutierrez , a melhor maneira de verificar o acesso de cada arquivo é executar sudo -u openldap cat <filename>. Eu olhei para todos os arquivos várias vezes e eles pareciam ter permissões definidas corretamente. Acabou sendo um problema de grupo para o openldap. Depois que finalmente descobri isso, um simples sudo usermod -a -G ssl-cert openldapresolveu para mim.

— Rob Archibald
fonte

2

Às vezes, o problema está no perfil do apparmor para o serviço slapd. Certifique-se de que o perfil apparmor tenha permitido caminhos de certificado para o daemon.

É bastante visualmente /etc/apparmor.d/usr.sbin.slapd. Por padrão, esse perfil permite ler certificados em locais padrão.

O Apparmor deve impedir ações não especificadas para o executável do daemon, apesar das permissões unix apropriadas.

— vskubriev
fonte

Se você usar letsencrypt, esta é a solução. Adicione as seguintes linhas a /etc/apparmor.d/usr.sbin.slapd: / etc / letsencrypt / r, / etc / letsencrypt / ** r e recarregue os perfis do apparmor.

— Bernhard

1

Como relatei neste bug no Ubuntu Launchpad , esse problema também pode ser causado por apparmor. Normalmente, isso será exibido no syslog como uma negação de acesso.

A correção está inserindo a seguinte linha no /etc/apparmor.d/usr.sbin.slapd:

/etc/letsencrypt/** r,

e, em seguida, atualizando o perfil:

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

— Tarek Loubani
fonte

0

Eu também tenho este problema. O problema é que o usuário que está executando o slapd não tem acesso aos arquivos certs. Verifique se o proprietário desses arquivos é um usuário openldap.

— A. Gutierrez
fonte

0

Para mim, o problema estava na ordem errada dos registros - aqui está o que funcionou:

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

— Arie Skliarouk
fonte

0

Infelizmente, este parece ser o erro "padrão" que você recebe para praticamente qualquer coisa. A resposta do @ wulfsdad geralmente corrige isso.

Uma outra coisa que sempre esqueço é que, por padrão, no ubuntu, o slapd quer a chave no formato openssl. Eu regularmente, mas o PCKS # 8 entra nele e espero que funcione (o que deve ser justo). Se você tentou todas as respostas acima, verifique também se a chave possui o formato correto. Ao pesquisar sobre o erro, você geralmente lê sobre permissões erradas e não sabe por que o apache funciona com a mesma chave que o slapd não gosta.

— user3240383
fonte