Bryan Payne skrev, on 21-02-2008 15:52:
> If the account is locked, the user cannot login. If the password has
> expired, the user can login.
Not at my site.
> I would like for it to prompt for the
> password but it fails to work for linux machines using pam or windows
> machines using pgina.
How are your users logging in - at a CLI login, gdm, su, ssh? On all of
these at my site the user gets prompted for his password. This *is* a
pam matter.
> I understand this is an openldap list so if you
> tell me the issue is client side (and pam related) regarding changing
> the password upon expiration, I'll take my question there.
Have a look at (haven't forgotten you're using CentOS4)
/etc/pam.d/system-auth, if in doubt about what the different libraries
do, read the html docs. Pam login and password change sub-*mechanism*s
can also defined in /etc/ldap.conf. Bits of what you're finding are pam
related, bits are OL ppolicy.
What happens if you comment out all the ppolicy-related stuff in
slapd.conf? Are your users still not getting prompted for a password?
> What about
> notification of expiration? As it is right now, the user is never shown
> if their password is expiring soon. It sends it to a log on the ldap
> server, but nothing pops up on the client machine. Is this pam related too?
No, purely OL ppolicy, works well at my site.
Best,
--Tonni
--
> Buchan Milne wrote:
>> On Wednesday 20 February 2008 17:10:00 Bryan Payne wrote:
>>
>>> Thank you for your help. I added the pwdPolicySubentry to a user to no
>>> avail. I did find this in the logfile though:
>>>
>>> Feb 20 09:01:13 ldapserver slapd[6709]: conn=95289 op=4 SEARCH RESULT
>>> tag=101 err=50 nentries=0 text=Operations are restricted to
>>> bind/unbind/abandon/StartTLS/modify password
>>>
>>> So it looks like it's trying to do something but cannot. While I'm
>>> concerned about password strength, I'm more concerned (at this point)
>>> with just having the machine prompt for a password change.
>>
>> Well, what do you mean by "the machine" ? It looks like the password
>> has expired, but if you're expecting a prompt for a password change,
>> that's a client side issue. So, what is the client in this case?
>> Recent versions of pam_ldap support ppolicy (IIRC including the one
>> shipped with RHEL4), but you didn't say which client this is.
>>
>> Also, you said accounts get locked, but users can still log in? This
>> sounds like you might not actually be using pam_ldap for
>> authentication, but the pam_unix->nss_ldap (NIS replacement and
>> nothing more) method, which won't see anything relating to ppolicy.
>>
>> Regards,
>> Buchan
>>
>
--
Tony Earnshaw
Email: tonni at hetnet dot nl
Hi everybody,
thank you all for your immediate replies.
As you correctly pointed out, the options I used were wrong.
With following ldap.conf, everything works out fine.
base dc=...
URI ldaps://<fqdn of ldap server>/
ldap_version 3
rootbinddn cn=...
bind_policy soft
pam_password md5
TLS_REQCERT yes
TLS_CACERT /usr/lib/ssl/certs/<ca>.chain.crt
The ldap.conf I used before has been created by dpkg-reconfigure
and I simply changed the default values there. That was a mistake ;-)
Creating a new ldap.conf from scratch with a man-page at hand
obviously did the trick.
Thank you very much for your help,
Best regards,
Hauke
--
----- Ursprüngliche Mail -----
Von: "Howard Chu" <hyc(a)symas.com>
An: "Hauke Coltzau" <hauke.coltzau(a)FernUni-Hagen.de>
CC: "openldap-technical" <openldap-technical(a)openldap.org>
Gesendet: Mittwoch, 27. August 2008 20:37:44 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien
Betreff: Re: SLAPD 2.4.9 and OpenSSL 0.9.8g on Ubuntu 8.04 server - client certificate not read
Hauke Coltzau wrote:
> Hello everybody,
>
> I'm just trying to set up a LDAPS server using my own
> certification authority, but the ldap server does not
> accept/understand my client certificate. Instead, the server
> sais:
>
> TLS: can't accept: The peer did not send any certificate..
> Here are the details:
>
> Client:
> =======
>
> # ldapsearch -x -LLL -ZZ -d 1
>
> ldap_create
> ldap_extended_operation_s
> ldap_extended_operation
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP<serverip>:636
> ldap_new_socket: 3
> ldap_prepare_socket: 3
> ldap_connect_to_host: Trying<serverip>:636
> ldap_pvt_connect: fd: 3 tm: -1 async: 0
> TLS: can't connect: A TLS packet with unexpected length was received..
> ldap_err2string
> ldap_start_tls: Can't contact LDAP server (-1)
>
>
> Server:
> ========
>
> # slapd -VV
> @(#) $OpenLDAP: slapd 2.4.9 (Aug 1 2008 01:09:46) $
> buildd@king:/build/buildd/openldap2.3-2.4.9/debian/build/servers/slapd
>
>
> # slapd -h "ldaps://<ip>/" -u openldap -g openldap -d 127
You cannot use StartTLS (ldapsearch -Z) with an ldaps:// server, it's redundant.
> ldap.conf (partially)
> ---------------------
>
> uri ldaps://132.176.4.6/
> ssl yes
> tls_cacertfile /usr/lib/ssl/cacartes/<ca>.chain.crt
> tls_ciphers TLSv1
The above 3 keywords are not valid for ldap.conf. Read the ldap.conf(5) manpage.
> tls_cert /usr/lib/ssl/certs/<clientfqdn>.cert.pem
> tls_key /usr/lib/ssl/private/<clientfqdn>.key.pem
> What did I do wrong?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
------------------------------------
Fernuniversität in Hagen
Lehrgebiet Kommunikationsnetze
http://www.fernuni-hagen.de/kn
Fon/Fax: +49 2331 987 -1142 / -353
------------------------------------
Sorry to bump on my own question...
Does anyone have an idea how I could solve this?
Nico
Hi,
I'm trying to set up a proxy-cache to a couple of OpenLDAP servers configured in mirror mode.
The back-ldap part is working fine and I can query the underlying slapd instances through the proxy.
However, I'm still struggling with the caching bit.
I couldn't find any documentation or posts related to setting this up using the new cn=config way of configuring LDAP. So after some reading and a bit of guessing, I came up with the following config:
# {1}ldap, config
dn: olcDatabase={1}ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: {1}ldap
olcSuffix: dc=sol1,dc=net
olcAccess: {0}to dn.base="" by * read
olcAccess: {1}to dn.base="cn=Subschema" by * read
olcAccess: {2}to * by self write by users read by anonymous auth
olcRootDN: uid=ldapadmin,dc=sol1,dc=net
olcRootPW: secret
olcDbURI: "ldap://192.168.200.12 ldap://192.168.200.14"
olcDbACLBind: bindmethod=simple binddn="uid=ldapadmin,dc=sol1,dc=net" credentials="secret" starttls=no
# {0}pcache, {1}ldap, config
dn: olcOverlay={0}pcache,olcDatabase={1}ldap,cn=config
objectClass: olcOverlayConfig
objectClass: olcPcacheConfig
olcOverlay: {0}pcache
olcPcache: bdb 10000 3 1000 100
olcPcacheAttrset: 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
olcPcacheAttrset: 1 sudoCommand sudoHost
olcPcacheAttrset: 2 gidNumber
olcPcacheTemplate: (&(objectClass=)(uid=)) 0 300
olcPcacheTemplate: (sudoUser=) 1 300
olcPcacheTemplate: (&(objectClass=)(memberUid=)) 2 300
# {2}bdb, config
dn: olcDatabase={2}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcDbDirectory: /var/lib/ldap/cache
olcSuffix: cn=proxy
olcRootDN: uid=ldapadmin,dc=sol1,dc=net
olcDbCacheSize: 5000
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: uid eq
olcDbIndex: cn eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: memberUid eq
olcDbIndex: uniqueMember eq
olcDbIndex: mail eq
olcDbIndex: surname eq
olcDbIndex: givenname eq
olcDbIndex: sambaSID eq
olcDbIndex: sambaPrimaryGroupSID eq
olcDbIndex: sambaDomainName eq
olcDbIndex: sudoUser eq
But running ldapsearch keeps returning:
# search result
search: 2
result: 52 Server is unavailable
text: pcachePrivDB: cacheDB not available
I didn't find any way to specify which database to use when declaring the overlay, apart from the 'bdb' part of olcPcache, but that seems to be interpreted as the database type, not its name (I've tried replacing it with cn=proxy, but that throws an error).
Looking at the pcache overlay source (I'm running 2.4.21 from Ubuntu Lucid and also checked the latest 2.4.23 stable source), I can see this bit:
{ "pcache-", "private database args",
1, 0, STRLENOF("pcache-"), ARG_MAGIC|PC_PRIVATE_DB, pc_cf_gen,
NULL, NULL, NULL },
That seems to be for the private DB options, but the other equivalent "pcacheXXXX" in this file have the corresponding attribute declaration for the schema instead of 'NULL, NULL, NULL'.
Anyway, I'm obviously missing something :)
If someone who's got this working or a developer could point me in the right direction, that would be greatly appreciated!
Thanks,
Nico
Hello,
I am facing an issue with syncrepl and STARTTLS on 389 port. The kind of
problem happening only sometimes, and disappearing "by itself". I use
Debian Jessie, OpenLDAP 2.4.40+dfsg-1+deb8u2.
Description : I have a production environment, and a preproduction
environment. Both of them consist of one provider and multiple
consumers.
Right now all is working fine. Then 2 times a days a script injects the
production data in the preproduction environment : ldapsearch on prod /
ldapdelete on preprod / stop slapd on preprod / slapadd on preprod /
start slapd on preprod.
Then sometimes during this injection I get a problem : one or more of
the consumers in preprod fail to sync. But sometimes all are OK. Then
the consumers facing the issue succeed syncrepl again "by themselves"
after a few dozens of minutes / hours. If I restart slapd on the failing
consumers, then the syncrepl succeeds immediately. When the syncrepl is
failing, I can still perform an ldapsearch using STARTTLS and the
syncrepl binding credentials from the consumer to the provider. There
is no issue with non-TLS LDAP replications.
Also, using ldapsearch with option "-d 3" I get TLS debug, but even with
"olcLogLevel -1" in cn=config I can't get precise debug for TLS during
syncrepl.
I captured the trafic and when there is the error, wireshark at some
point can't understand TLS sent by the
consumer (SSL "ignored unknown record"). Corresponding data is "30 05 02
01 02 42 00". Not sure it's related to the problem though, but it looks
like since (if I am right) the first information in TLS is the
content-type, and 30 is not a valid value for content type
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-pa…).
Any idea ? I would like to avoid making the injection script connect to
all my preprod consumers and restart slapd on them. Please feel free to
ask for more logs / configurations.
Log on the provider :
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1
descriptor
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]:
slap_listener_activate(9):
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=9 busy
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=10 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=11 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=12 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=13 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: >>>
slap_listener(ldap:///)
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1
descriptor
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: listen=9, new
connection on 18
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: added 18r
(active) listener=(nil)
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 fd=18
ACCEPT from IP=192.168.115.61:33816 (IP=0.0.0.0:389)
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=9 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=10 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=11 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=12 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=13 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1
descriptor
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active
on 18
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=9 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18)
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=10 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=11 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=12 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=13 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18):
got connid=1010
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18):
checking for input on id=1010
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: op tag 0x77, time
1496231248
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0
do_extended
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1
descriptor
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: do_extended:
oid=1.3.6.1.4.1.1466.20037
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=9 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0
STARTTLS
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=10 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: send_ldap_extended:
err=0 oid= len=0
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: send_ldap_response:
msgid=1 tag=120 err=0
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=11 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0 RESULT
oid= err=0 text=
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=12 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=13 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1
descriptor
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active
on 18
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=9 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18)
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=10 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18):
got connid=1010
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=11 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18):
checking for input on id=1010
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=12 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=13 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1
descriptor
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=9 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=10 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=11 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=12 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=13 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1
descriptor
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active
on 18
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=9 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18)
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=10 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18):
got connid=1010
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=11 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18):
checking for input on id=1010
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=12 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=13 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18):
unable to get TLS client DN, error=49 id=1010
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 fd=18 TLS
established tls_ssf=128 ssf=128
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 2
descriptors
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active
on 18
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=9 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=10 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=11 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=12 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18)
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=13 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18):
got connid=1010
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18):
checking for input on id=1010
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: ber_get_next on fd 18
failed errno=0 (Success)
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18):
input error=-2 id=1010, closing.
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_closing:
readying conn=1010 sd=18 for close
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_close:
conn=1010 sd=18
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1
descriptor
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: removing 18
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 fd=18
closed (connection lost)
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]:
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=9 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=10 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=11 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=12 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll:
listen=13 active_threads=0 tvp=zero
Log on the consumer :
May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll:
listen=9 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll:
listen=10 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: =>do_syncrepl
rid=006
May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll:
listen=11 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]:
slap_client_connect: URI=ldap://ldap-master-pp.acme Error,
ldap_start_tls failed (-11)
May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: do_syncrepl:
rid=006 rc -11 retrying
May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon:
activity on 1 descriptor
May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon:
activity on:
May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]:
May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll:
listen=9 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll:
listen=10 active_threads=0 tvp=zero
May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll:
listen=11 active_threads=0 tvp=zero
syncrepl config on consumer :
olcSyncrepl: {0}rid=6 provider=ldap://ldap-master-pp.acme
starttls=critical t
ls_reqcert=never bindmethod=simple
binddn="cn=replication,ou=Applications,d
c=acme,dc=fr" credentials=**** searchbase="dc=acme,dc=fr" schemacheck
ing=off type=refreshAndPersist filter="(objectClass=*)" attrs="*"
scope=sub
retry="60 +"
TLS config on provider :
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
structuralObjectClass: olcGlobal
entryUUID: 9efabaca-b31f-1036-9746-2d4f8feb88f1
creatorsName: cn=config
createTimestamp: 20170411162820Z
olcTLSCertificateFile: /etc/ssl/certs/ssl-cert-snakeoil.pem
olcTLSCertificateKeyFile: /etc/ssl/private/ssl-cert-snakeoil.key
olcLogLevel: 256
entryCSN: 20170531131949.877388Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20170531131949Z
Hi
What can lead a consumer to "randomly" delete ~50% of all objects in his database?
I have this problem now for ~1-2months and on 3 different master/slave groups.
The consumer starts to delete objects (but those are all present on the master):
Oct 19 17:16:22 ldap-slave002.xxx slapd[8554]: do_syncrep2: rid=999 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
Oct 19 17:16:22 ldap-slave002.xxx slapd[8554]: do_syncrep2: rid=999 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 9c802b18-7c2c-1033-9f25-2d4a65066d19, dn uid=jasmin.mans,ou=none,o=dd,dc=xxx,dc=xxx
Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 650ada00-e996-1035-80ac-a173474274df, dn uid=jasmine.suddr,ou=none,o=dd,dc=xxx,dc=xxx
Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID ec5c9aa4-7c2c-1033-9fa4-2d4a65066d19, dn uid=jonas.beffrnn,ou=none,o=dd,dc=xxx,dc=xxx
Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 7461d22e-e996-1035-80f6-a173474274df, dn uid=juerg.klegegeli,ou=none,o=dd,dc=xxx,dc=xxx
Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 758c744c-e996-1035-8100-a173474274df, dn uid=julia.sxgegegea,ou=none,o=dd,dc=xxx,dc=xxx
Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 47e4f6b4-7c2d-1033-8015-2d4a65066d19, dn uid=karin.vivwvwe,ou=none,o=dd,dc=xxx,dc=xxx
Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 8d26a4f2-7c2d-1033-807b-2d4a65066d19, dn uid=larissa.fewfewf,ou=none,o=dd,dc=xxx,dc=xxx
Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 98310aa4-7c2d-1033-808b-2d4a65066d19, dn uid=laura.cfwfew,ou=none,o=dd,dc=xxx,dc=xxx
syncrepl config:
olcSyncrepl: {0}rid=999 provider=ldap://ldap-master002.xxx.xxx:389 bindmethod=simple timeout=0 network-timeout=10 binddn="uid=replicator,ou=system,o=de,dc=xxx,dc=xxx"
credentials="pass" keepalive=0:0:0 starttls=yes tls_cacert="/etc/ssl/certs/SwissSign_Silver_CA_-_G2.pem" tls_reqcert=allow filter="(objectClass=*)" searchbase="dc=xxx,dc=xxx" scope=sub attrs="*,+"
syncdata="accesslog" logbase="cn=accesslog_xxx" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=off type=refreshOnly interval="00:00:01:00" retry="10 5 60 +"
Misconfiguration? (We've been running this configuration for years...)
Workaround is to remove the whole mdb database and restart slapd to let it resync.
I've found some posts with a similar problem but those are all related to pre 2.4.21, we're running slapd 2.4.44.
Cheers
So, before I ask my question, here are my referenced objects, from a "slapcat -n 0":
dn: olcDatabase={2}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap
olcDbIndex: objectClass eq,pres
olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub
structuralObjectClass: olcHdbConfig
entryUUID: eb941fcc-bef3-1036-9d74-0d6e032eb747
creatorsName: cn=config
createTimestamp: 20170426174545Z
olcAccess: {0}to dn.base="" by self write by dn="cn=ldapadmin,dc=XXXXXXX
,dc=net" write by * read
olcAccess: {1}to * by self write by dn="cn=ldapadmin,dc=XXXXXXX,dc=net" w
rite by * read
olcAccess: {2}to dn.subtree="ou=mail,ou=hosting,dc=XXXXXXX,dc=net" attrs=
userPassword,UseAppPassword,children,entry,objectClass,cn,sn,uid by self w
rite by dn="cn=ldapadmin,dc=XXXXXXX,dc=net" write by * auth by * read
olcSuffix: dc=XXXXXXXX,dc=net
olcRootDN: cn=ldapadmin,dc=XXXXXXX,dc=net
olcRootPW:: e1NTSEF9K2p6YnhXL0xQTDJKZFFIZitac3l6RzVXaEN3UEhQUkc=
entryCSN: 20170508155547.001404Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20170508155547Z
dn: olcOverlay={0}ppolicy,olcDatabase={2}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {0}ppolicy
olcPPolicyDefault: cn=passwordDefault,ou=policies,dc=XXXXXXX,dc=net
olcPPolicyHashCleartext: FALSE
olcPPolicyUseLockout: FALSE
olcPPolicyForwardUpdates: FALSE
structuralObjectClass: olcPPolicyConfig
the passwordDefaul policy exists in the correct location, and appears to apply to all user objects BUT
when I change a user object to a value that either violates the base policy (say, has only 4 characters instead of 5 or more), or would not conform to the check_password.so function, as established by various outside sources, it does not give me an error of any kind, and instead, writes the password to the DB and writes the following to the log:
May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 EXT oid=1.3.6.1.4.1.1466.20037
May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 STARTTLS
May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 RESULT oid= err=0 text=
May 10 11:00:06 ldapv slapd[1984]: conn=1007 fd=11 TLS established tls_ssf=256 ssf=256
May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 BIND dn="cn=ldapadmin,dc=XXXXXXX,dc=net" method=128
May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 BIND dn="cn=ldapadmin,dc=XXXXXXX,dc=net" mech=SIMPLE ssf=0
May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 RESULT tag=97 err=0 text=
May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 MOD dn="uid=USER,cn=TESTDOMAIN.com,ou=domain,ou=mail,ou=hosting,dc=XXXXXXX,dc=net"
May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 MOD attr=userPassword
May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 RESULT tag=103 err=0 text=
And the entry, as referenced by phpLDAPadmin, appears to correspond to the "bad" password. How can I go about confirming that the password policy is being enforced?
Hello,
i'm trying to setup a master/slave replication via delta-syncrepl, but for
the most of the entries i get the message: "Entry CSN greater than
snapshot". I had search in the archive of the mail list but i couldn't get
a solution for this. Any help is appreciate.
Some entrie i get in the syslog:
Oct 20 20:23:57 temperance slapd[7645]: Entry
uid=ari_oliveira,ou=uvanet.br,ou=mail,dc=uvanet,dc=br
CSN 20151015141738.689470Z#000000#000#000000 greater than snapshot
20150709142425.146445Z#000000#000#000000
Oct 20 20:23:57 temperance slapd[7645]: Entry
cn=SAPLIC,ou=groupOfNames,ou=intranet,dc=uvanet,dc=br CSN
20151020152042.450209Z#000000#000#000000 greater than snapshot
20150709142425.146445Z#000000#000#000000
Oct 20 20:23:57 temperance slapd[7645]: Entry
cn=SIGU,ou=groupOfNames,ou=intranet,dc=uvanet,dc=br CSN
20151020152042.636081Z#000000#000#000000 greater than snapshot
20150709142425.146445Z#000000#000#000000
I have the following config in the provider (slapd 2.4.23):
...
moduleload accesslog.la
moduleload syncprov.la
database hdb
suffix cn=accesslog
directory /opt/ldap/accesslog
rootdn cn=accesslog
index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart eq
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
database hdb
suffix "dc=uvanet,dc=br"
rootdn "xxxxxx"
directory "/var/lib/ldap"
overlay syncprov
syncprov-checkpoint 1000 60
#syncprov-checkpoint 500 30
syncprov-reloadhint TRUE
syncprov-sessionlog 500
# accesslog overlay definitions for primary db
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
# scan the accesslog DB every day, and purge entries older than 7 days
logpurge 07+00:00 01+00:00
index objectClass eq,pres
index ou,cn,sn,mail,givenname eq,pres,sub
index uidNumber,gidNumber,memberUid eq,pres
index loginShell eq,pres
index memberOf eq
## required to support pdb_getsampwnam
index uid pres,sub,eq
# required to support pdb_getsambapwrid()
index displayName pres,sub,eq
index nisMapName,nisMapEntry eq,pres,sub
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index default sub
index uniqueMember eq
index sambaGroupType eq
index sambaSIDList eq
# syncprov specific indexing
index entryUUID eq
index entryCSN eq
overlay memberof
In the consumer server we have:
syncrepl rid=1
provider=ldap://X.X.X.X
type=refreshAndPersist
retry="5 + 5 +"
interval=00:00:00:01
searchbase="dc=uvanet,dc=br"
filter="(objectClass=*)"
scope=sub
starttls=no
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
attrs="*"
schemachecking=on
bindmethod=simple
binddn="XXXX"
credentials="XXXX"
# Refer updates to the master
updateref ldap://X.X.X.X
Thanks in advance
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pedro Roger Magalhães Vasconcelos
http://www.proger.eti.br
On 11-09-22 7:37 PM, Howard Chu wrote:
> Daniel Qian wrote:
>> The problem direction has the same syncrepl configuration as the working
>> one except for the rid and provider name:
>>
>> olcSyncrepl: {0}
>> rid=102 provider="ldap://server2.prod:389/"
>> type=refreshAndPersist
>> retry="60 30 300 +"
>> keepalive=1200:10:3
>> searchbase="dc=mydomain,dc=com"
>> bindmethod=simple
>> binddn="cn=replica,dc=mydomain,dc=com"
>> credentials=xxxxxx
>> starttls=critical
>> tls_cacert="/etc/pki/CA/cacert.pem"
>>
>> On the consumer side I am seeing these messages:
>>
>> Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrep2: rid=102 got search
>> entry without Sync State control
>> Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrepl: rid=102 rc -1
>> retrying (29 retries left)
>>
>> and on the provider side I am seeing these:
>
>
>> The sync connection is supposed to be persistent but it keeps closing
>> down and reconnecting.
>>
>> Anyone know what could be the reason?
>
> Obviously your "provider side" doesn't actually have the syncprov
> overlay configured.
>
I put the exact same configuration for syncprov on two servers
[root@localhost cn=config]# ldapsearch -LLL -b cn=config -D
cn=admin,cn=config -W -ZZ -h ldaprov1.prod cn=module{0}
Enter LDAP Password:
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}syncprov
[root@localhost cn=config]# ldapsearch -LLL -b cn=config -D
cn=admin,cn=config -W -ZZ -h ldaprov2.prod cn=module{0}
Enter LDAP Password:
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}syncprov
[root@localhost cn=config]# ls /usr/lib64/openldap
accesslog-2.4.so.2 constraint-2.4.so.2 dyngroup-2.4.so.2
pcache-2.4.so.2 retcode-2.4.so.2 smbk5pwd-2.4.so.2
translucent-2.4.so.2
accesslog-2.4.so.2.6.0 constraint-2.4.so.2.6.0 dyngroup-2.4.so.2.6.0
pcache-2.4.so.2.6.0 retcode-2.4.so.2.6.0 smbk5pwd-2.4.so.2.6.0
translucent-2.4.so.2.6.0
accesslog.la constraint.la dyngroup.la
pcache.la retcode.la smbk5pwd.la
translucent.la
auditlog-2.4.so.2 dds-2.4.so.2 dynlist-2.4.so.2
ppolicy-2.4.so.2 rwm-2.4.so.2 sssvlv-2.4.so.2
unique-2.4.so.2
auditlog-2.4.so.2.6.0 dds-2.4.so.2.6.0 dynlist-2.4.so.2.6.0
ppolicy-2.4.so.2.6.0 rwm-2.4.so.2.6.0 sssvlv-2.4.so.2.6.0
unique-2.4.so.2.6.0
auditlog.la dds.la dynlist.la
ppolicy.la rwm.la sssvlv.la unique.la
collect-2.4.so.2 deref-2.4.so.2 memberof-2.4.so.2
refint-2.4.so.2 seqmod-2.4.so.2 syncprov-2.4.so.2
valsort-2.4.so.2
collect-2.4.so.2.6.0 deref-2.4.so.2.6.0 memberof-2.4.so.2.6.0
refint-2.4.so.2.6.0 seqmod-2.4.so.2.6.0 syncprov-2.4.so.2.6.0
valsort-2.4.so.2.6.0
collect.la deref.la memberof.la
refint.la seqmod.la syncprov.la
valsort.la
Can you tell what is missing on one of the two servers? Is there a
command to tell if the module is actually loaded into the execution space?
Thanks,
Daniel
>>On 11/30/2011 08:01 AM, Jayavant Patil wrote:
>>
>>
>> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
>> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>> wrote:
>>
>>
>> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
>> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
>> >>Hi
>>
>> >>I think you mean SSL connection or the STARTTLS Layer...?
>> >>Please read the manual http://www.openldap.org/doc/admin24/tls.html
>> >Ok.
>>
>> >>And tree security:
>> >>On my server, a client user can only see his own object:
>> >Are you using simple authentication mechanism?
>>
>> >>Maybe create a rule like this:
>> >>access to filter=(objectClass=
>> >>simpleSecurityObject)
>> >> by self read
>> >> by * none
>>
>> >I am not getting what the ACL rule specifies. Any suggestions?
>>
>>
>> I have two users ldap_6 and ldap_7. I want to restrict a user to
>> see his own data only.
>> In slapd.conf, I specified the rule as follows:
>> access to *
>> by self write
>> by * none
>>
>> But ldap_6 can see the ldap_7 user entries (or vice versa) with
>> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
>> "ou=People,dc=abc,dc=com" "uid=ldap_7"
>>
>> Any suggestions?
>>
>On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli <public(a)raffaelsahli.com>
wrote:
>Yes, that's exactly the rule I wrote above.
>access to filter=(objectClass=
>simpleSecurityObject)
> by self read
> by * none
>Maybe you have to change the objectClass to posixAccount, or both or
>whatever....
>access to
>filter=(|(objectClass=simpleSecurityObject)(objectClass=posixAccount))
> by self read
> by * none
>Just add this rule before the global rule "access to *"
>>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
>>"ou=People,dc=abc,dc=com" "uid=ldap_7"
>And if you search like this with bind "admin dn", you will see every
>object....
>You have to bind with user ldap_6 and not with root
But anyway client user knows the admin dn and rootbindpassword. So, with
this he will look into all directory information to which he is not
supposed to do.
e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster
So, how to avoid this?
--
Thanks & Regards,
Jayavant Ningoji Patil
Engineer: System Software
Computational Research Laboratories Ltd.
Pune-411 004.
Maharashtra, India.
+91 9923536030.
hi. i have two servers, in an mmr arrangement, using delta-syncrepl.
on a couple of occasions, the servers have stopped replicating, and the
following is logged:
dsa1:
Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000
LDAP_RES_SEARCH_RESULT
Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000
LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform
Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000 (53) Server is
unwilling to perform
Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrepl: rid=000 rc -2 retrying
dsa2:
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 ACCEPT from
IP=10.200.41.20:49141 (IP=0.0.0.0:389)
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 STARTTLS
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 RESULT oid= err=0 text=
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 TLS established
tls_ssf=256 ssf=256
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 BIND
dn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,dc=example,dc=org"
method=128
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 BIND
dn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,dc=example,dc=org"
mech=SIMPLE ssf=0
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 RESULT tag=97 err=0
text=
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SRCH
base="cn=accesslog" scope=2 deref=0
filter="(&(objectClass=auditWriteObject)(reqResult=0))"
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SRCH attr=reqDN
reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SEARCH RESULT
tag=101 err=53 nentries=0 text=consumer state is newer than provider!
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=3 UNBIND
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 closed
if i reload data and restart replication, things work again, for a
period of time, but then this happens again.
what determines "consumer state is newer than provider"? i'm also a
little bit confused about this message in the context of mmr. if one
has newer data than the other, i had sort of expected that the newer
data would replace the old [obviously it's not that simple, so i'd like
to understand what i'm missing].
lastly, how can i further troubleshoot why this happened in the first place?
i'm using 2.4.44 on freebsd, built from ports. i can provide any config
details etc - i just didn't want to inundate the post with guesses on
detail that might not be relevant.
thanks
-ben