Hi Andrew, I've got some updates.
1 ) Added tls_reqcert demand to the client side
2 ) Configured a user to bind instead of anonymous
binddn cn=ldapuser,Ou=Users,dc=server,dc=com
bindpwd :$6$oZ8qYohy$lU0sYJXInOO1ISO4WKgzeuDyyFh9a
3 ) Added olcTLSVerifyClient:demand to server side:
Now as I can see this is good, the TLS is established with a strong
security factor of 256.
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 fd=252 ACCEPT from
IP=X.X.X.X:58387 (IP=0.0.0.0:389)
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=0 STARTTLS
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=0 RESULT oid= err=0
text=
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 fd=252 TLS established
tls_ssf=256 ssf=256
The user configured to bind from the client side
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=1 BIND
dn="cn=ldapuser,ou=Users,dc=server,dc=com" method=128
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=1 BIND
dn="cn=ldapuser,ou=Users,dc=server,dc=com" mech=SIMPLE ssf=0
My user id used to login to the server:
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=3 BIND dn="cn=My
Username,ou=Users,dc=serverdc=com" method=128
Object added to server:
dn: olcDatabase={2}bdb,cn=config
changetype:modify
add: olcTLSVerifyClient:demand
Still I did not corrected my ACL but I do not see olcTLSVerifyClient:demand
reflected on my configuration
with slapcat -n0 I only see the this:
olcTLSCACertificateFile: /etc/openldap/certs/cert.pem
olcTLSCertificateKeyFile: /etc/openldap/certs/private.key
olcTLSCertificateFile: /etc/openldap/certs/cert.pem
Did I do something wrong?
Thanks for your time and support
Regards
2014-10-29 14:51 GMT-03:00 Net Warrior <netwarrior863(a)gmail.com>:
> Ok, thank you very much, I'm gonna review the configuration and follow
> your advice.
>
> Best regards.
>
> 2014-10-29 13:43 GMT-03:00 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk
> >:
>
> On Wed, Oct 29, 2014 at 08:19:03AM -0300, Net Warrior wrote:
>>
>> > 200 Servers and 20 users
>>
>> OK - that means that you will not have problems with the default
>> limits on result-set size (500 entries).
>>
>> > >I hope you don't really bind with the ROOTDN account!
>> > NO! and I have a user to test the configuration but I do not use it
>> to bind
>> > purposes, but I could if I knew how to configure it.
>>
>> As you have quite a lot of servers and a policy of hiding all data
>> from anonymous users, I would suggest having more than one LDAP-client
>> account. Either create one per client server, or one per group of similar
>> servers.
>>
>> I would suggest putting the client accounts in a dedicated part of the
>> LDAP tree, so it might look like this:
>>
>> ou=Users,dc=server,dc=com POSIX user accounts
>> ou=Groups,dc=server,dc=com POSIX groups
>> ou=Clients,dc=server,dc=com Client machine accounts
>>
>> You need to get all your client machines to bind with their account DN
>> and password before you start changing ACLs. Config file entries will look
>> something like this:
>>
>> binddn cn=server1,ou=Clients,dc=server,dc=com
>> bindpw SomeLongAndSecurePassword
>>
>> > >You should also add:
>> > >tls_reqcert demand
>> > >and you may want to consider restricting the connection to high-grade
>> ciphers
>> > e.g.:
>> > >tls_ciphers HIGH:MEDIUM:@STRENGTH
>> >
>> > Both, client and server side right?
>>
>> Yes, but the keyword for slapd.conf is TLSCipherSuite
>> and for ldap.conf it is TLS_CIPHER_SUITE
>>
>> Once you have *all* the clients using TLS and binding with their client
>> account and password, you can start on ACLs. If your logging includes
>> the 'stats' category (256) you will be able to see TLS setup and bind
>> in the logs, e.g.:
>>
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 ACCEPT from
>> IP=[::1]:43386 (IP=[::]:389)
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 EXT
>> oid=1.3.6.1.4.1.1466.20037
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 STARTTLS
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 RESULT oid= err=0
>> text=
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 TLS established
>> tls_ssf=128 ssf=128
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND
>> dn="cn=client234,ou=Clients,dc=server,dc=com" method=128
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND
>> dn="cn=client234,ou=Clients,dc=server,dc=com" mech=SIMPLE ssf=0
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 RESULT tag=97
>> err=0 text=
>>
>> After all that, the ACLs turn out to be really simple! Something like this
>> will probably be close to what you need for the main database:
>>
>> access to attrs="userPassword"
>> by self =w
>> by * auth
>>
>> access to * by users read
>>
>> access to * by * none
>>
>> If you have a replica server then you will need to add an ACL giving read
>> access
>> to all attributes. This should go right at the top of the list, and will
>> look something
>> like this:
>>
>> access to * by dn.exact="cn=replicator,ou=Clients,dc=server,dc=com" read
>>
>> If you are using the Monitor database then you should probably protect it
>> like this:
>>
>> access to dn.subtree="cn=Monitor"
>> by users read
>> by * none
>>
>> And to make sure that critical stuff like the root DSE and the schema can
>> be
>> read by everyone, add this to the global section of the config:
>>
>> access to * by * read
>>
>>
>> Andrew
>> --
>> -----------------------------------------------------------------------
>> | From Andrew Findlay, Skills 1st Ltd |
>> | Consultant in large-scale systems, networks, and directory services |
>> | http://www.skills-1st.co.uk/ +44 1628 782565 |
>> -----------------------------------------------------------------------
>>
>
>
On 20.10.2016 09:19, Raffael Sahli wrote:
> Hi
>
> What can lead a consumer to "randomly" delete ~50% of all objects in his database?
> I have this problem now for ~1-2months and on 3 different master/slave groups.
>
> The consumer starts to delete objects (but those are all present on the master):
>
> Oct 19 17:16:22 ldap-slave002.xxx slapd[8554]: do_syncrep2: rid=999 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> Oct 19 17:16:22 ldap-slave002.xxx slapd[8554]: do_syncrep2: rid=999 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 9c802b18-7c2c-1033-9f25-2d4a65066d19, dn uid=jasmin.mans,ou=none,o=dd,dc=xxx,dc=xxx
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 650ada00-e996-1035-80ac-a173474274df, dn uid=jasmine.suddr,ou=none,o=dd,dc=xxx,dc=xxx
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID ec5c9aa4-7c2c-1033-9fa4-2d4a65066d19, dn uid=jonas.beffrnn,ou=none,o=dd,dc=xxx,dc=xxx
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 7461d22e-e996-1035-80f6-a173474274df, dn uid=juerg.klegegeli,ou=none,o=dd,dc=xxx,dc=xxx
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 758c744c-e996-1035-8100-a173474274df, dn uid=julia.sxgegegea,ou=none,o=dd,dc=xxx,dc=xxx
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 47e4f6b4-7c2d-1033-8015-2d4a65066d19, dn uid=karin.vivwvwe,ou=none,o=dd,dc=xxx,dc=xxx
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 8d26a4f2-7c2d-1033-807b-2d4a65066d19, dn uid=larissa.fewfewf,ou=none,o=dd,dc=xxx,dc=xxx
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 98310aa4-7c2d-1033-808b-2d4a65066d19, dn uid=laura.cfwfew,ou=none,o=dd,dc=xxx,dc=xxx
>
> syncrepl config:
> olcSyncrepl: {0}rid=999 provider=ldap://ldap-master002.xxx.xxx:389 bindmethod=simple timeout=0 network-timeout=10 binddn="uid=replicator,ou=system,o=de,dc=xxx,dc=xxx"
> credentials="pass" keepalive=0:0:0 starttls=yes tls_cacert="/etc/ssl/certs/SwissSign_Silver_CA_-_G2.pem" tls_reqcert=allow filter="(objectClass=*)" searchbase="dc=xxx,dc=xxx" scope=sub attrs="*,+"
> syncdata="accesslog" logbase="cn=accesslog_xxx" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=off type=refreshOnly interval="00:00:01:00" retry="10 5 60 +"
>
>
> Misconfiguration? (We've been running this configuration for years...)
>
>
> Workaround is to remove the whole mdb database and restart slapd to let it resync.
> I've found some posts with a similar problem but those are all related to pre 2.4.21, we're running slapd 2.4.44.
>
>
> Cheers
>
Ideas?
(Most of the time slapd removes now ~99% of all objects)
--
Raffael Sahli
To avoid all this name problems and to keep things simple I use a wildcard certificate.
This cert is also used on the real servers and on the load balancer.
The clients talk only the a load balancer. Where I have 2 ip addresses. One for ldapwrite.domain.com and one for ldapread.domain.com
The load balancer terminates the ssl connection for port 636 and creates a new session to the backend server.
The reason that I have also the wildcard cert also on the backend servers is for secure connections over 389.
The load balancer doesn't speak the ldap protocol, so if a client is doing a starttls he would get the cert from the real server.
If 389 is not needed, then I think 1 or 2 certs on a load balancer would be enough.
The replication works also with self-signed certs if configured correctly.
--
Marco
On Aug 26, 2011, at 10:35 PM, Daniel Qian wrote:
> Still not sure how you did it. Are you saying you set the same certificate in slapd and played with DNS to make it look like only one server(URL) to everyone?
>
> Thanks,
> Daniel
>
> On 11-08-26 4:03 PM, Chris Jacobs wrote:
>>
>> What I did:
>> * setup servers behind VIP
>> * obtain cert with primary name of vip DNS w/ secondary names of the servers.
>>
>> That way, the servers can sync/tryst each other via the same cert used by clients.
>>
>> Note: some clients (lookin at you Firefox) won't use the primary name if subjectaltname exists - so include primary name in the alt names JIC.
>>
>> - chris
>>
>> Chris Jacobs, Systems Administrator, Technology Services Group
>> Apollo Group | Apollo Marketing and Product Development� |� Aptimus, Inc.
>> 2001 6th Ave� |� Suite 3200� |� Seattle, WA 98121
>> direct 206.839.8245� |� cell 206.601.3256� |� fax 206.839.8106
>> email chris.jacobs(a)apollogrp.edu
>>
>> From: openldap-technical-bounces(a)OpenLDAP.org <openldap-technical-bounces(a)OpenLDAP.org>
>> To: openldap-technical(a)openldap.org <openldap-technical(a)openldap.org>
>> Sent: Fri Aug 26 12:49:04 2011
>> Subject: Syncrepl over TLS for mirrormode
>>
>> From the openldap website the two nodes have to use different URLs like below:
>>
>> syncrepl rid=001
>> provider=ldap://ldap-sid2.example.com
>> bindmethod=simple
>> binddn="cn=mirrormode,dc=example,dc=com"
>> credentials=mirrormode
>> searchbase="dc=example,dc=com"
>> schemachecking=on
>> type=refreshAndPersist
>> retry="60 +"
>> and
>> syncrepl rid=001
>> provider=ldap://ldap-sid1.example.com
>> bindmethod=simple
>> binddn="cn=mirrormode,dc=example,dc=com"
>> credentials=mirrormode
>> searchbase="dc=example,dc=com"
>> schemachecking=on
>> type=refreshAndPersist
>> retry="60 +"
>>
>> I can set two different certificates so that TLS is fine for sync between the two nodes. However we will have regular Ldap client access these two nodes behind a loadbalancer over TLS too. Obviously the client can't connect with ldap-sid2.example.com, nor with ldap-sid1.example.com. So what is the solution to this scenario? Setup a pool of consumers with same hostname?
>>
>> Thanks,
>> Daniel
>>
>> This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
>>
>
Hi everyone
Question : are there some limitations (key size, encryption algorithm,
etc.) for certificates used by openldap to manage TLS connexions ?
See below why I ask :
I have used the following configuration in my slapd servers for quite a
while without any problem :
olcTLSCACertificateFile: /etc/openldap/cacerts/CA.crt
olcTLSCertificateFile: /etc/openldap/cacerts/server.crt
olcTLSCertificateKeyFile: /etc/openldap/cacerts/server.key
olcTLSCipherSuite: HIGH
olcTLSVerifyClient: allow
See for example my configuration for syncrepl (see: tls_reqcert=demand) :
olcSyncrepl: {0}rid=411 provider=ldap://ldap1.example.fr bindmethod=sasl
sizelimit=unlimited timeout=0 network-timeout=0 saslmech=external type
=refreshAndPersist retry="5 +" starttls=yes tls_cacert=/etc/openldap/cacer
ts/CA.crt tls_cert=/etc/openldap/cacerts/replicator.crt
tls_key=/etc/openldap
/cacerts/replicator.key scope=sub schemachecking=on keepalive=0:0:0 fil
ter="(objectclass=*)" searchbase="dc=example,dc=fr" tls_reqcert=demand
-> I have used this for couple of years on my multimastered ldap servers,
and until yesterday that worked perfectly : replication was working
properly and clients talked with the servers using TLS without any problem.
But I since my certicates were too weak (see this : sha1, 512 bit) :
$ openssl x509 -text -in server.crt
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 13998752034197585248 (0xc2458ece791fbd60)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=fr, ST=IDF, L=Town, O=example, OU=IT,
CN=ldap/emailAddress=ldap(a)example.fr
Validity
Not Before: Dec 29 15:41:56 2011 GMT
Not After : Jul 29 15:41:56 2021 GMT
Subject: C=fr, ST=IDF, L=Town, O=example, OU=IT,CN=
ldap1.example.fr/emailAddress=ldap(a)example.fr
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (512 bit)
I have renewed them using the same self signed authority to validate them,
and of course using exactly the same subject. My new certificate look like
this :
$ openssl x509 -text -in server.crt (see this : sha2, 4096 bit) :
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 10208063777793278590 (0x8daa53ebd7e6827e)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=fr, ST=IDF, L=Town, O=example, OU=IT,
CN=ldap/emailAddress=ldap(a)example.fr
Validity
Not Before: Jul 22 15:24:50 2015 GMT
Not After : Feb 19 15:24:50 2025 GMT
Subject: C=fr, ST=IDF, L=Town, O=example, OU=IT,CN=
ldap1.example.fr/emailAddress=ldap(a)example.fr
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
I installed my new certificate on ldap1 without changing the configuration,
and restarting the server here is what I get on ldap4 logs (loglevel =
sync ) :
$ tail -f /var/log/ldap.log
...
Jul 22 17:31:10 ldap4 slapd[53489]: slap_client_connect: URI=ldap://
ldap1.example.fr Warning, ldap_start_tls failed (-11)
Jul 22 17:31:10 ldap4 slapd[53489]: slap_client_connect: URI=ldap://
ldap1.example.fr ldap_sasl_interactive_bind_s failed (-2)
Jul 22 17:31:10 ldap4 slapd[53489]: do_syncrepl: rid=432 rc -2 retrying
Jul 22 17:31:15 ldap4 slapd[53489]: slap_client_connect:
URI=ldap://ldap1.example.fr Warning, ldap_start_tls failed (-11)
Jul 22 17:31:15 ldap4 slapd[53489]: slap_client_connect: URI=ldap://
ldap1.example.fr ldap_sasl_interactive_bind_s failed (-6)
Jul 22 17:31:15 ldap4-mrs slapd[53489]: do_syncrepl: rid=432 rc -6 retrying
When reinstalling the previous certificates and restarting ldap1 the server
I see this appearing in ldap4 logs :
...
Jul 22 17:31:20 ldap4-mrs slapd[53489]: do_syncrep2: rid=432
LDAP_RES_INTERMEDIATE - REFRESH_DELETE
Question : are there some limitations (key size, encryption algorithm,
etc.) for certificates used by openldap to manage TLS connexions ? Does
openldap tls connections work with certificates sha 256 With RSA Encryption
using a 4096 public key length ? May be I missed something ?
(note : I use openssl to manage my certificates)
Thanks for any help.
---
Olivier
On Wed, Oct 29, 2014 at 08:19:03AM -0300, Net Warrior wrote:
> 200 Servers and 20 users
OK - that means that you will not have problems with the default
limits on result-set size (500 entries).
> >I hope you don't really bind with the ROOTDN account!
> NO! and I have a user to test the configuration but I do not use it to bind
> purposes, but I could if I knew how to configure it.
As you have quite a lot of servers and a policy of hiding all data
from anonymous users, I would suggest having more than one LDAP-client
account. Either create one per client server, or one per group of similar
servers.
I would suggest putting the client accounts in a dedicated part of the
LDAP tree, so it might look like this:
ou=Users,dc=server,dc=com POSIX user accounts
ou=Groups,dc=server,dc=com POSIX groups
ou=Clients,dc=server,dc=com Client machine accounts
You need to get all your client machines to bind with their account DN
and password before you start changing ACLs. Config file entries will look
something like this:
binddn cn=server1,ou=Clients,dc=server,dc=com
bindpw SomeLongAndSecurePassword
> >You should also add:
> >tls_reqcert demand
> >and you may want to consider restricting the connection to high-grade ciphers
> e.g.:
> >tls_ciphers HIGH:MEDIUM:@STRENGTH
>
> Both, client and server side right?
Yes, but the keyword for slapd.conf is TLSCipherSuite
and for ldap.conf it is TLS_CIPHER_SUITE
Once you have *all* the clients using TLS and binding with their client
account and password, you can start on ACLs. If your logging includes
the 'stats' category (256) you will be able to see TLS setup and bind
in the logs, e.g.:
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 ACCEPT from IP=[::1]:43386 (IP=[::]:389)
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 STARTTLS
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 RESULT oid= err=0 text=
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 TLS established tls_ssf=128 ssf=128
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND dn="cn=client234,ou=Clients,dc=server,dc=com" method=128
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND dn="cn=client234,ou=Clients,dc=server,dc=com" mech=SIMPLE ssf=0
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 RESULT tag=97 err=0 text=
After all that, the ACLs turn out to be really simple! Something like this
will probably be close to what you need for the main database:
access to attrs="userPassword"
by self =w
by * auth
access to * by users read
access to * by * none
If you have a replica server then you will need to add an ACL giving read access
to all attributes. This should go right at the top of the list, and will look something
like this:
access to * by dn.exact="cn=replicator,ou=Clients,dc=server,dc=com" read
If you are using the Monitor database then you should probably protect it like this:
access to dn.subtree="cn=Monitor"
by users read
by * none
And to make sure that critical stuff like the root DSE and the schema can be
read by everyone, add this to the global section of the config:
access to * by * read
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
Hi Chris:
I have to regenerate the CA, and make sure that the hostname and common name match(ldap.server.com), the following is the command output:
[root(a)ldap.server.com ~]# echo | openssl s_client -connect ldap.server.com:636 -showcerts -state -CAfile /etc/openldap/cacerts/cacert.pem
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=1 /C=CN/ST=BJ/O=TS/OU=IT/CN=ldap.server.com/emailAddress=tianzy(a)server.com
verify return:1
depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=ldap.server.com/emailAddress=tianzy(a)server.com
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server certificate request A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client certificate A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
On LDAP Server run the command: "ldapsearch -x -H ldap://ldap.server.com -ZZ" is ok, I think CA is no problem now. But on my client , it also ouput "ldap_start_tls: Connect error (-11) "
LDAP Server log file output:
Oct 24 11:41:41 auth slapd[14371]: conn=49 fd=14 ACCEPT from IP=192.168.9.9:46226 (IP=0.0.0.0:389)
Oct 24 11:41:41 auth slapd[14371]: conn=49 op=0 STARTTLS
Oct 24 11:41:41 auth slapd[14371]: conn=49 op=0 RESULT oid= err=0 text=
Oct 24 11:41:41 auth slapd[14371]: conn=49 fd=14 closed (TLS negotiation failure)
Tian Zhiying
From: Chris Jacobs
Date: 2013-10-23 22:18
To: tianzy1225; DieterKlünter; openldap-technical
Subject: RE: Re: OpenLDAP 2.3.4 TLS negotiation failure
Inline...
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-
> technical-bounces(a)OpenLDAP.org] On Behalf Of Tian Zhiying
> Sent: Wednesday, October 23, 2013 2:59 AM
> To: DieterKlünter; openldap-technical
> Subject: Re: Re: OpenLDAP 2.3.4 TLS negotiation failure
>
> Hi Dieter:
>
> Thanks for your quick reply.
> I have changed 'TLS_REQCERT try' and check the commonName of the host
> certificate, the common name is LDAP Server hostname "auth.server.com",
> the following is the query results:
> [root@auth cacerts]# openssl s_client -connect localhost:636 -showcerts -
> state -CAfile /etc/openldap/cacerts/cacert.pem
> CONNECTED(00000003)
> SSL_connect:before/connect initialization
> SSL_connect:SSLv2/v3 write client hello A
> SSL_connect:SSLv3 read server hello A
> depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=auth.server.com/emailAddres
> s=tianzy(a)server.com
> verify error:num=18:self signed certificate
> verify return:1
Here is your problem. The host does not trust the SSL cert.
The 'CAfile' you've pointed the openssl command (and the real clients guessing by the path) isn't the CA chain for that SSL cert.
We also use an internal CA that our hosts don't trust globally. Same command and output for me:
[root(a)ldapmaster1.[snip] ~]# echo | openssl s_client -connect ldapmaster1.[snip]:636 -showcerts -state -CAfile /etc/openldap/cacerts/cacert.pem
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=2 C = US, O = [snip], OU = PKI, CN = [snip] Internal Root CA
verify return:1
depth=1 C = US, O = [snip], OU = PKI, CN = [snip] Internal Issuing CA 01
verify return:1
depth=0 C = US, ST = WA, L = Seattle, O = [snip], CN = ldap-vip. [snip], emailAddress = [snip]
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
The command then continues to dump the cert, and the chain certs, as expected.
You must put the entire CA chain from the Root CA to the signing/subordinate CA that signed this SSL cert (if applicable) in x509/PEM format in your 'CAfile' - assuming the Root CA isn't trusted server wide already.
Then try again. Also, make sure to use the name specified in your SSL cert when connecting/testing - mess with your local hosts file if needed.
- chris
> depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=auth.server.com/emailAddres
> s=tianzy(a)server.com
> verify return:1
> SSL_connect:SSLv3 read server certificate A
> SSL_connect:SSLv3 read server certificate request A
> SSL_connect:SSLv3 read server done A
> SSL_connect:SSLv3 write client certificate A
> SSL_connect:SSLv3 write client key exchange A
> SSL_connect:SSLv3 write change cipher spec A
> SSL_connect:SSLv3 write finished A
> SSL_connect:SSLv3 flush data
> SSL_connect:SSLv3 read finished A
>
> Now, the /etc/openldap/ldap.conf file:
> URI ldap://ldap.server.com/
> BASE dc=server,dc=com
> TLS_CACERT /etc/openldap/cacerts/cacert.pem
> #SSL ON
> TLS_REQCERT try
>
> But, run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I also get the
> following error:
> [root@client cacerts]# ldapsearch -x -H ldap://ldap.server.com -ZZ
> ldap_start_tls: Connect error (-11)
>
> ________________________________________
> Tian Zhiying
>
> From: DieterKlünter
> Date: 2013-10-23 17:35
> To: openldap-technical
> CC: tianzy1225
> Subject: Re: OpenLDAP 2.3.4 TLS negotiation failure
> Am Wed, 23 Oct 2013 16:47:25 +0800
> schrieb "Tian Zhiying" <tianzy1225(a)thundersoft.com>:
>
> > Hi
> >
> > On the LDAP Server , I run following command is ok:
> > #ldapsearch -x -H ldap://ldap.server.com -ZZ
> > #ldapsearch -x -H ldap://ldap.server.com
> >
> > But on my client , I run "#ldapsearch -x -H ldap://ldap.server.com",
> > is ok; Run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I get the
> > following error: [root@client cacerts]# ldapsearch -x -H
> > ldap://ldap.server.com -ZZ ldap_start_tls: Connect error (-11)
> >
> > On LDAP Server log file, I get the following error messages:
> > Oct 23 16:41:25 auth slapd[4213]: conn=206 fd=24 ACCEPT from
> > IP=192.168.9.9:45648 (IP=0.0.0.0:389) Oct 23 16:41:25 auth
> > slapd[4213]: conn=206 op=0 STARTTLS Oct 23 16:41:25 auth slapd[4213]:
> > conn=206 op=0 RESULT oid= err=0 text= Oct 23 16:41:25 auth
> > slapd[4213]: conn=206 fd=24 closed (TLS negotiation failure)
> >
> > My client ldap configuration:
> > /etc/openldap/ldap.conf file:
> > URI ldap://ldap.server.com/
> > BASE dc=server,dc=com
> > TLS_CACERT /etc/openldap/cacerts/ca.crt
> > SSL ON
> > TLS_REQCERT demand
>
> Set 'TLS_REQCERT try' and check the commonName of the host
> certificate.
> SSL ON is not an openldap configuration parameter.
> The /etc/ldap.conf file is not a openldap client configuration file,
> but of nss_ldap.
>
> > /etc/ldap.conf file:
> > BASE dc=server,dc=com
> > URI ldap://ldap.server.com
> > SSL ON
> > TLS_CACERT /etc/openldap/cacert/ca.crt
> > TLS_REQCERT demand
> >
> > Any suggestion what cause TLS negotiation failure?
>
> -Dieter
>
> --
> Dieter Klünter | Systemberatung
> http://dkluenter.de
> GPG Key ID:DA147B05
> 53°37'09,95"N
> 10°08'02,42"E
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Hello all,
Last year I switched from the slapd.conf to the OLC style config for
OpenLDAP and transitionally tested it by making the OLC server a
replication slave to the older LDAP server configured with slapd.conf.
Now I've disabled replication from that old server and am making the
OLC server (LDAP01 - version 2.4.23) the new master and threw up a new
VM called LDAP02 (2.4.23) to become the new sync replication
slave/consumer. Though I'm using multiple guides of varying detail the
simplest setup steps basically followed this article:
http://gagravarr.livejournal.com/145679.html.
I followed the same steps I thought I did for LDAP01, but despite the
fact that I see LDAP02 bind and try to fetch entries for replication
nothing is being fetched. The problem description is almost identical
to this person's issue:
http://www.openldap.org/lists/openldap-software/200911/msg00017.html
(with "nentries=0" in the replication log messages, but plenty of
entries found with an ldapsearch manually).
Though I think my setup situation is different than that person's, and
they were exporting using slapcat/slapadd (which I did for converting
my existing slapd.conf config to LDAP01 last year, but this time I
merely setup LDAP02 from scratch as a cn=config OLC server to begin
with), one of the follow-up responses to that email thread said this:
"The only correct usage of -w is when you have an LDIF produced by slapcat
on a database that was not being used with replication before, and so is missing
the contextCSN. But all the other operational attributes (entryUUID and
entryCSN in particular) are present and valid."
This made me wonder if the problem I'm seeing is because LDAP02 (or
LDAP01?) is somehow missing a contextCSN. I am seeing no "cookie"
messages associated with replication in my log.
Some of my config is below as well as the log messages I am seeing on
LDAP01 (edited domain & password). I did notice off-the-bat though
that I am missing an "olcDbIndex: entryUUID pres,eq" entry on LDAP02
where I have it on LDAP01. Is that a crucial setting for replication?
Lastly, I deleted the database files in /var/lib/ldap/ on LDAP02 and
restarted slapd once I had configured "olcSyncRepl" on LDAP02 to
ensure that I was starting from scratch.
-------
LDAP01's log entry for LDAP02's attempted connection looks like this:
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 fd=359 ACCEPT from
IP=192.168.21.60:46198 (IP=0.0.0.0:389)
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=0 STARTTLS
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=0 RESULT oid= err=0 text=
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 fd=359 TLS established
tls_ssf=256 ssf=256
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=1 BIND
dn="cn=root,dc=myerslab,dc=haib,dc=org" method=128
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=1 BIND
dn="cn=root,dc=myerslab,dc=haib,dc=org" mech=SIMPLE ssf=0
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=1 RESULT tag=97 err=0 text=
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=2 SRCH
base="dc=myerslab,dc=haib,dc=org" scope=2 deref=0
filter="(objectClass=*)"
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=2 SRCH attr=* +
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=2 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=3 UNBIND
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 fd=359 closed
-------
LDAP02's /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:
dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=mydomain,dc=org
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,dc=mydomain,dc=org
olcRootPW::
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap
olcDbCacheSize: 50000
olcDbCheckpoint: 10240 720
olcSyncrepl: {0}rid=001 provider=ldap://ldap01.mydomain.org bindmethod=si
mple timeout=1 network-timeout=0 binddn="cn=root,dc=mydomain,dc=org"
credentials="ld4p3650" keepalive=0:0:0 starttls=yes filter="(objectclass=*)" s
earchbase="dc=mydomain,dc=org" scope=sub schemachecking=off type=refr
eshOnly interval=00:00:00:10 retry="5 5 300 5"
tls_cacert=/etc/openldap/certs/rootCA.cert
olcUpdateRef: ldap://ldap01.mydomain.org
olcMirrorMode: TRUE
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass pres,eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: ou pres,eq,sub
olcDbIndex: loginShell pres,eq
olcDbIndex: sn pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbIndex: memberUid pres,eq,sub
olcDbIndex: nisMapName pres,eq,sub
olcDbIndex: nisMapEntry pres,eq,sub
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 31e2c8b0-c0ec-1033-8c20-43a6f59853d5
creatorsName: cn=config
createTimestamp: 20140825214036Z
entryCSN: 20140912164223.814325Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140912164223Z
-------
LDAP01's /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:
dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=mydomain,dc=org
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no
ne
olcAccess: {1}to * by anonymous read
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,dc=mydomain,dc=org
olcRootPW::
olcSyncUseSubentry: FALSE
olcMirrorMode: TRUE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap
olcDbCacheSize: 50000
olcDbCheckpoint: 10240 720
olcDbConfig: {0}# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/1
2/18 11:53:27 ghenry Exp $
olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas
es.
olcDbConfig: {2}#
olcDbConfig: {3}# See the Oracle Berkeley DB documentation
olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d
b/db/ref/env/db_config.html>
olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
olcDbConfig: {6}#
olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl
PTI+
olcDbConfig: {9}# in particular:
olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075>
olcDbConfig: {11}
olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re
building
olcDbConfig: {13}# the DB environment.
olcDbConfig: {14}
olcDbConfig: {15}# one 0.25 GB cache
olcDbConfig: {16}set_cachesize 0 268435456 1
olcDbConfig: {17}
olcDbConfig: {18}# Data Directory
olcDbConfig: {19}#set_data_dir db
olcDbConfig: {20}
olcDbConfig: {21}# Transaction Log settings
olcDbConfig: {22}set_lg_regionmax 262144
olcDbConfig: {23}set_lg_bsize 2097152
olcDbConfig: {24}#set_lg_dir logs
olcDbConfig: {25}
olcDbConfig: {26}# Note: special DB_CONFIG flags are no longer needed for "qui
ck"
olcDbConfig:: ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl
aXIgLXEgb3B0aW9uKS4g
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass pres,eq
olcDbIndex: entryUUID pres,eq
olcDbIndex: entryCSN pres,eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: ou pres,eq,sub
olcDbIndex: mail pres,eq,sub
olcDbIndex: memberUid pres,eq,sub
olcDbIndex: sn pres,eq,sub
olcDbIndex: loginShell pres,eq
olcDbIndex: givenName pres,eq,sub
olcDbIndex: nisMapName pres,eq,sub
olcDbIndex: nisMapEntry pres,eq,sub
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 727d260c-cc5c-1032-89cf-2fc7acd5ca31
creatorsName: cn=config
createTimestamp: 20131018161654Z
entryCSN: 20140915195740.431843Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140915195740Z
------
Thanks,
Josh Nielsen
Hi,
On 25/06/2009 15:56, Lanfeust troy wrote:
> Hi list,
>
> In configuration of provider and consumer server with syncrepl is
> possible to modify the replication filter for add new user in replica.
>
> In fisrt time the replica is :
>
> syncrepl rid=123
> provider=ldap://rh-test3.kvm.rla:389
> type=refreshOnly
> interval=00:00:01:00
> retry="30 10 600 20"
> searchbase="dc=local"
> filter="(|(objectClass=sambaGroupMapping)(uid=user1))"
> scope=sub
> schemachecking=off
> bindmethod=simple
> binddn="uid=syncrepl,ou=sysusers,dc=local"
> credentials=pwdsyncrepl
> # BEGIN Session TLS
> starttls="critical"
> tls_cacert=__CACERTFILE__
> # End Session TLS
Be careful of this syntax. Every line beginning with white space is
considered a continuation of the previous line.
So when this configuration file is read, it appears as one long line
starting with syncrepl... and anything after a "#" is a comment. So your
tls options are not being used, here.
> When start the replica server it doing an ldapsearch and retrieve my
> data in replica.
>
> So now we modify the filter as the following :
> filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))"
>
> Now when the replica doing the ldapsearch request it do with the new
> filter but returning numentrie to 0
> like this in the log of master LDAP server:
>
> Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=1 BIND
> dn="uid=syncrepl,ou=sysusers,dc=local" mech=SIMPLE ssf=0
> Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=1 RESULT tag=97 err=0
> text=
> Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SRCH base="dc=local"
> scope=2 deref=0
> filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))"
> Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SRCH attr=* +
> Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SEARCH RESULT
> tag=101 err=0 *nentries=0* text=
>
> And when i do ldapsearch manually :
>
> ldapsearch -x -b dc=local -H ldap://rh-test3.kvm.rla
> "(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))"
>
> Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=1 BIND dn="" method=128
> Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=1 RESULT tag=97 err=0
> text=
> Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=2 SRCH
> base="dc=local" scope=2 deref=0
> filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))"
> Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=2 SEARCH RESULT
> tag=101 err=0 *nentries=13* text=
>
>
> I don't understand why my new user is not sync !!
The reason for this is that syncrepl is state-based. This means that
when you restart your replica server, it only queries the master for
changes since the last know replication. If the object uid=user2 had
been changed since then, it would have been replicated.
If you change your syncrepl configuration, you should reset this status
by launching slapd with "-c rid=123". This will cause it to start
syncrepl from scratch, and will replicate all entries.
Regards,
Jonathan
--
--------------------------------------------------------------
Jonathan Clarke - jonathan(a)phillipoux.net
--------------------------------------------------------------
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--------------------------------------------------------------
Apologies for taking a while (and top posting - blackberry).
1)I setup the mirror-mode servers behind a VIP (named ldapmaster1 & 2). VIP hosted on an F5 BigIP - which doesn't load balance StartTLS - which was fine by us - all 389 connections are insecure and all 686 (?) are secure.
2) I created a cert via a CA trusted on all my client machines with:
2.A) Subject: ldap-vip.[domain]
2.B) subjectAltName(s): ldapmaster1.[domain], ldapmaster2.[domain], ldap-vip.[domain]
(Subject included in alt name list as some clients - like firefox - ignore the subject if alt names exist - dumb IMNSHO.)
Then the servers use the same cert to sync w/ each other as the clients use to connect to the VIP (or if needed, directly to the ldapmaster servers).
The subjectAltName part of a cert is the 'tricky' part I think you're missing knowledge of.
A wildcard cert works too, but then it'd be valid for any host *.[domain]. Not the most secure setup.
- chris
Chris Jacobs, Systems Administrator, Technology Services Group
Apollo Group | Apollo Marketing and Product Development | Aptimus, Inc.
2001 6th Ave | Suite 3200 | Seattle, WA 98121
direct 206.839.8245 | cell 206.601.3256 | fax 206.839.8106
email chris.jacobs(a)apollogrp.edu
________________________________
From: Daniel Qian <daniel(a)up247solution.com>
To: Chris Jacobs
Cc: 'openldap-technical(a)openldap.org' <openldap-technical(a)openldap.org>
Sent: Fri Aug 26 13:35:10 2011
Subject: Re: Syncrepl over TLS for mirrormode
Still not sure how you did it. Are you saying you set the same certificate in slapd and played with DNS to make it look like only one server(URL) to everyone?
Thanks,
Daniel
On 11-08-26 4:03 PM, Chris Jacobs wrote:
What I did:
* setup servers behind VIP
* obtain cert with primary name of vip DNS w/ secondary names of the servers.
That way, the servers can sync/tryst each other via the same cert used by clients.
Note: some clients (lookin at you Firefox) won't use the primary name if subjectaltname exists - so include primary name in the alt names JIC.
- chris
Chris Jacobs, Systems Administrator, Technology Services Group
Apollo Group | Apollo Marketing and Product Development� |� Aptimus, Inc.
2001 6th Ave� |� Suite 3200� |� Seattle, WA 98121
direct 206.839.8245� |� cell 206.601.3256� |� fax 206.839.8106
email chris.jacobs(a)apollogrp.edu<mailto:chris.jacobs@apollogrp.edu>
________________________________
From: openldap-technical-bounces(a)OpenLDAP.org<mailto:openldap-technical-bounces@OpenLDAP.org> <openldap-technical-bounces(a)OpenLDAP.org><mailto:openldap-technical-bounces@OpenLDAP.org>
To: openldap-technical(a)openldap.org<mailto:openldap-technical@openldap.org> <openldap-technical(a)openldap.org><mailto:openldap-technical@openldap.org>
Sent: Fri Aug 26 12:49:04 2011
Subject: Syncrepl over TLS for mirrormode
From the openldap website the two nodes have to use different URLs like below:
syncrepl rid=001
provider=ldap://ldap-sid2.example.com
bindmethod=simple
binddn="cn=mirrormode,dc=example,dc=com"
credentials=mirrormode
searchbase="dc=example,dc=com"
schemachecking=on
type=refreshAndPersist
retry="60 +"
and
syncrepl rid=001
provider=ldap://ldap-sid1.example.com
bindmethod=simple
binddn="cn=mirrormode,dc=example,dc=com"
credentials=mirrormode
searchbase="dc=example,dc=com"
schemachecking=on
type=refreshAndPersist
retry="60 +"
I can set two different certificates so that TLS is fine for sync between the two nodes. However we will have regular Ldap client access these two nodes behind a loadbalancer over TLS too. Obviously the client can't connect with ldap-sid2.example.com, nor with ldap-sid1.example.com. So what is the solution to this scenario? Setup a pool of consumers with same hostname?
Thanks,
Daniel
________________________________
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
________________________________
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.