Hi all, I am new to ldap and now having problem in changing admin password.

I saw few sites suggested to use slappasswd to change admin password. I did that and change the rootpw value on my slapd.conf on my ldap server. After restarted the slapd service, the client machine that used to connect to the ldap server having problem in connecting to the ldap service and it causes the ldap user not able to log in to the system. I found a file named ldap.secret in the client machine with a clear text words residing in it.

Now my question is
1. What is ldap.secret file function in client machine? Is it associated with the ldap server rootpw?
2. If i change rootpw in ldap server, do i need to change any other values in my client ldap.conf?

Thanks in advance.

your rootpw value should NEVER EVER be used outside of the server. that account is for management of the underlying server, not an account to ever be used to use the ldap service it provides. create system accounts for user binds etc, and never ever use that password for anything like that.

the ldap.secret file is generally a credentials file that can be used in lieu of putting passwords into scripts or configuration files which are world readable. so a script might be able to be read by anyone, but the password file can only be read by root or similar, so the password is much more secure.

Thanks. Anyway, my client machine fail to connect to the ldap server after i change the rootpw value and restart slapd service. The ldap user could not log in either. What would be the possible reason causing this?

no idea what your client and server configs are, so can't really comment. Clearly if you are binding with that admin account and the password has changed, that's pretty obvious.

Thanks Chris.

Below is my slapd.conf in my server and ldap.conf of my client.

slapd.conf

include /opt/etc/openldap/schema/core.schema
include /opt/etc/openldap/schema/cosine.schema
include /opt/etc/openldap/schema/inetorgperson.schema
include /opt/etc/openldap/schema/nis.schema
include /opt/etc/openldap/schema/ppolicy.schema
include /opt/etc/openldap/schema/samba.schema
include /opt/etc/openldap/schema/apple_auxillary.schema
include /opt/etc/openldap/schema/apple.schema

pidfile /opt/var/run/slapd.pid
argsfile /opt/var/run/slapd.args

database bdb
suffix "dc=local"
rootdn "cn=admin,dc=local"

rootpw {SSHA}sha1-string
directory /opt/var/openldap-data

index objectClass eq

access to attrs=userPassword,loginShell,homeDirectory,cn,givenName,sn,mail,gecos
by self write
by anonymous read
by * none

TLSCACertificateFile /opt/etc/openldap/ssl/sc.pem
TLSCertificateFile /opt/etc/openldap/ssl/sc.pem
TLSCertificateKeyFile /opt/etc/openldap/ssl/sc.key

TLSVerifyClient allow

---------------------------------------------------------------------------------------------------------------------------
ldap.conf

base dc=local

uri ldap://fw1:389

ldap_version 3

rootbinddn cn=admin,dc=local

pam_password md5

nss_initgroups_ignoreusers avahi,avahi-autoipd,backup,bin,couchdb,daemon,dhcpd,eucalyptus,games,gdm,gnats,haldaemon,hplip,irc,jetty,kernoop s,landscape,libuuid,libvirt-qemu,list,lp,mail,man,messagebus,mysql,news,oneadmin,openldap,postfix,proxy,pulse,root,rtkit,saned,s geadmin,smmsp,smmta,speech-dispatcher,sshd,statd,sync,sys,syslog,usbmux,uucp,www-data

-------------------------------------------------------------------------------------------------------------

Could you help me to point out how the client and server machine are bind in terms of their rootpw? Thanks.

what am I supposed to say? I must be missing something... you're binding with the admin account. you changed the password to the admin account...???

please understand how dangerous / dumb it is to be using THAT account over ANY other account to do this bind. It's just mental. you'd be more secure by allowing anonymous read only binds to the relevant OUs and filtering the available attributes to the posix essential ones only. As well as being more secure (at all secure) your original issue dissapears into thin air instantly.

Hi Chris, I have changed my ACL in server side to the following.

access to attrs=userPassword
by dn="cn=ldap,dc=local" write
by self write
by * auth

access to attrs=loginShell,homeDirectory,cn,givenName,sn,mail,gecos
by dn="cn=ldap,dc=local" write
by self write
by anonymous read
by * auth

I have created another account called ldap and do the binding from client by using binddn and bindpw directive and commented out rootbinddn directive.

binddn cn=ldap,dc=local
bindpw xxxxxx

After i done that, my ldap user can't logged in to the system anymore. I know it might be a dumb question but please help since i m so new in ldap as the previous setup is done by someone who has left the company. Thanks.

@xintzi: Please use code tags.

It's hard to troubleshoot problems like this without proper logging in place. For slapd.conf(5), something like the following would do:

You may also need to add a syslog.conf(5) entry for the local4 facility. (And touch(1) an appropriate log file.)

And I'll agree: do not use the rootdn for your day to day activities / services. That's what service accounts are for.

(Not to mention, you are doing so clear text over the wire. Non-routable network or not, it's an unnecessary risk.)

@anomie, could you show me a sample of using non rootdn on both client and server? I tried several ways but it does not seems working. Thanks.

I don't see an obvious problem with your slapd configuration / ACLs in post #7. What I would suggest (for a service account) would look similar to that.

Please turn on logging so that we can make sense out of what's happening.

@anomie, i have enable the logging and here's the log when i do the binding

Apr 18 12:37:57 fw1 slapd[3200]: conn=6 fd=15 ACCEPT from IP=172.20.20.106:55457 (IP=0.0.0.0:389)
Apr 18 12:37:57 fw1 slapd[3200]: conn=6 op=0 BIND dn="cn=ldap,dc=local" method=128
Apr 18 12:37:57 fw1 slapd[3200]: conn=6 op=0 RESULT tag=97 err=49 text=
Apr 18 12:37:57 fw1 slapd[3200]: conn=6 op=1 UNBIND
Apr 18 12:37:57 fw1 slapd[3200]: conn=6 fd=15 closed

"err=49" is invalid credentials. wrong password 99% of the time.

Are you getting accounts back from a "getent passwd"?

No. I cant see the user accounts. But I tested the account with the password and the password is correct. Is there any other possible field for wrong credentials?

There are a couple of subtle issues that can cause it, but things like locked out accounts you'd get an err=19 instead, which is "Constraint Violation". I think I've seen it when there is NO password attribute on the account, not sure what else. can you ldapsearch the data instead? post the command that works with a search, and there might be something you're not mapping across into the config files.