PERGUNTA ORIGINAL:
Eu quero definir a senha para o administrador backend para que eu possa alterar a ACL LDAP para o que eu preciso ... escusado será dizer que eu não quero minha configuração postada em todo o lugar, mais os arquivos .ldif são corrigir. Eu simplesmente não consigo me conectar ao servidor ldapi:/// . (apenas ...)
Até a última atualização do meu script de compilação LDAP foi bom (excluindo um pouco de mexer), com esta versão do openLDAP eu vi alguns problemas nos relatórios de bugs e aqui, mas nenhum aborda isso (e eu posso encontre um trabalho ...).
Estou executando o mais recente Ubuntu MATE. O firewall está desativado. Tentou acessar o servidor assim:
ldapi://localhost:389
ldapi:///
ldapi:///:389
ldapi://:389'
tried 'ldapadd ...
Aqui está a chamada para o DB e a mensagem de erro quando o servidor é ldapi://localhost:389 :
sudo ldapmodify -Y EXTERNAL -H ldapi://localhost:389 -f ./mcUser/management/LDAP/LDIFs/RPW.ldif
MODIFICATION attempt of ROOTPWD: ./mcUser/management/LDAP/LDIFs/RPW.ldif
stdout:
stderr:
ldap_url_parse_ext(ldapi://localhost:389)
ldap_initialize( ldapi://localhost:389/??base )
ldap_create
ldap_url_parse_ext(ldapi://localhost:389/??base)
ldap_sasl_interactive_bind: user selected: EXTERNAL
ldap_int_sasl_bind: EXTERNAL
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_path
ldap_new_socket: 5
ldap_connect_to_path: Trying localhost:389
ldap_connect_timeout: fd: 5 tm: -1 async: 0
ldap_ndelay_on: 5
ldap_close_socket: 5
ldap_msgfree
ldap_err2string
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
e para o servidor referenciado como ldapi:/// :
sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f ./mcUser/management/LDAP/LDIFs/RPW.ldif
MODIFICATION attempt of ROOTPWD: ./mcUser/management/LDAP/LDIFs/RPW.ldif
stdout:
stderr:
ldap_url_parse_ext(ldapi:///)
ldap_initialize( ldapi:///??base )
ldap_create
ldap_url_parse_ext(ldapi:///??base)
ldap_sasl_interactive_bind: user selected: EXTERNAL
ldap_int_sasl_bind: EXTERNAL
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_path
ldap_new_socket: 5
ldap_connect_to_path: Trying /var/run/slapd/ldapi
ldap_connect_timeout: fd: 5 tm: -1 async: 0
ldap_ndelay_on: 5
ldap_ndelay_off: 5
ldap_int_sasl_open: host=birraleef
SASL/EXTERNAL authentication started
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 26 bytes to sd 5
ldap_msgfree
ldap_result ld 0x7f2d73ca8b40 msgid 1
wait4msg ld 0x7f2d73ca8b40 msgid 1 (infinite timeout)
wait4msg continue ld 0x7f2d73ca8b40 msgid 1 all 1
** ld 0x7f2d73ca8b40 Connections:
* host: (null) port: 0 (default)
refcnt: 2 status: Connected
last used: Fri Jul 3 15:01:53 2015
** ld 0x7f2d73ca8b40 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x7f2d73ca8b40 request count 1 (abandoned 0)
** ld 0x7f2d73ca8b40 Response Queue:
Empty
ld 0x7f2d73ca8b40 response count 0
ldap_chkResponseList ld 0x7f2d73ca8b40 msgid 1 all 1
ldap_chkResponseList returns ld 0x7f2d73ca8b40 NULL
ldap_int_select
read1msg: ld 0x7f2d73ca8b40 msgid 1 all 1
ber_get_next
ldap_err2string
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
ldap_free_request (origid 1, msgid 1)
ldap_free_connection 1 1
ldap_free_connection: actually freed
Eu tenho depurado isso por um tempo, então meu script cospe praticamente tudo. Todas as outras modificações do banco de dados funcionam bem, o DIT, acréscimos de outros administradores, acréscimos de grupos e membros. É apenas a conexão ao serviço ldapi: /// (que é em / etc / default / slapd). Eu tenho apenas ldap-util e slapd instalado.
(além: quando isso funciona (de novo) eu tenho uma biblioteca LDAP bem legal em python ... embora seja um pouco simples)
EDITAR:
Utrecht está correta, a porta 389 está no estado LISTEN:
ss -nat |grep 389
LISTEN 0 128 *:389 :
LISTEN 0 128 :::389 :::*
Estou executando o comando na caixa que o servidor LDAP está executando.
Não tenho certeza mais porque estou executando o comando como sudo ... o comportamento sem é idêntico. Lembro-me de colocá-lo lá como uma tentativa de ver se o comportamento mudou, já que o / etc / ldap / ... dir (de propriedade root) está sendo gravado, neste caso, sem uma autenticação LDAP real para fornecer acesso e apenas deixou lá como não houve mudança de comportamento.
EDIT 2:
ss -lp | grep slapd
u_str LISTEN 0 128 /var/run/slapd/ldapi 20860 * 0
e
sudo netstat -lxp | grep slapd
unix 2 [ ACC ] STREAM LISTENING 20860 - /var/run/slapd/ldapi
Eu imagino que a intenção do 84104 é que eu substitua ldapi:/// por /var/run/slapd/ldapi , então eu fiz isso e:
ldapmodify -Y EXTERNAL -H /var/run/slapd/ldapi
Could not parse LDAP URI(s)=/var/run/slapd/ldapi (3)
e
ldapmodify -Y EXTERNAL -H ldapi:/var/run/slapd/ldapi
Could not parse LDAP URI(s)=ldapi:/var/run/slapd/ldapi (3)
e (teste de sanidade):
ldapmodify -Y EXTERNAL -H ldapi:///var/run/slapd/ldapi
DNS SRV: Could not turn DN="var/run/slapd/ldapi" into a domain
então, não há dados lá. Eu imagino que o slapd analisa o ldapi: /// no caminho correto do arquivo, para permanecer consistente em como você chama o banco de dados, já que o ldap é comumente usado como um sistema de autenticação remoto.
/ var / run / slapd / ldapi existe, mas não consigo ver o que está dentro dele e:
sudo find / -name ldapi
/run/ldapi
/run/slapd/ldapi
ls -ao /var/run/slapd
srwxrwxrwx 1 root 0 Jul 13 10:38 ldapi
-rw-r--r-- 1 openldap 84 Jul 13 10:38 slapd.args
-rw-r--r-- 1 openldap 5 Jul 13 10:38 slapd.pid
cat /var/run/slapd/slapd.args
/usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d
cat /var/run/slapd/slapd.pid
1340
PERGUNTA ACTUALIZADA:
Eu consegui inserir olcRootPW e olcRootDN em olcDatabase {0} config, cn = config scope usando:
'ldapmodify -Y EXTERNAL -H ldapi:/// -f ./mcUser/management/LDAP/LDIFs/RPW.ldif'
e coloque a ACL necessária nesse escopo do banco de dados dividindo o ACL.ldif em ACL_add.ldif e ACL_del.ldif.
ldapmodify -b <config_admin> -w <admin_pwd> -f ./mcUser/management/LDAP/LDIFs/ACL_<add/del>.ldif
No entanto, as linhas olcAccess originais permanecem no olcDatabase {1} hdb.ldif e nenhuma combinação de senha ou dn concede as permissões necessárias para removê-las.
A questão tornou-se: Qual escopo de administração eu preciso usar para remover as linhas olcAccess no olcDatabase {1} hdb?
A combinação olcRootDN / PW no olcDatabase {0} config.ldif lança (53) o que basicamente significa que o DN / PW está fora do escopo, e a combinação olcRootDN / PW no olcDatabase {1} hdb.ldif gera (49 ) que é 'não correcto nível de acesso' ou 'incorrect pwd / dn combination' (o que não é).
O arquivo ACL_del.ldif é aplicado antes do ACL_add.ldif