OpenLDAP – Troubleshooting OpenLDAP Replication Problem

ldapopenldap

I have a LDAP master server installed on CentOS-5.4 and I have installed LDAP on one more machine and I want it be configured as LDAP slave server but when I am importing the LDIF file or trying to create any new object in slave LDAP getting the below errors:

LDIF text import Could not add object
dc=transcomus,dc=com LDAP said: Server
is unwilling to perform Error
number: 0x35
(LDAP_UNWILLING_TO_PERFORM)
Description: The LDAP server refused
to perform the operation.

There is no permission issue already checked that on /var/lib/ldap

Any help much appreciate..

Thanks
Ramesh

Best Answer

It sounds to me like you're attempting to import a database dump into a running slave, either by means of ldapadd or slapcat. A running slapd instance with a replication mechanism configured in slave mode will reject all write attempts and return the message you provided.

If my slurpd based slapd servers ever became inconsistent I executed a fairly straight forward recovery procedure:

Put the master into read-only mode.
Make a fresh dump from the master and copy it to any inconsistent slaves (or copy from backups).
Completely stop slapd on the slave you want to recover.
Clear the contents of the data directory, /var/lib/ldap (you might want to save your DB_CONFIG file if the parameters aren't defined in slapd.conf)
Use slapadd to rebuild the directory on the slave (move DB_CONFIG back if necessary)
Start the slave normally.
Switch the master back into read-write mode.

yes, I am using slurpd replication method. It was running fine but somehow it broke down and till then its not working

You're probably running OpenLDAP 2.3.43 since that's what's packaged in CentOS 5.4. Unfortunately because of that you're also likely to run into replication issues again in the future unless you can upgrade to a newer OpenLDAP (2.4) server.

slurpd was very flawed, check out the OpenLDAP 2.4 docs for a complete explanation of why. The newer OpenLDAP releases come with a new replication mechanism called syncrepl which is much more robust and nearly impervious to failure.

In the future if you're interested in getting help migrating to a newer OpenLDAP server I can offer guidance there as well.

Related Solutions

Windows – Setting up LDAP connection between CentOS and Windows server 2008

The error message is fairly straightforward:

text: 000004DC: LdapErr: DSID-0C0906DC, comment: In order to perform this 
operation a successful bind must be completed on the connection., data 0

That means you need to authenticate before you can query the directory. A typical command line will look something like this:

ldapsearch -x -H ldaps://dc.example.com/ -D lars@example.com -W cn=lars

This connect using simple authentication (-x) to dc.example.com using LDAP over SSL (ldaps://). I am authenticating as lars@example.com and the command will prompt me for a password (-W). I am searching for records matching cn=lars.

You can also authenticate against AD using Kerberos. Assuming everything is set up correctly, that looks like:

$ kinit lars@example.com
Password for lars@EXAMPLE>COM: 
$ ldapsearch -H ldap://dc.example.com cn=lars

In either case, you generally want to create accounts specifically to act as bind credentials, rather than using an administrative or a user account.

It is possible to configure Active Directory to allow anonymous binds. It is also possible to set up something else -- e.g., OpenLDAP -- as an anonymous bind proxy for AD.

Openldap startup problems after upgrade

LDAP replication under syncrepl is quite robust. The servers don't have to be the same version, they just need to understand each other. (Proper multi-master requires 2.4.X, but that's not what you're asking about as far as I can tell.)

"The consumer replica can be constructed from a consumer-side or a provider-side backup at any synchronization status." Most notably in this case, is that syncrepl can create a proper replica on a server which has never been synced before by any method.

What do to:

stop the replica's slapd
remove the contents of /var/lib/ldap (except DB_CONFIG)
make sure your syncrepl or olcsyncrepl directive is correct
start the replica's slapd
wait for the replica to sync

Note: Use of certain overlays (e.g. memberof) will cause you to lose (override) the operational attributes creatorsName and createTimestamp on the replica, but otherwise everything will be the same.

Best Answer

Related Solutions

Windows – Setting up LDAP connection between CentOS and Windows server 2008

Openldap startup problems after upgrade

Related Topic