LDAP - ReplicationUser can not log in properly

Hello,
with the manager I can login without problems . The ReplicationUser I can not sign in. Does anyone know why? I enclose my slapd.conf and the error message in / var / log / messages

Thank you

slapd.conf

[CODE]#

See slapd.conf(5) for details on configuration options.

This file should NOT be world readable.

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/rfc2307bis.schema
include /etc/openldap/schema/yast.schema
include /etc/openldap/schema/YYY-attributes.schema
include /etc/openldap/schema/YYY-objects.schema

Define global ACLs to disable default read access.

Do not enable referrals until AFTER you have a working directory

service AND an understanding of referrals.

#referral ldap://root.openldap.org

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

Load dynamic backend modules:

modulepath /usr/lib/openldap/modules

moduleload back_ldap.la

moduleload back_meta.la

moduleload back_monitor.la

moduleload back_perl.la

Sample security restrictions

Require integrity protection (prevent hijacking)

Require 112-bit (3DES or better) encryption for updates

Require 63-bit encryption for simple bind

security ssf=1 update_ssf=112 simple_bind=64

Sample access control policy:

Root DSE: allow anyone to read it

Subschema (sub)entry DSE: allow anyone to read it

Other DSEs:

Allow self write access to user password

Allow anonymous users to authenticate

Allow read access to everything else

Directives needed to implement policy:

access to dn.base=""
by * read

access to dn.base=“cn=Subschema”
by * read

access to attrs=userPassword,userPKCS12
by self write
by dn.base=“cn=jndiServ Modul,ou=jndiServ,o=Administration,c=de” write
by dn.base=“cn=ReplicationUser,ou=AdminUser,o=Administration,c=de” write
by dn.base=“cn=DMSAAA Modul,ou=DMSAAA,o=Administration,c=de” read
by * auth

#access to attr=shadowLastChange

by self write

by * read

#access to *

by * read

access to dn.base=“o=Administration,c=de”
by dn.base=“cn=XXZZread,ou=AdminUser,o=Administration,c=de” read
by dn.base=“cn=XXZZwrite,ou=AdminUser,o=Administration,c=de” read
by dn.base=“cn=ReplicationUser,ou=AdminUser,o=Administration,c=de” write

access to dn.children=“o=Administration,c=de”
by dn.base=“cn=ReplicationUser,ou=AdminUser,o=Administration,c=de” write

access to dn.base=“o=FIRMA1,c=de”
by dn.base=“cn=jndiServ Modul,ou=jndiServ,o=Administration,c=de” read
by dn.base=“cn=XXZZread,ou=AdminUser,o=Administration,c=de” read
by dn.base=“cn=XXZZwrite,ou=AdminUser,o=Administration,c=de” read
by dn.base=“cn=ReplicationUser,ou=AdminUser,o=Administration,c=de” write
by dn.base=“cn=IPEMAread,ou=IPEMA,o=Administration,c=de” read
by dn.base=“cn=dkspider,ou=dkspider,o=Administration,c=de” read

access to dn.children=“ou=Person,o=FIRMA1,c=de”
by dn.base=“cn=DMSAAA Modul,ou=DMSAAA,o=Administration,c=de” read
by dn.base=“cn=jndiServ Modul,ou=jndiServ,o=Administration,c=de” write
by dn.base=“cn=XXZZread,ou=AdminUser,o=Administration,c=de” read
by dn.base=“cn=XXZZwrite,ou=AdminUser,o=Administration,c=de” write
by dn.base=“cn=ReplicationUser,ou=AdminUser,o=Administration,c=de” write
by dn.base=“cn=HHHHread,ou=HHHH,o=Administration,c=de” read
by dn.base=“cn=dkspider,ou=dkspider,o=Administration,c=de” read

access to dn.children=“o=FIRMA1,c=de”
by dn.base=“cn=jndiServ Modul,ou=jndiServ,o=Administration,c=de” write
by dn.base=“cn=XXZZread,ou=AdminUser,o=Administration,c=de” read
by dn.base=“cn=XXZZwrite,ou=AdminUser,o=Administration,c=de” write
by dn.base=“cn=ReplicationUser,ou=AdminUser,o=Administration,c=de” write
by dn.base=“cn=HHHHread,ou=HHHH,o=Administration,c=de” read
by dn.base=“cn=dkspider,ou=dkspider,o=Administration,c=de” read

access to dn.base=“o=Landesverwaltung Rheinland-Pfalz,c=de”
by dn.base=“cn=jndiServ Modul,ou=jndiServ,o=Administration,c=de” write
by dn.base=“cn=XXZZread,ou=AdminUser,o=Administration,c=de” read
by dn.base=“cn=XXZZwrite,ou=AdminUser,o=Administration,c=de” write
by dn.base=“cn=ReplicationUser,ou=AdminUser,o=Administration,c=de” write

access to dn.children=“o=FIRMA2,c=de”
by dn.base=“cn=Konto Login Modul,ou=Informationssystem,ou=Administrative Dienste,o=FIRMA2,c=de”
write
by dn.base=“cn=jndiServ Modul,ou=jndiServ,o=Administration,c=de” write
by dn.base=“cn=XXZZread,ou=AdminUser,o=Administration,c=de” read
by dn.base=“cn=XXZZwrite,ou=AdminUser,o=Administration,c=de” write
by dn.base=“cn=ReplicationUser,ou=AdminUser,o=Administration,c=de” write
by self write

by * read

#access to * by self write

by * read

disallow bind_anon

if no access controls are present, the default policy

allows anyone and everyone to read anything but restricts

updates to rootdn. (e.g., “access to * by * read”)

rootdn can always read and write EVERYTHING!

#######################################################################

BDB database definitions

#######################################################################

loglevel 4

database bdb
suffix “c=de”
rootdn “cn=Manager,c=de”
rootpw “{SSHA}3i/nHQ+UOZ5syPwY0/V7Go64p/lA0uaN”
directory /var/lib/ldap
checkpoint 1024 5
cachesize 10000
sizelimit 999999

hinzugefuegt fuer replication

index objectClass eq

Hinzugefuegt fuer Replication

index entryCSN,entryUUID eq
index uidNumber eq

overlay syncprov

overlay syncprov
syncprov-checkpoint 100 10

Maximale Anzahl der Eintraege fuer das Sessionlog im Arbeitsspeicher

syncprov-sessionlog 200[/CODE]

logfile:

Apr 20 15:16:12 ldap01 slapd[8380]: send_ldap_result: err=0 matched="" text="" Apr 20 15:16:12 ldap01 slapd[8380]: connection_get(12) Apr 20 15:16:12 ldap01 slapd[8380]: SRCH "c=de" 1 0 Apr 20 15:16:12 ldap01 slapd[8380]: 0 60 0 Apr 20 15:16:12 ldap01 slapd[8380]: filter: (objectClass=*) Apr 20 15:16:12 ldap01 slapd[8380]: attrs: Apr 20 15:16:12 ldap01 slapd[8380]: objectclass Apr 20 15:16:12 ldap01 slapd[8380]: Apr 20 15:16:12 ldap01 slapd[8380]: send_ldap_result: err=32 matched="" text=""

An LDAP 32 error indicates that the object specified could not be found.
Guessing from your log, the only thing you provided as an object was what
looks like the base context (c=de) which appears in your configuration
file many times. Was slapd restarted? Is there any other way you can see
what slapd does see? I have used some other directories and specifying a
‘’ (two single-quotes) base context lets me dump the entire structure;
maybe doing so in your case can find out what your server sees as available.


Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

Hi TRex1,

with the manager I can login without problems . The ReplicationUser I can not sign in. Does anyone know why?

as you’re talking about replication - where are you trying to log on (which machine), by which means do you do so (is it a systems login, via PAM - or are you “logging in” via i.e.ldapsearch, specifying bind credentials?), and is the clinet machine actually using the slapd on ldap01? Is ldap01 the replication master?

If this actually is a system login, how’s the LDAP client set up (/etc/ldap.conf)… and if this is something else (i.e. ldapsearch with bind credentials), which is the actual command you’re using?

Regards,
Jens

Hello everybody,
the ldap01 is the master and the slave- ldap02 is.The entries in the slapd.conf look like this:

[QUOTE]ldap02
loglevel 48
syncrepl rid=1 \
provider=ldaps://ldap01p:398 \
type=refreshAndPersist \
retry=“10 5 360 5” \
searchbase=“c=de” \
filter="(objectClass=*)" \
scope=sub \
schemachecking=off \
bindmethod=simple \
binddn=“cn=ReplicationUser,ou=AdminUser,o=Administration,c=de” \
credentials=xxyyww
[/QUOTE]

The /var/log/messages file returns the following error:

[QUOTE]Apr 21 15:17:15 ldap02p slapd[21891]: slapd starting
Apr 21 15:17:20 ldap02p slapd[21891]: slap_client_connect: URI=ldaps://ldap01p:398 DN=“cn=replicationuser,ou=adminuser,o=administration,c=de” ldap_sasl_bind_s failed (-1)
Apr 21 15:17:20 ldap02p slapd[21891]: do_syncrepl: rid=001 rc -1 retrying (4 retries left)
Apr 21 15:17:30 ldap02p slapd[21891]: slap_client_connect: URI=ldaps://ldap01p:398 DN=“cn=replicationuser,ou=adminuser,o=administration,c=de” ldap_sasl_bind_s failed (-1)
Apr 21 15:17:30 ldap02p slapd[21891]: do_syncrepl: rid=001 rc -1 retrying (3 retries left)
Apr 21 15:17:40 ldap02p slapd[21891]: slap_client_connect: URI=ldaps://ldap01p:398 DN=“cn=replicationuser,ou=adminuser,o=administration,c=de” ldap_sasl_bind_s failed (-1)
Apr 21 15:17:40 ldap02p slapd[21891]: do_syncrepl: rid=001 rc -1 retrying (2 retries left)
[/QUOTE]

When I log in with the schema browser appears the error message
LDAP error : Object does not exist !

Hi TRex1,

[QUOTE=TRex1;27581]Hello everybody,
the ldap01 is the master and the slave- ldap02 is.The entries in the slapd.conf look like this:

The /var/log/messages file returns the following error:

When I log in with the schema browser appears the error message
LDAP error : Object does not exist ![/QUOTE]

does accessing the object via i.e. “ldapsearch” work, especially when using the same credentials you configured for the LDAP client?

Regards,
Jens

My result from ldapsearch (same credentials) is as follows

[CODE]ldap01p:~ # ldapsearch -x -D “cn=ReplicationUser,ou=AdminUser,o=Administration,c=de” -b “ou=AdminUser,o=Administration,c=de” -W
Enter LDAP Password:

extended LDIF

LDAPv3

base <ou=AdminUser,o=Administration,c=de> with scope subtree

filter: (objectclass=*)

requesting: ALL

AdminUser, Administration, de

dn: yyyyyy
ou: yyyyyyy
objectClass: top
objectClass: organizationalUnit

ReplicationUser, AdminUser, Administration, de

dn: cn=ReplicationUser,ou=AdminUser,o=Administration,c=de
objectClass: inetOrgPerson
objectClass: top
sn: ReplicationUser
cn: ReplicationUser
userPassword:: xxxxxxx

search result

search: 2
result: 0 Success

numResponses: 5

numEntries: 4[/CODE]

Hi TRex1,

with the manager I can login without problems . The ReplicationUser I can not sign in. Does anyone know why?

ldap01p:~ # ldapsearch -x -D “cn=ReplicationUser,ou=AdminUser,o=Administration,c=de” -b “ou=AdminUser,o=Administration,c=de” -W
Enter LDAP Password:

extended LDIF

doesn’t this say that you tried to log in with the credentials of the replication user - and this works?

From your earlier message, what I understand is a slapd message from ldap01:

DN=“cn=replicationuser,ou=adminuser,o=administrati on,c=de” ldap_sasl_bind_s failed

I see a certain difference in the credentials - could you please verify you’re using the proper replication credentials on ldpa02? (It well might be you redacted the strings for posting here, so this is just a shot into the dark.)

Regards,
Jens

Hello,
the entries of my slapd.conf Replication Server are as follows:

loglevel 48 syncrepl rid=1 \\ provider=ldaps://ldap01p:398 \\ type=refreshAndPersist \\ retry="10 5 360 5" \\ searchbase="c=de" \\ filter="(objectClass=*)" \\ scope=sub \\ schemachecking=off \\ bindmethod=simple \\ binddn="cn=ReplicationUser,ou=AdminUser,o=Administration,c=de" \\ credentials=xxxxxx

The credentials are in my view identical to ldapsearch.

Regards,
Manuel