Search results for "starttls" - openldap-technical

Re: Ldap is up, trying to get tls working.

by Christopher Wood

Cheap advice inline. On Fri, Oct 28, 2011 at 11:44:25AM -0400, John Tobin wrote: > 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 Always test starttls with -ZZ, so if your starttls isn't working the connection will fail. > 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 Augh. If you can stop using nscd all this will be much easier for you. I personally like nslcd rather than nss-ldap, but each to their own. If not, restart nscd before you start every troubleshooting round. > 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) First I would test that all the CA certs and server certs in use are understandable by each other. Does the server cert on the machine running slapd validate against the CA cert on the machine running ldapsearch? Does the server cert on the machine running slapd validate against the CA cert on the client machine? openssl verify -CAfile cacert.pem servercert.pem If the output says "ok" then the actual cert part is fine. At this point I would crank up the slapd debug level (run it in the foreground) and match it again your ldap client debug logs. See if you can reproduce the error above using a client like ldapsearch, using the same search parameters as the nss-ldap client would use. > [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 [1]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. I'm getting a puppetized starttls working with 2.4.26/openssl on debian, but much the same thing. > Thanks in advance. > tob > > References > > Visible links > 1. http://www.openldap.org/faq/data/cache/185.html

14 years, 1 month

RE: Syncrepl and mmr

by Borresen, John - 0442 - MITLL

Thanks, Quanah Not sure what you meant by " Well, it may not have been this issue, but it definite would become an issue then." Was what I did a good thing or not? Curious minds want to know. <lol> MM Server1: # ldapsearch -H ldap://mm-server1.example.ldap -d 256 -x -D cn=admin,cn=config -W -ZZ -b olcDatabase=\{1\}bdb,cn=config olcSyncrepl Enter LDAP Password: # extended LDIF # # LDAPv3 # base <olcDatabase={1}bdb,cn=config> with scope subtree # filter: (objectclass=*) # requesting: olcSyncrepl # # {1}bdb, config dn: olcDatabase={1}bdb,cn=config olcSyncrepl: {0}rid=002 provider=ldap://mm-server2.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs="*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem olcSyncrepl: {1}rid=001 provider=ldap://mm-server1.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,dc=ldap" credentials=<password> interva l=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs= "*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem # {0}syncprov, {1}bdb, config dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config # {1}accesslog, {1}bdb, config dn: olcOverlay={1}accesslog,olcDatabase={1}bdb,cn=config # search result search: 3 result: 0 Success # numResponses: 4 # numEntries: 3 MM Server2: # ldapsearch -H ldap://mm-server2.example.ldap -d 256 -x -D cn=admin,cn=config -W -ZZ -b olcDatabase=\{1\}bdb,cn=config olcSyncrepl Enter LDAP Password: # extended LDIF # # LDAPv3 # base <olcDatabase={1}bdb,cn=config> with scope subtree # filter: (objectclass=*) # requesting: olcSyncrepl # # {1}bdb, config dn: olcDatabase={1}bdb,cn=config olcSyncrepl: {0}rid=001 provider=ldap://mm-server1.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs= "*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem olcSyncrepl: {1}rid=002 provider=ldap://mm-server2.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,dc=ldap" credentials=<password> interva l=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs= "*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem # {0}accesslog, {1}bdb, config dn: olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config # {1}syncprov, {1}bdb, config dn: olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config # search result search: 3 result: 0 Success # numResponses: 4 # numEntries: 3 I modified, the "starttls" statement (just to test) to no. and now receiving the following >From MM-Server2: Jan 31 12:39:15 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc 13 retrying Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 fd=101 ACCEPT from IP=<mm-server1-ip>:48899 (IP=0.0.0.0:389) Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 op=0 BIND dn="cn=ldapadmin,dc=example,dc=ldap" method=128 Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 op=0 RESULT tag=97 err=13 text=TLS confidentiality required Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 op=1 UNBIND Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 fd=101 closed Jan 31 12:40:15 gp42-admin4 slapd[26000]: conn=8616 fd=106 ACCEPT from IP=<mm-server2-ip>:43431 (IP=0.0.0.0:389) Jan 31 12:40:15 gp42-admin4 slapd[26000]: conn=8616 op=0 BIND dn="cn=ldapadmin,dc=example,dc=ldap" method=128 Jan 31 12:40:15 gp42-admin4 slapd[26000]: conn=8616 op=0 RESULT tag=97 err=13 text=TLS confidentiality required Jan 31 12:40:15 gp42-admin4 slapd[26000]: slap_client_connect: URI=ldap://mm-server2.example.ldap DN="cn=ldapadmin,dc=example,dc=ldap" ldap_sasl_bind_s failed (13) Very similar on MM-Server1. I am at a loss. The TLS configuration, files, are exactly as they are in the standard client configuration...as far as I can tell. Three other SysAdmins, for sanity sake, have checked that the paths are identical between the various files. I turned on a flood of debugging (-1) and on "mm-server1 and 2", seeing: tls_write: want=810 error=Broken pipe ldap_write: want=732 error=Broken pipe 52ebe8e0 ber_flush2 failed errno=32 reason="Broken pipe" and TLS trace: SSL3 alert write:warning:close notify ldap_free_connection: actually freed tls_read: want=5 error=Bad file descriptor Thanks in advance -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Friday, January 31, 2014 12:07 PM To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org Subject: RE: Syncrepl and mmr --On Friday, January 31, 2014 8:54 AM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > Thanks Quanah > > I'm sure it isn't 100% correct, but I added the following ACL to my > accesslog DB on both MM servers: > > olcAccess: to * by dn="cn=ldapadmin,dc=group42,dc=ldap" read by * none Well, it may not have been this issue, but it definite would become an issue then. ;) > I'm still seeing > gp42-admin3 (MM server1) > Jan 31 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH > base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 31 > 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH attr=reqDN > reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan > 31 08:25:17 > gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with > LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:17 gp42-admin3 slapd[3599]: > do_syncrepl: rid=001 rc -1 retrying Jan 31 08:25:17 gp42-admin3 > slapd[3599]: send_search_entry: conn 5551 ber write failed. Jan 31 > 08:25:17 gp42-admin3 slapd[3599]: conn=5551 fd=32 closed (connection > lost on write) Jan 31 08:25:17 gp42-admin3 slapd[3599]: do_syncrep2: > rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 31 > 08:25:17 > gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying Your masters are unable to talk to each other. You need to determine why. This will take debugging on your part, as I've never seen anything like this before. > gp42-admin4 (MM server2) > Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 fd=101 ACCEPT from > IP=155.34.133.73:10446 (IP=0.0.0.0:389) Jan 31 08:25:19 gp42-admin4 > slapd[26000]: conn=8050 op=0 BIND dn="dc=group42,dc=ldap" method=163 > Jan > 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=0 RESULT tag=97 > err=13 text=TLS confidentiality required Jan 31 08:25:19 gp42-admin4 > slapd[26000]: conn=8050 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" > method=128 Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=1 > RESULT tag=97 err=13 text=TLS confidentiality required Jan 31 08:25:19 > gp42-admin4 slapd[26000]: conn=8050 op=2 UNBIND Jan 31 08:25:19 > gp42-admin4 slapd[26000]: conn=8050 fd=101 closed Jan 31 08:25:51 > gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with > LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:51 gp42-admin4 > slapd[26000]: do_syncrepl: rid=001 rc -1 retrying This says that your consumer is connecting without sending a startTLS, while you've configured the master to require startTLS. Clearly you need to either enable startTLS in the syncrepl statement, or not require starttls on your master. --Quanah > -----Original Message----- > From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Sent: Thursday, January 30, 2014 5:10 PM > To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org > Subject: RE: Syncrepl and mmr > > --On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 - > MITLL" <John.Borresen(a)ll.mit.edu> wrote: > >> Well, that was helpful -- lol > > > Looking at your previously supplied configuration, it is clearly > apparent that you provided your replication user no ACLs to read the > accesslog DB, so the error you see makes sense. It can't read the > data out of accesslog, so it throws an error stating that fact. > > --Quanah > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

11 years, 10 months

RE: openldap to AD proxy

by Alex Samad - Yieldbroker

Still haven't been able to get this working. And can't find any way to turn on any debugging for ldap backend. If anyone has done this if they could provide some feed back. A -----Original Message----- From: Alex Samad - Yieldbroker Sent: Friday, 4 May 2012 2:32 PM To: 'openldap-technical(a)openldap.org' Subject: openldap to AD proxy Hi I am still struggling with the my openldap to AD proxy connection. I have successfully connected such that I can do search when I bind to openldap with an AD dn, but I want to be able to do anon search and I want anon to map through to a dn I have created in AD which has read only rights. dn: olcDatabase={3}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {3}ldap olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * read olcReadOnly: TRUE olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcSizeLimit: 500 olcSuffix: dc=xyz,dc=com olcDburi: "ldap://ldap. xyz.com " olcDbRebindAsUser: TRUE olcDbChaseReferrals: TRUE olcdbaclbind: bindmethod=simple binddn="CN=ad readonly,OU=YB Services,OU= xyz,DC= xyz,DC=com" credentials=":)" starttls=no olcDbIDAssertBind: bindmethod=none binddn="CN=ad readonly,OU=YB Services,OU= xyz,DC= xyz,DC=com" credentials=":)" starttls=no I have a subordinate db at ou=external, DC= xyz,DC=com I can do a ldapsearch -x -D " CN=ad readonly,OU=YB Services,OU= xyz,DC= xyz,DC=com" -b " DC= xyz,DC=com" -w :) what I can't do is ldapsearch -x -b " DC= xyz,DC=com" I am thinking I want to map anon request through to the readonly DN. But still leave it such that when people bind to openldap as themselves they bind to AD as themselves How would I do that ? Thanks Alex

13 years, 6 months

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, 1 month

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&… >

8 years, 4 months

RE: Debugging TLS negotiation failure

by Christopher Paul

> -----Original Message----- > From: terry.lemons(a)dell.com <terry.lemons(a)dell.com> > Sent: Thursday, May 11, 2023 1:10 PM > To: openldap-technical(a)openldap.org > Subject: Re: Debugging TLS negotiation failure > > I'm using a self-signed server certificate, so no CA should be involved. Not > sure if that is causing the problem? Try prepending to your ldapsearch: "LDAPTLS_REQCERT=allow ldapsearch ..." I have also noticed that the errors returned when using StartTLS (TCP/389 "ldap://" prefix URIs) are more informative than when using (non-protocol but widely supported) TCP/636 "ldaps://". Chris Paul | Rex Consulting | https://www.rexconsulting.net

2 years, 6 months

Re: OpenLDAP with SSL connection and search only with wildcard

by Quanah Gibson-Mount

--On Monday, June 15, 2020 7:03 AM +0000 a.leurs(a)consense-gmbh.de wrote: > I thought maybe the size limit is exceeded. > > But when I go back to a ldap connection (instead of a ldaps-connection) > it works fine. Active Directory does things differently than OpenLDAP does. What actions are available over ldaps:/// may not match what can be done with startTLS. You'd need to talk to your AD administrator to determine what actions are allowed on which ports, or for them to adjust your permissions. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 years, 5 months

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

by Quanah Gibson-Mount

--On Friday, April 1, 2022 11:59 AM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > 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? For your first bit, you can set up the server to only accept certain cipher suites which would not allow such a thing to happen. On the second bit, there is no way to prevent a client that attempts to bind with a dn/password over ldap:/// from sending it in the clear. Regards, Quanah

3 years, 8 months

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

by Quanah Gibson-Mount

--On Thursday, March 31, 2022 9:11 AM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.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. --Quanah

3 years, 8 months

Re: How do tool verify certs with ldapi:// ?

by Philip Guenther

On Mon, 28 May 2012, Philip Guenther wrote: > If no path is specified (e.g., "ldapi://") then the checking code is > passed a hostname of "localhost". ...which then remaps that to the local hostname (if available) for the actual check. Huh. So for any URI that doesn't specify a host component, be it "ldapi://" or "ldap://" or "ldaps://", the OpenLDAP tools will connect to the default 'host' for the schema, be it "/var/run/ldpai" or "localhost", but for StartTLS they'll match the server cert against the *hostname*. I did not expect that, though I can see how it can be justified. Philip Guenther

13 years, 6 months

openldap-technical search results for query "starttls"