Hi
I think you mean SSL connection or the STARTTLS Layer...?
Please read the manual http://www.openldap.org/doc/admin24/tls.html
And tree security:
On my server, a client user can only see his own object:
Maybe create a rule like this:
access to filter=(objectClass=simpleSecurityObject)
by self read
by * none
....
--
Raffael Sahli
public(a)raffaelsahli.com
On 11/28/2011 10:04 AM, Jayavant Patil wrote:
> Hi,
>
> I am using openLDAP-2.4.19-4 on fedora 12 machine. I want to make
> server secure from client nodes so that clients don't hack the server
> node. Hack in the sense that one client doesn't even read the data of
> another client, client doesn't tamper the server directory information
> or try to spoof the server.
>
> Does anybody have any suggestions how to avoid these things in openLDAP?
>
> Thanks in advance.
>
> --
>
> Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
--On Monday, February 04, 2013 9:16 AM +0200 Chris <chris(a)flamengro.co.za>
wrote:
> Thank you for the link. I have downloaded the newest version.
Please keep replies on the list.
> I get the following error message in my messages file when I start slapd
>
> Feb 4 09:15:53 ibm-01 slapd[25637]: [INFO] Using /etc/default/slapd for
> configuration
> Feb 4 09:15:53 ibm-01 slapd[25642]: [INFO] Launching OpenLDAP
> configuration test...
> Feb 4 09:15:53 ibm-01 nslcd[18834]: [a6c6dc] failed to bind to LDAP
> server ldaps://ibm-01: Can't contact LDAP server
> ldpasearch gives the following results
>
> ldapsearch -x -Z -b'dc=flamengro,dc=co,dc=za' uid=izak
> ldap_start_tls: Protocol error (2)
> additional info: unsupported extended operation
Are you using startTLS (extended operation) or ldaps? These are two
different things, and yet it seems you are trying to use both.
--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 07/05/2012 06:18 PM, Gavin Henry wrote:
> HI all,
>
> Taking advantage of the technical list for once and the OpenLDAP
> "related" questions :-)
>
> Anyone messed with ejabberd and OpenLDAP? I'm looking for an XMPP
> server with the best LDAP support.
>
> ejabberd does auth, rosters and vcards but the ability to load a list
> of hosts/domains from LDAP like you can do
> with Exim etc. would rule.
>
> Any suggestions?
i went through this exercise, albeit some time ago, and ultimately
settled on openfire. others i considered at the time were ejabberd,
in.jabberd, jabberd2, openfire, prosody, and tigase. none had what i
would call fantastic ldap support, but openfire came reasonably close,
and offered other benefits which outweighed the areas in which its ldap
implementation lacked. most notably, there was only support for ldaps.
no starttls. i don't recall any providing the ability to read hosts
or domains from ldap. prosody also seemed to have promise, but at the
time, it was too early in it's development stages to be used as a daily
service.
regards
-ben
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
When we start up samba, we see many lines like these in log.smbd:
[2009/08/03 15:40:40, 1] lib/smbldap.c:another_ldap_try(1170)
Connection to LDAP server failed for the 4 try!
and these:
[2009/08/03 15:51:56, 0] lib/smbldap.c:smb_ldap_start_tls(595)
Failed to issue the StartTLS instruction: Can't contact LDAP server
[2009/08/03 15:51:56, 5] lib/smbldap.c:smbldap_search_ext(1199)
smbldap_search_ext: base => [], filter => [(&(|(objectclass=sambaGroupMapping)(sambaGroupType=4))(|(sambaSIDList=S-1-22-1-97)(sambaSIDList=S-1-22-2-97)(sambaSIDList=S-1-1-0)(sambaSIDList=S-1-5-2)(sambaSIDList=S-1-5-32-546)))], scope => [2]
[2009/08/03 15:51:56, 5] lib/smbldap.c:smbldap_close(1103)
The connection to the LDAP server was closed
But over on the PDC (gentoo linux 2.6.29, samba-3.2.13 , openldap-2.4.27)
we see this in tcpdump:
$ tcpdump -vv -c 4 port ldaps
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:51:29.736629 IP (tos 0x0, ttl 61, id 60609, offset 0, flags [DF], proto TCP (6), length 52) nature.Berkeley.EDU.56299 > xxxyyy.CNR.Berkeley.EDU.ldaps: S, cksum 0x6a18 (correct), 1637042825:1637042825(0) win 49640 <mss 1380,nop,wscale 0,nop,nop,sackOK>
15:51:29.736651 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) xxxyyy.CNR.Berkeley.EDU.ldaps > nature.Berkeley.EDU.56299: R, cksum 0x6c68 (correct), 0:0(0) ack 1637042826 win 0
15:51:30.746803 IP (tos 0x0, ttl 61, id 60610, offset 0, flags [DF], proto TCP (6), length 52) nature.Berkeley.EDU.56302 > xxxyyy.CNR.Berkeley.EDU.ldaps: S, cksum 0xa6d9 (correct), 2235230749:2235230749(0) win 49640 <mss 1380,nop,wscale 0,nop,nop,sackOK>
15:51:30.746827 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) xxxyyy.CNR.Berkeley.EDU.ldaps > nature.Berkeley.EDU.56302: R, cksum 0xa929 (correct), 0:0(0) ack 2235230750 win 0
It appears that there is indeed an ldaps conversation going on. We created new certificate on the PDC to see if certificate is the problem to no avail. Same message, and same problem. We disable firewall on the PDC as well and make sure that LDAP ports are all open. The Solaris 10 machine (ROLE_DOMAIN_MEMBER) and the PDC are on two different subnets.
We're hoping someone will recognize this behavior and reveal our mistake to us.
Or perhaps point out where we should check/debug/RTFM next.
Are you using self-signed certificates? Could it be that the update
overwrote your CA certificate file, or overwrote the path to your CA
file(s) with one that doesn't contain your own CA's certificate in some
config file?
Thierry Lacoste wrote:
> Hello,
>
> I have 2 CentOS 5.4 servers running OpenLDAP 2.4.20
> installed from Buchan Milne's repository
> (openldap2.4-servers-2.4.20-1.el5).
>
> The first server is a Sync Provider.
> The second is a consumer with 'starttls=critical'.
>
> I have no problem after 'yum update' of the master
> (openldap2.4-servers-2.4.22-1.el5 is installed and replication is OK).
>
> But after 'yum update' of the slave, syncrepl won't work anymore because
> of TLS failures.
>
> Here are the logs on the master :
> Oct 20 16:51:15 vcos-castor slapd2.4[20097]: @(#) $OpenLDAP: slapd
> 2.4.22 (Apr 27 2010 12:04:27) $
> bgmilne@centos5-32.ranger.dnsalias.com:/home/bgmilne/rpm/BUILD/openldap-2.4.22/servers/slapd
>
> Oct 20 16:51:15 vcos-castor slapd2.4[20098]: slapd starting
> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 fd=16 ACCEPT from
> IP=IP.OF.THE.SLAVE:46212 (IP=0.0.0.0:389)
> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 EXT
> oid=1.3.6.1.4.1.1466.20037
> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 STARTTLS
> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 RESULT oid=
> err=0 text=
> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 fd=16 closed (TLS
> negotiation failure)
>
> Here are the logs on the slave :
> Oct 20 16:51:45 vcos-pollux slapd2.4[1808]: @(#) $OpenLDAP: slapd 2.4.22
> (Apr 27 2010 12:04:27) $
> bgmilne@centos5-32.ranger.dnsalias.com:/home/bgmilne/rpm/BUILD/openldap-2.4.22/servers/slapd
>
> Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: slapd starting
> Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: slap_client_connect:
> URI=ldap://NAME_OF_THE_MASTER Error, ldap_start_tls failed (-11)
> Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: do_syncrepl: rid=000 rc -11
> retrying (4 retries left)
>
> ldapsearch from the slave can do TLS :
> $ ldapsearch -ZZ -x -h NAME_OF_THE_MASTER
> This is ldapsearch from openldap-clients-2.3.43-12.el5_5.2 as packaged
> by CentOS
>
> Any ideas on how to troubleshoot the problem?
>
> Regards,
> Thierry
>
> PS : as a side note both servers are Xen VMs running on CentOS hosts.
>
--
Prentice
On 11/05/12 21:02 +0100, Admus wrote:
>On 11/05/2012 04:05 PM, Dan White wrote:
>>On 11/05/12 08:29 +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?
>>>>
>>>>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.
>>
>>Assuming that your OpenLDAP was compiled against GnuTLS, use the GnuTLS
>>tools to trouble shoot your certificate.
>>
>>A google search for "peer cert untrusted or revoked (0x42)" finds
>>users who
>>also received that error.
>>
>The output of `gnutls-cli --print-cert -p 636 ldap1.example.com` is:
>
>- The hostname in the certificate matches 'ldap1.example.com'.
>- Peer's certificate issuer is unknown
>- Peer's certificate is NOT trusted
>- Version: TLS1.2
>- Key Exchange: RSA
>- Cipher: AES-128-CBC
>- MAC: SHA1
>- Compression: NULL
>- Handshake was completed
According to gnutls-cli, your certificate is not trusted, and it's signer
it not trusted.
If you have created your own CA, or have self-signed your certificate, then
you will need to properly configure your ldap.conf containing a TLS_CACERT
directive, for ldapsearch to succeed.
Consult gnutls-cli's manpage for how to do the same for it.
--
Dan White
On 2013.10.03 08.22, Axel Grosse wrote:
-----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter Klünter
> Sent: Thursday, 3 October 2013 6:46 PM
> To: openldap-technical(a)openldap.org
> Subject: Re: Openldap server with TLS not working
>
> Am Thu, 3 Oct 2013 00:16:28 +0000
> schrieb Axel Grosse <agrosse(a)axway.com>:
>
>> Hi ben,
>> thanks for the comment.
>> agree with you on TLS usage should be perferred
>> but the client that is connecting is only capable of LDAPS ... he has
>> not implemented TLS Client jet .
>>
>> But can you please take a look to the error I am facing
>>
>> openssl s_client -connect 192.168.30.169:389 -showcerts
>> -CAfile ./ssl/VordelCA.crt CONNECTED(00000003)
>> 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>> failure:s23_lib.c:188:
>>
>> any idea what can cause this ?
>>
>> -----Original Message-----
>> From: openldap-technical-bounces(a)OpenLDAP.org
>> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb
>> Sent: Wednesday, 2 October 2013 10:57 PM To:
>> openldap-technical(a)openldap.org Subject: Re: Openldap server with TLS
>> not working
>>
>> On 2013.10.02 07.29, Axel Grosse wrote:
>>
>>> when I test on the server itself ..
>>> openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile
>>> ./ssl/VordelCA.crt
>>> CONNECTED(00000003)
>>> 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>>> failure:s23_lib.c:188:
>>
>> ldaps [port 636] is deprecated. use starttls with the standard port
>> [389]. to test, just use ldapsearch [see the reference to -Z in the
>> man page]
>
> You are connnecting to port 389, but s_client is not able to initiate a
> LDAP startTLS session (only SMTP and IMAP), so you have to connect
> ldaps and port 636.
>
> -Dieter
>
> Hi Ben, Dieter
> can we focus on LDAPS because TLS1 is not an option and even if LDAPS
> is deprecated I should be able to configure it ..
>
> TLSCACertificateFile /etc/openldap/ssl/VordelCA.crt
> TLSCertificateFile /etc/openldap/ssl/VordelDev.crt
> TLSCertificateKeyFile /etc/openldap/ssl/VordelDev.key
> TLSVerifyClient never
>
>
> are this entries in the slapd.conf sutable for LDAPS ?
> if not whats missing ?
nothing more is required
> start the server with
> /usr/sbin/slapd -h ldap://192.168.30.169:636 -u ldap
/usr/sbin/slapd -h 'ldaps:///' [...]
you must specify ldaps, and you do not need to explicitly specify the
port. 636 is the default. see man 8 slapd for details.
On 10/14/2011 01:48 AM, Olivier Guillard wrote:
> Hi Rich
>
> as far as I remember, when I used this version :
> openldap-servers-2.4.23-15.el6_1.1.x86_64
>
> I could use external mecanism in syncrepl and was
> able to present the client certificate without asking for
> the server one.
>
> My syncrepl sections looked like this :
>
> syncrepl rid=121
> provider=ldap://ldap2.example.fr
> searchbase="dc=example,dc=fr"
> schemachecking=on
> type=refreshOnly
> interval=00:00:00:05
> retry="10 +"
> bindmethod=sasl
> saslmech=external
> tls_cert=/etc/openldap/cacerts/syncrepl.crt
> tls_key=/etc/openldap/cacerts/syncrepl.key
>
> And that worked. BTW, I'm not sure that his should have
> worked since I think normaly the protocole indicates that
> the client should check the server cert before sending its.
Yes, that's odd.
> Anyway that worked (-:
>
> With openldap-servers-2.4.23-15.el6_1.3.x86_64, I'm not
> able to use the external mecanism anymore if I don't add
> explicitely the following directives in syncrepl: "starttls=yes",
> "tls_cacert=.../cacerts/CA.crt" and "tls_reqcert=allow/try/demand"
I don't think it ever should have worked without at least specifying
starttls=yes (and assuming that didn't fallback - I think starttls=yes
is misleading, as it will just silently fallback to plain LDAP if it
doesn't establish a TLS connection - everything will seem to be working,
but unless you have set up the server to require a TLS connection, it
will just work and you won't know that it is not using TLS). I
recommend always using starttls=critical to make sure your client will
only work if TLS was successfully established.
> That works in master/slave mode, that doesn't in multimaster.
>
> Now last thing : I've never been able to make work syncrepl
> with : "starttls=yes", "tls_cacert=.../cacerts/CA.crt" and
> "tls_reqcert=allow/try/demand" in multimaster N-WAY mode
> anyway (nor now, nor before).
>
> I only made it work in master/salve and that weither using
> simple or sasl bindmethod.
>
> So the problem is not linked to sasl in my view but with
> tls in synchrepl (may be both slapd try to use the first
> TLS session opened to exchange in both direction in
> multimaster, a shared variable mixing information about
> certicates ? something like that).
Would it be possible for you to get it working with simple
binddn/password auth first, to see if that is working? Then we could at
least narrow down the problem to being related to sasl/external auth.
> I just realise that I had a core dump collected by abrtd (not
> sure if that could help nor how to use it, I'm not familiar with
> this kind of debugging) : let me know if that file could help
> (or if I could try to run any gdb command using that file).
Yes indeed that would be very helpful.
https://bugzilla.redhat.com/show_bug.cgi?id=701678#c6 has some
information about handling openldap core dumps on RHEL6
> Best,
>
> ---
> Olivier
>
> On Wed, Oct 12, 2011 at 10:25 PM, Rich Megginson
> <rich.megginson(a)gmail.com> wrote:
>> On 10/11/2011 02:38 AM, Olivier Guillard wrote:
>>> Thanks Rich, see below :
>>>
>>>> -12272 is SSL_ERROR_BAD_MAC_ALERT and -12273 is SSL_ERROR_BAD_MAC_READ
>>>> I've seen this when the client and server do not have the same SSL
>>>> certificate signature algorithm support. Is everything running on RHEL6
>>>> and/or Fedora 14 and later?
>>> [root@ldap2 ~]# cat /etc/issue
>>> Red Hat Enterprise Linux Server release 6.1 (Santiago)
>>> Kernel \r on an \m
>>>
>>> [root@ldap2 ~]# rpm -qa | grep -i openldap
>>> openldap-2.4.23-15.el6_1.3.x86_64
>>> openldap-servers-2.4.23-15.el6_1.3.x86_64
>>> openldap-debuginfo-2.4.23-15.el6_1.1.x86_64
>>> openldap-clients-2.4.23-15.el6_1.3.x86_64
>>>
>>> [root@ldap1 ~]# cat /etc/issue
>>> Red Hat Enterprise Linux Server release 6.1 (Santiago)
>>> Kernel \r on an \m
>>>
>>> [root@ldap1 ~]# rpm -qa | grep -i openldap
>>> openldap-debuginfo-2.4.23-15.el6_1.1.x86_64
>>> openldap-clients-2.4.23-15.el6_1.3.x86_64
>>> openldap-2.4.23-15.el6_1.3.x86_64
>>> openldap-servers-2.4.23-15.el6_1.3.x86_64
>>>
>>> [root@ldap2 cacerts]# rpm -qa | grep openssl
>>> openssl-1.0.0-10.el6_1.4.x86_64
>>>
>>> [root@ldap1 ldap1]# rpm -qa | grep openssl
>>> openssl-1.0.0-10.el6_1.4.x86_64
>>>
>>> Not sure if that made a difference but I "yum-updated"
>>> on last friday and openldap servers version passed :
>>>
>>> from
>>> openldap-servers-2.4.23-15.el6_1.1.x86_64
>>> to
>>> openldap-servers-2.4.23-15.el6_1.3.x86_64
>> Was it working before you yum updated?
>>> ---
>>> Olivier
>>>
>>> On Mon, Oct 10, 2011 at 9:54 PM, Rich Megginson
>>> <rich.megginson(a)gmail.com> wrote:
>>>
>>>>> here is what I get :
>>>>>
>>>>> ldap1 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync
>>>>> ...
>>>>> TLS: error: accept - force handshake failure: errno 11 - moznss error
>>>>> -12273
>>>>> TLS: can't accept: TLS error -12273:Unknown code ___P 15.
>>>>> TLS: error: connect - force handshake failure: errno 0 - moznss error
>>>>> -12272
>>>>> TLS: can't connect: TLS error -12272:Unknown code ___P 16.
>>>>> slap_client_connect: URI=ldap://ldap2.example.fr Warning,
>>>>> ldap_start_tls failed (-11)
>>>>> slap_client_connect: URI=ldap://ldap2.example.fr
>>>>> ldap_sasl_interactive_bind_s failed (-6)
>>>>> do_syncrepl: rid=121 rc -6 retrying
>>>>>
>>>>> ldap2 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync
>>>>> ...
>>>>> TLS: error: connect - force handshake failure: errno 0 - moznss error
>>>>> -12272
>>>>> TLS: can't connect: TLS error -12272:Unknown code ___P 16.
>>>>> slap_client_connect: URI=ldap://ldap1.eaxample.fr:389 Warning,
>>>>> ldap_start_tls failed (-11)
>>>>> slap_client_connect: URI=ldap://ldap1.example.fr:389
>>>>> ldap_sasl_interactive_bind_s failed (-6)
>>>>> do_syncrepl: rid=211 rc -6 retrying
>>>>> TLS: error: accept - force handshake failure: errno 11 - moznss error
>>>>> -12273
>>>>> TLS: can't accept: TLS error -12273:Unknown code ___P 15.
>>>>>
>>>>> Any idea ?
>>
Hi list,
I tried to read all information about the subject, both in the mail
archives and on the website (admin guide and faq-o-matic), but somehow
things are not working as expected.
I have 3 servers, Debian 6 with the distro-version of openldap
(2.4.23-7). I use phpldapadmin (PLA for short), version 1.2.0.5. I also
use ldapvi and the standard ldap-tools (ldapadd/ldapmodify etc). I use
the slapd.d/ config backend. My userdata DIT is empty at the moment,
until the issues are resolved.
*) When using n-way multimaster, I understand that the whole DIT is
identical on all servers (assuming full read access for the replication
DN, which is the case). Because of this, I used a generic name for the
certificates, while on each server the content of the files are
server-specific. This works as expected. The other difference between
the servers is the slapd startup command line: in it is each server's
own FQDN. On debian, this is specified in /etc/default/slapd. On server1
this file has:
SLAPD_SERVICES=ldap://127.0.0.1 ldaps://server1.domain.tld ldapi:///"
On server2 the URI changes in ldaps://server2.domain.tld and on server3
it changes likewise. This is al per the admin guide.
For some reason, replication is not working as expected. Some updates go
through, others are ignored and stay local on a server. The servers are
on different subnets with a firewall in-between, but I can access each
server from the other servers using eg 'ldapsearch'.
Question: With n-way multimaster, I understand the DIT should be
identical on all servers. Can I just do tar -czf slapd.conf.tgz
/etc/ldap/slapd.d on one server, and copy and untar this on the other
servers (with slapd stopped) and start slapd? My (anonymized) slapd.d is
at the end of this message (I deleted the (default) schema definitions
for readability).
Question: Is the above-mentioned method a valid way to add/restore an
extra n-way multimaster node in the setup? If so, Do I do the export
AFTER adding the extra node to the config, or BEFORE?
Question: I also want to replicate the dc=domain,dc=tld DIT. Can I use
the same rid values in de replication statements as for the cn=config
DIT, or do they need to be unique within the total config?
Question: I do not like to use the cn=admin,cn=config identity as the
replication ID. Yet I do not have content in the dc=domain,dc=tld DIT,
and thus no way to specifiy another identity. Can this be solved?
Once the DIT has the identity, I assume I can change the replication ID
(as long as ACLs are not blocking things).
Can anyone answer my questions, or point me in the right direction? I
tried numerous things with all kind of different results, but I feel I
miss some fundamental insight.
Thanks for any help!
Marcel
--------------------------------------------------------------------
Anonymized slapd.d config of server1 (exported using PLA)
--------------------------------------------------------------------
# Server: Server1 (ldap://localhost)
# Search Scope: sub
# Search Filter: (objectClass=*)
# Total Entries: 13
#
# Generated by phpLDAPadmin (http://phpldapadmin.sourceforge.net) on
June 29, 2011 8:19 am
# Version: 1.2.0.5
version: 1
# Entry 1: cn=config
dn: cn=config
cn: config
contextcsn: 20110621205759.540662Z#000000#000#000000
createtimestamp: 20110429201711Z
creatorsname: cn=config
entrycsn: 20110621205759.540662Z#000000#000#000000
entrydn: cn=config
entryuuid: 690a54f4-06e9-1030-9aec-e9c45301ace2
modifiersname: cn=admin,cn=config
modifytimestamp: 20110621205759Z
objectclass: olcGlobal
olcargsfile: /var/run/slapd/slapd.args
olcloglevel: sync
olcloglevel: stats
olcloglevel: args
olcpidfile: /var/run/slapd/slapd.pid
olcserverid: 11 ldaps://server1.domain.tld
olcserverid: 12 ldaps://server2.domain.tld
olcserverid: 13 ldaps://server3.domain.tld
olctlscacertificatefile: /etc/ssl/certs/cacert.org.pem
olctlscertificatefile: /etc/ssl/certs/thishost.crt
olctlscertificatekeyfile: /etc/ssl/private/thishost.key
olctlsverifyclient: NEVER
olctoolthreads: 1
structuralobjectclass: olcGlobal
subschemasubentry: cn=Subschema
# Entry 2: cn=module{0},cn=config
dn: cn=module{0},cn=config
cn: module{0}
createtimestamp: 20110429201711Z
creatorsname: cn=admin,cn=config
entrycsn: 20110429201711.660046Z#000000#000#000000
entrydn: cn=module{0},cn=config
entryuuid: 690b3608-06e9-1030-9af4-e9c45301ace2
modifiersname: cn=admin,cn=config
modifytimestamp: 20110429201711Z
objectclass: olcModuleList
olcmoduleload: {0}back_hdb
olcmoduleload: {1}syncprov.la
olcmodulepath: /usr/lib/ldap
structuralobjectclass: olcModuleList
subschemasubentry: cn=Subschema
# Entry 3: cn=schema,cn=config
### DELETED default schema definitions for readability
# Entry 4: cn={0}core,cn=schema,cn=config
### DELETED default schema definitions for readability
# Entry 5: cn={1}cosine,cn=schema,cn=config
### DELETED default schema definitions for readability
# Entry 6: cn={2}nis,cn=schema,cn=config
### DELETED default schema definitions for readability
# Entry 7: cn={3}inetorgperson,cn=schema,cn=config
### DELETED default schema definitions for readability
# Entry 8: olcBackend={0}hdb,cn=config
dn: olcBackend={0}hdb,cn=config
createtimestamp: 20110429201711Z
creatorsname: cn=admin,cn=config
entrycsn: 20110429201711.707740Z#000000#000#000000
entrydn: olcBackend={0}hdb,cn=config
entryuuid: 69127d0a-06e9-1030-9af5-e9c45301ace2
modifiersname: cn=admin,cn=config
modifytimestamp: 20110429201711Z
objectclass: olcBackendConfig
olcbackend: {0}hdb
structuralobjectclass: olcBackendConfig
subschemasubentry: cn=Subschema
# Entry 9: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={-1}frontend,cn=config
createtimestamp: 20110429201711Z
creatorsname: cn=config
entrycsn: 20110429201711.654507Z#000000#000#000000
entrydn: olcDatabase={-1}frontend,cn=config
entryuuid: 690a5da0-06e9-1030-9aed-e9c45301ace2
modifiersname: cn=config
modifytimestamp: 20110429201711Z
objectclass: olcDatabaseConfig
objectclass: olcFrontendConfig
olcaccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=extern
al,cn=auth manage by * break
olcaccess: {1}to dn.exact="" by * read
olcaccess: {2}to dn.base="cn=Subschema" by * read
olcdatabase: {-1}frontend
olcsizelimit: 500
structuralobjectclass: olcDatabaseConfig
subschemasubentry: cn=Subschema
# Entry 10: olcDatabase={0}config,cn=config
dn: olcDatabase={0}config,cn=config
createtimestamp: 20110429201711Z
creatorsname: cn=config
entrycsn: 20110619065612.945749Z#000000#000#000000
entrydn: olcDatabase={0}config,cn=config
entryuuid: 690a693a-06e9-1030-9aee-e9c45301ace2
modifiersname: cn=admin,cn=config
modifytimestamp: 20110619065612Z
objectclass: olcDatabaseConfig
olcaccess: {0}to * by dn.exact=cn=admin,cn=config read by
dn.exact=gidNumber=0+uidNumber=0,cn=pe
ercred,cn=external,cn=auth manage by * break
olcdatabase: {0}config
olcmirrormode: TRUE
olcrootdn: cn=admin,cn=config
olcrootpw: {SSHA}deletedforsecurityreasons
olcsyncrepl: {0}rid=011 provider=ldaps://server1.domain.tld
binddn="cn=admin,cn=config" credentials="mysecretpassword"
bindmethod=simple starttls=no searchbase="cn=config"
type=refreshAndPersist retry="5 5 300 +" timeout=0 network-timeout=0
filter="(objectclass=*)" attrs="*,+" scope=sub
olcsyncrepl: {1}rid=012 provider=ldaps://server2.domain.tld
binddn="cn=admin,cn=config" credentials="mysecretpassword"
bindmethod=simple starttls=no searchbase="cn=config"
type=refreshAndPersist retry="5 5 300 +" timeout=0 network-timeout=0
filter="(objectclass=*)" attrs="*,+" scope=sub
olcsyncrepl: {2}rid=013 provider=ldaps://server3.domain.tld
binddn="cn=admin,cn=config" credentials="mysecretpassword"
bindmethod=simple starttls=no searchbase="cn=config"
type=refreshAndPersist retry="5 5 300 +" timeout=0 network-timeout=0
filter="(objectclass=*)" attrs="*,+" scope=sub
structuralobjectclass: olcDatabaseConfig
subschemasubentry: cn=Subschema
# Entry 11: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
createtimestamp: 20110512150606Z
creatorsname: cn=admin,cn=config
entrycsn: 20110522201415.682681Z#000000#000#000000
entrydn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
entryuuid: 1ae3191c-10f5-1030-9102-e14c7638455a
modifiersname: cn=admin,cn=config
modifytimestamp: 20110522201415Z
objectclass: olcOverlayConfig
objectclass: olcSyncProvConfig
objectclass: top
olcoverlay: {0}syncprov
olcspcheckpoint: 100 10
structuralobjectclass: olcSyncProvConfig
subschemasubentry: cn=Subschema
# Entry 12: olcDatabase={1}hdb,cn=config
dn: olcDatabase={1}hdb,cn=config
createtimestamp: 20110512144416Z
creatorsname: cn=admin,cn=config
entrycsn: 20110619123128.846982Z#000000#000#000000
entrydn: olcDatabase={1}hdb,cn=config
entryuuid: 0e60d5a6-10f2-1030-9d9b-35ce2d01c34c
modifiersname: cn=admin,cn=config
modifytimestamp: 20110619123128Z
objectclass: olcDatabaseConfig
objectclass: olcHdbConfig
olcaccess: {0}to attrs=userPassword,shadowLastChange by self write by anonym
ous auth by dn="cn=admin,cn=config" write by * none
olcaccess: {1}to dn.base="" by * read
olcaccess: {2}to * by self write by dn="cn=admin,cn=config" write by * read
olcdatabase: {1}hdb
olcdbcheckpoint: 512 30
olcdbconfig: {0}set_cachesize 0 2097152 0
olcdbconfig: {1}set_lk_max_objects 1500
olcdbconfig: {2}set_lk_max_locks 1500
olcdbconfig: {3}set_lk_max_lockers 1500
olcdbdirectory: /var/lib/ldap/
olcdbindex: objectClass eq
olcdbindex: entryCSN eq
olcdbindex: entryUUID eq
olclastmod: TRUE
olcmirrormode: TRUE
olcrootdn: cn=admin,cn=config
olcrootpw: {SSHA}s1C7GBjdeletedforsecurityreasons
olcsuffix: dc=domain,dc=tld
olcsyncrepl: {0}rid=011 provider=ldaps://server1.domain.tld
binddn="cn=admin,cn=config" credentials="mysecretpassword"
bindmethod=simple starttls=no searchbase="dc=domain,dc=tld"
type=refreshAndPersist retry="5 5 300 +" timeout=0 network-timeout=0
filter="(objectclass=*)" attrs="*,+" scope=sub
olcsyncrepl: {1}rid=012 provider=ldaps://server2.domain.tld
binddn="cn=admin,cn=config" credentials="mysecretpassword"
bindmethod=simple starttls=no searchbase="dc=domain,dc=tld"
type=refreshAndPersist retry="5 5 300 +" timeout=0 network-timeout=0
filter="(objectclass=*)" attrs="*,+" scope=sub
olcsyncrepl: {2}rid=013 provider=ldaps://server3.domain.tld
binddn="cn=admin,cn=config" credentials="mysecretpassword"
bindmethod=simple starttls=no searchbase="dc=domain,dc=tld"
type=refreshAndPersist retry="5 5 300 +" timeout=0 network-timeout=0
filter="(objectclass=*)" attrs="*,+" scope=sub
structuralobjectclass: olcHdbConfig
subschemasubentry: cn=Subschema
# Entry 13: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config
dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config
createtimestamp: 20110522163658Z
creatorsname: cn=admin,cn=config
entrycsn: 20110522201502.521704Z#000000#000#000000
entrydn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config
entryuuid: 74b70896-18dd-1030-94f4-2183161cb5d6
modifiersname: cn=admin,cn=config
modifytimestamp: 20110522201502Z
objectclass: olcOverlayConfig
objectclass: olcSyncProvConfig
objectclass: top
olcoverlay: {0}syncprov
olcspcheckpoint: 100 10
structuralobjectclass: olcSyncProvConfig
subschemasubentry: cn=Subschema
Hi Machael,
The first command works fine (ldapsearch -x -H ldap://ldap-company.com -ZZ)
but the second one (ldapsearch -x -H ldaps://ldap-company.com:636 -ZZ) is
showing error :
*ldap_start_tls: Operations error (1)*
-Asimananda
2009/7/20 Michael Ströder <michael(a)stroeder.com>
> Asimananda Mohanty wrote:
> > Hi Michael,
> >
> > Thanks for the reply.
> >
> > I tried with "ldapsearch -x -H ldap://ldap-company.com:636
> > <http://ldap-company.com:636> -ZZ -D dc=ldap-company,dc=com" and got the
> > error :
> >
> > ber_get_next failed.
> > ldap_start_tls: Can't contact LDAP server (-1)
>
> Sorry should have been
>
> ldapsearch -x -H ldap://ldap-company.com -ZZ
>
> for LDAP access going to standard port 389 (clear-text) and then using
> StartTLS extended operation.
>
> Another option is to use LDAPS (LDAP over SSL) to separate port:
>
> ldapsearch -x -H ldaps://ldap-company.com:636 -ZZ
>
> Ciao, Michael.
>
> --
> Michael Ströder
> E-Mail: michael(a)stroeder.com
> http://www.stroeder.com
>
