Search results for "starttls" - openldap-technical

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, 2 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.

5 years, 12 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

11 years, 7 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

11 years, 7 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, 4 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

5 years, 9 months

Re: ldapi without TLS and ldap with TLS?

by Patrick Lists

Hi Philip, Thank you for your elaborate feedback. Comments inline. On 02/19/2013 03:42 AM, Philip Guenther wrote: [snip] > "We need to protect corporate data in LDAP from being modified or even > accessed by untrusted resources. Yes. [snip] > "Because some of the applications cannot be configured to bind > non-anonymously but they all (except for that one) _can_ be configured > to always use StartTLS and provide a client certificate, we want to > require that all ldap:// connections use the StartTLS operation with a > client cert before performing any LDAP operations that access or modify > data. Yes. Client certificate authentication is used everywhere where possible (for things like corporate web access, email, VPN). > (That's a complete guess and probably not your real reason. Client certs > are just another form of secret which are, IMO, a bigger pain to generate > and manage.) Thankfully the security overlords who came up with this one are also the ones who have to generate and manage the certs :-) [snip] > Well, for starters, the peername.ip="127.0.0.1" clause does *NOT* match > ldapi:// connections. It matches ldap://127.0.0.1/ and ldaps://127.0.0.1/ > connections. I did not try to use ldapi with this setup. I used ldap on 127.0.0.1. Sorry if that was not clear. [snip] > In what way is an ldapi:// connection insecure? It's a UNIX domain socket > for which the data never goes over a physical net and that therefore > cannot be snooped. That's *MORE* secure than a TCP connection secured > with TLS! You can even authenticate it via the uid and gid of the process > that opened the connection! Agreed. The authentication via uid/gid is a nice one I did not know was possible. Will look into that. > Anyway, if you want to permit only > a) read-only ldapi:// connections and > b) ldap:// connections using TLS w/client certs > > then *I think* you can do that with three options in the config: > > # require clients that clients that do TLS provide a client cert > olcTLSVerifyClient: demand > # treat ldapi:// connections as at least as secure as a 256bit cipher > olcLocalSSF: 256 > # require connections to be at least as secure as a 256bit cipher to do > # anything at all (the "ssf=256") clause, and specifically require that > # they be using TLS (and not just ldapi) with 256bit cipher to do updates > olcSecurity: ssf=256 update_tls=256 Your example had me stumped. Upon reading the olcLocalSSF section again I realized I made a mistake. Although it says "Specifies the Security Strength Factor (SSF) to be *given* local LDAP sessions" my mind munched it into "Specifies the Security Strength Factor (SSF) to *require* for local LDAP sessions". Obviously setting it to 0 did not help... Staring at the screen too long I guess. So thanks for making me read the man page again :-) > But I haven't tested it. Works like a charm. [snip] > Yes, an unconditional "require blah" should be taken to be unconditional. Duly noted. Thank you very much for all your help and enlightening comments. Much appreciated. Regards, Patrick

11 years, 8 months

RE: Issues with resetting user password

by Quanah Gibson-Mount

--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: <http://www.symas.com>

4 years, 1 month

Re: Antw: [EXT] Re: STARTTLS vs LDAPS

by Ulrich Windl

>>> Quanah Gibson-Mount <quanah(a)fast-mail.org> schrieb am 31.03.2022 um 17:45 in Nachricht <EAAAB9ABE315CDA6FADC9E00(a)[192.168.1.12]>: > > ‑‑On Thursday, March 31, 2022 9:11 AM +0200 Ulrich Windl > <Ulrich.Windl(a)rz.xn--uniregensburg-dm6g.de> wrote: > >> I think the point was that you can bind even when not having started TLS >> before. > > Correct. > >> I don't know whether this can prevent it: >> olcSecurity: ssf=0 update_ssf=128 simple_bind=64 > > There is no way to prevent a client from sending a BIND request to an > ldap:/// URI with the DN and password in the clear. Even if you set ssf=1 > (server mandates encryption), the most that will happen is that the client > will get disconnected, but the DN and password will already have traveled > over the network in the clear before the client gets disconnected so anyone > sniffing the traffic would have access to it. But honestly, you could get the same when setting up SSL incorrectly (using eNULL or RSA-PSK-NULL-SHA). Also I think if you require an anonymous bind first, the SSF may prevent sending actual user passwords unencrypted; right? Regards, Ulrich > > ‑‑Quanah

2 years, 7 months

MirrorMode, delta syncrepl and memberof issues

by Al

Hi All - I'm having an issue with mirrormode replication (via delta syncrepl) and the memberof overlay. When a group membership is changed on the first node, slapd on the second node is crashing with the following error (as seen from running slapd with -d-1): slapd: memberof.c:1465: memberof_res_modify: Assertion `0' failed. If I disable either memberof or mirrormode, the change replicates correctly. This behavior happens on both bdb and mdb backends. Any thoughts on what that might mean? I am still in development, so I can try pretty much anything at this point - I appreciate any guidance that you can offer. Here are the important details: OpenLDAP 2.4.33 Redhat Linux 6.3 - x64 Server1 and Server2 are using the same configuration, minus the serverid and the syncrepl provider. here is server1's pertinent config: olcServerID: 1 ... olcSyncrepl: rid=000 provider=ldap://server1.xxx.xxx.com:389/ bindme thod=simple timeout=0 network-timeout=0 binddn="cn=ldapreplicator,xxx, xxx,xxx.com" credentials="secret" keepalive=0:0:0 starttls=critical filter="(objectclass=*)" searchbase="xxx.com" logfilter= "(&(objectClass=auditWriteObject)(reqResult=0))" logbase="cn=accesslog" scope =sub schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog olcMirrorMode: TRUE ... olcMemberOfRefInt: FALSE olcMemberOfGroupOC: groupOfUniqueNames olcMemberOfMemberAD: uniquemember Regards, Al

11 years, 10 months

openldap-technical search results for query "starttls"