Search results for "starttls" - openldap-technical

problem with ldap backend

by Alex Samad - Yieldbroker

Hi I am trying to setup a connection from openldap to MS AD I am using this dn: olcDatabase={3}ldap objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {3}ldap olcSuffix: dc=xyz,dc=com olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=Subschema" by * read olcAccess: {2}to * by self write by users read by anonymous auth olcReadOnly: TRUE olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcSizeLimit: 500 olcDbURI: "ldap://dc101. xyz.com ldap://dc201. xyz.com" olcDbRebindAsUser: TRUE olcDbChaseReferrals: TRUE This works fine when I pass a bind DN. I would like to convert this to allow anon access to ldap, which does a user bind to MS AD so I added this olcdbaclbind: bindmethod=simple binddn="CN=ad readonly,OU= xyz,DC= xyz,DC=com" credentials="secret" starttls=no but it is not working, I can not make a anon search request, they retrieve any thing frome the MSAD ldap server. Thanks

13 years, 2 months

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

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>

6 years, 4 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

17 years, 4 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

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

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

13 years, 6 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>

6 years, 4 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/

14 years, 3 months

RE: OpenLDAP Pass-through Authentication

by Dino Edwards

> As I said, you'll need to adjust for your environment. You also will likley need to > moduleload the remoteauth overlay. Thanks I appreciate you taking the time to assist. Trying to wrap my head around all this. The olcRemoteAuthDNAttribute: seeAlso, is that a an attribute that's supposed to be present in my LDAP structure? The documentation is not very clear on this. Let's say I need to authenticate against an AD domain with the following settings over 389 or 636: Domain server: dc01.domain.tld What exactly do I need to put in the remoteauth.ldif file? I have the following but it's not even trying to authenticate with the remote server. It simply fails auth. I have added the user in openldap with the UserPassword value empty: dn: cn=module{2},cn=config objectClass: olcModuleList cn: module{1} olcModulePath: /opt/bitnami/openldap/lib/openldap olcModuleLoad: remoteauth.so dn: olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRemoteAuthCfg olcOverlay: {6}remoteauth olcRemoteAuthTLS: starttls=yes tls_reqcert=never olcRemoteAuthMapping: default ldap://dc01.domain.tld:389 olcRemoteAuthDNAttribute: seeAlso olcRemoteAuthDomainAttribute: maildrop olcRemoteAuthDefaultDomain: default olcRemoteAuthDefaultRealm: ldap://dc01.domain.tld:389 olcRemoteAuthStore: FALSE olcRemoteAuthRetryCount: 3 Thanks

3 months, 4 weeks

openldap-technical search results for query "starttls"