Search results for "starttls" - openldap-technical

cn=config chaining

by Jancewicz, Russell

Hello, I have been trying to configure my slave ldap servers to send changes to the master servers. >From what I have been able to understand from previous mailing lists and various google searches I need to configure and olcUpdateref on the salve and then add the chaining overlay (I think it should be on the olcDatabase{-1}frontend database from everything I have read however slaptest using openldap-2.4.36 slapd-chain2.conf as the seed generates the overlay atop of the declared database…) Everything I have been trying results in a failure: ldap_modify: Server is unwilling to perform (53) additional info: operation restricted I cannot for the life of me figure out what needs to be done to enable this. Any help would be appreciated, my ldifs are included below. -Russell J. Jancewicz University of Connecticut dn: olcDatabase={1}mdb,cn=config … olcUpdateref: ldap://master.example.com … dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: FALSE dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: ldap olcDbURI: "ldap://master.example.com" olcDbStartTLS: start starttls=no olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="cn=admin,dc=example,dc=com" credentials="<SECRET>" keepalive=0:0:0 olcDbIDAssertAuthzFrom: * olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0

11 years, 1 month

Antw: RE: Replication fails after network outage

by Ulrich Windl

>>> Quanah Gibson-Mount <quanah(a)zimbra.com> schrieb am 13.11.2013 um 19:07 in Nachricht <58534BED9C430B31FE4F6B5E(a)[192.168.1.93]>: > --On Wednesday, November 13, 2013 1:02 PM -0500 "Darouichi, Aziz" > <adarouic(a)post03.curry.edu> wrote: > >> Is it necessary to upgrade? I have to take my case to Management...!!!! > > Well, that depends. Do you want syncrepl to work, or do you want it to not > work? I strongly advise you to read the changelog for OpenLDAP so you can > see the numerous fixes to syncrepl replication since 2.4.23 was released. Let me comment that I run a multi-master configuration with openldap2-2.4.26-0.16.1 (SLES11 SP2) sucessfully. I haven tested network outages, but I restarted individual servers, and there were no problems. For the update: I contacted support, and they told me I'll have to demonstrate them how many $$ we would gain by using a later version. At that point I stopped arguing. olcSyncrepl: {0}rid=1 provider="ldap://server.de/" searchbase="cn=config" type="refreshAndPersist" retry="120 +" starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,ou=system,dc=server,dc=de" credentials="youdontexpectittobehere,right?" Regards, Ulrich > > --Quanah > > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

11 years

SASL EXTERNAL, sasldb2 and authz-regexp

by Götz Reinicke - IT-Koordinator

Hi folks, first of all thanks to all comments about my previous posts! Finaly I'm faced with hopefully the last authentication problem and may be somewone could tell me an answere or point me once more into the right direction. My consumer server should bind to the provider using sasl with the saslmech external. (Red Hat 5.x, cyrus-sasl-2.1.22, openldap-2.3.43-3 ) I'v changed the slapd.conf files on both servers: consumer: syncrepl ... bindmethod=sasl saslmech=EXTERNAL starttls=yes provider: authz-regexp "dn=email=webmaster(a)filmakademie.de,cn=ldap2.filmakademie.de,ou=it officenet,o=filmakademie baden-wuerttemberg gmbh,l=ludwigbsburg,st=baden-wuerttemberg,c=de" "cn=replicator,dc=filmakademie,dc=de" after restarting both servers I do get the error: <==slap_sasl2dn: Converted SASL name to <nothing> SASL [conn=0] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory I've searched my docs, online howtoos and found postings about "know sasl before using openldap" but the sasl docs didn't help too. Thanks for any help and best regards, Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reinicke(a)filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Geschäftsführer: Prof. Thomas Schadt

14 years, 7 months

Migration from openldap 2.4.20 to 2.4.33

by anil beniwal

Hi We are planing migration from openldap 2.4.20 (with bdb 4.8) to openldap 2.4.33 (bdb 5.1.29) No of users are 4 million and about to go live within next 10 days. We are using flat file for configuration in use. Below is my slapd.conf and DB_CONFIG files include /apps/openldap/etc/openldap/schema/core.schema include /apps/openldap/etc/openldap/schema/cosine.schema include /apps/openldap/etc/openldap/schema/nis.schema include /apps/openldap/etc/openldap/schema/inetorgperson.schema include /apps/openldap/etc/openldap/schema/openldap.schema include /apps/openldap/etc/openldap/schema/dyngroup.schema include /apps/openldap/etc/openldap/schema/ppolicy.schema include /apps/openldap/etc/openldap/schema/channelIdentifier.schema include /apps/openldap/etc/openldap/schema/platform.schema include /apps/openldap/etc/openldap/schema/extendedProfileKey.schema include /apps/openldap/etc/openldap/schema/extendedProfileValue.schema include /apps/openldap/etc/openldap/schema/behaviorKey.schema include /apps/openldap/etc/openldap/schema/behaviorValue.schema include /apps/openldap/etc/openldap/schema/questionAnswer.schema include /apps/openldap/etc/openldap/schema/extendedTop.schema include /apps/openldap/etc/openldap/schema/counter.schema pidfile /apps/openldap/var/run/slapd.pid argsfile /apps/openldap/var/run/slapd.args logfile /apps/logs/ldap loglevel 16640 database bdb suffix "dc=ibm,dc=com" access to attrs=userPassword by self write by anonymous auth by * break access to * by group/groupOfUniqueNames/uniqueMember.exact="cn=VWrite,ou=businessUsersGroup,dc=ibm,dc=com" manage by group/groupOfUniqueNames/uniqueMember.exact="cn=VRead,ou=businessUsersGroup,dc=ibm,dc=com" read by * break access to * by self write by anonymous auth by * read rootdn "cn=Manager,dc=ibm,dc=com" rootpw {SSHA}dXDFSQeFjSoa/A1HfJ3TAzYf8 ################## SSL ########################################## # #TLSVerifyClient allow TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCACertificateFile /apps/openldap/etc/openldap/cacerts/nascarcacert.pem TLSCertificateFile /apps/openldap/etc/openldap/cacerts/sj.crt TLSCertificateKeyFile /apps/openldap/etc/openldap/cacerts/sj.key # index entryCSN eq index entryUUID eq index mail,uid,postalCode,smail,channelType,channelValue,answer,behavName,objectclass,tokenID,type eq index givenName,sn,city,question,behavValue,cn,extName sub index displayName approx overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 serverid 3 syncrepl rid=111 provider=ldap://mmprod04 binddn="cn=Manager,dc=ibm,dc=com" bindmethod=simple starttls=yes tls_reqcert=allow credentials=G00gle# searchbase="dc=ibm,dc=com" type=refreshAndPersist retry="5 5 300 +" interval=00:00:00:10 syncrepl rid=222 provider=ldap://mmprod05 binddn="cn=Manager,dc=ibm,dc=com" bindmethod=simple starttls=yes tls_reqcert=allow credentials=G00gle# searchbase="dc=idm,dc=com" type=refreshAndPersist retry="5 5 300 +" interval=00:00:00:10 mirrormode TRUE cachesize 100000 idlcachesize 300000 lastmod on checkpoint 128 15 concurrency 100 directory /apps/openldap/var/openldap-data overlay unique unique_attributes mail overlay ppolicy ppolicy_default "cn=default,ou=pwdPolicy,dc=idm,dc=com" ppolicy_use_lockout DB_CONFIG set_cachesize 0 4294967295 0 set_lg_regionmax 2048576 set_lg_max 20485760 set_lg_bsize 2097152 set_lk_max_locks 10000 set_lk_max_objects 5000 set_lk_max_lockers 5000 My querries are:- 1. What should be taken care(Best Practices). 2. Data migration can be db_hotbackup will work? 3. Can same flat file method be used, if not what could be the way should work out. 4. any thing else i should be aware and is critical. -- Thanks&Regards Anil Beniwal

11 years, 10 months

Re: replica of schema info

by Francesco Malvezzi

> The correct way to enable replication after cn=config already exists is > with ldapmodify: > > dn: olcDatabase={0}config,cn=config > changetype: modify > add: olcSyncRepl > > >> It does work to add olcSyncrepl to olcDatabase={0}config,cn=config with >> a filter like: >> olcSyncrepl: {0}rid=001 provider=... binddn=... bindmethod=simple >> search base="cn=schema,cn=config" filter="(!(cn=core))" >> >> but then the whole olcDatabase={0}config,cn=config becomes a shadow >> context and I'm unable to ldapmodify anything (olcLoglevel for example). >> >> What am I missing? > > You need to set up all rids in your modify operation, each listing > provider with their own URI. Optionally, you could even have different > credentials pointing in different directions - nothing prevents this. > For n-way replication, you need to perform the same modification to n > sides. Otherwise your replicas will be read-only as you have seen. This > is the same for any database, not just n0. Go back and enable CRL > checking after you are sure that it works, if using TLS. > > Example, change the macros to suit your setup and apply this same ldif > to each of your replicas: > > dn: olcDatabase={0}config,cn=config > changetype: modify > add: olcSyncRepl > olcSyncrepl: rid=001 > provider=%%LDAP_URI_1%% > bindmethod=simple > timeout=0 > network-timeout=0 > binddn="%%CONFIG_ROOT_DN%%" > credentials="%%CONFIG_ROOT_PW%%" > keepalive=0:0:0 > starttls=critical > tls_cert="%%LDAP_SERVER%%/ssl/cert.pem" > tls_key="%%LDAP_SERVER%%/ssl/key.pem" > tls_cacert="%%CA_CHAIN_SERVERS%%" > tls_reqcert=demand > tls_crlcheck=none > filter="(objectclass=*)" > searchbase="cn=config" > scope=sub > attrs="*,+" > schemachecking=off > type=refreshAndPersist > retry="60 +" > olcSyncrepl: rid=002 > provider=%%LDAP_URI_2%% > bindmethod=simple > timeout=0 > network-timeout=0 > binddn="%%CONFIG_ROOT_DN%%" > credentials="%%CONFIG_ROOT_PW%%" > keepalive=0:0:0 > starttls=critical > tls_cert="%%LDAP_SERVER%%/ssl/cert.pem" > tls_key="%%LDAP_SERVER%%/ssl/key.pem" > tls_cacert="%%CA_CHAIN_SERVERS%%" > tls_reqcert=demand > tls_crlcheck=none > filter="(objectclass=*)" > searchbase="cn=config" > scope=sub > attrs="*,+" > schemachecking=off > type=refreshAndPersist > retry="60 +" > - > add: olcMirrorMode > olcMirrorMode: TRUE > Thank you for answering so quick. If I understand correctly, this is a n-way multi master layout for the whole cn=config. Does it mean if I ldapmodify the olcLogLevel on a replica, it will be modified on all other peers as well? So it's not what I was looking for. I was looking for a way to replicate (master -> slave) a sub-portion of the cn=config, namely the cn=schema,cn=config. BTW, olcMirrorMode turns out to be very powerful. In a master slave setup, allows me to ldapmodify slave without incurring in the "err=53 text=shadow context; no update referral". Am I allowed to insert a olcMirrorMode in a slave while using master slave setup? Or am I just exploiting a grey-zone configuration? I am scared to mark as 'mirror' a slave server. It looks wrong. If instead is correct, my problem is solved. thank you, Francesco

10 years, 6 months

slapd-meta

by Fr3ddie

Hello to the list, I'm trying to configure the slapd-meta OpenLDAP backend on an online cn=config configuration with no luck. Slapd version is 2.4.39 (the maximum I can achieve on the target machines building from vanilla source). The documentation is clear but too concise for me so I will try to explain what I'm trying to do to see if there is anybody that can help me. Currently I have 3 slapd servers that share a common root for the DIT, i.e.: dc=loc1,dc=root dc=loc2,dc=root dc=loc3,dc=root What I would like to achieve is to obtain a fourth server that contains the previous trees, along with its own tree, i.e. a server that contains: dc=loc0,dc=root (locally hosted data) dc=loc1,dc=root (coming from the first server, chasing referrals) dc=loc2,dc=root (coming from the second server, chasing referrals) dc=loc3,dc=root (coming from the third server, chasing referrals) this way, all the clients connecting to this server will be able to retrieve data also from the other three remote servers. As far as I understood, I only need to configure the "loc0" server to access the other three servers and get the data to serve to clients. I have already configured the fourth server with its local DIT and this is the configuration: # cat 'cn=config.ldif' dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid structuralObjectClass: olcGlobal creatorsName: cn=config olcServerID: 1 olcThreads: 32 olcToolThreads: 8 olcRequires: LDAPv3 olcConnMaxPendingAuth: 100 olcTLSCACertificateFile: /etc/ssl/certs/my_ca_cert.pem olcTLSCertificateFile: /etc/ssl/certs/this-host_x509_cert.pem olcTLSCertificateKeyFile: /etc/ssl/private/this-host_x509_key.key olcTLSVerifyClient: try olcTimeLimit: 600 olcLogLevel: stats2 sync [...] # cat 'cn=module{0}.ldif' dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}syncprov olcModuleLoad: {2}accesslog structuralObjectClass: olcModuleList [...] Schema files are the following: cn={0}core.ldif cn={1}cosine.ldif cn={2}nis.ldif cn={3}inetorgperson.ldif cn={4}dyngroup.ldif cn={5}kerberos.ldif # cat 'olcDatabase={1}hdb.ldif' dn: olcDatabase={1}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=loc0,dc=root olcAccess: {0}to attrs=userPassword,shadowLastChange,krbPrincipalKey by dn="cn =admin,dc=loc0,dc=root" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=admin,dc=loc0,dc=root" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=loc0,dc=root olcRootPW:: xxxxxxxxxxxxxxxxxxxx olcDbCacheSize: 10000 olcDbCheckpoint: 512 10 olcDbConfig: {0}set_cachesize 0 524288000 1 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE olcDbIDLcacheSize: 30000 olcDbIndex: default pres,eq [...] structuralObjectClass: olcHdbConfig olcSyncrepl: {0}rid=0 provider=ldap://second-host.loc0.root bindmethod=s imple binddn="cn=admin,dc=loc0,dc=root" credentials=xxxxxx searchbase="dc=loc0,dc=root" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObj ect)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syn cdata=accesslog starttls=yes olcMirrorMode: TRUE [...] On top of this DB I have the "syncprov" and the "accesslog" overlays configured (these are two servers in "MirrorMode", configured following the OpenLDAP admin documentation). I believe this DB is the ones containing the actual "loc0" DIT data... Then I have the accesslog DB for the replica (with the syncprov overlay on top): # cat 'olcDatabase={2}hdb.ldif' dn: olcDatabase={2}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=loc0,dc=root olcDbConfig: {0}set_cachesize 0 524288000 1 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart [...] On top of this environment I start loading the needed modules with this LDIF file: version: 1 dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: back_ldap - add: olcModuleLoad olcModuleLoad: back_meta - add: olcModuleLoad olcModuleLoad: rwm and it seems I'm able to load the new modules without errors into the configuration, thus I obtain: # cat 'cn=module{0}.ldif' dn: cn=module{0} structuralObjectClass: olcModuleList objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}syncprov olcModuleLoad: {2}accesslog olcModuleLoad: {3}back_ldap olcModuleLoad: {4}back_meta olcModuleLoad: {5}rwm [...] Now I try to load the slapd-meta directives into a new database using this LDIF: version: 1 dn: olcDatabase={3}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {3}meta olcSuffix: dc=root olcDbURI: "ldap://server-loc1.loc1.root/dc=loc1,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc1,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand olcDbURI: "ldap://server-loc2.loc2.root/dc=loc2,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc2,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand olcDbURI: "ldap://server-loc3.loc3.root/dc=loc3,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc3,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand but I obtain an error that sticks me trying various combinations without success: # ldapadd -Y EXTERNAL -H ldapi:/// -f slapd-META-DB-CREATION.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase={3}meta,cn=config" ldap_add: Object class violation (65) additional info: attribute 'olcDbURI' not allowed and: # tail /var/log/openldap/slapd.log Nov 9 19:47:17 server01 slapd[32392]: conn=1025 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:47:29 server01 slapd[32392]: conn=1052 op=2 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 Nov 9 19:49:47 server01 slapd[32392]: conn=1327 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:52:17 server01 slapd[32392]: conn=1628 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:54:46 server01 slapd[32392]: conn=1929 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:57:07 server01 slapd[32392]: Entry (olcDatabase={3}meta,cn=config), attribute 'olcDbURI' not allowed Into the slapd-meta documentation the "URI" directive is mentioned but the "DbURI" seems to raise a "better error", in fact if I try to modify the above LDIF file using "URI" I obtain: SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase={3}meta,cn=config" ldap_add: Undefined attribute type (17) additional info: olcUri: attribute type undefined Moreover, it is not stated into the slapd-meta docs that the slapd-ldap backend is needed by slapd-meta but, anyway, I think its needed because if I try to load the slapd-meta alone it raises an error (I don't remember exactly which one). At this point I'm stuck to this error and I wasn't able to find any hint on the web to solve this :( The examples I was able to find were related with the static slapd.conf configuration, I counldn't find any "full" configuration example using the cn=config. I'm wondering if I should create a "cn=root" actual DB first and then link the sub-DITs to it, or, maybe, add some other overlay... I really can't understand how it should work :( Can please anybody help me? Thank you very much

9 years

Can't contact LDAP server

by Mark

I have a 2-way multi-master setup on srv1.foo.com (EDT) and srv2.foo.com (PDT). For about 2hrs this morning srv2 was syslog'ing "Can't contact LDAP server" while it was in a replication conversation with srv1: Sep 9 05:29:45 srv2 slapd[9413]: do_syncrep2: rid=001 (-1) Can't contact LDAP server Sep 9 05:29:45 srv2 slapd[9413]: do_syncrepl: rid=001 rc -1 retrying Sep 9 05:30:00 srv2 slapd[9413]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Sep 9 05:30:01 srv2 last message repeated 34 times Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 be_search (0) Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 ... Sep 9 05:30:01 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:01 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 be_modify ... (0) Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 be_search (0) Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 ... Sep 9 05:30:01 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:01 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 be_modify ... (0 ... Sep 9 05:30:29 srv2 slapd[9413]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Sep 9 05:30:29 srv2 slapd[9413]: syncrepl_entry: rid=001 be_search (0) Sep 9 05:30:29 srv2 slapd[9413]: syncrepl_entry: rid=001 ... Sep 9 05:30:29 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:29 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:29 srv2 slapd[9413]: syncrepl_entry: rid=001 be_modify ... (0) Sep 9 05:30:29 srv2 slapd[9413]: do_syncrep2: rid=001 (-1) Can't contact LDAP server Sep 9 05:30:29 srv2 slapd[9413]: do_syncrepl: rid=001 rc -1 retrying Sep 9 05:30:45 srv2 slapd[9413]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Sep 9 05:30:45 srv2 last message repeated 34 times Sep 9 05:30:45 srv2 slapd[9413]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Sep 9 05:30:45 srv2 slapd[9413]: syncrepl_entry: rid=001 be_search (0) Sep 9 05:30:45 srv2 slapd[9413]: syncrepl_entry: rid=001 ... Sep 9 05:30:45 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:45 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:45 srv2 slapd[9413]: syncrepl_entry: rid=001 be_modify ... (0) ... During that time no errors or closes were logged in the srv2 syslog. I tried bouncing each slapd, but the issue continued. After about 2hrs it stopped occurring. My question is: What would cause the "Can't contact LDAP server message"? The srv1 side doesn't log any error or log that the connection was closed. The text "Can't contact" would seem to imply that the error occurred during a connection attempt, but these errors seemed to occur during a active conversation. Does the srv2 side notice an read or write error on the socket and abandon the connection? I've been looking through the code trying to determine what causes that error message. Does it happen on a single read/write error? Does it retry a few times? I hate to just say "Must be a network error" without some due diligence. My env: RHEL 5.5 OpenLDAP 2.4.25 BerkeleyDB 4.8.40 OpenSSL 1.0.0d Cyrus SASL 2.1.23 2-way Multi-master ==================== #srv1 slapd.conf -> slapd.d include /appl/openldap/etc/schema/core.schema include /appl/openldap/etc/schema/cosine.schema include /appl/openldap/etc/schema/nis.schema include /appl/openldap/etc/schema/inetorgperson.schema include /appl/openldap/etc/schema/foo.com.schema argsfile /appl/openldap/var/run/slapd.args pidfile /appl/openldap/var/run/slapd.pid threads 16 tool-threads 4 idletimeout 300 writetimeout 5 reverse-lookup off timelimit time.soft=30 time.hard=300 sizelimit size.soft=500 size.hard=1000 password-hash {SSHA} loglevel stats sync serverid 1 ldap://srv1.foo.com:10806 modulepath /appl/openldap/libexec moduleload back_monitor.la moduleload back_hdb.la moduleload syncprov.la database config rootdn cn=manager,dc=foo,dc=com database monitor rootdn cn=manager,dc=foo,dc=com database hdb rootdn cn=manager,dc=foo,dc=com suffix dc=foo,dc=com directory /appl/openldap/var/data/dc=foo,dc=com cachesize 1000 idlcachesize 3000 cachefree 5 checkpoint 128 15 index objectClass eq index entryCSN eq index entryUUID eq syncrepl rid=001 provider=ldap://srv1.foo.com:10806 type=refreshAndPersist retry="15 +" bindmethod=simple binddn="cn=replicator,dc=foo,dc=com" credentials="secret" searchbase="dc=foo,dc=com" starttls=no schemachecking=off syncrepl rid=002 provider=ldap://srv2.foo.com:10806 type=refreshAndPersist retry="15 +" bindmethod=simple binddn="cn=replicator,dc=foo,dc=com" credentials="secret" searchbase="dc=foo,dc=com" starttls=no schemachecking=off mirrormode TRUE overlay syncprov syncprov-checkpoint 50 10 syncprov-sessionlog 100 limits dn.exact="cn=replicator,dc=foo,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ==================== #srv2 slapd.conf -> slapd.d include /appl/openldap/etc/schema/core.schema include /appl/openldap/etc/schema/cosine.schema include /appl/openldap/etc/schema/nis.schema include /appl/openldap/etc/schema/inetorgperson.schema include /appl/openldap/etc/schema/foo.com.schema argsfile /appl/openldap/var/run/slapd.args pidfile /appl/openldap/var/run/slapd.pid threads 16 tool-threads 4 idletimeout 300 writetimeout 5 reverse-lookup off timelimit time.soft=30 time.hard=300 sizelimit size.soft=500 size.hard=1000 password-hash {SSHA} loglevel stats sync serverid 2 ldap://srv2.foo.com:10806 modulepath /appl/openldap/libexec moduleload back_monitor.la moduleload back_hdb.la moduleload syncprov.la database config rootdn cn=manager,dc=foo,dc=com database monitor rootdn cn=manager,dc=foo,dc=com database hdb rootdn cn=manager,dc=foo,dc=com suffix dc=foo,dc=com directory /appl/openldap/var/data/dc=foo,dc=com cachesize 1000 idlcachesize 3000 cachefree 5 checkpoint 128 15 index objectClass eq index entryCSN eq index entryUUID eq syncrepl rid=001 provider=ldap://srv1.foo.com:10806 type=refreshAndPersist retry="15 +" bindmethod=simple binddn="cn=replicator,dc=foo,dc=com" credentials="secret" searchbase="dc=foo,dc=com" starttls=no schemachecking=off syncrepl rid=002 provider=ldap://srv2.foo.com:10806 type=refreshAndPersist retry="15 +" bindmethod=simple binddn="cn=replicator,dc=foo,dc=com" credentials="secret" searchbase="dc=foo,dc=com" starttls=no schemachecking=off mirrormode TRUE overlay syncprov syncprov-checkpoint 50 10 syncprov-sessionlog 100 limits dn.exact="cn=replicator,dc=foo,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

13 years, 2 months

Re: In case ldap_install_tls fails, should we call ldap_unbind_ext?

by sbose＠redhat.com

Howard Chu wrote: > Simon Pichugin wrote: > > Hello, > > I have a question regarding libldap function ldap_install_tls(). > > > > If it fails, is it the right thing to call ldap_unbind_ext() after that? > Probably. > > > If we call it, does it mean that ldap_install_tls() made a bind? > > > No. > > > Or do we call ldap_install_tls() on the connection that is already > > bound? > That's not the usual way to do things, no. Most likely you should be using > ldap_start_tls() instead. > > > Sorry if the information is available somewhere, but I missed to find > > it. > Most likely ldap_install_tls() should never have been released as a public > API. You can't use it correctly without coordinating with the server, which > ldap_start_tls() already does. I suggest you forget that this function exists. Hi, thanks for the recommendation. We are currently using ldap_install_tls() after calling ldap_init_fd() with a file-descriptor connected to port 636 and a ldaps uri. Can ldap_start_tls() but used in this case as well? I had the assumption that sending the StartTLS exop at this state might confuse the server? Thanks for your help. bye, Sumit > > > The only thing I found is that OpenLDAP server > > calls ldap_unbind_ext() in case of failure but maybe I miss something... > > > > https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/ba... > > > The code you reference is inside an #ifdef block whose comments state that > the feature is unimplemented. > > So again, don't use this function. > > > > Thank you, > > Simon

3 years, 11 months

RE: Issues with resetting user password

by CLARKE, ED C

Hello Quanah, Thank you very much, I will try that and let you know on Monday, I really appreciate it. Have a great weekend all. Thanks, Ed -----Original Message----- From: Quanah Gibson-Mount <quanah(a)symas.com> Sent: Friday, September 18, 2020 4:46 PM To: CLARKE, ED C <ec4397(a)att.com>; openldap-technical(a)openldap.org Subject: RE: Issues with resetting user password --On Friday, September 18, 2020 2:42 PM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > Nothing you've provided shows any attempt to connect to the ldap > server using an SIMPLE BIND with the user DN > "uid=foxdiv,ou=People,dc=att,dc=com" and a password. As an example, the correct way to test the user password change went through would be something like: ldapwhoami -x -H ldap://ldap.example.com:389/ -D uid=foxdiv,ou=People,dc=att,dc=com -W If slapd is running on ldaps, adjust the URI accordingly. If it's on port 389 but requires startTLS, add the -ZZ option, etc. You will be prompted for the password for the LDAP user. If the operation succeeds, then the password was correctly updated in LDAP. It sounds as though you may be attempting *nix <-> ldap integration, but that hasn't been specified. Regardless, the above ldapwhoami command is the next step in confirming whether or not the password was correctly changed and accepted on the user side. If that works, and you're attempting the *nix<->ldap integration and *that* is not working, it would imply that the integration is not configured correctly. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.symas.com&d=DwICAg&… >

4 years, 1 month

Re: syncrepl does not work as expected

by Scott Classen

Hello Kumar, What does the entire olcSyncrepl entry look like on your consumer? There are many options as you can see from the documentation: 5.2.5.8. olcSyncrepl <> olcSyncrepl: rid=<replica ID> provider=ldap[s]://<hostname>[:port] [type=refreshOnly|refreshAndPersist] [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of retries>]+] searchbase=<base DN> [filter=<filter str>] [scope=sub|one|base] [attrs=<attr list>] [attrsonly] [sizelimit=<limit>] [timelimit=<limit>] [schemachecking=on|off] [bindmethod=simple|sasl] [binddn=<DN>] [saslmech=<mech>] [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>] [realm=<realm>] [secprops=<properties>] [starttls=yes|critical] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_crlcheck=none|peer|all] [logbase=<base DN>] [logfilter=<filter str>] [syncdata=default|accesslog|changelog] And unless I missed it in one of your previous responses, I really don’t know the full set of olcSyncrepl parameters you have specified. Scott > On Jun 16, 2020, at 7:31 AM, Kumar Rahul <rahul2002mit(a)gmail.com> wrote: > > Hi Quanah > > Please let me know if you need more information. > > Thanks > Rahul

4 years, 5 months

openldap-technical search results for query "starttls"