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.
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
>
Hello,
>> I run an LDAP directory on 3 servers : one master, and two slaves,
>> synchronised with syncrepl. The 3 servers are running FreeBSD 7.0 and
>> openLDAP 2.4.13.
>>
>> I encountered yesterday an issue with syncrepl that should have been
>> solved with openLDAP 2.4.13
>
> Yeah, I'm pretty sure this has been solved since, as I recall running
> into it at one point.
The problem just happened again.
It it possible that it is only half solved, or that my config present
some errors ?
slave :
oclSyncrpepl: {0}rid=101 provider=ldap://amon.u-strasbg.fr:389
bindmethod=simple timeout=0 network-timeout=0 starttls=no
filter="(objectclass=*)" searchbase="o=annuaire" scope=sub
schemachecking=off type=refreshAndPersist retry="60 +"
master:
18 olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 600
olcSpSessionlog: 1000
It's a very serious problem for me, because when this happens, no other
modification is replicated.
Is there some config parameter to prevent this blocking ?
I plan an upgrade to 2.4.17. I Hope this will help.
--
Alain ZAMBONI
Direction Informatique
Université de Strasbourg
Bruno Steven <aspenbr(a)gmail.com> writes:
> Hi,
>
> I am trying configure openldap work with tls , but I have two question about this, first
> when I use tls openldap use port 389 and ssl port 639 , is this correct ?
> Second How I can test connection between client and server, cryptography is working ?
There is no ssl port! SSL (Secure Socket Layer) is a proprietary,
licence based protocol, owned by Netscape? I don't know whether the
IPR of this protocol have been part of the Netscape/AOL deal. OpenLDAP,
and most other network based applications, have implemented Transport
Layer Security (TLS), RFC 2246. As a LPI certified professional you
should be aware of this.
OpenLDAP uses port 639, which has not been assigned by IANA to LDAP(S)
protocol, as TLS-enabled port. Port 389 is still required for the LDAP
extended operation startTLS (RFC-4513).
You may test your TLS session with:
openssl s_client -connect localhost:639 -CAfile <file>
Unfortunately openssl is not able to initiate a ldap_starttls session on
port 389.
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:8EF7B6C6
53°37'09,95"N
10°08'02,42"E
----- Original Message -----
> From: "Dieter Klünter" <dieter(a)dkluenter.de>
> To: openldap-technical(a)openldap.org
> Sent: Thursday, 27 December, 2012 3:53:21 PM
> Subject: Re: Forcing TLS encryption
>
> Am Mon, 24 Dec 2012 10:14:39 +0100 (CET)
> schrieb Wiebe Cazemier <wiebe(a)halfgaar.net>:
>
>
>
> In order to initiate Transport Layer Security you have to call the
> extended operation ldapSTARTTLS.
>
> -Dieter
>
> --
> Dieter Klünter | Systemberatung
> http://dkluenter.de
> GPG Key ID:DA147B05
> 53°37'09,95"N
> 10°08'02,42"E
>
>
I understand that, but this way, even when you're forcing TLS, users can still expose their passwords if their computers are mal-configured. SMTP, IMAP, FTP, etc don't allow this, because they reject the connection if LOGINNAME is given before STARTTLS.
It's kind of a security issue. Is it because in LDAP, username and password are given as one command, and the server doesn't have the chance to abort at that point? If so, then I guess it's unavoidable.
