Não é possível usar a autenticação EXTERNAL após ativar o TLS no ldap-2.4

Question

Eu usei o seguinte arquivo LDIF para ativar o suporte a TLS para o servidor LDAP:

dn: cn=config
changetype: modify
add: olcTLSCipherSuite
olcTLSCipherSuite: NORMAL 
-
add: olcTLSCRLCheck
olcTLSCRLCheck: none
-
add: olcTLSVerifyClient
olcTLSVerifyClient: never
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/CA.crt
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/server.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/key.pem

e forçar o uso do TLS para as conexões do cliente com o seguinte LDIF:

dn: cn=config
changetype: modify
add: olcSecurity
olcSecurity: tls=1

Depois disso, não posso mais usar o "-Y EXTERNAL" para ler ou modificar o esquema de configuração. Por exemplo, recebo um erro SASL se eu executar:

$ sudo ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b "" -LLL -s base -Z supportedSASLMechanisms
ldap_sasl_interactive_bind_s: Authentication method not supported (7)
    additional info: SASL(-4): no mechanism available: 

e se eu verificar mecanismos SASL suportados:

$ sudo ldapsearch -x -H ldapi:/// -b "" -LLL -s base -Z supportedSASLMechanisms
dn:
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: LOGIN

Eu realmente não consigo ver o EXTERNAL incluído na lista. O que estou perdendo aqui?

Isso está no Ubuntu-12.04 e no slapd-2.4.31.

    

Answer 1

Sem acesso à configuração atual, você terá que parar slapd e editar a configuração off-line.

1. pare slapd : service slapd stop
2. despeje o banco de dados de configuração em um arquivo de texto: slapcat -F /etc/ldap/slapd.d -b cn=config -l config.ldif
3. mova o banco de dados de configuração existente para fora do caminho: mv /etc/ldap/slapd.d{,.old}

4. crie uma nova base de dados de configuração vazia:

   mkdir /etc/ldap/slapd.d chown --reference=/etc/ldap/slapd.d.old /etc/ldap/slapd.d chmod --reference=/etc/ldap/slapd.d.old /etc/ldap/slapd.d

5. edite o config.ldif despejado para remover sua configuração de olcSecurity (ou adicione olcRootDN e olcRootPW a cn=config ou qualquer outra alteração que você goste)
6. carrega o LDIF editado no novo banco de dados vazio: slapadd -F /etc/ldap/slapd.d -b cn=config -l config.ldif

(O acima assume que sua configuração mora em /etc/ldap/slapd.d , que é o padrão no Debian e no Ubuntu.)

Observe que slapadd de um LDIF completo sempre deve ser feito em um banco de dados vazio; Portanto, se você cometer um erro e slapadd falhar, limpe o banco de dados parcial antes de tentar novamente.

Você pode encontrar mais informações no Guia de administração do OpenLDAP , bem como nas páginas do manual relevantes.

    

Answer 2

Olhando para o código: no lado do servidor, em servidores / slapd / daemon.c , o authid para EXTERNAL é configurado usando o uid e gid logo após a conexão de entrada ser accept() ed. Mais tarde, em servers / slapd / connection.c , se o TLS estiver ativo, ele substitui isso pelo nome do certificado do cliente. Como você não está fornecendo um certificado de cliente, neste momento o authid é substituído com NULL, tornando EXTERNAL indisponível.

Em resumo, se o TLS estiver ativo, a autenticação uid + gid não será usada. Dependendo da sua perspectiva, isso pode ser considerado um erro; idealmente, voltaria ao ID peercred.

Dito isto, o TLS no ldapi não é realmente necessário, já que o socket local já oferece total privacidade; então você pode definir olcSecurity apenas em seu próprio banco de dados, deixando não definido para o frontend e cn=config (ver por exemplo, esta postagem ) ou você pode usar ssf= em vez de tls= e definir olcLocalSSF apropriadamente. Ou você poderia usar um DN diferente como o gerenciador para cn=config , para não depender do recurso peercred.

    

Answer 3

Obrigado, muito obrigado. Eu realmente não queria colocá-lo no ldapi, mas não estava ciente do fato de que ele também será afetado.

O problema é que o EXTERNAL foi a única maneira que eu pude modificar o cn=config então já que eu perdi aquele acesso e não criei outro cn=config admin como sugerido, existe alguma outra maneira que eu possa resolver isso?