Search results for "starttls" - openldap-technical

Re: Syncrepl SSL fail

by Hugo Deprez

Hello, On the provider I have the following settings : TLSCACertificateFile /etc/ssl/certs/ldap-cert.pem TLSCertificateFile /etc/ssl/certs/ldap-cert.pem TLSCertificateKeyFile /etc/ldap/ssl/ldap-key.pem but no TLSCipherSuite defined. I added the starttls=yes on the consumer : Syncrepl rid=003 provider=ldaps://ldap.mydomain.fr:1024/ type=refreshOnly retry="60 10 600 +" interval=00:00:00:10 searchbase="dc=mydomain,dc=fr" scope=sub schemachecking=on bindmethod=simple starttls=yes tls_cert=/etc/ssl/certs/ldap-cert.pem tls_cacert=/etc/ssl/certs/ldap-cert-ca.pem binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr" credentials=my_password But still the same error. Any idea ? Hugo On 14 October 2011 13:52, Olivier Guillard <olivier(a)guillard.nom.fr> wrote: > Hi, > > Have you set up the follwing appropriately : > > TLSCertificateFile > TLSCertificateKeyFile > TLSCipherSuite > > On the provider ? > > You probably also want to set this up correctly in > your syncrepl section : > > starttls=yes > tls_cacert=/path/to/certificate > > I suspect better if TLS_CACERT is also properly > set up in both ldap server slapd config. > > --- > Olivier > > On Thu, Oct 13, 2011 at 6:38 PM, Hugo Deprez <hugo.deprez(a)gmail.com> wrote: >> Dear community, >> >> I setup a syncrepl between my master openldap server and a consumer. >> >> I am trying to use SSL for this syncrepl >> I got the following error in the log when I start slapd on the consumer : >> >> Oct 13 17:04:59 server slapd[16905]: slapd starting >> Oct 13 17:04:59 server slapd[16905]: slap_client_connect: >> URI=ldaps://ldap.mydomain.fr:1024/ >> DN="cn=syncrepluser,o=others,dc=mydomain,dc=fr" ldap_sasl_bind_s >> failed (-1) >> Oct 13 17:04:59 server slapd[16905]: do_syncrepl: rid=003 rc -1 >> retrying (9 retries left) >> >> >> I don't understand why it is failing as a single ldapsearch from the >> same server with the syncrepl user is working. >> >> here is my syncrepl configuration : >> >> Syncrepl rid=003 >> provider=ldaps://ldap.mydomain.fr:1024/ >> type=refreshOnly >> retry="60 10 600 +" >> interval=00:00:00:10 >> searchbase="dc=mydomain,dc=fr" >> scope=sub >> schemachecking=on >> bindmethod=simple >> binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr" >> credentials=my_password >> >> >> Any idea ? >> >> Regards, >> >> Hugo >> >> >

14 years, 10 months

RE: [EXTERNAL] Re: back-ldap and ldaps not working

by Jon C Kidder

Yeah, that's actually how I started and where the starttls=no setting came from. This .conf section overlay chain chain-uri "ldaps://ds2-q.global.aep.com" chain-rebind-as-user TRUE chain-idassert-bind bindmethod=simple binddn="cn=syncuser,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com" credentials=<redacted> mode="self" chain-tls ldaps tls_cacert=/appl/openldap/etc/openldap/tls/cacerts.cer chain-return-error TRUE becomes this ldap backend when using slaptest # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 bdc4cf96 dn: olcDatabase={1}ldap objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: "ldaps://ds2-q.global.aep.com" olcDbStartTLS: ldaps starttls=no tls_cacert="/appl/openldap/etc/openldap/tl s/cacerts.cer" tls_reqcert=demand tls_crlcheck=none olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bin dmethod=simple timeout=0 network-timeout=0 binddn="cn=syncuser,ou=automaton s,ou=users,dc=global,dc=aep,dc=com" credentials=<redacted> keepalive=0:0:0 olcDbRebindAsUser: TRUE 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 structuralObjectClass: olcLDAPConfig entryUUID: 7b1cc741-120e-4ce2-b539-17791a361cb1 creatorsName: cn=config createTimestamp: 20170707202053Z entryCSN: 20170707202053.340477Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20170707202053Z I guess it's time to start diving into the source. -Jon -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@symas.com] Sent: Friday, July 07, 2017 3:45 PM To: Jon C Kidder; openldap-technical(a)OpenLDAP.org Subject: RE: [EXTERNAL] Re: back-ldap and ldaps not working --On Friday, July 07, 2017 8:10 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > I've removed the starttls=no syntax and the line now reads. > > olcDbStartTLS: ldaps > tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer " > tls_reqcert=demand tls_crlcheck=none > > I have verified the change propagated to the configuration directory and > restarted the instance. I saw no errors during configuration parsing in > the log. I am still seeing this error when the chain overlay tries to > follow the referral but no complaints when syncrepl connects. I'm not sure how you do this with cn=config. With slapd.conf, it would be done via using "chain-tls" and not "tls", as per the man page: There are very few chain overlay specific directives; however, directives related to the instances of the ldap backend that may be implicitly instantiated by the overlay may assume a special meaning when used in conjunction with this overlay. They are described in slapd-ldap(5), and they also need to be prefixed by chain-. It may be worthwhile to set up a slapd.conf where "chain-tls" is specified, and see what happens with that on conversion. --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&… >

9 years, 1 month

right order mmr-main-DB combined with mmr cn=config

by Stefan Kania

Hello, I'm still working on replication of cn=config. The replication of the main DB is working with delta-syncrepl but I still have problems getting mmr running for cn=config. As I use Ansible to configure it here my question: Is the order of setting up the replication relevant? What I do at the moment: Setting up a basic config for all 4 servers: ----------------------------------------- dn: cn=config objectClass: olcGlobal cn: config olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/symas/run/slapd.pid olcArgsFile: /var/symas/run/slapd.args olcToolThreads: 1 olcServerID: 1 ldap://ldap01.example.net olcServerID: 2 ldap://ldap02.example.net olcServerID: 3 ldap://ldap03.example.net olcServerID: 4 ldap://ldap04.example.net # create cn=config #dn: olcBackend={0}mdb,cn=config #objectClass: olcBackendConfig #olcBackend: {0}mdb dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /opt/symas/lib/openldap olcModuleLoad: back_mdb olcModuleLoad: back_monitor olcModuleLoad: autoca.la olcModuleLoad: otp.la olcModuleLoad: argon2.la olcModuleLoad: syncprov olcModuleLoad: back_monitor olcModuleLoad: accesslog.la include: file:///opt/symas/etc/openldap/schema/core.ldif include: file:///opt/symas/etc/openldap/schema/cosine.ldif include: file:///opt/symas/etc/openldap/schema/nis.ldif include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif include: file:///opt/symas/etc/openldap/schema/dyngroup.ldif include: file:///opt/symas/etc/openldap/schema/kerberos.openldap.ldif dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcSizeLimit: 500 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcPasswordHash: {ARGON2} dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by * break dn: olcDatabase={1}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to dn.subtree="cn=monitor" by dn.exact=cn=admin,cn=config read by dn.exact=cn=admin,dc=example,dc=net read dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcmdbConfig olcDatabase: {2}mdb olcSuffix: dc=example,dc=net olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcSizeLimit: unlimited olcTimeLimit: unlimited olcDbCheckpoint: 512 30 olcDbDirectory: /var/symas/openldap-data olcDbIndex: default eq olcDbIndex: objectClass olcDbIndex: entryUUID olcDbIndex: entryCSN olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: mail pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: description pres,eq,sub olcDbIndex: title pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbMaxSize: 85899345920 olcAccess: {0} to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcAccess: {3} to attrs=userPassword by anonymous auth by self write by * none olcLimits: {0} dn.exact="uid=repl-user,ou=users,dc=example,dc=net" time=unlimited size=unlimited olcLimits: {1} dn.exact="uid=ldap-admin,ou=users,dc=example,dc=net" time=unlimited size=unlimited ----------------------------------------- As you can see serverID is already set to URL-style for all servers ;-) But now I'm not sure, do I have to set up the replication for cn=config on all 4 servers and then set up replication of the main DB on just one of the servers and let it be replicated by the cn=config-replication? Or do I have to set up replication of the main DB on all servers first and then add the replication of cn=config to all servers and only replicate the changes made afterwards? Or do I have to set up the replication of main-DB and replication of cn=config on one server at a time? Or can I do it either way? The testsuit is showing using updateref on the replication of the main-DB do I really need it for mmr? If yes, do I need it for mmr of cn=config? I could not find any example that uses both, mmr for main-DB and mmr for cn=config. here is the order of my set up for cn=config replication: ------------------------ dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=1 provider=ldap://ldap01.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow olcSyncRepl: rid=2 provider=ldap://ldap02.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow olcSyncRepl: rid=3 provider=ldap://ldap03.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow olcSyncRepl: rid=4 provider=ldap://ldap04.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow - add: olcMultiprovider olcMultiprovider: TRUE ------------------------ And last but not least the set up of the main-DB replication: ----------------------- dn: olcDatabase={2}mdb,cn=config changetype: modify replace: olcSyncrepl olcSyncrepl: rid=102 provider=ldap://ldap02.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes tls_reqcert=allow olcSyncrepl: rid=103 provider=ldap://ldap03.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes tls_reqcert=allow olcSyncrepl: rid=104 provider=ldap://ldap04.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes tls_reqcert=allow - add: olcMultiprovider olcMultiprovider: TRUE ----------------------- This is the ldif for the first server so olcSyncrepl for ldap01.example.net is not configured. On the other servers is the same the own URI has no olcSyncrepl entry. Here olcUpdatRef is not configured. Replication of the main-DB is running. BTW olcUpdateRef is also not configured in the howto of Quanah ;-) So it must be ok :-) Could you please take a look if I did something wrong. I don't know where to look anymore.

4 years, 8 months

new entry lost on multi-master setup (two scenarios)

by Jose Ildefonso Camargo Tolosa

Greetings, At first, I was going to create a bug report, but decided to send to list first. I tried this with both: 2.4.23 (Debian package), and 2.4.25, compiled from source, bdb 4.8. After a couple of entries just disappeared on one multi-master setup I had, I decided to further investigate, and found this (there are two cases, for the same procedure): 1. Configure two LDAP servers in multi-master setup. 2. Make sure they replicate correctly (off course). 3. Shutdown one of the two ldap servers. 4. Create a new entry (say, ou1) on the LDAP server that is left up. 5. Shutdown the last LDAP server. 6. Start the *other* LDAP server, the one where you didn't create the entry. 7. Create another entry, say: ou2, so that both servers has a new entry, that is *not* on the other server. 8. Shutdown the LDAP server (both servers down now). 9. Start both LDAP servers. Result (case 1): one of the two newly created entries is missing on *one* of the servers, and only one of the entries is missing on the other server. Result (case 2): one entry is missing on *both* servers. Both servers has NTP, and has the same timezone (ie, time is synchronized). I'm *not* replicating cn=config (I shouldn't, because I have different SSL certificates on each server). Now, more details: slapd with -d 16384 gives me this on the server that misses both entries, on this server I created the entry dn ou=ou2,dc=st-andes,dc=com (and the server decided to delete it!, and, for some reason, it didn't detected the new ou1 entry created on the other server): http://www.st-andes.com/openldap/case1/log-server2-case1.txt The other server (the one that kept one entry and lost the other), on this server I created the entry ou=ou1,dc=st-andes,dc=com, and it says it was changed by peer.....: http://www.st-andes.com/openldap/case1/log-server1-case1.txt Now, I'm seeing here that it is using 000 server id... but on the cn=config.ldif I have: olcServerID: 1 ldap://ldap.ildetech.com:389/ olcServerID: 2 ldap://ldap2.ildetech.com:389/ And the syncrepl: olcSyncRepl: rid=001 provider=ldap://ldap.ildetech.com:389 binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple credentials="secret" searchbase="dc=st-andes,dc=com" type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple credentials="secret" searchbase="dc=st-andes,dc=com" type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical olcMirrorMode: TRUE And, as you can see on the command line, I have the URL specified on the -h parameter, but it seems to be ignoring it!. Or, should I specify the *whole* urls that I put on the -h parameter? (ldap://ldap2.ildetech.com:389 ldap://127.0.0.1:389/ ldaps:/// ldapi:///) So, I decided to change the config: On server 1 (kirara): olcServerID: 1 and olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple credentials="secret" searchbase="dc=st-andes,dc=com" type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical olcMirrorMode: TRUE On server 2 (happy): olcServerID: 2 and olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple credentials="secret" searchbase="dc=st-andes,dc=com" type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical olcMirrorMode: TRUE With this new setup, and following the same procedure, I get one missing entry on *both* servers (at least servers gets to a consistent state), but I still have a missing entry. The logs for this setup: Server 2 (ID 2, where I created entry: ou2 while the other server was down), this server decided, wrongly, to delete entry ou2: http://www.st-andes.com/openldap/case2/log-server2-case2.txt And the other server (where I created ou1): http://www.st-andes.com/openldap/case2/log-server1-case2.txt This one never saw the other entry, ou2. For both cases, the syncprov module was with default configuration: dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: 24354488-e5bf-102f-9e6a-ad3cba95f7f1 creatorsName: cn=config createTimestamp: 20110318152128Z entryCSN: 20110318152128.935227Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20110318152128Z What do you think? Thanks in advance! Ildefonso Camargo

15 years, 4 months

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

by Jean-Francois Malouin

Sorry if this is long and naive, I'm making my way with OpenLDAP. I have this annoying problem of local access over ldapi:/// of a configured mdb database using its rootDN. Some details: (I typically use ldapvi to access/modify/edit config as I'm an old wolf with vi hard-wired in my brain!) (Same could be done using native OpenLDAP utilities ldapadd/search/delete/etc: just replace the ldapvi '-h' option with '-H' to specify the protocol/host/port). Binding using EXTERNAL mech over local ldapi:/// works correctly for 'cn=config'. For example, here I made a mod to olcLogLevel for 'cn=config': ~# ldapvi -Y EXTERNAL -h ldapi:/// -b 'cn=config' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 24 entries read add: 0, rename: 0, modify: 1, delete: 0 Action? [yYqQvVebB*rsf+?] y Done. Server logs for slapd show the binding with ssf=71: Sep 6 11:40:52 slapd[677]: conn=48667 fd=17 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND dn="" method=163 Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 However for the configured mdb database 'olcDatabase={1}mdb,cn=config' I have set olcSecurity: tls=1 to force binding with StartTLS. Here the relevant config piece for it: ('--out' makes ldapvi behave like ldapsearch). ~# ldapvi --out -Y EXTERNAL -h ldapi:/// -b 'olcDatabase={1}mdb,cn=config' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcRootDN: cn=admin,dc=example,dc=com olcRootPW: {SSHA}XXXXXXXXXXXXXXXXXXXX olcSecurity: tls=1 ... However this setting prohibits me from binding to it using ldapi:/// with EXTERNAL mech with its rootDN 'cn=admin,dc=example,dc=com' as I then get the message: ~# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -D 'cn=admin,dc=example,dc=com' -b 'dc=example,dc=com' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 Confidentiality required (13) Additional information: TLS confidentiality required I can however do a simple bind over StartTLS with the rootDN of the database either over localhost or a remote client: ~# ldapsearch -LLL -Z -x -w xxxxxxxx -H ldap://localhost -D 'cn=admin,dc=example,dc=com' -b 'dc=example,dc=com' slapd logs show: Sep 6 11:54:40 slapd[677]: conn=48699 fd=17 ACCEPT from IP=127.0.0.1:53542 (IP=0.0.0.0:389) Sep 6 11:54:40 slapd[677]: conn=48699 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 6 11:54:40 slapd[677]: conn=48699 op=0 STARTTLS Sep 6 11:54:40 slapd[677]: conn=48699 op=0 RESULT oid= err=0 text= Sep 6 11:54:40 slapd[677]: conn=48699 fd=17 TLS established tls_ssf=256 ssf=256 Sep 6 11:54:40 slapd[677]: conn=48699 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128 Sep 6 11:54:40 slapd[677]: conn=48699 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 So ssf=265... 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. Regards! jf

7 years, 11 months

Re: Reg OpenLdap on Ubuntu

by Michael Ströder

Asimananda Mohanty wrote: > Hi Michael, > > Thanks for the reply. > > I tried with "ldapsearch -x -H ldap://ldap-company.com:636 > <http://ldap-company.com:636> -ZZ -D dc=ldap-company,dc=com" and got the > error : > > ber_get_next failed. > ldap_start_tls: Can't contact LDAP server (-1) Sorry should have been ldapsearch -x -H ldap://ldap-company.com -ZZ for LDAP access going to standard port 389 (clear-text) and then using StartTLS extended operation. Another option is to use LDAPS (LDAP over SSL) to separate port: ldapsearch -x -H ldaps://ldap-company.com:636 -ZZ Ciao, Michael. -- Michael Ströder E-Mail: michael(a)stroeder.com http://www.stroeder.com

17 years, 1 month

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

by luxInteg

On Tuesday 06 March 2012 14:40:17 Dan White wrote: > 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. I did the test as you suggested. I get the same result whether ldap:// or ldaps:// (i.e whether or not I use tls). Unfortunately I cannot make head nor tail of the link if there is a gssppi-sasl patch or indeed which file in sasl-2.1.25 I need to modify for a fix. I also did a wander on the internet search engines but found nowt of consequence. Advice would be much appreciated. sincerely lux-integ

14 years, 5 months

Re: STARTTLS vs LDAPS

by Braiam

On Thu, Mar 31, 2022 at 11:46 AM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thursday, March 31, 2022 12:16 PM -0400 Braiam <braiamp(a)gmail.com> > wrote: > > > What would be the process to modify content on the openldap.org page? > > Depends on the content. The main web pages are in the OpenLDAP Web git > repository. > This repository seems to be the FAQ: https://git.openldap.org/project/faq/-/tree/master/data/item There's a website project too. I couldn't figure out what markup language items on the faq project uses. > --Quanah > -- Braiam

4 years, 5 months

Re: Problems using OpenLPAP for authentification of users: Client library issues STARTTLS but TLS is not configured

by Jörg Spilker

Dieter Kluenter schrieb: Hello Dieter, > Some Linux distributions have enabled 'ssl start_tls' as default, > please check your /etc/ldap.conf carefully. thanks for your help. Tracing getent passwd, i could see that ldap.conf is first searched in /etc, then in /etc/openldap. And OpenSUSE 11.0 installs /etc/ldap.conf with the pwdutils package and /etc/openldap/ldap.conf with the openldap package. I did all my configuration work in /etc/openldap/ldap.conf. But /etc/ldap.conf contains the line ssl start_tls. I´ve now removed /etc/ldap.conf and the nss_ldap error is gone. I will probably open a bugzilla case because it´s very annoying. Greetings, Jörg

18 years, 1 month

Re: ldaprc with ldaps:// and ldap:// fallback

by Dieter Kluenter

manu(a)netbsd.org (Emmanuel Dreyfus) writes: > Dieter Kluenter <dieter(a)dkluenter.de> wrote: > >> No, ldapi:/// doesn't present a certificate, but you may establish a >> startTLS session to ldapi:///, in this case the client requests a >> server certificate. > > Let me rephrase: I would like to specify two LDAP servers in ldaprc > - one ldapi:/// with anonymous bind > - one ldaps:// with SASL EXTERNAL for and required server certificate > > It seems to me it is not possible. This can be achieved by ACL's, man slapd.access(5), access to ... by sockname=... access to .. by tls_ssf=... -Dieter -- Dieter Klünter | Systemberatung sip: +49.40.20932173 http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6

16 years, 2 months

openldap-technical search results for query "starttls"