ORIGINAL QUESTION:
I want to set the password to the backend admin so that I can change the LDAP ACL to what I need... needless to say I don't want my config posted all over the place, plus the .ldif files are correct. I just cannot connect to the ldapi:/// server. (just...)
Up till the last update my LDAP build script has been fine (excluding a bit of fiddling), with this version of openLDAP I have seen quite a few problems on the bug reports and on here but none address this (and I can't find a work around...).
I am running the latest Ubuntu MATE. Firewall is turned off. Attempted accessing the server thus:
ldapi://localhost:389
ldapi:///
ldapi:///:389
ldapi://:389`
tried `ldapadd ...
Here is the call to the DB and the error message when the server is 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)
and for the server referenced as 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
I have been debugging this for a while so my script spits pretty much everything out. All other DB modifications work fine, the DIT, additions of other admins, additions of groups and members. It is only the connection to ldapi:/// service (which is in /etc/default/slapd). I have only ldap-util and slapd installed.
(aside: when this gets working (again) I have a pretty nice LDAP library in python...although it's a little simple)
EDIT:
Utrecht is correct, port 389 is in LISTEN state:
ss -nat |grep 389
LISTEN 0 128 *:389 :
LISTEN 0 128 :::389 :::*
I am running the command on the box which the LDAP server is running.
Not actually sure any more why I am running the command as sudo... behaviour without is identical. I recall putting it in there as an attempt to see if the behaviour changed as the /etc/ldap/... dir (owned by root) is being written to, in this case, without an actual LDAP authentication occurring to provide access and just left it in there as there was no behaviour change.
EDIT 2:
ss -lp | grep slapd
u_str LISTEN 0 128 /var/run/slapd/ldapi 20860 * 0
and
sudo netstat -lxp | grep slapd
unix 2 [ ACC ] STREAM LISTENING 20860 - /var/run/slapd/ldapi
I imagine that the intent of 84104 is that I replace ldapi:/// with /var/run/slapd/ldapi so I have done that and:
ldapmodify -Y EXTERNAL -H /var/run/slapd/ldapi
Could not parse LDAP URI(s)=/var/run/slapd/ldapi (3)
and
ldapmodify -Y EXTERNAL -H ldapi:/var/run/slapd/ldapi
Could not parse LDAP URI(s)=ldapi:/var/run/slapd/ldapi (3)
and (sanity check):
ldapmodify -Y EXTERNAL -H ldapi:///var/run/slapd/ldapi
DNS SRV: Could not turn DN="var/run/slapd/ldapi" into a domain
so, no dice there. I imagine that slapd parses ldapi:/// into the correct file path, to remain consistent on how you call the DB, as ldap is commonly used as a remote auth system.
/var/run/slapd/ldapi exists but I can't see what's inside it and:
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
UPDATED QUESTION:
I have managed to insert the olcRootPW and olcRootDN into olcDatabase{0}config,cn=config scope using:
`ldapmodify -Y EXTERNAL -H ldapi:/// -f ./mcUser/management/LDAP/LDIFs/RPW.ldif`
and put the required ACL into that scope of the database by splitting the ACL.ldif into ACL_add.ldif and ACL_del.ldif.
ldapmodify -b <config_admin> -w <admin_pwd> -f ./mcUser/management/LDAP/LDIFs/ACL_<add/del>.ldif
However, the original olcAccess lines remain in olcDatabase{1}hdb.ldif and no combination of password or dn grant the requisite permissions to remove them.
The question has now become: Which admin scope do I need to use to remove the olcAccess lines in olcDatabase{1}hdb?
The olcRootDN/PW combination in olcDatabase{0}config.ldif throws (53) which basically means that the DN/PW are out of scope, and the olcRootDN/PW combo in olcDatabase{1}hdb.ldif throws (49) which is either 'not correct access level' or 'incorrect pwd/dn combination' (which it is not).
The ACL_del.ldif file is applied before the ACL_add.ldif
