I did exactly the same until I had my head wrapped around all the details of openldap. I then converted everything to the cn=config method quite easily after that.
Anyway, if you provide the details mentioned before, we should be able to figure out where the problem is coming in.
What I'm *really* trying to do is get Samba working again. There's a long-ish story, involving me backing up an old server and trying to get services running again on a new server, without having backed up Samba and its backend password database the "proper" way. The Samba passdb is ldap.
Samba is throwing ldap-related errors, so the focus at the moment is to satisfy myself that ldap is working before I turn my attention again to Samba.
It is significant to note that both Samba and ldap are running on the same box; there is no reference to any service running on any other computer.
For some reason, slapd will not start properly from init.d; I suspect a permissions problem on /var/lib/ldap or something.
Here's the syslog snippet for that failed start:
########### # syslog start # ###########
Feb 21 07:47:03 drbgate slapd[1242]: @(#) $OpenLDAP: slapd (Jan 16 2016 23:00:08) $#012#011root@chimera:/tmp/buildd/openldap-2.4.40+dfsg/debian/build/servers/slapd Feb 21 07:47:03 drbgate slapd[1242]: daemon: bind(11) failed errno=2 (No such file or directory) Feb 21 07:47:03 drbgate slapd[1242]: slapd stopped. Feb 21 07:47:03 drbgate slapd[1242]: connections_destroy: nothing to destroy. Feb 21 07:47:03 drbgate slapd[1158]: Starting OpenLDAP: slapd failed! Feb 21 07:47:03 drbgate systemd[1]: slapd.service: control process exited, code=exited status=1 Feb 21 07:47:03 drbgate systemd[1]: Unit slapd.service entered failed state.
########### # syslog end # ###########
No matter in the short term (that problem is down the priority list), I can simply start it manually with slapd -t /etc/ldap/slapd.conf; slapd starts, here's the syslog snippet:
########### # syslog start # ###########
Feb 21 07:51:27 drbgate slapd[2146]: @(#) $OpenLDAP: slapd (Jan 16 2016 23:00:08) $#012#011root@chimera:/tmp/buildd/openldap-2.4.40+dfsg/debian/build/servers/slapd Feb 21 07:51:28 drbgate slapd[2147]: slapd starting
########### # syslog end # ###########
Here's /etc/ldap/slapd.conf
####################### # OpenLDAP slapd.conf # ####################### # include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/samba.schema
pidfile /var/run/slapd.pid loglevel 256 password-hash {SMD5}
# Load dynamic backend modules: modulepath /usr/lib/ldap moduleload back_bdb.la moduleload back_ldap.la moduleload back_passwd.la moduleload back_shell.la
############################ # bdb database definitions # ############################
database bdb suffix dc=drbhome,dc=ca
rootdn "cn=admin,dc=drbhome,dc=ca" rootpw {SMD5}jucQ+foqlF7O/VLmLllThlYH5zY=
directory /var/lib/ldap
index objectClass,uidNumber,gidNumber eq index cn,sn,uid,displayName pres,sub,eq index memberUid,mail,givenname eq,subinitial index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq
############## # end slapd.conf # ##############
So, now to use ldapsearch to see if I can successfully query the database. Running slapcat shows me my Samba backend passdb info; here's one entry from the slapcat output that Samba is looking for:
#################### # slapcat output snippet # ####################
dn: sambaDomainName=DRBHOME,dc=drbhome,dc=ca structuralObjectClass: sambaDomain entryUUID: b55dd658-8373-102b-926b-934392865679 creatorsName: cn=Manager,dc=drbhome,dc=ca createTimestamp: 20070420101446Z gidNumber: 1000 sambaDomainName: DRBHOME sambaSID: S-1-5-21-379225270-2612589903-3976116126 objectClass: top objectClass: sambaDomain objectClass: sambaUnixIdPool sambaMaxPwdAge: -1 sambaRefuseMachinePwdChange: 0 sambaMinPwdAge: 0 sambaLockoutThreshold: 0 sambaMinPwdLength: 5 sambaLogonToChgPwd: 0 sambaForceLogoff: -1 sambaNextRid: 1010 uidNumber: 1017 sambaPwdHistoryLength: 0 entryCSN: 20160210051916Z#000000#00#000000 modifiersName: cn=Manager,dc=drbhome,dc=ca modifyTimestamp: 20160210051916Z
####################### # end slapcat output snippet # #######################
One obvious observation from this output is that it refers to cn=Manager and not cn=admin. Manager was the rootdn of the previous installation, whereas admin is the rootdn of the current installation. I don't know if that means anything in terms of my current problems, but I tend to doubt it. I don't get authentication errors now using cn=admin, so I'm presuming the references to Manager in the snippet above are informational only and not significant.
So, I believe this demonstrates that the entry is there to be found. I'm trying to check that ldap is working by using ldapsearch to search for the information in that slapcat snippet above. Here's the command line I'm using:
ldapsearch -D cn=admin,dc=drbhome,dc=ca -W -b "dc=drbhome,dc=ca" -s sub "(&(objectClass=sambaDomain)(sambaDomainName=DRBHOME))" sambaDomainName
I get prompted for the password, for which I enter the cleartext password that generated the hash found in my slapd.conf as shown above.
The result is:
################ # ldapsearch result # ################
# extended LDIF # # LDAPv3 # base <dc=drbhome,dc=ca> with scope subtree # filter: (&(objectClass=sambaDomain)(sambaDomainName=DRBHOME)) # requesting: sambaDomainName #
# search result search: 2 result: 32 No such object
# numResponses: 1
################### # end ldapsearch result # ###################
I take from this response ("no such object") that it could not find the entry.
Where am I going wrong?