Michael Ströder wrote:
> We're using self-compiled OpenLDAP 2.4.27 under RHEL 6.1 linked against
> OpenSSL 1.0.0 libs shipped with RHEL.
>
> (some names are consistently obfuscated herein to keep real names confidential)
>
> Unfortunately we can't get StartTLS to work. It always fails:
>
> # /opt/xxxdir/bin/ldapsearch -x -ZZ ldap://ldap-srv01.rz.domain
> ldap_start_tls: Connect error (-11)
> additional info: TLS: hostname does not match CN in peer certificate
> # /opt/xxxdir/bin/ldapsearch -x -ZZ ldap://ldap.domain
> ldap_start_tls: Connect error (-11)
> additional info: TLS: hostname does not match CN in peer certificate
>
> But OpenSSL lists the (IMO correct) hostnames in the server's certificate:
>
> ---------------------------------- snip ----------------------------------
> Subject: CN=ldap.domain,OU=xxx,O=xxx,C=DE
> [..]
> X509v3 Subject Alternative Name:
> email:certificate@xxx.domain,
> DNS:ldap.domain,
> DNS:ldap-srv01.rz.domain,
> DNS:ldap-srv02.rz.domain
> ---------------------------------- snip ----------------------------------
>
> Is the hostname check confused by the email in the first subjectAltName
> sequence value?
I tried to understand the code in function tlso_session_chkhost() in
libraries/libldap/tls_o.c (RE24) but got totally confused by the use of vars
ntype and gn->type.
Ciao, Michael.
On 9/26/2011 11:33, Dan White wrote:
> On 26/09/11 10:18 -0400, criderkevin(a)aol.com wrote:
>>
>> I'm struggling with the need for SSL...
>>
>> We will use our new LDAP for apps. These servers are all locally
>> housed so
>> each app server will talk to the LDAP server over our network. (why)
>> Would
>> we need SSL?
>>
>> What about for mail services? It seems to me that our mail server would
>> also talk directly to the LDAP server...what am I missing here that
>> dictates the use of SSL with LDAP? I could see if one had their LDAP
>> open
>> to be accessible direct access from off-network. Perhaps SSL is used
>> simply as a means to authenitcate?
>
> If you're performing TLS authentication, using client certificates, via
> STARTTLS, then using X.509 provides for a strong authentication mechanism
> using SASL (EXTERNAL).
>
> That's the one benefit that I know of beyond the obvious session based
> encryption that you obtain using certificates.
>
The tls/ssl also protects against packet interception, which while it
may seem obvious that noone can or will, I assure you someone could and
might.
On 11/29/2011 01:56 PM, Jayavant Patil wrote:
>
> >Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
> >Hi
>
> >I think you mean SSL connection or the STARTTLS Layer...?
> >Please read the manual http://www.openldap.org/doc/admin24/tls.html
> Ok.
>
> >And tree security:
> >On my server, a client user can only see his own object:
> Are you using simple authentication mechanism?
>
Both simple and/or SASL with GSSAPI
> >Maybe create a rule like this:
> >access to filter=(objectClass=
> >simpleSecurityObject)
> > by self read
> > by * none
>
> I am not getting what the ACL rule specifies. Any suggestions?
Just an idea, this rule allows an authenticated user access only his own
object.
He can't see other simpleSecurityObject Objects.... or whatever
But for your subject; the best setup is using TLS.....
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
--
Raffael Sahli
public(a)raffaelsahli.com
I'm trying to set up slapo-pcache using cn=config, and this is my settings:
dn: olcDatabase={1}ldap,cn=config
objectClass: olcConfig
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
objectClass: top
olcDatabase: {1}ldap
olcRootDN: cn=admin,cn=config
olcAccess: {0}to * by * read
olcDbACLBind: bindmethod=simple binddn="ou=group,dc=remote"
credentials="password" tls_cacert="/etc/ssl/certs/ca-certificates.crt"
starttls=yes
olcDbURI: ldap://remote.host
olcSuffix: dc=remote
dn: olcOverlay={0}pcache,olcDatabase={1}ldap,cn=config
objectClass: olcPcacheConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}pcache
olcPcache: hdb 10000 1 50 100
olcPcacheAttrset: 0 member
olcPcacheTemplate: "(objectClass=)" 0 3600
dn: olcDatabase={0}hdb,olcOverlay={0}pcache,olcDatabase={1}ldap,cn=config
objectClass: olcPcacheDatabase
objectClass: olcHdbConfig
objectClass: olcDatabaseConfig
objectClass: olcConfig
objectClass: top
olcDatabase: {0}hdb
olcDbDirectory: /var/lib/ldap/cache
olcDbIndex: objectClass eq
olcDbIndex: pcacheQueryid eq
But each time I'm trying to run
ldapsearch -b"cn=test2,ou=group,dc=remote" '(objectClass=*)' member
I'm getting QUERY NOT ANSWERABLE/QUERY NOT CACHEABLE errors in the log.
Besides, it is impossible to modify attributes
olcPcacheTemplate/olcPcacheAttrset:
modify/add: olcPcacheTemplate: no equality matching rule
Can anyone confirm that the one have managed to make slapo pcache
working on 2.4.31?
Is there a specific way, i have to configure the slapd to listem to 636
port..?
And does the 389 search is a secure search...?
Is there a particular way of Starting the TLS operation..?
Thanks in advance
On Fri, Jan 4, 2013 at 4:31 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote:
> --On Friday, January 04, 2013 4:09 PM -0800 Bheeshma SM <
> bheeshma.manjunath(a)gmail.com> wrote:
>
>
>> Hi guys.
>>
>> I have a problem in Openldap 2.4.33 on RHEL 5.8
>>
>> I am able to do a " ldapsearch -x -p 389 -h -D<> -w<> -b<> "
>>
>> but i am not able to do
>>
>> " ldapsearch -x -p 636 -h -D<> -w<> -b<>
>>
>
> Sounds like slapd is not configured to listen to port 636. No amount of
> mucking with ldapsearch is going to change that.
>
> I would note that you can do secure searches over port 389 just fine.
> Simply use the startTLS operation.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
On 2013.07.31 06.36, Tony Davis wrote:
> Hi,
>
> I wonder if anyone can help me with a question I have regarding an
> openldap setup on Redhat / Centos 5.8 using openldap-2.3.43.
>
> I am trying to setup replication, I have set this up using the simple
> bind method, which stores a password for the replication in the config.
> (This works) but I wondered if there was a way to have this replication
> take place using ssl certificates without the need to store the unhashed
> password in the slapd.conf? Is this possible? or do I still have to
> specify a replication user and pass, but all the auth takes place over ssl?
you are talking about two different things. one is encryption, and one
is authentication.
making some basic assumptions [e.g. that the provider is properly
configured for encryption], using starttls means that communication is
encrypted, regardless of how you might be authenticating or what sasl
mechanism might be in use.
as far authentication goes, if you want to do certificate based
authentication, first read the section in the admin guide which covers
this [chapter 16. using tls]. then, use ldapsearch or friends for the
exercise of set up and testing of the provider. once that is working,
translate those settings to the consumer syncrepl config element.
on a related note, the tls_cert/tls_key syncrepl settings are to specify
the key and cert of the client [e.g. the consumer]. not the provider.
those files are what the consumer will use when authenticating to the
provider via certificates.
-ben
On 09/25/13 13:43 -0700, Chad Scott wrote:
>I'm having a lot of trouble with replication when using SSL. If I configure
>everything exactly the same without SSL, it works flawlessly. The instant I
>try to encrypt traffic, one or both servers will deadlock, even after
>restart.
Does slapd still respond? If so, verify that your entropy is not being
depleted for your ssl connections. I believe by default openssl uses
/dev/random which can block. Check /proc/sys/kernel/random/entropy_avail.
>I'm configuring according to the instructions at
>http://www.openldap.org/doc/admin24/replication.html#N-Way Multi-Master,
>except using ldaps:// instead of ldap://.
>
>In cn=config, I've setup:
>olcTLSCACertificateFile: /etc/openldap/certs/Operations_CA_Certificate.pem
>olcTLSCertificateFile: /etc/openldap/certs/ldap.pem
>olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.key
>
>I've also tried using STARTTLS over ldap:// and it seems to make no
>difference.
>
>Permissions are right and I can connect via SSL from clients without issue.
>
>I'm completely stumped as to what might be going on. Has anyone seen this
>before?
>
>This is running on Scientific Linux 6 with the following packages:
>openldap-2.4.23-32.el6_4.x86_64
>openldap-clients-2.4.23-32.el6_4.x86_64
>openldap-servers-2.4.23-32.el6_4.x86_64
--
Dan White
Quanah Gibson-Mount wrote:
>
>
> --On Wednesday, October 9, 2019 3:23 PM +0000 Howard.Gillison(a)gvltec.edu wrote:
>
>>
>>
>> Good morning to you,
>
> I suggest you read the OpenLDAP client code and the libldap code which fully utilizes the API to make connections with or without TLS. I think the *function*> you're looking for is ldap_start_tls_s (at least for startTLS over port 389):
Since he mentions port 636, he should just be using an ldaps://<host> URL with ldap_initialize().
>
> <https://www.openldap.org/software/man.cgi?query=ldap_start_tls_s&apropos=0&…>
>
>> From the library, I would suggest perusing libldap/init.c, libldap/open.c,
> libldap/options.c, and libldap/unbind.c
>
> Since this is open source software it is of course trivial to access the code and have working examples before you.
>
> Regards,
> Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Friday, November 17, 2017 12:53 PM +1000 William Brown
<wibrown(a)redhat.com> wrote:
Hi William,
> Hey mate,
>
> Just want to point out there are some security risks with ssf settings.
> I have documented these here:
>
> https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.html
>
> This is a flaw in the ldap protocol and can never be resolved without
> breaking the standard. The issue is that by the time the ssf check is
> done, you have already cleartexted sensitive material.
I think what you mean is: There is no way with startTLS to prevent possible
leakage of credentials when using simple binds. ;) Your blog certainly
covers this concept well, but just wanted to be very clear on what the
actual issue is. ;) I've been rather unhappy about this for a long time as
well, and have had a discussion going on the openldap-devel list about
LDAPv4 and breaking backwards compatibility to fix this protocol bug.
Another note -- The reason GSSAPI shows up as an SSF of 56 is because it
has been hard coded that way in cyrus-sasl. Starting with cyrus-sasl
version 2.1.27, which is near release, the actual SASL SSF is finally
passed back into the caller. It may be worthwhile noting this in your blog
post. ;)
Warm regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
