Hi Michael,
On Monday, 28. May 2012, Michael Ströder wrote:
> Peter Marschall wrote:
> > On Monday, 28. May 2012, Philip Guenther wrote:
> >> On Mon, 28 May 2012, Michael Ströder wrote:
> >>> Peter Marschall wrote:
> >>>> how do the openldap tools technically verfify certificates with
> >>>> ldapi:// ?
> >>>
> >>> Which certs do you want to verify?
> >>
> >> I assume the answer is "the one the server returns when you do StartTLS
> >> on the ldapi:// connection".
> >
> > Correct.
>
> So if the quite liberal RFC 6125 does not provide any inspiration this
> boils down to being undefined. StartTLS over LDAPI is an unusal scenario
> anyway.
Thanks for your reply.
It helps a bit ("looking at the issue from the standard angle"), but
my question was how the openldap tools do it.
Best
Peter
--
Peter Marschall
peter(a)adpm.de
On 11/04/2012 11:59 PM, Dan White wrote:
> On 11/04/12 23:13 +0100, admus wrote:
>> Hello,
>> I'm following
>> https://help.ubuntu.com/12.04/serverguide/openldap-server.html#openldap-tls…
>> how to:
>> LDAP serwer starts correctly but when I tries to test StartTLS:
>> ldapsearch -x -H ldap:/// -ZZ -d -1
>> I gets the following error:
>> TLS: peer cert untrusted or revoked (0x42)
>> TLS: can't connect: (unknown error code).
>> ldap_err2string
>> ldap_start_tls: Connect error (-11)
>> additional info: (unknown error code)
>> Any idea?
>
> Your hostname will need to match the certificate you have installed. '-H
> ldap:///' will, instead, need to include the hostname matching your
> certificate.
>
> For project documentation, see chapter 16 of the OpenLDAP Administrator's
> Guide, slapd-config(5), ldap.conf(5), and ldapsearch(1).
>
ldapsearch -x -H ldap://ldap1.example.com -ZZ -d -1
Does not help, same error. CN in my certificate is ldap1.example.com.
On Mon, Nov 05, 2012 at 08:29:45AM +0100, Admus wrote:
> On 11/04/2012 11:59 PM, Dan White wrote:
> >On 11/04/12 23:13 +0100, admus wrote:
> >>Hello,
> >>I'm following
> >>https://help.ubuntu.com/12.04/serverguide/openldap-server.html#openldap-tls…
> >>how to:
> >>LDAP serwer starts correctly but when I tries to test StartTLS:
> >>ldapsearch -x -H ldap:/// -ZZ -d -1
> >>I gets the following error:
> >>TLS: peer cert untrusted or revoked (0x42)
> >>TLS: can't connect: (unknown error code).
> >>ldap_err2string
> >>ldap_start_tls: Connect error (-11)
> >> additional info: (unknown error code)
> >>Any idea?
Well, your error does say 'untrusted or revoked'. Have you taken steps to
have your client trust the certifcate?
--
Brian Reichert <reichert(a)numachi.com>
BSD admin/developer at large
Hi all,
Can anyone please provide me some link for enabling "ldaps" i have followed
many links but continuously failing to do so. I have also tried "startTLS"
but its not compatible with Apache Knox. Any help would be appreciated.
Thanks
On 12/02/2011 02:50 PM, Hugo Deprez wrote:
> Hello Philip,
>
> thank you for your explanation.
>
> This is more clear now.
>
> So I changed my configuration like :
>
> Syncrepl rid=003
> provider=ldaps://my.server:1024/
> type=refreshOnly
> retry="60 10 600 +"
> interval=00:00:00:10
> searchbase="dc=my,dc=domain"
> scope=sub
> schemachecking=on
> bindmethod=simple
> tls_reqcert=demand
> tls_cert=/etc/ssl/certs/ldap-cert.pem
> tls_cacert=/etc/ssl/certs/ldap-cert.pem
> tls_key=/etc/ldap/ssl/ldap-key.pem
> binddn="cn=syncrepluser..."
> credentials=********
>
> I added the tls_key, tls_cacert, tls_reqcert parameter.
> The tls option are using the certificate and the key of the LDAP Provider.
>
> The last thing I don't understand is that the tls_key is needed. So I
> need to deploy the private key of the provider to each consumer.
>
> I though the certificate would be sufficient ?
No you don't have to deploy the private key!
In syncrepl, just define the tls_cacert, and it works.
>
> Regards,
>
>
>
>
>
> On 18 October 2011 06:28, Philip Guenther
> <guenther+ldaptech(a)sendmail.com> wrote:
>> On Sun, 16 Oct 2011, Hugo Deprez wrote:
>>> It seems that the proper configuration for my case is :
>>>
>>> syncrepl rid=003
>>> provider=ldaps://ldap.mydomain.fr:1024/
>>> type=refreshOnly
>>> retry="60 10 600 +"
>>> interval=00:00:00:10
>>> searchbase="dc=mydomain,dc=fr"
>>> scope=sub
>>> schemachecking=on
>>> bindmethod=simple
>>> tls_reqcert=never
>>> binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
>>> credentials=my_password
>>>
>>> It works, but I am confuse with those parameters. If I understand
>>> well, I will never use TLS here, but only ssl ?
>>> Hence, it was a TLS issue ?
>> No, you're using TLS. You're just not using the StartTLS operation.
>>
>> There are two ways to use SSL/TLS: "negotiate-on-connect" and "upgrade
>> from clear". The former is what you get when you use an ldaps:// URL,
>> where the first data the client sends is the raw SSL/TLS ClientHello
>> packet. The latter is what you get when you use an ldap:// URL and have
>> starttls=yes or starttls=critical, where the first data the client sends
>> is LDAP protocol data in the clear, including a StartTLS request. If the
>> server sends a success response to that StartTLS request, then the client
>> starts the SSL/TLS handshake with its ClientHello packet.
>>
>> This should answer why it failed when you tried to combine an ldaps:// URL
>> with starttls=yes: the exchange was already using SSL/TLS and (rightly)
>> libldap won't let you negotiate multiple levels of SSL/TLS encryption.
>>
>> (You may note that I write "SSL/TLS". That's because they're just
>> different versions of the same protocol. Using 'SSL' as a shorthand for
>> "negotiate on connect" and 'TLS' for "upgrade from clear" is poor naming,
>> as the choice of method is orthogonal to the protocol version. Your
>> ldaps:// connection is probably negotiating the TLS 1.0 protocol (aka SSL
>> version 3.1), just as an ldap:// connection using StartTLS may, on a
>> poorly configured server, negotiate SSL 3.0)
>>
>>
>> Next: the fact that you need tls_reqcert=never for TLS negotiation to
>> succeed strongly suggests the problem is either
>> a) the subject and subjectAltName of the cert don't match the hostname in
>> the URL, OR
>> b) the client doesn't have the self-signed CA cert at the root of the
>> signing chain for the server's cert.
>>
>> Those are both necessary to protect the server against Man-in-the-Middle
>> attacks.
>>
>> (It used to be that tls_reqcert=allow would disable check (b) and only
>> perform check (a), or at least that was the case when using the OpenSSL
>> crypto backend, but that behavior has apparently been removed from the
>> version in git as of August. Given the vagaries of the error reporting of
>> the underlying crypto libraries, this was a useful tool in tracking down
>> which check was causing TLS failures. Oh well.)
>>
>> So, does the server's certificate subject or subjectAltName match the
>> hostname from the URL the client is using? Have you verified that the CA
>> at the root of the server's cert's chain really is configured for the
>> client?
>>
>>
>> Philip Guenther
--
Raffael Sahli
public(a)raffaelsahli.com
Switzerland
--On August 4, 2009 3:51:18 PM -0700 Ivan Ordonez
<iordonez(a)nature.berkeley.edu> wrote:
> Hello,
>
> We've been using an ldap based PDC from quite a while. Now we're
> suddenly having trouble getting our main fileserver to talk with the
> PDC.
>
> samba-3.2.13 on solaris 10.
>
> Here is our smb.conf global defs:
>
> Server role: ROLE_DOMAIN_MEMBER
> [global]
> workgroup = CNRDOM
> server string = nature (Samba %v)
> security = DOMAIN
> passdb backend = ldapsam:ldaps://169.229.xxx.yyy
> log level = 5
> log file = /var/log/samba/log.%m
> name resolve order = wins host lmhosts
> os level = 65
> local master = No
> domain master = No
> dns proxy = No
> wins support = Yes
> ldap ssl = start tls
ldaps:// and startTLS are mutually exclusive. Pick one and only one.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Hi,
During initial communication setup with LDAP server with TLS on we are
doing:
ldap_initialize()
ldap_set_option()
ldap_start_tls_s()
ldap_sasl_bind_s()
and
We are running the LDAP server remotely
We observed that ldap_start_tls_s() is taking around 15 sec time to execute.
Anybody has any idea why this is taking this much time?
Please help
Thanks,
Sayantan Ray
On 15/10/2011 2:30 μμ, Olivier Guillard wrote:
> If you youldaps:// add this :
>
> tls_reqcert=demand
> and add starttls=critical
In my installations, syncrepl doesn't work with these directives
(although ldapsearch using ldaps: works fine).
I wonder what may be the cause...
Nick
Hello,
I just try to set up the replication for cn=config using the example
from the documentation:
https://www.openldap.org/doc/admin24/replication.html
I have 3 Provider in an MMR with delta-syncrpl. Delta-syncrepl is
working fine I can add and change objects from all three providers.
Then I set up the replication for cn=config. Here are the changes I made
on all three providers:
-----------
olcServerID: 1 ldap://hm-01.example.net
olcServerID: 2 ldap://hm-02.example.net
olcServerID: 3 ldap://hm-03.example.net
...
# {0}config, config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
olcRootDN: cn=admin,cn=config
olcRootPW: {SSHA}Uyelb0kyqWuEqr4QmfvrpDaD7VYjeU8h
olcSyncrepl: {0}rid=001 provider=ldap://hm-01.example.net
binddn="cn=admin,cn=
config" bindmethod=simple credentials=geheim searchbase="cn=config"
type=ref
reshAndPersist retry="5 5 300 5" timeout=1 starttls=yes
olcSyncrepl: {1}rid=002 provider=ldap://hm-02.example.net
binddn="cn=admin,cn=
config" bindmethod=simple credentials=geheim searchbase="cn=config"
type=refr
eshAndPersist retry="5 5 300 5" timeout=1 starttls=yes
olcSyncrepl: {2}rid=003 provider=ldap://hm-03.example.net
binddn="cn=admin,cn=
config" bindmethod=simple credentials=geheim searchbase="cn=config"
type=refr
eshAndPersist retry="5 5 300 5" timeout=1 starttls=yes
olcMirrorMode: TRUE
# {0}syncprov, {0}config, config
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
----------------
It's same on all three providers.
When I do a change on the first provider (hm-01) the change will be
replicat to hm-02 and hm-03. But if I try to change or add an ACL on one
either hm-02 or hm-03 the change will not be replicated to the other
providers.
I'm using Debian 10 with the OpenLDAP-packages from debian-backport
version 2.4.57.
Before setting up the replication for cn=config I checked that the
configuration on all three providers are the same.
So what did I do wrong or did I miss something
Stefan
Am Sun, 26 Feb 2012 12:39:26 +0100
schrieb Daniel Pocock <daniel(a)pocock.com.au>:
>
>
> On 26/02/12 12:15, Dieter Klünter wrote:
> > Am Sun, 26 Feb 2012 11:49:14 +0100
> > schrieb Daniel Pocock <daniel(a)pocock.com.au>:
> >
> >>
> >>
> >>
> >> Is there some way to ensure that a client who connects on port 389
> >> can do nothing without StartTLS?
> >>
> >> Or is it necessary to just disable port 389 and only listen for
> >> ldaps:/// ?
> >
> > read on TLS OPTIONS in
> > man ldap.conf(5) and man slapd.conf(5)
> >
>
> Thanks for the fast reply
>
> I'm not keen to rely on ldap.conf (client side config) - I want to
> enforce a preference for TLS from the server side, to avoid a
> situation where some application might be configured non-TLS by
> mistake.
>
> I've looked at the TLS options and I have TLS running fine already. I
> notice the TLSCipherSuite option sets the cipher level within TLS, but
> it doesn't appear to guarantee that TLS is used.
>From man slapd.conf
TLSVerifyClient <level>
demand | hard | true
These keywords are all equivalent, for
compatibility reasons. The client certificate is
requested. If no certificate is provided, or a bad
certificate is provided, the session is immediately terminated.
>
> To make an analogy, in postfix, I require `plain' authentication: but
> the client is not allowed to try to authenticate until it has done
> StartTLS, because I never want a client to try sending a password
> over a channel that is not encrypted.
Postfix is a LDAP client, thus all client configurations apply
according to man ldap.conf(5).
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
