Search results for "starttls" - openldap-technical

Re: Spurious Start TLS failed errors on proxyed bind OpenLDAP 2.4.40 [possible cause found]

by Quanah Gibson-Mount

--On Monday, January 28, 2019 6:47 PM +0200 Janne Peltonen <janne.peltonen(a)helsinki.fi> wrote: > Next, we tried Unto Sten's suggestion: we confirmed that the "timeout" > variable is zero, so we go into the "else" branch he mentioned; then > instead of calling the macro in the else branch, we just directly set > tv.sec = 3 and tv.usec = 0 (a quick and dirty hack, I know). After that, > we were no longer able to get any Start TLS failed errors on the proxy, > and all proxy binds were completed succesfully. To make sure, we > downgraded the proxy again, and sure enough, the Start TLS failed > errors reappeared, or rather, we began to have some of them again. > Upgraded again, and no errors at all. > > To us, this really seems as if the root of the problem were that the > starttls timeout ends up being 0.1 seconds, which is too short if > there're any latencies in the network. What would be the correct place > to fix this? It appears to me that you should be able to say "timeout > extended=5" or something similar in a config file, but in > back-ldap/config.c the "extended" timeout option is commented out as > unimplemented. So, what would be required to implement it? > > Relevant files: > > back-ldap/bind.c (ldap_back_start_tls function, setting of tv using > LDAP_BACK_TV_SET macro) > back-ldap/back-ldap.h (defining the LDAP_BACK_TV_SET to basically set > the timeout to 0.1 s) > back-ldap/config.f (definition of timeout_table) Please file an issue report at http://www.openldap.org/its/ so this can be tracked and resolved. Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 years, 9 months

Re: Chaining

by Dieter Klünter

Am Thu, 21 Mar 2013 20:52:37 +0000 schrieb jeevan kc <jeev_biz(a)hotmail.com>: > HelloI've set up a chaining overlay on the slave server. I think I > followed the proper procedures but every time I try to update entries > (delete,add,change)the slave server I get LDAP error code 8 - Strong > Authentication Required. How can I modify entries on the slave > without getting the error? I've openldap 2.4.30 installed on Red Hat > and my configuration is as follows. Any help would be appreciated. > > dn: olcDatabase={0}ldapobjectClass: olcLDAPConfigobjectClass: > olcChainDatabaseolcDatabase: {0}ldapolcDbURI: > "ldap://lap00621.cov.vinex.com"olcDbStartTLS: none > starttls=noolcDbIDAssertBind: mode=self > flags=prescriptive,proxy-authz-non-critical bindm ethod=simple > timeout=0 network-timeout=0 binddn="cn=manager,o=vinex,c=us" > credentials="l4s3rj3t" keepalive=0:0:0olcDbRebindAsUser: > FALSEolcDbChaseReferrals: TRUEolcDbTFSupport: noolcDbProxyWhoAmI: > FALSEolcDbProtocolVersion: 3olcDbSingleConn: FALSEolcDbCancel: > abandonolcDbUseTemporaryConn: FALSEolcDbConnectionPoolMax: > 16olcDbSessionTrackingRequest: FALSEolcDbNoRefs: > FALSEolcDbNoUndefFilter: FALSEstructuralObjectClass: > olcLDAPConfigentryUUID: > df6c7dc4-26a0-1032-829d-b5d50f9d249ecreatorsName: > cn=manager,o=vinex,c=uscreateTimestamp: 20130321182829ZentryCSN: > 20130321182829.558457Z#000000#000#000000modifiersName: > cn=manager,o=vinex,c=usmodifyTimestamp: 20130321182829Z > > dn: olcOverlay={0}chainobjectClass: olcOverlayConfigobjectClass: > olcChainConfigolcOverlay: {0}chainolcChainCacheURI: > FALSEolcChainMaxReferralDepth: 1olcChainReturnError: > TRUEstructuralObjectClass: olcChainConfigentryUUID: > 8a6734ba-2685-1032-8293-b5d50f9d249ecreatorsName: > cn=manager,o=vinex,c=uscreateTimestamp: 20130321151250ZentryCSN: > 20130321151250.505781Z#000000#000#000000modifiersName: > cn=manager,o=vinex,c=usmodifyTimestamp: 20130321151250Z You have to enable tls with propper settings in order to perform a simple bind, or disable security settings. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E

11 years, 7 months

Re: olcAccess replication - error 80 attributes not within database namespace

by Howard Chu

Igor Zinovik wrote: > Hello. > > I'm trying to replicate access rules and limits for one of my databases, but > with no success: > suse:~ # cat olcAccess-syncrepl.ldif > dn: olcDatabase={1}mdb,cn=config > changetype: modify > add: olcSyncrepl > olcSyncrepl: {1}rid=002 > provider=ldap://ldap1.local > bindmethod=simple > binddn="cn=admin,cn=config" > credentials="TopSecret" > searchbase="olcDatabase={1}mdb,cn=config" > attrs="olcAccess,olcLimits" > timeout=3 > network-timeout=0 > starttls=yes > tls_cert="/etc/openldap/ldap.pem" > tls_key="/etc/openldap/ldap.key" > tls_cacert="/etc/ssl/local-ca.pem" > tls_reqcert=demand > tls_crlcheck=none > > > suse:~ # ldapmodify -H ldap://ldap2.local -ZZxWD cn=admin,cn=config -f > olcAccess-syncrepl.ldif > Enter LDAP Password: > modifying entry "olcDatabase={1}mdb,cn=config" > ldap_modify: Other (e.g., implementation specific) error (80) > additional info: Base DN "olcAccess,olcLimits" is not within the > database naming context > slapd-2.4.33 if it matters. The error message is a bit garbled (obviously the Base DN is wrong) but the error is basically correct. You're trying to replicate the wrong thing from the wrong place. Setting a syncrepl consumer on the olcDatabase={1}mdb database lets you replicate the *content* of that database. To replicate the *configuration* of that database your consumer must be set where that configuration is stored. The configuration is stored in olcDatabase={0}config. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

11 years, 6 months

Re: slapo-chain - can't get it working

by Richard A Nelson

On Sat, 17 May 2008, Howard Chu wrote: > Use the example in test018 of the test suite. test018 uses a global chain overlay. Well, using that layout did allow remote updates However, I need this to be database specific as there are several databases being shadowed/cached (from various parts of the company), but only this one is updatable... Why forward requests to the local master when they are doomed to fail ? So, I took the working global chain, and tried to make it database specific - and I'm back to square one (failure): database hdb directory "/var/lib/ldap/cobpli.svl.ibm.com" suffix "dc=cobpli,dc=svl,dc=ibm,dc=com" rootdn "cn=Manager,ou=DSA,dc=cobpli,dc=svl,dc=ibm,dc=com" ... overlay chain chain-uri ldap://ldap-master.cobpli.svl.ibm.com/ chain-idassert-bind bindmethod=simple binddn="cn=Manager,ou=DSA,dc=cobpli,dc=svl,dc=ibm,dc=com" credentials=<password> mode=self ... syncrepl rid=1 provider=ldap://ldap-master.cobpli.svl.ibm.com/ starttls=no binddn="cn=Replicator,ou=DSA,dc=cobpli,dc=svl,dc=ibm,dc=com" bindmethod=simple credentials=<password> searchbase="dc=cobpli,dc=svl,dc=ibm,dc=com" schemaChecking=off type=refreshAndPersist retry="10 10 300 +" updateref ldap://ldap-master.cobpli.svl.ibm.com/ > If you're looking at docs that aren't from OpenLDAP.org they're most likely > wrong or at least out of date. There are a few notable exceptions (symas.com > / connexitor.com tend to be pretty good as well ;) :) -- Rick Nelson <StevenK> You're rewriting parts of Quake in *Python*? <knghtbrd> MUAHAHAHA

16 years, 6 months

Consumer Delta Sync Lost After Provider Restarted

by thomaswilliampritchard＠gmail.com

Hi, I'm experiencing an issue between my 3 providers and multiple consumer setup and delta sync repl. We manage a primary, or active, provider and send all writes to the primary as long as it's healthy letting the two others replicate and be standby providers ready to take over in the event of a failure. All consumers replicate from all providers and all providers replicate from all providers. After the system was running healthily for over a week a standby provider was restarted. This caused my consumers to re-establish the persistent sync connection. Upon re-establishing the connection, some consumers began a sync refresh with the following message. Jun 28 18:32:55 openldap-hdb-consumer slapd[15746]: do_syncrep1: rid=003 starting refresh (sending cookie=rid=003,csn=20210331192036.214412Z#000000#000#000000;20210119225955.133811Z#000000#001#000000;20210128213906.596429Z#000000#002#000000;20210226190704.219043Z#000000#005#000000;20210412181659.152626Z#000000#065#000000;20210610231714.990702Z#000000#066#000000;20210614191744.122968Z#000000#44d#000000;20210412175600.595586Z#000000#835#000000;20210423182110.684843Z#000000#836#000000;20210331193249.570935Z#000000#ce5#000000) Jun 28 18:32:55 openldap-hdb-consumer slapd[15746]: do_syncrep2: rid=003 LDAP_RES_SEARCH_RESULT Jun 28 18:32:55 openldap-hdb-consumer slapd[15746]: do_syncrep2: rid=003 delta-sync lost sync, switching to REFRESH Jun 28 18:32:55 openldap-hdb-consumer slapd[15746]: do_syncrep2: rid=003 (4096) Content Sync Refresh Required This was re-establishing a connection with rid=003 which is "20210412175600.595586Z#000000#835#000000" (a standby system) however we have only been sending writes to server #44d# (the primary provider). We see 44d CSN is over 7 days old, beyond our providers access log period. On the consumer that did not trigger sync refresh we see Jun 28 18:32:55 openldap-hdb-consumer slapd[24439]: do_syncrep1: rid=003 starting refresh (sending cookie=rid=003,csn=20210331192036.214412Z#000000#000#000000;20210119225955.133811Z#000000#001#000000;20210128213906.596429Z#000000#002#000000;20210226190704.219043Z#000000#005#000000;20210412181659.152626Z#000000#065#000000;20210621212459.620195Z#000000#066#000000;20210621214400.407867Z#000000#44d#000000;20210412175600.595586Z#000000#835#000000;20210423182110.684843Z#000000#836#000000;20210331193249.570935Z#000000#ce5#000000) Here we see 20210621214400.407867Z#000000#44d#000000 is much more recent and did not trigger a full resync, although it is close to the 7 day threshold at this point. We notice the rid=003 835 csn is the same as the consumer experiencing the problem which makes me believe the #44d# csn being old is what causes this sync refresh. I am concerned why when the standby provider is restarted the connection is getting re-established with old provider CSNs, when I search the CSNs on the consumers they look newer than the ones used to reestablish the connection. If we restart slapd on the providers after running consumers for 7 days it seems like it will trigger a sync refresh. How can we make the consumers re-establish the connection with the most recent CSN? Replication is working as expected, just the CSNs seem to remain old in this connection message. The sync refresh behavior causes a large load on the consumers and providers spiking bind times and degrading service making this concerning for our production environment. Configuration details are below. Your insights are appreciated. @(#) $OpenLDAP: slapd 2.4.56 (Dec 14 2020 17:31:23) $ @57af0b7ce0ba:/root/rpmbuild/BUILD/openldap-2.4.56/openldap-2.4.56/servers/slapd Provider config Primary DB # {2}mdb, config dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/lib/ldap ... olcSizeLimit: unlimited olcSyncrepl: {0}rid=1 provider=ldap://10.20.0.4 bindmethod=simple binddn ="cn=replicant,dc=example,dc=com" credentials="" searchbase="dc=example,dc=com" schemachecking=on type=refresh AndPersist retry="5 10 60 +" sizelimit=unlimited timelimit=unlimited starttls=critical tls_reqcert=demand logbase="cn=accesslog" logfilter=" (&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {1}rid=2 provider=ldap://10.20.1.151 bindmethod=simple bind dn="cn=replicant,dc=example,dc=com" credentials="" searchbase="dc=example,dc=com" schemachecking=on type=refre shAndPersist retry="5 10 60 +" sizelimit=unlimited timelimit=unlimited starttls=critical tls_reqcert=demand logbase="cn=accesslog" logfilter ="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {2}rid=3 provider=ldap://10.20.2.240 bindmethod=simple bind dn="cn=replicant,dc=example,dc=com" credentials="" searchbase="dc=example,dc=com" schemachecking=on type=refre shAndPersist retry="5 10 60 +" sizelimit=unlimited timelimit=unlimited starttls=critical tls_reqcert=demand logbase="cn=accesslog" logfilter ="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcMirrorMode: TRUE ... olcDbMaxSize: 15000000000 Sync Prov # {1}syncprov, {2}mdb, config dn: olcOverlay={1}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpCheckpoint: 1 1 Access Log # {3}accesslog, {2}mdb, config dn: olcOverlay={3}accesslog,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {3}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE # {3}mdb, config dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {3}mdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=example,dc=com olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart olcDbMaxSize: 15000000000 # {0}syncprov, {3}mdb, config dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE Consumer Config: # {2}hdb, config dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcRootDN: cn=admin,dc=example,dc=com olcRootPW: {SSHA} olcSyncrepl: {0}rid=1 provider=ldap://10.20.0.4 bindmethod=simple binddn ="cn=replicant,dc=example,dc=com" credentials="" searchbase="dc=example,dc=com" schemachecking=on type=refresh AndPersist retry="60 +" sizelimit=unlimited timelimit=unlimited start tls=critical tls_reqcert=demand logbase="cn=accesslog" logfilter="(&(ob jectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {1}rid=2 provider=ldap://10.20.1.151 bindmethod=simple bind dn="cn=replicant,dc=example,dc=com" credentials="" searchbase="dc=example,dc=com" schemachecking=on type=refre shAndPersist retry="60 +" sizelimit=unlimited timelimit=unlimited sta rttls=critical tls_reqcert=demand logbase="cn=accesslog" logfilter="(&( objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {2}rid=3 provider=ldap://10.20.2.240 bindmethod=simple bind dn="cn=replicant,dc=example,dc=com" credentials="" searchbase="dc=example,dc=com" schemachecking=on type=refre shAndPersist retry="60 +" sizelimit=unlimited timelimit=unlimited sta rttls=critical tls_reqcert=demand logbase="cn=accesslog" logfilter="(&( objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcDbCheckpoint: 102400 10

3 years, 4 months

Ldap is up, trying to get tls working.

by John Tobin

Folks, I have openldap up, it supports vsftpd, sshd, and 5 client linux machines for remote login. I would like to get tls working. I would support either ldaps [port 636], or the tls available on port 389, I am aware of the differences in implementation, and the fact that an administrator effectively has to make a decision to support one or the other in most cases. Currently: I have slapd running configured for tls under ldap [std port 389]. I am testing it on the slapd machine, with a client on the same machine. I am pointing to the same cacertificate in slapd.d [cn=config.ldif] and ldap.conf. With that in place, and the ldap.conf below: nightmare:/etc # cat ldap.conf base dc=dark,dc=net uri ldap://nightmare.dark.net # scope sub # binddn "cn=admin,dc=dark,dc=net" # bindpw jackie bind_policy soft # The user ID attribute (defaults to uid) pam_login_attribute uid pam_lookup_policy yes pam_password exop nss_schema rfc2307bis tls_reqcert never pam_filter objectClass=posixAccount ldap_version 3 nss_map_attribute uniqueMember uniqueMember ssl start_tls tls_cacert /var/lib/ldap/cacert.pem tls_cert /var/lib/server.crt tls_key /var/lib/ldap/server.key I have run ldapsearch: nightmare:/media # ldapsearch -v -x -H ldap://nightmare.dark.net:389/ -b "dc=dark,dc=net" -Z ldap_initialize( ldap://nightmare.dark.net:389/??base ) filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base <dc=dark,dc=net> with scope subtree # filter: (objectclass=*) # requesting: ALL # # dark.net dn: dc=dark,dc=net dc: dark o: dark objectClass: organization objectClass: dcObject # admin, dark.net dn: cn=admin,dc=dark,dc=net objectClass: organizationalRole cn: admin # Default Policy, dark.net dn: cn=Default Policy,dc=dark,dc=net objectClass: namedObject objectClass: pwdPolicy cn: Default Policy # People, dark.net dn: ou=People,dc=dark,dc=net objectClass: organizationalUnit ou: People description: People is used in mapping the /etc/passwd entries # jtobin, People, dark.net dn: uid=jtobin,ou=People,dc=dark,dc=net uid: jtobin cn: John C. Tobin objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount loginShell: /bin/ksh uidNumber: 5000 gidNumber: 100 homeDirectory: /home/jtobin gecos: John C. Tobin # defaultDNS, dark.net dn: cn=defaultDNS,dc=dark,dc=net cn: defaultDNS objectClass: top objectClass: suseDnsConfiguration suseDefaultBase: ou=DNS,dc=dark,dc=net # DNS, dark.net dn: ou=DNS,dc=dark,dc=net objectClass: top objectClass: organizationalUnit ou: DNS # search result search: 3 result: 0 Success # numResponses: 8 # numEntries: 7 nightmare:~ # ##### So I am assuming the ldapserver on ldap://nightmare.dark.net:389/ with tls works. [I looked through the message output in /var/log/message and see the ³STARTTLS² and ³TLS established tls_ssf=256²] I have done a number of similar ldapsearches. This appears to work correctly. On the client machine I now do : nightmare:/media # su - jtobin su: user jtobin does not exist nightmare:/media # /var/log/message - output...... nightmare:/var/log # tail f |grep I tls Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 op=0 STARTTLS Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls failed:stat=-1 Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept failure error=-1 id=1217, closing Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 fd=14 closed (TLS negotiation failure) Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 op=0 STARTTLS Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls failed:stat=-1 Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept failure error=-1 id=1218, closing Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 fd=14 closed (TLS negotiation failure) [if you want more of the log, I can obviously get it, but these appear to be the important parts.] This is probably a configuration error, or a logical / architecture misunderstanding, ok, I m a newbie. Do I have certificates incorrectly generated? [certificates were generated via http://www.openldap.org/faq/data/cache/185.html]. What did I do wrong? This is running openldap 2.4.26 off of Suse 12.1 milestone 5. Thanks in advance. tob

13 years

RE24 testing call (2.4.48) LMDB RE0.9 testing call (0.9.24)

by Quanah Gibson-Mount

This is expected to be the only testing call for 2.4.48, with an anticipated release, depending on feedback, during the week of 2019/07/22. Specific to this release, it would be helpful if anyone using back-ldap or back-meta with TLS can confirm their existing configurations continue to work (Due to the changes related to ITS#8427). Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> Configure & build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.4.48 Engineering Added libldap OpenSSL Elliptic Curve support (ITS#7595) Added libldap Expose OpenLDAP specific interfaces via openldap.h (ITS#8671) Added slapd-monitor support for slapd-mdb (ITS#7770) Fixed liblber leaks (ITS#8727) Fixed liblber with partial flush (ITS#8864) Fixed libldap ASYNC TLS so it works (ITS#8957,ITS#8980) Fixed libldap ASYNC connections with Solaris 10 (ITS#8968) Fixed libldap with SASL_NOCANON=on and ldapi connections (ITS#7585) Fixed libldap to use AI_ADDRCONFIG when available (ITS#7326) Fixed libldap to be able to unset syncrepl TLS options (ITS#7042) Fixed libldap race condition in ldap_int_initialize (ITS#7996, ITS#8450) Fixed libldap return code in ldap_create_assertion_control_value (ITS#8674) Fixed libldap to correctly disable IPv6 when configured to do so (ITS#8754) Fixed libldap to correctly close TLS connection (ITS#8755) Fixed libldap_r handling of deprecated OpenSSL function (ITS#8353) Fixed liblunicode case correspondance (ITS#8508) Fixed slapd with an idletimeout of less than four seconds (ITS#8952) Fixed slapd config parser variable for Windows64 (ITS#9012) Fixed slapd syncrepl fallback handling with delta-syncrepl (ITS#9015) Fixed slapd telephoneNumberNormalize, cert DN validation (ITS#8999) Fixed slapd syncrepl for relax with delta-syncrepl (ITS#8037) Fixed slapd TLS settings on reconnection (ITS#8427) Fixed slapd to restrict rootDN proxyauthz to its own databases (ITS#9038) Fixed slapd to initialize SASL SSF per connection (ITS#9052) Fixed slapo-accesslog with SLAP_MOD_SOFT modifications (ITS#8990) Fixed slapd-ldap starttls connections timeout behavior (ITS#8963) Fixed slapd-ldap TLS settings on reconnection (ITS#8427) Fixed slapd-ldap segfault when entry result doesn't match filter (ITS#8997) Fixed slapd-meta conversion from slapd.conf to cn=config (ITS#8743) Fixed slapd-meta TLS settings on reconnection (ITS#8427) Fixed slapd-meta assertion when network interface goes down (ITS#8841) Fixed slapd-mdb fix bitshift integer overflow (ITS#8989) Fixed slapd-mdb index cleanup with cn=config (ITS#8472) Fixed slapd-mdb to improve performance with alias deref (ITS#7657) Fixed slapo-accesslog possible assert with exops (ITS#8971) Fixed slapo-chain to correctly reject multiple chaining URIs (ITS#8637) Fixed slapo-chain conversion from slapd.conf to cn=config (ITS#8799) Fixed slapo-memberof conversion from slapd.conf to cn=config (ITS#8663) Fixed slapo-memberof for group name change to itself (ITS#9000) Fixed slapo-ppolicy behavior when pwdInHistory is changed (ITS#8349) Fixed slapo-rwm to not free original filter (ITS#8964) Fixed slapo-syncprov contextCSN generation (ITS#9015) Build Environment Fixed slapd to only link to BDB libraries with static build (ITS#8948) Fixed libldap implicit declaration with LDAP_CONNECTIONLESS (ITS#8794) Fixed libldap double inclusion of limits.h in cyrus.c (ITS#9041) Documentation General - Fixed minor typos (ITS#8764, ITS#8761) admin24 - Miscellaneous updates promoting mdb and fixing examples (ITS#9031) slapd.access(5) - Note MDB is the primary backend (ITS#8881) slapd.backends(5) - Note MDB is the recommended backend (ITS#8771) slapd-ldap(5) - Document starttls parameter (ITS#8693) Contrib Added slapo-lastbind capability to forward authTimestamp updates (ITS#7721) LMDB 0.9.24 Engineering ITS#8969 Tweak mdb_page_split ITS#8975 WIN32 fix writemap set_mapsize crash ITS#9007 Fix loose pages in WRITEMAP Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 years, 4 months

OpenLDAP crash when defining multiple olcDbURI for chaining

by Khosrow Ebrahimpour

Hello list, I am trying to setup referral chaining in a multi-master setup. I can setup chaining to one of the masters without any problems. And I can perform a MOD operation that is then referral chased and performed on the master. However, when I define both masters the replica crashes when I do a MOD operation. Snippet of cn=config from the working example: dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbStartTLS: start starttls=yes olcDbIDAssertAuthzFrom: {0}* olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbURI: ldap://ldap-m1.example.com 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 starttls=yes tls_reqcert=allow If I change olcDbURI to either of the entries below, the replica server crashes * olcDbURI: "ldap://ldap-m1.example.com,ldap://ldap-m2.example.com" * olcDbURI: "ldap://ldap-m1.example.com ldap://ldap-m2.example.com" According to slapd-ldap(5), the URI list can be comma or space separated. I've turned on "args" and "trace" debugging to troubleshoot, but never get any errors in the logs. I only see an attempt to chase the referral followed by an immediate crash (see log snippet at the end of email). Finally, I'm running OpenLDAP 2.4.31 on Ubuntu Trusty, but was also able to replicate this same error on OpenLDAP 2.4.28 on Ubuntu Precise. Any help is much appreciated. -- Khosrow Ebrahimpour Crash Log: Sep 8 21:07:23 ldap-rep1 slapd[20947]: conn=1000 op=1 modifications: Sep 8 21:07:23 ldap-rep1 slapd[20947]: replace: givenName Sep 8 21:07:23 ldap-rep1 slapd[20947]: one value, length 1 Sep 8 21:07:23 ldap-rep1 slapd[20947]: conn=1000 op=1 MOD dn="uid=user1,ou=people,dc=example,dc=com" Sep 8 21:07:23 ldap-rep1 slapd[20947]: conn=1000 op=1 MOD attr=givenName Sep 8 21:07:23 ldap-rep1 slapd[20947]: bdb_dn2entry("uid=user1,ou=people,dc=example,dc=com") Sep 8 21:07:23 ldap-rep1 slapd[20947]: => hdb_dn2id("ou=people,dc=example,dc=com") Sep 8 21:07:23 ldap-rep1 slapd[20947]: <= hdb_dn2id: got id=0x6 Sep 8 21:07:23 ldap-rep1 slapd[20947]: => hdb_dn2id("uid=user1,ou=people,dc=example,dc=com") Sep 8 21:07:23 ldap-rep1 slapd[20947]: <= hdb_dn2id: got id=0xe Sep 8 21:07:23 ldap-rep1 slapd[20947]: entry_decode: "" Sep 8 21:07:23 ldap-rep1 slapd[20947]: <= entry_decode() Sep 8 21:07:23 ldap-rep1 slapd[20947]: send_ldap_result: conn=1000 op=1 p=3 Sep 8 21:07:23 ldap-rep1 slapd[20947]: send_ldap_result: err=10 matched="" text="" Sep 8 21:07:23 ldap-rep1 slapd[20947]: send_ldap_result: referral="ldap://ldap-m1.example.com/uid=user1,ou=people,dc=example,dc=com" Sep 8 21:07:23 ldap-rep1 slapd[20947]: >>> dnPrettyNormal: <uid=user1,ou=people,dc=example,dc=com> Sep 8 21:07:23 ldap-rep1 slapd[20947]: <<< dnPrettyNormal: <uid=user1,ou=people,dc=example,dc=com>, <uid=user1,ou=people,dc=example,dc=com> Sep 8 21:07:23 ldap-rep1 slapd[20947]: conn=1000 op=1 ldap_chain_op: ref="ldap://ldap-m1.example.com/uid=user1,ou=people,dc=example,dc=com" -> "ldap://ldap-m1.example.com" Sep 8 21:09:02 ldap-rep1 slapd[21057]: @(#) $OpenLDAP: slapd (Ubuntu) (Mar 17 2014 21:20:08) $ buildd@aatxe:/build/buildd/openldap-2.4.31/debian/build/servers/slapd

10 years, 2 months

Re: STARTTLS vs LDAPS

by Braiam

On Thu, Mar 31, 2022 at 5:40 AM Norman Gray <gray(a)nxg.name> wrote: > > Quanah and all, hello. > > On 30 Mar 2022, at 18:54, Quanah Gibson-Mount wrote: > > > --On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania < > stefan(a)kania-online.de> wrote: > > > >> That's what can be found in the FAQ on openldap.org: > >> > >> https://www.openldap.org/faq/data/cache/605.html > >> > >> I would trust this more then any rumors on any stackxxxx page ;) > > > > Unfortunately, the FAQ is dead weight we want to kill and not > maintained in any way, shape, or form. It's currently provided for > historical purposes. > > Since the copyright dates at the bottom of that page are '1998-2013', so > that the content of the site is now nearly a decade out of date, I feel the > FAQ-o-matic now has negative utility, and that you should give in to the > urge to kill it. > > I respect and applaud the desire to preserve the content for historical > reasons, but surely that goal can be served by making a tarball of the > content available at whatever page https://www.openldap.org/faq/.../* > were to redirect to (ie, the pages shouldn't be 404-ed, but neither should > they be 200; 301 is good). > > I have previously (indeed recently) looked at that page and, without > thinking much about the question, taken its deprecation of LDAPS as current > doctrine. > > And.... ah, FAQ-o-matic I have fond memories of FAQ-o-matics, back when > wikis were new... > > Best wishes, > > Norman > > > -- > Norman Gray : https://nxg.me.uk > What would be the process to modify content on the openldap.org page? -- Braiam

2 years, 7 months

Re: help with openldap-2.4.29-sasl-2.1.25 bind problems

by Dan White

On 03/04/12 15:04 +0000, luxInteg wrote: >Greetings, > >i am new to this list. I have a computer with these:- >cpu: amd64 2 cores >os linux 64bit distro=cblfs kernel-3.2.1, gcc-4.5.2 >auth progs: MIT-kerberos-1.10, sasl-2.1.25. openldap-2.4.29 > >( I have an inhouse CA and generated a signed Certicate/Key pair on this >machine running openssl-0.9.8 I transferred these and the cacert.pem file >securely to the machine above and these are included in the slapd.conf file ) > >I verified ldap is running without sasl with the ldapsearch command like >so:- >ldapsearch -xWLLL "ou=people" -H ldaps://tester.example.com > >When I tried the same command for a sasl bind:- >ldappsearch -LLL "ou=people" -H ldaps://tester.example.com > >I get this >################################################### >SASL/GSSAPI authentication started >ldap_sasl_interactive_bind_s: Invalid credentials (49) > additional info: SASL(-13): authentication failure: GSSAPI Failure: >gss_accept_sec_context >################################################### Check your kdc logs. Research what 'gss_accept_sec_context' and 'res_matched' mean, since those appear to be errors returned from your krb5 library. Make sure you are not hitting this bug in cyrus sasl: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3480 One way to determine if you are, is to perform your gssapi bind without ldaps or starttls-over-ldap. >-------------- >read1msg: ld 0x2018010 0 new referrals >read1msg: mark request completed, ld 0x2018010 msgid 1 >request done: ld 0x2018010 msgid 1 >res_errno: 49, res_error: <SASL(-13): authentication failure: GSSAPI Failure: >gss_accept_sec_context>, res_matched: <> >ldap_free_request (origid 1, msgid 1) >ldap_int_sasl_bind: <null> >ldap_parse_sasl_bind_result >ber_scanf fmt ({eAA) ber: >ber_dump: buf=0x20eb750 ptr=0x20eb753 end=0x20eb7a5 len=82 >-------------- -- Dan White

12 years, 8 months

openldap-technical search results for query "starttls"