Search results for "starttls" - openldap-technical

Re: fedora and openldap

by Judith Flo Gaya

Hello Aaron, I already changed the parameter in the pam_ldap.conf and in the nslcd.conf ssl on instead of ssl start_tls Anywhere else? Thanks for the advice, I thought I had fixed it... and in fact ldapsearch -x -H ldaps://server does work, the problem is within pam, it seems to be stucked using start_tls... On 04/14/2011 07:08 PM, Aaron Richton wrote: > On Thu, 14 Apr 2011, Judith Flo Gaya wrote: > >> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from >> IP=[::1]:36208 (IP=[::]:636) >> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established >> tls_ssf=256 ssf=256 >> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT >> oid=1.3.6.1.4.1.1466.20037 >> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS >> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1 text=TLS >> already started >> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND >> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed > > So you're trying to issue a StartTLS operation over an implicit SSL > connection? There's no point to starting encryption on a connection that's > already encrypted (hence the error). Either combine: > > a cleartext port (i.e. 389) with the StartTLS operation > > or > > an SSL port (i.e. 636) with NO StartTLS operation.

13 years, 6 months

Re: Forcing TLS encryption

by Dieter Klünter

Am Fri, 28 Dec 2012 09:14:51 +0100 (CET) schrieb Wiebe Cazemier <wiebe(a)halfgaar.net>: > ----- 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. No. RFC 4513 clearly states: ... however, where a client intends to perform both a Bind operation and a StartTLS operation, it SHOULD first perform the StartTLS operation so that the Bind request and response messages are protected by the data security services established by the StartTLS operation. [...] -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E

11 years, 10 months

Re: require StartTLS

by Daniel Pocock

On 26/02/12 12:15, Dieter Klünter wrote: > Am Sun, 26 Feb 2012 11:49:14 +0100 > schrieb Daniel Pocock <daniel(a)pocock.com.au>: > >> >> >> >> Is there some way to ensure that a client who connects on port 389 can >> do nothing without StartTLS? >> >> Or is it necessary to just disable port 389 and only listen for >> ldaps:/// ? > > read on TLS OPTIONS in > man ldap.conf(5) and man slapd.conf(5) > Thanks for the fast reply I'm not keen to rely on ldap.conf (client side config) - I want to enforce a preference for TLS from the server side, to avoid a situation where some application might be configured non-TLS by mistake. I've looked at the TLS options and I have TLS running fine already. I notice the TLSCipherSuite option sets the cipher level within TLS, but it doesn't appear to guarantee that TLS is used. To make an analogy, in postfix, I require `plain' authentication: but the client is not allowed to try to authenticate until it has done StartTLS, because I never want a client to try sending a password over a channel that is not encrypted. For the moment, I have just disabled port 389

12 years, 8 months

Re: OpenLDAP-Client TLS

by btb

On 2012.11.16 03.45, Martin.Heinzmann(a)belden.com wrote: > Hi, > i am trying to write my own client which connects to an active directory > and searches for an user. So far it works, i call "ldap_initialize", set > version 3, "ldap_simple_bind_s" and then search the directory. > Now i want the connection to be secure by executing a "Simple TLS > handshake". I changed my hostname variable to "ldaps://ip:636" and tried > "ldap_start_tls_s(ld,NULL,NULL)" before the bind but get a "cant contact > ldap server" error. I think my active directory is configured the right > way because with JXplorer it works over ssl and port 636. > > Does anyone know which functions i have to call so a successful tls > connection will be set up? i know very little about libldap and its routines, but i do know that ldaps is not starttls, and starttls is not 636. man 3 ldap_start_tls_s seems to specifically indicate that routine is strictly for starttls, not ldaps. that would mean that you should be connecting to the regular ldap port [389] - e.g. "ldap://hostname/", and then using ldap_start_tls_s. that wouldn't work with ldaps/636 [and ldaps is deprecated anyway]. -ben

11 years, 11 months

Re: STARTTLS vs LDAPS

by Michael Ströder

On 3/31/22 19:15, Quanah Gibson-Mount wrote: > I think the clear text bind issue in fact shows that LDAPS is > technically superior to startTLS when encryption is required. The > remaining issue is there's no RFC for it. I'd like to see that > addressed. My attempt to resurrect the IETF ldapext WG failed back in 2015. :-/ Well, in fact every LDAP server I've tested supports LDAPS. So at least implementors should not have any objections. So if you're eager to write an individual I-D I'd be willing to review, discuss and support it. But I won't write it. Ciao, Michael.

2 years, 7 months

Re: ldapsearch over SSL can not bind

by Dieter Klünter

Am Mon, 2 Nov 2015 17:28:06 +0100 schrieb Matthias Apitz <guru(a)unixarea.de>: > > Hello, > > I'm trying to make from FreeBSD a LDAPsearch in some Novell eDirectory > with the following command: > > $ ldapsearch -Z -H ldaps://romega:1027 -b 'ou=person,o=uni' -D [...] Quite obvious, you initiated startTLS AND ldaps. To my knowledge, edirectory does not support startTLS, so just omit -Z. -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

9 years

Re: SSL/TLS connection on port 389

by Quanah Gibson-Mount

--On Monday, January 28, 2008 5:10 PM +0000 Chris Carr <chris.carr(a)camden.gov.uk> wrote: > On Mon, 2008-01-28 at 09:00 -0800, Quanah Gibson-Mount wrote: >> --On Monday, January 28, 2008 2:57 PM +0000 Chris Carr >> >> > Hi All, >> > >> > I've been running slapd with "-h ldaps:///" so that it takes SSL/TLS >> > connections on port 636. This has worked with most clients (Outlook, >> > Seamonkey, Thunderbird) but does not work for Evolution. I don't know >> > why not, but Evolution seems to insist on using port 389 for secure >> > connections. >> > >> > When I type >> > >> > openssl s_client -connect my.server.com:389 >> >> If you read the documentation on openssl, it clearly states it doesn't >> support doing LDAP startTLS over port 389. > > I thought startTLS was supposed to be the replacement for ldaps, so that > only one port was needed for both secure and insecure connections. > Wasn't that discussed on this list quite recently? I have definitely > misunderstood something. You are correct, startTLS is the replacement for LDAPS. My point is, if you read the documentation about the "openssl s_client" command, the openssl folks have yet to add support for LDAP startTLS to it. Which is why using that command in your case for testing it is pointless. As for the debian 2.4.7 package, there's a bug already tracking this issue. I'm not clear if it is a GnuTLS bug or an OpenLDAP bug or both. I don't use OpenLDAP with GnuTLS myself. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

16 years, 9 months

OpenLDAP 2.4.23 - Syncrepl - TLS Trouble

by Alexey Tyurikov

Dear OpenLDAP experts, I'm about to setup an OpenLDAP server with the following features: - TLS/SSL with self-signed certificates - TLS-encrypted N-way replication (Syncrepl) My environment: - 2 x RHEL 6.0 - OpenLDAP 2.4.23 I try to sync both databases: cn=config and backend-db. The problem is that I'm not able to turn on TLS for both sync-connections at the same time. It works for each connection but only if the second one is unencrypted. Working configuration: ----- olcDatabase={0}config,cn=config ... olcSyncrepl: {0}rid=001 provider=ldap://ldapserver1.com binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncrepl: {1}rid=002 provider=ldap://ldapserver2.com binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 ... olcDatabase={1}bdb,cn=config ... olcSyncrepl: {0}rid=003 provider=ldap://ldapserver1.com binddn="cn=manager,dc=ldap,dc=com" bindmethod=simple credentials=password searchbase="dc=ldap,dc=com" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cacert=/etc/openldap/cacerts/ca.pem olcSyncrepl: {1}rid=004 provider=ldap://ldapserver2.com binddn="cn=manager,dc=ldap,dc=com" bindmethod=simple credentials=password searchbase="dc=ldap,dc=com" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cacert=/etc/openldap/cacerts/ca.pem ----- (desired) Configuration, which doesn't work: ----- olcDatabase={0}config,cn=config ... olcSyncrepl: {0}rid=001 provider=ldap://ldapserver1.com binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 starttls=yes tls_cacert=/etc/openldap/cacerts/ca.pem olcSyncrepl: {1}rid=002 provider=ldap://ldapserver2.com binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 starttls=yes tls_cacert=/etc/openldap/cacerts/ca.pem ... olcDatabase={1}bdb,cn=config ... olcSyncrepl: {0}rid=003 provider=ldap://ldapserver1.com binddn="cn=manager,dc=ldap,dc=com" bindmethod=simple credentials=password searchbase="dc=ldap,dc=com" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cacert=/etc/openldap/cacerts/ca.pem olcSyncrepl: {1}rid=004 provider=ldap://ldapserver2.com binddn="cn=manager,dc=ldap,dc=com" bindmethod=simple credentials=password searchbase="dc=ldap,dc=com" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cacert=/etc/openldap/cacerts/ca.pem ----- /etc/openldap/cacerts/ca.pem contains CA certificates of both servers. What is wrong? I would be very thankful for every advise.

13 years, 2 months

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation

by Robert Heller

At Thu, 28 Sep 2017 10:19:43 -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > --On Thursday, September 28, 2017 2:08 PM -0400 Robert Heller > <heller(a)deepsoft.com> wrote: > > > OK, I have narrowed things down to slapd and sssd not playing nice with > > each other. slapd is able to listen on ldaps (port 636) and accept SSL > > connections (eg from openssl s_client and other applications using > > straight SSL). slapd will also listen on ldap (port 389), but refuses > > to negotiate a TLS connection on port 389. It also refuses to negotiate > > TLS connection on port 636. sssd seems to *insist* on negotiating a TLS > > connection on port 636 or port 389 and won't just connect using ssl to > > port 636. (At least that is what I *think* is going on.) > > > > So, I either need to get slapd to do TLS negotiation on port 389 OR port > > 636, or get sssd to NOT do TLS negotiation on port 636 and just connect > > with SSL. > > You're using a bit of a confusing word soup. Well, yes... > > ldaps == Deprecated, non-standard way of securing connection to LDAP. > Usually on port 636 > startTLS == RFC standard way of securing connections to LDAP. Usually on > port 389 > > If you are using ldaps, then you want startTLS to be disabled > if you are using startTLS, then you want it enabled. > > Your SSD config has: > > ldap_id_use_start_tls = false > > so this would be correct with use with ldaps:/// But SSSD does not work with ldaps:///... It *wants* startTLS over ldap:///, which does not *seem* to work. > > You don't provide any error messages or other useful information, so one > can only specualte what issues you may be having. Slapd is reporting TLS Negotiation failure when SSSD tries to connect to it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess something is wrong with slapd's TLS configuration -- it is failing to do TLS Negotiation, either it is just not doing it or it is doing it wrong (somehow). Unless SSSD is not configured properly. > > I would note that most versions of openssl s_client do not support startTLS > with LDAP (Thus you cannot use it to test port 389). That feature was only > recently added to OpenSSL. > > If you want to test startTLS on port 389, your best bet is to use an ldap > client utility such as ldapwhoami, like: > > ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

7 years, 1 month

Re: SSL/TLS connection on port 389

by Buchan Milne

On Monday 28 January 2008 16:57:28 Chris Carr wrote: > Hi All, > > I've been running slapd with "-h ldaps:///" so that it takes SSL/TLS > connections on port 636. This has worked with most clients (Outlook, > Seamonkey, Thunderbird) but does not work for Evolution. I don't know > why not, but Evolution seems to insist on using port 389 for secure > connections. Which version of Evolution? Mine has a "Use secure connection" drop-down box, with "SSL encryption", "TLS encryption" and "No encryption" options. Since the port doesn't change based on your selection, I'll assume what they actually mean is "ldaps", "STARTTLS", and "No encryption". Naturally, STARTTLS would run on the normal unencrypted port (389 by default), and "upgrade" to SSL/TLS with a STARTTLS command. It seems that no matter what you select here, if the port is 389, it does STARTTLS: Jan 29 17:59:16 seaknight slapd[840]: conn=0 fd=15 ACCEPT from IP=127.0.0.1:53243 (IP=0.0.0.0:389) Jan 29 17:59:16 seaknight slapd[840]: conn=0 op=0 STARTTLS Jan 29 17:59:16 seaknight slapd[840]: conn=0 op=0 RESULT oid= err=0 text= Jan 29 17:59:16 seaknight slapd[840]: conn=0 fd=15 TLS established tls_ssf=256 ssf=256 However, if you select 636 as the port, it greys out the "Use secure connection" drop-down box, and does ldaps. Jan 29 18:03:51 seaknight slapd[840]: conn=14 fd=27 ACCEPT from IP=127.0.0.1:54153 (IP=0.0.0.0:636) Jan 29 18:03:51 seaknight slapd[840]: conn=14 fd=27 closed (TLS negotiation failure) Jan 29 18:03:58 seaknight slapd[840]: conn=15 fd=27 ACCEPT from IP=127.0.0.1:45074 (IP=0.0.0.0:389) (Can't get it to work right right now with ldaps ...). Note however that evo caches LDAP connections, it seems you need to restart it for your config changes to take effect. And, it will only prompt you for the password once the connection is up ... > When I type > > openssl s_client -connect my.server.com:389 > > It says connection refused. When I type the same command with :636 at > the end it connects fine. > > Could somebody explain to me how to tell slapd to accept secure > connections on port 389? I am using the new version of slapd in Debian > Testing (2.4.7-1). start slapd with with no -h flag, or -h "ldaps:/// ldap:///" so it listens on port 636 for ldaps connections, and 389 for ldap connections (which could use START_TLS to upgrade). > Sorry if this is a really stupid question, but according to the docs the > "startTLS" process should be automatic if a secure connection comes in > on port 389. Something is obviously not quite right. Hmm, SSL/TLS isn't really automatic ... Regards, Buchan

16 years, 9 months

openldap-technical search results for query "starttls"