Search results for "starttls" - openldap-technical

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.

6 years, 5 months

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

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, 3 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

8 years, 7 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

8 years, 8 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.

2 years, 7 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>

7 years, 5 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/

2 years, 7 months

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"

3 days, 19 hours

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

by Dieter Kluenter

Robert Heller <heller(a)deepsoft.com> writes: R> 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. OK, back to basics, 1. check whether sssd is compiled with openssl's libcrypto: ldd sssd which should present something like libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 2. check whether slapd has been build with openssl ldd slapd, which should present: libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 3. verify your certificates: openssl verify -CAfile <file> <hostcert> 4. run slapd -h ldaps:///; than test connection: openssl s_client -connect <host:636> -CAfile <file> -Dieter >> 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 [...] -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

7 years, 1 month

openldap-technical search results for query "starttls"