Search results for "starttls" - openldap-technical

Re: ldap PDC -- Failed to issue the StartTLS instruction

by Ivan Ordonez

Quanah Gibson-Mount wrote: > > > --On August 4, 2009 3:51:18 PM -0700 Ivan Ordonez > <iordonez(a)nature.berkeley.edu> wrote: > >> Hello, >> >> We've been using an ldap based PDC from quite a while. Now we're >> suddenly having trouble getting our main fileserver to talk with the >> PDC. >> >> samba-3.2.13 on solaris 10. >> >> Here is our smb.conf global defs: >> >> Server role: ROLE_DOMAIN_MEMBER >> [global] >> workgroup = CNRDOM >> server string = nature (Samba %v) >> security = DOMAIN >> passdb backend = ldapsam:ldaps://169.229.xxx.yyy >> log level = 5 >> log file = /var/log/samba/log.%m >> name resolve order = wins host lmhosts >> os level = 65 >> local master = No >> domain master = No >> dns proxy = No >> wins support = Yes >> ldap ssl = start tls > > ldaps:// and startTLS are mutually exclusive. Pick one and only one. We tried removing the "s" on ldaps:// and still no go. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

15 years, 3 months

openldap to AD proxy

by Alex Samad - Yieldbroker

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

12 years, 6 months

Re: Ubuntu Server 12.04: StartTLS

by Dan White

On 11/05/12 08:29 +0100, Admus wrote: >On 11/04/2012 11:59 PM, Dan White wrote: >>On 11/04/12 23:13 +0100, admus wrote: >>>Hello, >>>I'm following https://help.ubuntu.com/12.04/serverguide/openldap-server.html#openldap-tls… >>>how to: >>>LDAP serwer starts correctly but when I tries to test StartTLS: >>>ldapsearch -x -H ldap:/// -ZZ -d -1 >>>I gets the following error: >>>TLS: peer cert untrusted or revoked (0x42) >>>TLS: can't connect: (unknown error code). >>>ldap_err2string >>>ldap_start_tls: Connect error (-11) >>> additional info: (unknown error code) >>>Any idea? >> >>Your hostname will need to match the certificate you have installed. '-H >>ldap:///' will, instead, need to include the hostname matching your >>certificate. >> >>For project documentation, see chapter 16 of the OpenLDAP Administrator's >>Guide, slapd-config(5), ldap.conf(5), and ldapsearch(1). >> > >ldapsearch -x -H ldap://ldap1.example.com -ZZ -d -1 > >Does not help, same error. CN in my certificate is ldap1.example.com. Assuming that your OpenLDAP was compiled against GnuTLS, use the GnuTLS tools to trouble shoot your certificate. A google search for "peer cert untrusted or revoked (0x42)" finds users who also received that error. -- Dan White

12 years

Re: Understanding TLS SSF

by Patrick Patterson

Hello On Wed, Jul 30, 2008 at 9:59 AM, J Davis <mrsalty0(a)gmail.com> wrote: > Greetings, > > I'm testing an installation of openldap 2.4.9. I want to enforce TLS for > all access to the directory. > My problem is that I cannot get the client to meet the ssf restictions I > have in place. The documentation I've seen on ssf and tls_ssf is very sparse > so I don't really understand what it does. > > I'm using self signed cert created using the openssl CA.sh script. > > Relevant portions of the slapd.conf... > > TLSCACertificateFile /etc/ldap/ssl/cacert.pem > TLSCertificateFile /etc/ldap/ssl/servercrt.pem > TLSCertificateKeyFile /etc/ldap/ssl/serverkey.pem > ... > access to * > by tls_ssf=128 ssf=128 anonymous auth > by tls_ssf=128 ssf=128 self write > > Relevant portions of the lapd.conf... > > TLS_CACERT /etc/ldap/ssl/cacert.pem > > With those ACLs in place I get the following error: > > $ ldapsearch -x -ZZ -D "uid=jake,ou=people,dc=example,dc=com" -W -b > "uid=jake,ou=people,dc=example,dc=com" > ldap_bind: Invalid credentials (49) > You may want to try adding -q as one of the options to your ldapsearch. It appears that the tls_ssf turns on STARTTLS, instead of LDAP over SSL and in order to use that, you need to tell the client to use starttls as well, which is what (if I read the man page correctly), -q does. Have fun. -- Personal Mail from Patrick Patterson No company affiliation

16 years, 3 months

Ipad/iPhone ldap setup

by Chris Jackson

I am having trouble accessing my openldap server over SSL using an iPhone/iPad/iPod Touch using ios 4.2.1. If I check the SSL box in the client setup on the iPhone/iPad/iPod Touch I get an error in the slapd log -- TLS negotiation Failure. With logging level 9 I get TLS accept failure error=-1 id=1. Other clients work fine over SSL/StartTLS. Outlook, addressbook in osX 10.6, jxplorer. I am using openldap 2.4.19-15 on RHEL6 with a comodo wildcard SSL cert. Chris Jackson

13 years, 8 months

Spurious Start TLS failed errors on proxyed bind OpenLDAP 2.4.40

by Janne Peltonen

Hi! We've got a proxy OpenLDAP setup using the "ldap" proxy database (the newer "meta" backend had some issues, so I couldn't use that one). Most of the time, the proxy bind goes OK, but sometimes, the connection goes like this (proxy log, using ldaps): --clip-- Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 ACCEPT from IP=128.214.54.152:36460 (IP=0.0.0.0:636) Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 TLS established tls_ssf=256 ssf=256 Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 BIND dn="<removed>" method=128 Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 RESULT tag=97 err=52 text=Start TLS failed Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 closed (connection lost) --clip-- 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: --clip-- Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 ACCEPT from IP=128.214.222.155:46144 (IP=0.0.0.0:389) Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 ACCEPT from IP=128.214.222.155:46146 (IP=0.0.0.0:389) Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 STARTTLS Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=1 UNBIND Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 closed Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 STARTTLS Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 RESULT oid= err=0 text= Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 TLS established tls_ssf=256 ssf=256 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" method=128 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 RESULT tag=97 err=0 text= [SRCH and result lines] Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=3 UNBIND Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 closed --clip-- This doesn't seem to have any correlation to the amount of binds of server load, at least that I'm aware - and anyway, the servers are nowhere near at capacity - we only get ~2 binds per second. Normal connection would look like this: --clip-- Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 ACCEPT from IP=128.214.54.152:36362 (IP=0.0.0.0:636) Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 TLS established tls_ssf=256 ssf=256 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" method=128 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 RESULT tag=97 err=0 text= [SRCH and SEARCH RESULT lines] Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 op=219 UNBIND Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 fd=159 closed --clip-- So this far, it looks as if the problem was that if we accept a second connection for the same client before the proxy has had time to do a bind (or indeed, a STARTTLS for the bind) on the backend for the second connection. 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: --clip-- Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 ACCEPT from IP=128.214.173.135:43148 (IP=0.0.0.0:389) Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 STARTTLS Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 RESULT oid= err=0 text= Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 TLS established tls_ssf=256 ssf=256 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 BIND dn="ou=shibboleth,ou=login,dc=helsinki,dc=fi" method=128 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 RESULT tag=97 err=52 text=Start TLS failed Jan 17 17:46:22 ldap-r-1 slapd[28738]: conn=529684 fd=62 closed (connection lost) --clip-- on the proxy, and backend: --clip-- Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 ACCEPT from IP=128.214.222.155:48996 (IP=0.0.0.0:389) Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 STARTTLS Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 RESULT oid= err=0 text= Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 closed (TLS negotiation failure) --clip-- Succesful ldap+starttls connection on proxy: --clip-- Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 ACCEPT from IP=128.214.173.137:48700 (IP=0.0.0.0:389) Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 STARTTLS Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 RESULT oid= err=0 text= Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 TLS established tls_ssf=256 ssf=256 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 BIND dn="<removed>" method=128 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 RESULT tag=97 err=0 text= [SRCH and SEARCH RESULT lines] Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=3 UNBIND Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 closed --clip-- Any ideas what could be causing these? It's a bit hard to pinpoint the problem, since it happens so rarely - we seem to get a couple dozen of these every hour to around 16 000 succesful binds, not really depending on system load. This is RHEL 7 and OpenLDAP 2.4.40. It may be the case that the same DN binding very often increases the probability of a Start TLS failed error, which I guess would be the first case (a new ACCEPT + BIND for a DN too soon after the previous one). But as I said, these seem to also sometimes appear even without any other connections being opened at the same time. (Although there might be some old connections open for the same DN.) --Janne Peltonen University of Helsinki

5 years, 9 months

Error: CSN too old and replication fails

by Jérémy Wagner

Hello, I'm facing some issues with syncrepl... The simplest situation in which I was able to reproduce the problem consists of 1 provider and 1 consumer. I have configured syncrepl to do a partial replication : olcSyncrepl: {0}rid=105 provider=ldaps://****:636 bindmethod=simple timeout=0 network-timeout=0 starttls=no filter="(mail=*)" searchbase="ou=groups,o=mydir" scope=sub schemachecking=off attrs="cn description mail member +" type=refreshAndPersist retry="60 +" tls_cert=**** tls_cacert=**** tls_key=**** olcSyncrepl: {1}rid=107 provider=ldaps://****:636 bindmethod=simple timeout=0 network-timeout=0 starttls=no filter="(objectclass=*)" searchbase="ou=operators,o=mydir" scope=sub schemachecking=off type=refreshAndPersist retry="60 +" tls_cert=**** tls_cacert=**** tls_key=**** olcSyncrepl: {2}rid=104 provider=ldaps://****:636 bindmethod=simple timeout=0 network-timeout=0 starttls=no filter="(uid=mytestuser)" searchbase="ou=people,o=mydir" scope=sub schemachecking=off type=refreshAndPersist retry="60 +" tls_cert=**** tls_cacert=**** tls_key=**** The initial sync (i.e. from an empty base) is fine, but then when I modify an entry (uid=mytestuser), it is not updated on the consumer, and I get the following messages: Feb 16 15:42:32 do_syncrep2: rid=107 NEW_COOKIE: rid=107,csn=20110216144232.222152Z#000000#000#000000 Feb 16 15:42:32 do_syncrep2: rid=104 cookie=rid=104,csn=20110216144232.222152Z#000000#000#000000 Feb 16 15:42:32 slap_graduate_commit_csn: removing 0x7fb58c0227d0 20110216144232.222152Z#000000#000#000000 Feb 16 15:42:32 do_syncrep2: rid=104 CSN too old, ignoring 20110216144232.222152Z#000000#000#000000 Feb 16 15:43:05 do_syncrep2: rid=105 LDAP_RES_INTERMEDIATE - NEW_COOKIE Feb 16 15:43:05 do_syncrep2: rid=105 NEW_COOKIE: rid=105,csn=20110216144305.545784Z#000000#000#000000 Feb 16 15:43:05 slap_queue_csn: queing 0x7fb58c020b50 20110216144305.545784Z#000000#000#000000 Feb 16 15:43:05 do_syncrep2: rid=107 LDAP_RES_INTERMEDIATE - NEW_COOKIE Feb 16 15:43:05 do_syncrep2: rid=107 NEW_COOKIE: rid=107,csn=20110216144305.545784Z#000000#000#000000 Feb 16 15:43:05 do_syncrep2: rid=104 cookie=rid=104,csn=20110216144305.545784Z#000000#000#000000 Feb 16 15:43:05 slap_graduate_commit_csn: removing 0x7fb58c0227d0 20110216144305.545784Z#000000#000#000000 Feb 16 15:43:05 do_syncrep2: rid=104 CSN too old, ignoring 20110216144305.545784Z#000000#000#000000 (both servers are perfectly in sync with an NTP daemon) It looks like ITS #6619 is quite similar, and unresolved. What do these messages mean ? Is there a way to force the update ? Regards, Jeremy W.

13 years, 8 months

Re: changes in libldap?

by Michael Ströder

On 4/15/19 10:09 AM, Dieter Kluenter wrote: > Michael Ströder <michael(a)stroeder.com> writes: >> On 4/14/19 5:32 PM, Dieter Kluenter wrote: >>> § ldapfuse ldap://localhost ~/adbook >>> Unhandled LDAP error code -1 >>> LDAP Can't contact LDAP server >> >> Is the server running? > > Yes, slapd is running. In fact I tested it with 3 hosts. Do you have required StartTLS configured in your ldap.conf or .ldaprc? Ciao, Michael.

5 years, 7 months

Re: Openldap server with TLS not working

by btb＠bitrate.net

On Oct 3, 2013, at 17.46, Axel Grosse <agrosse(a)axway.com> wrote: > Hi all, Ben, Dieter, > thank you for your help ... > got it working on ldaps without TLS :-)) > > we can close that thread glad you had success. a note of pedantry - just because ldaps was used doesn't mean tls was not. those two concepts are orthogonal. [e.g. starttls and tls are two different things]. in fact, tls should be [and probably is] used with your ldaps connection. ssl should not be, having been replaced by tls. -ben

11 years, 1 month

Re: SASL/EXTERNAL not available

by Dieter Klünter

Am Mon, 31 Aug 2015 19:43:39 -0400 schrieb Frank Crow <fjcrow2008(a)gmail.com>: > Hi, > > I'm trying to configure OpenLDAP 2.4.23 (running on RHEL6.5) to use > client-side certificates via the SASL/EXTERNAL mechanism. I have > successfully configured server-side certs with TLS and was wanting to > expand my configuration on the client-side. > > If set the TLSClientVerify to "allow" or "try" and attempt to use "-Y > EXTERNAL", I get the following message: > > SASL/EXTERNAL authentication started > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) > additional info: SASL (-4): no mechaism available: > > > If I do a search on the DSE, I get the following available methods: > > dn: > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: LOGIN > supportedSASLMechanisms: CRAM-MD5 > supportedSASLMechanisms: DIGEST-MD5 > supportedSASLMechanisms: PLAIN > > > I know that other people are using this but nobody (here at work) > knows why my particular configuration is getting this error. Can > anyone help me figure this out? It seems you have not initialised a TLS session, that is, either startTLS on port 389 or without starttls on secure port 636 ldapsearch -LLL -Y EXTERNAL -ZZ -H ldap://localhost -b "" -s base supportedSASLMechanisms SASL/EXTERNAL authentication started SASL username: xxxxx SASL SSF: 0 dn: supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: SCRAM-SHA-1 -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

9 years, 2 months

openldap-technical search results for query "starttls"