Search results for "starttls" - openldap-technical

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

by Quanah Gibson-Mount

--On August 4, 2009 4:20:06 PM -0700 Ivan Ordonez <iordonez(a)nature.berkeley.edu> wrote: > Sorry Quanah, I am not following you on what you want me to do. Can you > please elaborate? > > Thank you for all your help. Keep replies on the list please. I was saying, I would have kept the ldaps:// URI in your config file, and drop the start TLS bit, and seen whether or not that works. In either case, I would use the ldapsearch binary to test against your server, both with ldaps:// URIs, and with ldap:// URIs using the -ZZ or -ZZZ flags to ldapsearch. ldapsearch with ldap:/// and -ZZ(Z) will use startTLS. ldapsearch with ldaps:// will try an SSL connection to the LDAP server. This way, you can hopefully get more meaningful error messages. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

15 years, 10 months

LDAPS Support

by web＠tomjay.co.uk

Hello, I'm under the impression that LDAPS (and not StartTLS) has been depreciated in OpenLDAP, but I can't find anything on the OpenLDAP website that says this. Is this the case, and is there a reference for it? Thanks.

7 years

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

by Quanah Gibson-Mount

--On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > 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. You need to start with the following: >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w to test startTLS and ldapwhoami -x -H ldaps://myhost:636 -D binddn -w to test without startTLS If you can get those to work, then you can move on to SSSD. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

7 years, 8 months

Re: ldapi and StartTLS

by Michael Ströder

On 07/11/2018 08:52 PM, Norman Gray wrote: > I would have thought (possibly naively) that StartTLS was unnecessary > when connecting to slapd through a unix socket -- the client and the > server are on the same machine, and so don't need to be reassured about > each other's identity. Yes. > However this seems not to be be the case: > > % ldapsearch -LLL -H ldapi://%2Fvar%2Frun%2Fopenldap%2Fldapi > '(uid=foo)' > ldap_sasl_interactive_bind_s: Confidentiality required (13) > additional info: stronger confidentiality required You want to set localSSF in your config to match the minimum SSF you've configured (the default is 71). 'localSSF' is old slapd.conf name and 'olcLocalSSF' the accompanying LDAP attribute in cn=config. > dn: cn=config > [..] > olcSecurity: ssf=128 So add to cn=config: olcLocalSSF: 128 Ciao, Michael.

6 years, 10 months

Syncrepl TLS woes

by Xavier Landreville

Hello, I am currently in the grips of trying to get syncrepl replication working with StartTLS. It was working fine until recently. The only change that occurred over the last 12 months (that relates to OpenLDAP) is that I've started requiring TLS for connections. My provider is running OpenLDAP 2.4.31 on Ubuntu 14.04, while one consumer is running the exact same version on a Ubuntu 14.04 machine and the other consumer is running OpenLDAP 2.4.28 on Ubuntu 12.04. The provider has, AFAIK, a correct TLS configuration, given that I can connect and search using the ldapsearch -ZZ utility from any of the servers. The syncprov overlay is loaded and configured on the provider. The consumers have the following (redacted, with unique rid values) olcSyncRepl: olcSyncrepl: {0}rid=1 provider=ldap://[LDAP_DNS] bindmethod=simple bi nddn="[SYNC_USER]" credentials=[SYNC_PASS] searchbase="[L DAP_BASE]" logbase="cn=accesslog" logfilter="(&(objectClass=auditWr iteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog starttls=critical tls_reqcert=demand Unfortunately, on both consumers can't seem to be able to actually start the TLS connection: slapd[1257]: slap_client_connect: URI=ldap://[LDAP_DNS] Error, ldap_start_tls failed (-11) slapd[1257]: do_syncrepl: rid=001 rc -11 retrying And the provider shows the following errors: slapd[2126]: conn=1586 fd=100 ACCEPT from IP=[CONSUMER_IP]:35500 (IP=0.0.0.0:389) slapd[2126]: conn=1586 op=0 EXT oid=1.3.6.1.4.1.1466.20037 slapd[2126]: conn=1586 op=0 STARTTLS slapd[2126]: conn=1586 op=0 RESULT oid= err=0 text= slapd[2126]: conn=1586 fd=100 closed (TLS negotiation failure) Is there anything that I'm missing? Cheers, -- Xavier

9 years, 2 months

Re: Disallow ldap operations without start_tls

by Joshua Schaeffer

On 02/15/2016 09:00 PM, Howard Chu wrote: > ldap://host/????starttls > Thanks Howard, I'll do that. Joshua

9 years, 3 months

Re: STARTTLS vs LDAPS

by Michael Ströder

On 4/1/22 10:59, Ulrich Windl wrote: >>> Quanah Gibson-Mount <quanah(a)fast-mail.org> schrieb am 31.03.2022 um 17:45 >> 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). Yes, but you would have to misconfigure this deliberately since Linux distros ship with rather safe crypto policy defaults. In opposite to that it's quite likely that StartTLS fails accidently. Ciao, Michael.

3 years, 2 months

Re: problem with syncrepl and STARTTLS

by Quanah Gibson-Mount

--On Friday, June 02, 2017 11:01 AM +0200 r0m5 <r0m5(a)r0m5.eu> wrote: > > Hello, > > I am facing an issue with syncrepl and STARTTLS on 389 port. The kind of > problem happening only sometimes, and disappearing "by itself". I use > Debian Jessie, OpenLDAP 2.4.40+dfsg-1+deb8u2. 2.4.40 is 2.5 years old, 5 point releases behind, and had significant known replication issues. I believe there is a build of 2.4.44 in backports for Jessie. I would advise using that instead. As far as debug logging, you would need to use "-d -1" to slapd, rather than attempting to set the loglevel to -1, as some debug logging is only possible via the slapd daemon. But your first step is to move to a current release. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

8 years

Re: Issue with slapd and Google LDAP Integration (lowercase user)

by tmp 2810

Thank you for the response! No, no... these are example data that I put together to understand how Google users are structured and the issue that uppercase letters are causing me. In the Google LDAP audit, I see that the user fails and appears in lowercase. Once again, I apologize; I ran so many tests that I accidentally copied one where the binddn was incorrect. The target looks more like this: ## example.com uri "ldaps://ldap.google.com/dc=proxy" suffixmassage "dc=proxy" "dc=example,dc=com" lastmod off readonly on idassert-bind bindmethod=simple binddn="cn=ChiwewDaw" credentials="password-fake" tls_reqcert=demand tls_reqsan=demand starttls=critical tls_cert=/root/ldapcerts/ldap_cert.crt tls_key=/root/ldapcerts/ldap_cert.key tls_cacert=/root/ldapcerts/ca/gtsr1.pem if i use: idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_reqcert=demand tls_reqsan=demand starttls=critical i have the error : "Unauthenticated"

7 months

Re: STARTTLS vs LDAPS

by Howard Chu

Michael Ströder wrote: > 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. At this point it could just be an Informational RFC, describing current practice. > > Ciao, Michael. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 years, 2 months

openldap-technical search results for query "starttls"