This has been driving me up the wall and I wondered if someone could
point out the bit I'm missing - the desk is getting badly damaged by my
head bashing it :-)
On our master server I can query the rootdb no problem, but I can't do
this on the slaves - this applies whether I use external or ldaps
authentication. I've turned on access and search filter debugging and I
can't see any rejections. I'm trying to query contextCSN to ensure that
the slave is in sync. "slapcat" works, but seems an ugly hack. I can
query all the children - just not the root.
The config is the same (ish) on both - here's the slave:
dn: olcDatabase={1}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=example,dc=com
olcLastMod: TRUE
olcRootDN: cn=admin,dc=example,dc=com
olcRootPW:: .......
olcDbCheckpoint: 512 30
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
structuralObjectClass: olcHdbConfig
entryUUID: 07f3fede-c201-1031-8b17-f3837148ab05
creatorsName: cn=config
createTimestamp: 20121113171221Z
olcSyncrepl: {0}rid=000 provider=ldap://ldap.example.com type=refreshandPers
ist interval=00:00:00:60 retry="60 10 300 +" timelimit=10
searchbase="dc=example
,dc=com" binddn="cn=admin,dc=example,dc=com" bindmethod=simple credent
ials=..... starttls=critical tls_reqcert=demand attrs="*,+"
olcUpdateRef: ldap://ldap.example.com
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: objectClass eq
olcDbIndex: cn,sn pres,eq,sub
olcDbIndex: uid,uidNumber,gidNumber,memberOf,sudoUser,memberUid pres,eq
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
anonymou
s auth by dn="cn=admin,dc=example,dc=com" manage by
group.exact="cn=admins,
ou=Group,dc=example,dc=com" manage by
dn.exact=gidNumber=0+uidNumber=0,cn=p
eercred,cn=external,cn=auth manage by * none
olcAccess: {1}to attrs=SambaLMPassword,SambaNTPassword by self write by
dn="cn
=freenas-auth,ou=services,dc=example,dc=com" read by
dn="cn=admin,dc=example
,dc=com" manage by group.exact="cn=admins,ou=Group,dc=example,dc=com" ma
nage by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth mana
ge by * none
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to * by self write by dn="cn=admin,dc=example,dc=com" manage b
y group.exact="cn=admins,ou=Group,dc=example,dc=com" manage by
dn.exact=gid
Number=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * read
olcAccess: {4}to dn.base="dc=example,dc=com" by * read
On the slave:
ldapsearch -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com -s base -Q#
extended LDIF
# search result
search: 2
result: 0 Success
# numResponses: 1
On the master:
ldapsearch -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com -s base
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example.com
dc: example
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Hi,
If I remeber correctly, you mentioned sasl authentication. My comments
on plaintext passwords are only related to sasl authentication. A sasl
authentication is based on a SASL MECHANISM, as described in rfc-4422.
In order to compare the sasl authentication string with the stored
password value, this has to be cleartext.
If your ldap operation is based on a simple bind, the stored password
can, and should be, hashed.
-Dieter
Am Tue, 8 Apr 2014 14:16:31 +0800
schrieb 田格瑄 <tiangexuan(a)sinap.ac.cn>:
> Hi Michael and Dieter,
>
>
>
> I see the below mail, can I understand only the mirror mode
> replication can’t use the HASH password in rootpw, other Synchronous
> replication mode(example: syncrepl proxy) can use the HASH password?
>
>
>
> Thanks and regards
>
> tiangexuan
>
>
>
> ------------------ 原始邮件 ------------------
>
> 发件人: "Michael Ströder";<michael(a)stroeder.com
> <mailto:michael@stroeder.com> >;
>
> 发送时间: 2014年3月5日(星期三) 下午4:09
>
> 收件人: "Dieter Klünter"<dieter(a)dkluenter.de
> <mailto:dieter@dkluenter.de> >;
> "openldap-technical"<openldap-technical(a)openldap.org
> <mailto:openldap-technical@openldap.org> >;
>
> 主题: Re: mirror mode & sasl question
>
>
>
> Dieter Klünter wrote:
> > Am Wed, 5 Mar 2014 14:38:04 +0800
> > schrieb "Eileen(=^ω^=)" <123784635(a)qq.com <mailto:123784635@qq.com>
> > >:
> >> This is Eileen from China SINAP. I am a beginner for openldap
> >> soft. I encountered a problem in my study on two LDAP services
> >> replication. I have 2 LDAP services, one name LDPA1, the other is
> >> LDAP2 . I want to make them synchronously in mirror mode. But when
> >> I set LDAP services rootpw both in hash, the 2 LDAP serivces can’t
> >> be synchronous. My question is
> >> 1. if I set my rootpw in hash, my bindmethod must be SASL? If
> >> I must use sasl method, can I put the sasl service in the same ldap
> >> service? If bindmethod=sasl then what is the saslmech should be?
> >> 2. If I change to sasl method, do I need change my database
> >> record?
> >
> > In order to use sasl, passwords must be cleartext and you should
> > configure an apropriate authz-regexp, see man slapd.conf(5)
> > You may use any sasl mechanism that you sasl framework provides.
> > [...]
>
> To be more precise: In order to use password-based SASL mechs the
> passwords have to be stored in clear-text.
>
> Well, if working with SASL and TLS (LDAPS, StartTLS) one should
> consider using client certs and SASL/EXTERNAL for replication.
>
> Ciao, Michael.
>
>
>
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
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