Search results for "starttls" - openldap-technical

unable to query rootdn on slave via external auth

by Adrian Bridgett

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

11 years, 11 months

Re: 回复： mirror mode question

by Dieter Klünter

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

11 years, 2 months

Re: Ppolicy issues

by Tony Earnshaw

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

17 years, 4 months

[SOLVED] Re: SLAPD 2.4.9 and OpenSSL 0.9.8g on Ubuntu 8.04 server - client certificate not read

by Hauke Coltzau

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 ------------------------------------

16 years, 10 months

Re: Proxycache overlay to back-ldap with cn=config

by Nicolas Brisac

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

14 years, 10 months

problem with syncrepl and STARTTLS

by r0m5

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

8 years

delta-synrepl consumer randomly delete objects

by Raffael Sahli

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

8 years, 8 months

ppolicy overlay - not seeming to function?

by John Cooter

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?

8 years, 1 month

Delta-syncrepl not syncing entire directory: Entry CSN greater than snapshot

by Pedro Roger

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

9 years, 8 months

Re: MirrorMode sync only happening in one direction

by Daniel Qian

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

13 years, 9 months

openldap-technical search results for query "starttls"