Search results for "starttls" - openldap-technical

Re: Reg OpenLdap on Ubuntu

by Dieter Kluenter

Asimananda Mohanty <asimananda.mohanty(a)gmail.com> writes: > Hi Dieter, > > I understand. But my concern is if ssl was not enabled properly, then I should not be > able to use -ZZ or ldaps url in commands like ldapsearch. Please correct me if I am > wrong. If you can connect to slapd via startTLS or TLS than slapd has been setup correctly. > If ssl is enabled already, then I am unable to understand why ldaps doesn't work from > apache point of view. Back to my first mail. Ths is a question you have to raise on a solaris related mailing list or news group. - Check the libraries apache has been built with, - check whether you can connect from solaris host to ubuntu host on port 389 and 636 , - check whether apache is able to verify the certificate presented, - debug slapd to whatch the apache connection. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°37'09,95"N 10°08'02,42"E

15 years, 1 month

Re: Spurious Start TLS failed errors on proxyed bind OpenLDAP 2.4.40

by Quanah Gibson-Mount

--On Thursday, January 17, 2019 4:52 PM +0000 Howard Chu <hyc(a)symas.com> wrote: >> 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: > > These aren't spurious - your TLS library has genuinely failed to start a > session. Which TLS library are you using? What OS are you running on? The > most common cause for periodic failures is running out of entropy for the > PRNG. They noted RHEL7 and 2.4.40, which would mean MozNSS, as the most recent RHEL7 build of 2.4.44 switched back to OpenSSL. I would just add this to the many reasons not to use RHEL for OpenLDAP. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 years, 10 months

SSL/TLS connection on port 389

by 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 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). 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. Thanks in advance, Chris This e-mail may contain information which is confidential, legally privileged and/or copyright protected. This e-mail is intended for the addressee only. If you receive this in error, please contact the sender and delete the material from your computer

16 years, 9 months

Re: ssf settings for SASL and TLS

by Dieter Klünter

Am Thu, 18 Feb 2016 22:20:16 -0700 schrieb Joshua Schaeffer <jschaeffer0922(a)gmail.com>: > On 02/18/2016 03:19 AM, Dieter Klünter wrote: > > Am Wed, 17 Feb 2016 20:25:56 -0700 > > schrieb Joshua Schaeffer <jschaeffer0922(a)gmail.com>: > > > >> What is the proper way to setup SASL and TLS with different > >> security strength factors? I've setup SASL on my OpenLDAP server > >> so that it can connect to my Kerberos server using GSSAPI. I also > >> have TLS setup for simple auth. My database config is below: > > [...] > >> olcSecurity: sasl=56 simple_bind=256 ssf=256 > > > > ssf=x specifies the overall security, a value '1' enables security. > > This setting would meet your requirements: > > olcSecurity: ssf=1 sasl=56 tls=256 > > > > > > -Dieter > > > > I updated olcSecurity and now I get the following when using simple > auth: > > root@immortal:/var/log/kerberos# ldapsearch -LLL -x -D > cn=admin,dc=harmonywave,dc=com -W -H > ldap://baneling.harmonywave.com/????starttls -b dc=harmonywave,dc=com > Enter LDAP Password: ldap_bind: Confidentiality required (13) > additional info: SASL confidentiality required > > I see this in the logs: > > Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 ACCEPT from > IP=10.1.10.12:55750 (IP=0.0.0.0:389) Feb 18 22:19:04 baneling > slapd[22171]: conn=1005 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Feb 18 > 22:19:04 baneling slapd[22171]: conn=1005 op=0 STARTTLS Feb 18 > 22:19:04 baneling slapd[22171]: conn=1005 op=0 RESULT oid= err=0 > text= Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 TLS > established tls_ssf=256 ssf=256 [...] You still have a overall security ssf=256 and it seems your TLS session used a key length lower than 256 bit, check your TLS configuration. -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

8 years, 9 months

Re: slapd-meta

by Dirk Kastens

Hi, >>> dn: olcDatabase={3}meta,cn=config >>> objectClass: olcDatabaseConfig >>> objectClass: olcMetaConfig >>> olcDatabase: {3}meta >>> olcSuffix: dc=loc1,dc=root >>> olcSuffix: dc=loc2,dc=root >>> olcSuffix: dc=loc3,dc=root >> >> I've never used meta backend, but the above doesn't look valid to me >> (multiple suffixes). The man page shows a single suffix, with URI >> directives for additional representations of the DB. Indeed, you can only have one olcSuffix. This is the suffix under which your source URIs will be presented. I'm running a meta backend with the following configuration: I have two source servers, first and second. Both have a subtree ou=people,ou=mydomain. The trees are combined on the meta server under the new suffix ou=newsuffix,dc=mydomain as ou=apeople and ou=bpeople. dn: olcDatabase={1}meta, cn=config olcDatabase: {1}meta olcSuffix: ou=newsuffix,dc=mydomain objectClass: olcDatabaseConfig objectClass: olcMetaConfig dn: olcMetaSub={0}uri, olcDatabase={1}meta, cn=config olcDbURI: "ldap://first.source.server/ou=apeople,ou=newsuffix,dc=mydomain" objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbRewrite: {0}suffixmassage "ou=apeople,ou=newsuffix,dc=mydomain" "ou=people,dc=mydomain" olcDbIDAssertBind: mode=none flags=override,prescriptive,proxy-authz-critical bindmethod=simple binddn="cn=myadmin" credentials="secret" starttls=yes tls_cert="/etc/openldap/certs/mycert.pem" tls_key="/etc/openldap/certs/mycert.key" tls_cacert="/etc/openldap/cacerts/cacerts.pem" tls_cacertdir="/etc/openldap/cacerts" tls_reqcert=demand dn: olcMetaSub={1}uri, olcDatabase={1}meta, cn=config olcDbURI: "ldap://second.source.server/ou=bpeople,ou=newsuffix,dc=mydomain" objectClass: olcMetaTargetConfig olcMetaSub: {1}uri olcDbRewrite: {0}suffixmassage "ou=bpeople,ou=newsuffix,dc=mydomain" "ou=people,dc=mydomain" olcDbIDAssertBind: mode=none flags=override,prescriptive,proxy-authz-critical bindmethod=simple binddn="cn=myadmin" credentials="secret" starttls=yes tls_cert="/etc/openldap/certs/mycert.pem" tls_key="/etc/openldap/certs/mycert.key" tls_cacert="/etc/openldap/cacerts/cacerts.pem" tls_cacertdir="/etc/openldap/cacerts" tls_reqcert=demand Hope this helps. Dirk

8 years, 8 months

Re: Enforce remote SSL/TLS

by Raffael Sahli

On 11/24/2011 03:53 PM, Kasper Loopstra wrote: > On 11/23/2011 05:51 PM, Dan White wrote: >> On 23/11/11 17:06 +0100, Kasper Loopstra wrote: >>> Dear list, >>> >>> We are using PAM to authenticate posixUsers against OpenLDAP. This >>> works great, and allows 'local' (ssh) logins. However, we also use >>> LDAP for a number of other services, including remote access and >>> editing via other software. This means we would like to keep our >>> users passwords as secure as possible, and enforce encrypted logins >>> for all remote hosts. However, PAM should still be able to >>> authenticate. The manner of encryption is not really important, it >>> just has to be strong enough to be useful over the internet, and >>> usable for all (or most) clients. >>> >>> We have tried various solutions with ssf directives in >>> /etc/ldap/slapd.conf as well as the security tls=1 directive. All of >>> these attempts broke PAM. >> >> Which PAM ldap module are you using? with PADL's module, you'd want to >> configure 'ssl on' (for ldaps:///) or 'ssl starttls' (for starttls over >> ldap:///) and also configure the tls_* settings appropriately. >> > > We're using libpam-ldap from Debian, which is indeed the PADL module > according to the comments. Is it really necesary to use SSL when > communicating within localhost? If it is, that's fine, it just doesn't > seem to be the right way to handle local traffic. > No, it isn't necesary, or you can use ldapi:// >> For your slapd configuration, see the slapd.conf manpage - the TLS* >> options, as well as the 'security' option. If you are wishing to perform >> secure connections over ldaps:///, verify that in your slapd init >> script, >> that you are passing 'ldaps:///' as one of your '-h' command line >> parameters. >> > > According to the init file provided by Debian, it seems to be using > the conf file for this information. Is that correct/possible, or > should we be asking the Debian people? Debian takes the default config /etc/default/slapd for daemon related parameters > > Thanks for the quick response, > > Kasper Loopstra > -- Raffael Sahli public(a)raffaelsahli.com

12 years, 11 months

Re: Spurious Start TLS failed errors on proxyed bind OpenLDAP 2.4.40

by Quanah Gibson-Mount

--On Tuesday, January 22, 2019 3:10 PM +0200 Janne Peltonen <janne.peltonen(a)helsinki.fi> wrote: > Quanah Gibson-Mount wrote: >>>> 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: >>> These aren't spurious - your TLS library has genuinely failed to start a >>> session. Which TLS library are you using? What OS are you running on? >>> The most common cause for periodic failures is running out of entropy >>> for the PRNG. >> They noted RHEL7 and 2.4.40, which would mean MozNSS, as the most recent >> RHEL7 build of 2.4.44 switched back to OpenSSL. I would just add this to >> the many reasons not to use RHEL for OpenLDAP. > > The fact that they keep switching the TLS libraries they're linking to? I > can roll out my own RPMs and keep them linked to the very same library > all the time, but do you think linking to OpenSSL could help resolve my > issue? Running out of entropy with only a few starttls calls per second, > or only a few ldaps connections per second, seems to be a bit weird to me. Hi Janne, RedHat pursued linking OpenLDAP against MozNSS against the advice of the OpenLDAP foundation. We reluctantly included those patches in the 2.4 series, but they were a constant source of problems. RedHat never disclosed to the OpenLDAP project why exactly they abandoned MozNSS and switched back to OpenSSL. Regardless, you should at the least update to the latest RHEL7 version from RH to see if it offers any relief from the issue you are encountering. There are also alternatives to the RH build that you can use on RH, such as: a) The Symas OpenLDAP for Linux packages (currently at 2.4.47). See <https://symas.com/linux-openldap-support-symas-corporation/>, <https://symas.com/linuxopenldap/>. These packages are provided for free, with the option of having paid support. b) The LTB project: <https://ltb-project.org/documentation/openldap-rpm#yum_repository> c) The Symas commercial version of OpenLDAP, which requires a support contract and has additional features: <https://symas.com/symasopenldap/> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 years, 9 months

Re: Error: CSN too old and replication fails

by Howard Chu

Jérémy Wagner wrote: > 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 ? Your current configuration is unsupported. Ordinarily when you configure multiple consumers in a DB it is assumed they are all pointing at different providers, and each provider will have a different serverID. In your case, since it is all a single provider with a single serverID, all 3 consumers will share a single contextCSN. Any update in any branch will update the contextCSN to that newest state. Any updates in other branches that hadn't been received yet (due to random timing between threads) will be received as "too old" because the contextCSN already has a newer state. A workaround for this would be to split each consumer into its own subordinate database, then each will have a private copy of its own contextCSN to work with. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

13 years, 9 months

Re: STARTTLS vs LDAPS

by Quanah Gibson-Mount

--On Thursday, March 31, 2022 3:13 PM -0400 Braiam <braiamp(a)gmail.com> wrote: > > > > > > > On Thu, Mar 31, 2022 at 11:46 AM Quanah Gibson-Mount > <quanah(a)fast-mail.org> wrote: > > > > --On Thursday, March 31, 2022 12:16 PM -0400 Braiam <braiamp(a)gmail.com> > wrote: > >> What would be the process to modify content on the openldap.org page? > > Depends on the content. The main web pages are in the OpenLDAP Web git > repository. > > > This repository seems to be the FAQ: > > > https://git.openldap.org/project/faq/-/tree/master/data/item > > > There's a website project too. I couldn't figure out what markup language > items > on the faq project uses. It uses whatever format the FAQ-O-Matic software uses (<https://sourceforge.net/projects/faqomatic/>) --Quanah

2 years, 7 months

Re: Reg OpenLdap on Ubuntu

by Asimananda Mohanty

Hi Michael, Indeed, it's fine now :) But is there any way that I make the password stuff working as well. Thanks again.... -Asimananda 2009/7/20 Michael Ströder <michael(a)stroeder.com> > Asimananda Mohanty wrote: > > > > The first command works fine (ldapsearch -x -H ldap://ldap-company.com > > <http://ldap-company.com/> -ZZ) but the second one (ldapsearch -x -H > > ldaps://ldap-company.com:636 <http://ldap-company.com:636/> -ZZ) is > > showing error : > > > > *ldap_start_tls: Operations error (1)* > > Sorry, stupid copy&paste by me. Should have another coffee. Omit the -ZZ > in the second command since LDAPS and StartTLS ext.op. cannot be used > together. > > See also: > http://www.openldap.org/faq/data/cache/605.html > > Ciao, Michael. > > -- > Michael Ströder > E-Mail: michael(a)stroeder.com > http://www.stroeder.com >

15 years, 3 months

openldap-technical search results for query "starttls"