Search results for "starttls" - openldap-technical

Re: syncrepl and "no equality matching rule"

by Alain ZAMBONI

Hello, >> I run an LDAP directory on 3 servers : one master, and two slaves, >> synchronised with syncrepl. The 3 servers are running FreeBSD 7.0 and >> openLDAP 2.4.13. >> >> I encountered yesterday an issue with syncrepl that should have been >> solved with openLDAP 2.4.13 > > Yeah, I'm pretty sure this has been solved since, as I recall running > into it at one point. The problem just happened again. It it possible that it is only half solved, or that my config present some errors ? slave : oclSyncrpepl: {0}rid=101 provider=ldap://amon.u-strasbg.fr:389 bindmethod=simple timeout=0 network-timeout=0 starttls=no filter="(objectclass=*)" searchbase="o=annuaire" scope=sub schemachecking=off type=refreshAndPersist retry="60 +" master: 18 olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 600 olcSpSessionlog: 1000 It's a very serious problem for me, because when this happens, no other modification is replicated. Is there some config parameter to prevent this blocking ? I plan an upgrade to 2.4.17. I Hope this will help. -- Alain ZAMBONI Direction Informatique Université de Strasbourg

15 years, 10 months

Re: TLS + SSL and openldap

by Dieter Kluenter

Bruno Steven <aspenbr(a)gmail.com> writes: > Hi, > > I am trying configure openldap work with tls , but I have two question about this, first > when I use tls openldap use port 389 and ssl port 639 , is this correct ? > Second How I can test connection between client and server, cryptography is working ? There is no ssl port! SSL (Secure Socket Layer) is a proprietary, licence based protocol, owned by Netscape? I don't know whether the IPR of this protocol have been part of the Netscape/AOL deal. OpenLDAP, and most other network based applications, have implemented Transport Layer Security (TLS), RFC 2246. As a LPI certified professional you should be aware of this. OpenLDAP uses port 639, which has not been assigned by IANA to LDAP(S) protocol, as TLS-enabled port. Port 389 is still required for the LDAP extended operation startTLS (RFC-4513). You may test your TLS session with: openssl s_client -connect localhost:639 -CAfile <file> Unfortunately openssl is not able to initiate a ldap_starttls session on port 389. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°37'09,95"N 10°08'02,42"E

15 years, 6 months

Re: Forcing TLS encryption

by Wiebe Cazemier

----- Original Message ----- > From: "Dieter Klünter" <dieter(a)dkluenter.de> > To: openldap-technical(a)openldap.org > Sent: Thursday, 27 December, 2012 3:53:21 PM > Subject: Re: Forcing TLS encryption > > Am Mon, 24 Dec 2012 10:14:39 +0100 (CET) > schrieb Wiebe Cazemier <wiebe(a)halfgaar.net>: > > > > In order to initiate Transport Layer Security you have to call the > extended operation ldapSTARTTLS. > > -Dieter > > -- > Dieter Klünter | Systemberatung > http://dkluenter.de > GPG Key ID:DA147B05 > 53°37'09,95"N > 10°08'02,42"E > > I understand that, but this way, even when you're forcing TLS, users can still expose their passwords if their computers are mal-configured. SMTP, IMAP, FTP, etc don't allow this, because they reject the connection if LOGINNAME is given before STARTTLS. It's kind of a security issue. Is it because in LDAP, username and password are given as one command, and the server doesn't have the chance to abort at that point? If so, then I guess it's unavoidable.

12 years, 5 months

Re: AW: syncrepl connection / reconnect

by Dieter Kluenter

Thorsten Mueller <Thorsten.Mueller(a)aachen.utimaco.de> writes: > Here you are, the config of the second machine is identical, apart from the > different provider [...] > syncprov-checkpoint 100 10 > > syncprov-sessionlog 100 > > # syncrepl directiv > > syncrepl rid=001 > > provider=ldap://192.168.120.237:388 > > bindmethod=simple > > binddn="cn=Replicator,dc=DatabaseReplication,dc=head" > > credentials="fdet2zS3" > > searchbase="dc=head" > > starttls=critical > > tls_cacert=/etc/TLS/ca-certs/trusted_CAs.pem > > tls_cert=etc/TLS/client/client.pem > > tls_key=etc/TLS/client/client_key.pem > > schemachecking=on > > type=refreshAndPersist > > retry="5 12 60 +" > > mirrormode on [...] order matters, syncrepl has to be declared within a database specification, modules are loaded last, after all database specific configuration parameters. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°37'09,95"N 10°08'02,42"E

15 years, 2 months

Re: olcSecurity: tls=1 and olcLocalSSF= : what value should I use?

by Jean-Francois Malouin

Hi, * Quanah Gibson-Mount <quanah(a)symas.com> [20180906 14:36]: > --On Thursday, September 06, 2018 1:40 PM -0400 Jean-Francois > Malouin <Jean-Francois.Malouin(a)bic.mni.mcgill.ca> wrote: > > >I guess I need to modify either 'olcSecurity: tls=1' in the database > >config or add/insert the proper value for 'olcLocalSSF=' in the > >cn=config. What value should I use in order to still force StartTLS over > >simple binding and allow read/write/modify local access on the ldapi:/// > >listener. > > Hello, > > Just set: > > olcSecurity: ssf=1 > > that will allow either to work as *some* SSF level is then required. > > As long as you have tls=X, then it will always require TLS, > regardless of what the LocalSSF setting is configured to be. Thank you for the pointer! jf > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com>

6 years, 9 months

ldapmodify add olcSyncrepl (okey but not okey)

by lejeczek

hi everyone I'm must be doing something trivially wrong and am hoping someone could help. I'm trying to add second replica: $ ldapmodify -vv -h rider.my.dom:1389 -D "cn=admin,cn=config" -w my.Biotec13 -x ldap_initialize( ldap://rider.my.dom:1389 ) dn: olcDatabase={1}bdb,cn=config changetype: modify add: olcSyncrepl: rid=002 provider=ldap://swir.my.dom:1389 bindmethod=simple timeout=0 network-timeout=0 binddn="uid=replicator,ou=people,dc=my,dc=dom" credentials="lejek9090" keepalive=0:0:0 starttls=no filter="(objectclass=*)" searchbase="dc=my,dc=dom" scope=sub attrs="*,+" schemachecking=off type=refreshOnly interval=00:00:10:00 retry="5 5 300 +" exit code of the above to shell is 0 yet next ldapsearch finds no such new entry exists. At the time of ldapmodify in logs I see: Nov 19 14:40:48 rider slapd[90048]: slap_queue_csn: queueing 0x7f22cc111e00 20181119144048.167126Z#000000#005#000000 Nov 19 14:40:48 rider slapd[90048]: slap_graduate_commit_csn: removing 0x7f22cc111e00 20181119144048.167126Z#000000#005#000000 How to get it work? Many thanks, L.

6 years, 6 months

Chaining

by jeevan kc

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

12 years, 2 months

Openldap Chaining help

by jeevan kc

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

12 years, 2 months

Re: [Q] can I replicate several branches to the same slave from one master?

by Andrew Findlay

On Tue, Jun 27, 2017 at 01:04:38AM -2100, Zeus Panchenko wrote: > Subject: [Q] can I replicate several branches to the same slave from one master? > on master I see: consumer state is newer than provider > on slave: LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform > > so ... what is wrong here? I suspect part of the trouble is that you have two syncrepl clauses using the same search base on the same master. The timestamps are likely to be stored in the same place, causing a clash. One definite error is that all three clauses are labelled 'rid=123'. They should all have different numbers. Try fixing the RIDs - use small numbers, all different. The exact values are not important. Also try commenting out the second syncrepl clause until you have the others working properly. You should be able to merge the first and second clauses as they share a search-base. You may also need to put ACLs on the accesslog database. Andrew > - ---[ master configuration quotation start ]--------------------------- > ... > access to dn.children="dc=example" > by dn.exact="uid=replABC,ou=repl,dc=example" read > by * break > > # syncprov specific indexing > index entryCSN eq > index entryUUID eq > > overlay syncprov > syncprov-checkpoint 50 10 > syncprov-sessionlog 100 > > overlay accesslog > logdb cn=example-accesslog > logops writes > logold (objectclass=*) > index default eq > > ### Accesslog DB > database mdb > maxsize 1073741824 > suffix cn=example-accesslog > rootdn "cn=root,cn=example-accesslog" > rootpw *** > directory "/var/db/openldap-data/example-accesslog" > > index default eq > index entryCSN,objectClass,reqEnd,reqResult,reqStart > > overlay syncprov > syncprov-nopresent TRUE > syncprov-reloadhint TRUE > ... > - ---[ master configuration quotation end ]--------------------------- > > > > - ---[ slave configuration quotation start ]---------------------------- > syncrepl rid=123 > provider=ldap://master.example:389 > starttls=critical > searchbase="dc=example" > bindmethod=simple > binddn="uid=replABC,ou=repl,dc=example" > credentials="***" > filter="(|(&(objectClass=authorizedServiceObject)(objectClass=mailutilsAccount)(authorizedService=mail(a)foo.bar)))" > attrs="cn,entry,entryCSN,entryUUID,o,uid,uidNumber,gidNumber,gecos,homeDirectory,loginShell,userPassword,creatorsName,createTimestamp,modifiersName,modifyTimestamp,mail,rfc822MailMember,sn,authorizedService,mu-mailBox" > tls_cacert=/usr/local/etc/openldap/ssl/ca.crt > tls_cert=/usr/local/etc/openldap/ssl/ABC.crt > tls_key=/usr/local/etc/openldap/ssl/ABC.key > tls_reqcert=try > type=refreshAndPersist > retry="60 +" > logbase="cn=example-accesslog" > logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" > syncdata=accesslog > > syncrepl rid=123 > provider=ldap://master.example:389 > starttls=critical > searchbase="dc=example" > bindmethod=simple > binddn="uid=replABC,ou=repl,dc=example" > credentials="***" > filter="(&(objectClass=authorizedServiceObject)(authorizedService=xmpp(a)foo.bar))" > tls_cacert=/usr/local/etc/openldap/ssl/ca.crt > tls_cert=/usr/local/etc/openldap/ssl/ABC.crt > tls_key=/usr/local/etc/openldap/ssl/ABC.key > tls_reqcert=try > type=refreshAndPersist > retry="60 +" > logbase="cn=example-accesslog" > logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" > syncdata=accesslog > > syncrepl rid=123 > provider=ldap://master.example:389 > starttls=critical > searchbase="ou=ABC,ou=Sendmail,dc=example" > bindmethod=simple > binddn="uid=replABC,ou=repl,dc=example" > credentials="***" > tls_cacert=/usr/local/etc/openldap/ssl/ca.crt > tls_cert=/usr/local/etc/openldap/ssl/ABC.crt > tls_key=/usr/local/etc/openldap/ssl/ABC.key > tls_reqcert=try > type=refreshAndPersist > retry="60 +" > logbase="cn=example-accesslog" > logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" > syncdata=accesslog -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

7 years, 11 months

Re: Spurious Start TLS failed errors on proxyed bind OpenLDAP 2.4.40

by Janne Peltonen

Hi! Thanks for the replies! Howard Chu wrote: >> On the backend, this appears to be the case that a new connection kind of >> overruns the old one; see what happens with connection 6983: > > Looks odd indeed, but doesn't seem related to the other errors. Would need much finer > resolution timestamps to correlate what's going on, unless you know there are no other > active connections on the proxy when this occurred on the backend. Yeah. I don't know for certain, but those are the only connections that would match the dates and the results. > These aren't spurious - your TLS library has genuinely failed to start a session. Which TLS library > are you using? What OS are you running on? The most common cause for periodic failures is > running out of entropy for the PRNG. RHEL 7, and slapd seems to be linked to the Mozilla nss libraries. I called them "spurious" because there doesn't seem to be any correlation between the errors and any external events. But I have to admit I do not understand what kind of activity might cause entropy to be low; I somehow thought it would be a simple case of "more entropy used than the pool has" and then it would be simply caused by too much activity. But these errors seem to come sometimes when the server is more loaded and sometimes when it is less loaded and I haven't found any way to make them more probable. Or less. Anything I can do about this? I mean, if the connection from the proxy to the backend fails because of Start TLS issues, couldn't the proxy just wait a while and try again once some entropy becomes available? Currently, the problems gets propagated back to the client of the OpenLDAP service, which then has to retry a failed connection. Quanah Gibson-Mount wrote: >>> But we seem to be getting spurious Start TLS failed messages also >>> without any competing connections. Here's one using ldap+STARTTLS but no >>> other ACCEPTs anywhere near: >> These aren't spurious - your TLS library has genuinely failed to start a >> session. Which TLS library are you using? What OS are you running on? The >> most common cause for periodic failures is running out of entropy for the >> PRNG. > They noted RHEL7 and 2.4.40, which would mean MozNSS, as the most recent > RHEL7 build of 2.4.44 switched back to OpenSSL. I would just add this to the > many reasons not to use RHEL for OpenLDAP. The fact that they keep switching the TLS libraries they're linking to? I can roll out my own RPMs and keep them linked to the very same library all the time, but do you think linking to OpenSSL could help resolve my issue? Running out of entropy with only a few starttls calls per second, or only a few ldaps connections per second, seems to be a bit weird to me. Anyway, thanks again. --Janne / Helsinki Uni

6 years, 4 months

openldap-technical search results for query "starttls"