openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

OpenLdap provider-client replication error
by Seun Ojedeji 12 Mar '14

12 Mar '14

Hello, I am trying to setup a sync between 2 ldap instance, following the guide here<http://askubuntu.com/questions/360190/how-to-configure-master-slave-ldap-re…>. I ran the command below, but got the following error message. sudo ldapadd -x -W -D cn=admin,dc=acme,dc=come -f /root/enable_sync_prov.ldif Enter LDAP Password: *modifying entry "olcDatabase={1}hdb,cn=config"ldap_modify: Insufficient access (50)* How do i fix the insuffient access problem? I am using the admin that has full write access on ldap. Regards -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji(a)fuoye.edu.ng <seun.ojedeji(a)fuoye.edu.ng>*

2 8

Re: TLS QUESTION
by Dieter Klünter 12 Mar '14

12 Mar '14

Am Tue, 11 Mar 2014 09:19:15 -0400 schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > Guten morgen Dieter; > > I ran the openssl commands indicated below. > > But, ran them against my cacert.pem -- both the original and new > successfully (they failed with servercrt.pem). > > I re-ran the CA.sh script this morning, and receiving the following > errors when creating a new CA: > > Certificate is to be certified until Mar 8 13:09:05 2024 GMT (3650 > days) failed to update database > TXT_DB error number 2 This is an error of your certificate database files index.txt and serial. -Dieter > -----Original Message----- > From: Dieter Klünter [mailto:dieter@dkluenter.de] > Sent: Monday, March 10, 2014 5:12 PM > To: Borresen, John - 0442 - MITLL > Subject: Re: TLS QUESTION > > Am Mon, 10 Mar 2014 16:55:04 -0400 > schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > > > Vielen Danke Dieter; > > > > Originally my command to create the client.pem was: > > > > grep -A 100 CERTIFICATE cacert.pem > client.pem > > > > Then I scp'd that out to the clients. That worked when doing SSL > > on port 636 (and not wild-card certificates), but it is not working > > now on TLS over 389 to mm-server1 and mm-server3 with wild-card > > certs. > > > > The cacert.pem and client.pem is on each client. > > > > Doing further reading...the client.pem since it was built off the > > cacert.pem (the server certificate) it should work. > > > > Should I use the cacert.pem or the servercrt.pem to create the > > client.pem? > > Test this on each host > openssl verify -CAfile path/to/ca client.pem servercert.pem > > openssl x509 -in servercert.pem -noout -text check for Common Name > > -Dieter > > > > > > > > > > > > > -----Original Message----- > > From: Dieter Klünter [mailto:dieter@dkluenter.de] > > Sent: Monday, March 10, 2014 2:41 PM > > To: Borresen, John - 0442 - MITLL > > Subject: Re: TLS QUESTION > > > > Am Mon, 10 Mar 2014 13:33:53 -0400 > > schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > > > > > Thanks Dieter... > > > > > > As I stated I saw Howard Chu's response to an individual in 2005 > > > with a similar issue and he stated then, " For the slapd server > > > you use the corresponding TLSCACertificateFile directive. You > > > must use these configuration directives if you want to accept a > > > self-signed cert." > > > > > > I did add the olcTLSCACertificateFile attribute (just forgot to > > > list it in my original post). Was not certain at the time if the > > > "olcTLSCertificateFile" should be removed so I did not remove it. > > > So, before I do remove it, the attribute should be > > > "olcTLSCACertificateFile" instead of "olcTLSCertificateFile" (and > > > this should be removed), correct? > > > > > > The CA directories on all three servers look like this: > > > > > > # ll > > > total 28 > > > lrwxrwxrwx 1 root root 10 Jan 24 11:44 600f07a1.0 -> cacert.pem > > > --> client hash -rw-r--r-- 1 ldap ldap 5136 Jan 17 12:15 > > > cacert.pem --> Self-signed certificate -rw-r--r-- 1 ldap ldap > > > 1090 Jan 17 12:07 cert.csr --> Certificate Signing Request > > > -rw-r--r-- 1 ldap ldap 1757 Jan 17 12:23 client.pem --> Client > > > Certificate PEM -rw-r--r-- 1 ldap ldap 0 Jan 14 16:20 > > > index.txt drwxr-xr-x 2 ldap ldap 4096 Jan 14 16:18 newcerts > > > (empty) drwxr-xr-x 2 ldap ldap 4096 Jan 17 12:06 private --> > > > server private key directory (cakey.pem) -rw-r--r-- 1 ldap > > > ldap 3 Jan 17 11:59 serial This may sound like a dumb > > > question... > > > > > > I created the client.pem from the cacert.pem (as indicated on > > > openssl.org) then copied that to each client. Is there a step I > > > missed in there? > > > > Yes, you have to create a client certificate for each host, while > > the Common Name must match the FQDN of this host. my blog entry may > > be of help: > > > > https://sys4.de/de/blog/2013/08/20/how-create-and-administer-x509-cert > > ificate-chains-part-i > > > > -Dieter > > > > > If so, where? > > > > > > Thanks in advance > > > > > > John > > > -----Original Message----- > > > From: openldap-technical-bounces(a)OpenLDAP.org > > > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of > > > Dieter Klünter Sent: Monday, March 10, 2014 12:58 PM To: > > > openldap-technical(a)openldap.org Subject: Re: TLS QUESTION > > > > > > Am Mon, 10 Mar 2014 11:18:14 -0400 > > > schrieb "Borresen, John - 0442 - MITLL" > > > <John.Borresen(a)ll.mit.edu>: > > > > > > > All, > > > > > > > > > > > > > > > > My set up consists of three servers each syncing with each > > > > other. The host names are: > > > > > > > > 1) mm-server1.example.ldap > > > > > > > > 2) mm-server2.example.ldap > > > > > > > > 3) mm-server3.example.ldap > > > > > > > > > > > > > > > > Utilizing TLSv1, on all three I have: > > > > > > > > olcTLSCertificateFile: > > > > /usr/local/openldap/etc/openldap/CA/cacert.pem > > > > > > this should be opcTLSCAcertificateFile > > > > > > > > > > > olcTLSCertificateKeyFile: > > > > /usr/local/openldap/etc/openldap/CA/private/cakey.pem > > > > > > you are misssing the host certificate, something like > > > olcTLSCertificateFile /usr/local/openldap/etc/openldap/CA/host.pem > > > > > > > > > > > olcTLSCipherSuite: HIGH:MEDIUM+TLSv1+SSLv3 > > > > > > > > > > > > > > > > Configured with self-signed wild-card certs, originally > > > > configured (using openssl 0.9.8) on mm-server2 and exported to > > > > the other servers. > > > > > > > > > > > > > > > > When running ldapmodify, ldapsearch, etc with a "-Z", and > > > > openssl s_client on mm-server1 or mm-server3 or any client > > > > pointing back to mm-server1 or 3, I receive the following error: > > > > > > > > > > > > > > > > TLS certificate verification: Error, self signed certificate > > > > > > > > TLS: can't connect: error:14090086:SSL > > > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > > > (self signed certificate). > > > > > > > > ldap_start_tls: Connect error (-11) > > > > > > > > additional info: error:14090086:SSL > > > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > > > (self signed certificate) > > > > > > > > > > > > > > > > Running any of those to mm-server2, it works with no such error. > > > > > > > > > > > > > > > > I am guessing, that since the certs were created on mm-server2, > > > > originally, that is why it works this way. Also, guessing I > > > > missed a step somewhere. > > > > > > > > > > > > > > > > I read online a post from 2005 with a good explanation of > > > > self-signed from Howard Chu about a similar problem. > > > > > > > > > > > > > > > > What is the best procedure for creating wild-card certs and > > > > sharing those out to other servers? The procedure that was > > > > used was from openssl.org so it was not a fly-by-night weblog. > > > > > > > > > > > > > > > > What did I miss (besides: a lot)? > > > > > > > > > > > > > > > > Thanks in advance, > > > > > > > > > > > > > > > > > > > > > > > > John D. Borresen (Dave) > > > > > > > > Linux/Unix Systems Administrator > > > > > > > > MIT Lincoln Laboratory > > > > > > > > Surveillance Systems Group > > > > > > > > 244 Wood St > > > > > > > > Lexington, MA 02420 > > > > > > > > Ph: (781) 981-1609 > > > > > > > > Email: john.borresen(a)ll.mit.edu > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Dieter Klünter | Systemberatung > > > http://sys4.de > > > GPG Key ID: E9ED159B > > > 53°37'09,95"N > > > 10°08'02,42"E > > > > > > > > > > > -- > > Dieter Klünter | Systemberatung > > http://sys4.de > > GPG Key ID: E9ED159B > > 53°37'09,95"N > > 10°08'02,42"E > > > > -- > Dieter Klünter | Systemberatung > http://sys4.de > GPG Key ID: E9ED159B > 53°37'09,95"N > 10°08'02,42"E -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

2 8

LMDB test assertion failures on Linux/MIPS
by Martin Lucina 11 Mar '14

11 Mar '14

Hi, I've recently started using LMDB in a new project targeted to MIPS (and later also ARM) architectures. While developing my storage code I found that test cases which execute perfectly on x86 were failing with assertions inside LMDB on mips and mipsel devices. Investigating further, I've found that the "mtest" test program included with LMDB also fails. Specifically, the failures I'm seeing are any of the following: mdb.c:2635: Assertion 'pglast <= env->me_pglast' failed in mdb_freelist_save() or mdb.c:5100: Assertion 'IS_BRANCH(mc->mc_pg[mc->mc_top])' failed in mdb_cursor_sibling() or mdb.c:5176: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() or mdb.c:1713: Assertion 'rc == 0' failed in mdb_page_dirty() etc. The failures are intermittent in that there's about a 50% chance mtest will complete successfully. The line numbers are against LMDB 0.9.11 source. Target devices and toolchain combinations I have tried (all fail): - mips-sf-linux-musl cross compilers from musl.codu.org, musl libc 0.9.15. Atheros AR9344 cpu, OpenWRT trunk (Linux 3.10.28). - mipsel-sf-linux-musl cross compilers from musl.codu.org, musl libc 0.9.15, Broadcom BCM4706, Tomato firmware by "shibby" (Linux 2.6.22.x based on ASUS SDK). In all cases the code fails both with and without optimization, and is compiled as a static executable. Consulting with a friend who is also developing on MIPS devices he said he ran into similar problems when trying LMDB. He suggested that I check for problems with unaligned memory accesses; indeed compiling LMDB with -Wcast-align produces many warnings regarding such accesses. My knowledge of LMDB and MIPS internals is not up to debugging this but it seems like unaligned accesses may(?) be the underlying cause. What is the status of LMDB on MIPS? Has anyone tried it? Any help would be much appreciated. Martin

4 16

open(ldap|ssh) interaction
by Doug OLeary 11 Mar '14

11 Mar '14

Hey; When using local accounts, ssh honors password expiration even if using public key authentication. This is the case at least on HPUX, Solaris, and various flavors of Linux. This is a good thing. I won't go through all the security reasons why passwords should periodically change. Suffice to say that they should and most companies have policies regarding password expiration. When using openldap, however, if a user is configured to use public key authentication, he is allowed access to the account regardless of the password aging and/or pwdReset parameter. Is there a way to force openssh to honor these settings like it does for local accounts? Test environment is centos6.5 running on a kvm tying into an openldap server ver 2.4.23. My test environment is certainly following the symptoms of my client's unboundid server supporting a variety of linux platforms - all rhel based - from ver 4 through 6. Any help greatly appreciated. Doug O'Leary ------------ Senior UNIX/Security Admin CISSP, CISA, RHCSA, CEH O'Leary Computers Inc dkoleary(a)olearycomputers.com (w) 630-904-6098 (c) 630-248-2749 linkedin: http://www.linkedin.com/in/dkoleary resume: http://www.olearycomputers.com/resume.html

6 8

LMDB and FD_CLOEXEC
by Martin Lucina 11 Mar '14

11 Mar '14

Hi, is there any particular reason for MDB setting FD_CLOEXEC *only* on me->lfd? I can't see why it should not set it for the other fds it opens, as IMO it doesn't make sense to hang onto the fds after exec() -- the mmap will be gone in any case. Martin

2 4

Stuck with SSL issue
by saurabh ohri 11 Mar '14

11 Mar '14

Hi All, my ldapsearch and other things were working perfectly fine but not sure what happened now. Seem some SSL issue. When i am doing ldapsearch i am getting below error. [root@xxx-xxx-xxx etc]# ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f /usr/local/openldap/dit.ldif -H ldaps://xxx-xxx-xxx.example.com Enter LDAP Password: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Logs error: TLS trace: SSL_accept:SSLv3 flush data tls_read: want=5 error=Resource temporarily unavailable TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A 531ecbee daemon: activity on 1 descriptor 531ecbee daemon: activity on:531ecbee 531ecbee daemon: epoll: listen=7 active_threads=0 tvp=zero 531ecbee daemon: activity on 1 descriptor 531ecbee daemon: activity on:531ecbee 11r531ecbee 531ecbee daemon: read active on 11 531ecbee daemon: epoll: listen=7 active_threads=0 tvp=zero 531ecbee connection_get(11) 531ecbee connection_get(11): got connid=1000 531ecbee connection_read(11): checking for input on id=1000 tls_read: want=5, got=5 0000: 15 03 01 00 02 ..... tls_read: want=2, got=2 0000: 02 30 .0 TLS trace: SSL3 alert read:fatal:unknown CA ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca. 531ecbee connection_read(11): TLS accept failure error=-1 id=1000, closing 531ecbee connection_closing: readying conn=1000 sd=11 for close 531ecbee connection_close: conn=1000 sd=11 531ecbee daemon: removing 11 531ecbee daemon: activity on 1 descriptor 531ecbee daemon: activity on:531ecbee 531ecbee daemon: epoll: listen=7 active_threads=0 tvp=zero Please suggest. Regards Sam

4 4

RE: TLS QUESTION
by Borresen, John - 0442 - MITLL 11 Mar '14

11 Mar '14

Guten morgen Dieter; I ran the openssl commands indicated below. But, ran them against my cacert.pem -- both the original and new successfully (they failed with servercrt.pem). I re-ran the CA.sh script this morning, and receiving the following errors when creating a new CA: Certificate is to be certified until Mar 8 13:09:05 2024 GMT (3650 days) failed to update database TXT_DB error number 2 -----Original Message----- From: Dieter Klünter [mailto:dieter@dkluenter.de] Sent: Monday, March 10, 2014 5:12 PM To: Borresen, John - 0442 - MITLL Subject: Re: TLS QUESTION Am Mon, 10 Mar 2014 16:55:04 -0400 schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > Vielen Danke Dieter; > > Originally my command to create the client.pem was: > > grep -A 100 CERTIFICATE cacert.pem > client.pem > > Then I scp'd that out to the clients. That worked when doing SSL on > port 636 (and not wild-card certificates), but it is not working now > on TLS over 389 to mm-server1 and mm-server3 with wild-card certs. > > The cacert.pem and client.pem is on each client. > > Doing further reading...the client.pem since it was built off the > cacert.pem (the server certificate) it should work. > > Should I use the cacert.pem or the servercrt.pem to create the > client.pem? Test this on each host openssl verify -CAfile path/to/ca client.pem servercert.pem openssl x509 -in servercert.pem -noout -text check for Common Name -Dieter > > > > > > -----Original Message----- > From: Dieter Klünter [mailto:dieter@dkluenter.de] > Sent: Monday, March 10, 2014 2:41 PM > To: Borresen, John - 0442 - MITLL > Subject: Re: TLS QUESTION > > Am Mon, 10 Mar 2014 13:33:53 -0400 > schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > > > Thanks Dieter... > > > > As I stated I saw Howard Chu's response to an individual in 2005 > > with a similar issue and he stated then, " For the slapd server you > > use the corresponding TLSCACertificateFile directive. You must use > > these configuration directives if you want to accept a self-signed > > cert." > > > > I did add the olcTLSCACertificateFile attribute (just forgot to list > > it in my original post). Was not certain at the time if the > > "olcTLSCertificateFile" should be removed so I did not remove it. > > So, before I do remove it, the attribute should be > > "olcTLSCACertificateFile" instead of "olcTLSCertificateFile" (and > > this should be removed), correct? > > > > The CA directories on all three servers look like this: > > > > # ll > > total 28 > > lrwxrwxrwx 1 root root 10 Jan 24 11:44 600f07a1.0 -> cacert.pem > > --> client hash -rw-r--r-- 1 ldap ldap 5136 Jan 17 12:15 cacert.pem > > --> Self-signed certificate -rw-r--r-- 1 ldap ldap 1090 Jan 17 > > 12:07 cert.csr --> Certificate Signing Request -rw-r--r-- 1 ldap > > ldap 1757 Jan 17 12:23 client.pem --> Client Certificate PEM > > -rw-r--r-- 1 ldap ldap 0 Jan 14 16:20 index.txt drwxr-xr-x 2 > > ldap ldap 4096 Jan 14 16:18 newcerts (empty) drwxr-xr-x 2 ldap ldap > > 4096 Jan 17 12:06 private --> server private key directory > > (cakey.pem) -rw-r--r-- 1 ldap ldap 3 Jan 17 11:59 serial > > This may sound like a dumb question... > > > > I created the client.pem from the cacert.pem (as indicated on > > openssl.org) then copied that to each client. Is there a step I > > missed in there? > > Yes, you have to create a client certificate for each host, while the > Common Name must match the FQDN of this host. my blog entry may be of > help: > > https://sys4.de/de/blog/2013/08/20/how-create-and-administer-x509-cert > ificate-chains-part-i > > -Dieter > > > If so, where? > > > > Thanks in advance > > > > John > > -----Original Message----- > > From: openldap-technical-bounces(a)OpenLDAP.org > > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter > > Klünter Sent: Monday, March 10, 2014 12:58 PM To: > > openldap-technical(a)openldap.org Subject: Re: TLS QUESTION > > > > Am Mon, 10 Mar 2014 11:18:14 -0400 > > schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > > > > > All, > > > > > > > > > > > > My set up consists of three servers each syncing with each other. > > > The host names are: > > > > > > 1) mm-server1.example.ldap > > > > > > 2) mm-server2.example.ldap > > > > > > 3) mm-server3.example.ldap > > > > > > > > > > > > Utilizing TLSv1, on all three I have: > > > > > > olcTLSCertificateFile: > > > /usr/local/openldap/etc/openldap/CA/cacert.pem > > > > this should be opcTLSCAcertificateFile > > > > > > > > olcTLSCertificateKeyFile: > > > /usr/local/openldap/etc/openldap/CA/private/cakey.pem > > > > you are misssing the host certificate, something like > > olcTLSCertificateFile /usr/local/openldap/etc/openldap/CA/host.pem > > > > > > > > olcTLSCipherSuite: HIGH:MEDIUM+TLSv1+SSLv3 > > > > > > > > > > > > Configured with self-signed wild-card certs, originally configured > > > (using openssl 0.9.8) on mm-server2 and exported to the other > > > servers. > > > > > > > > > > > > When running ldapmodify, ldapsearch, etc with a "-Z", and openssl > > > s_client on mm-server1 or mm-server3 or any client pointing back > > > to mm-server1 or 3, I receive the following error: > > > > > > > > > > > > TLS certificate verification: Error, self signed certificate > > > > > > TLS: can't connect: error:14090086:SSL > > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > > (self signed certificate). > > > > > > ldap_start_tls: Connect error (-11) > > > > > > additional info: error:14090086:SSL > > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > > (self signed certificate) > > > > > > > > > > > > Running any of those to mm-server2, it works with no such error. > > > > > > > > > > > > I am guessing, that since the certs were created on mm-server2, > > > originally, that is why it works this way. Also, guessing I > > > missed a step somewhere. > > > > > > > > > > > > I read online a post from 2005 with a good explanation of > > > self-signed from Howard Chu about a similar problem. > > > > > > > > > > > > What is the best procedure for creating wild-card certs and > > > sharing those out to other servers? The procedure that was used > > > was from openssl.org so it was not a fly-by-night weblog. > > > > > > > > > > > > What did I miss (besides: a lot)? > > > > > > > > > > > > Thanks in advance, > > > > > > > > > > > > > > > > > > John D. Borresen (Dave) > > > > > > Linux/Unix Systems Administrator > > > > > > MIT Lincoln Laboratory > > > > > > Surveillance Systems Group > > > > > > 244 Wood St > > > > > > Lexington, MA 02420 > > > > > > Ph: (781) 981-1609 > > > > > > Email: john.borresen(a)ll.mit.edu > > > > > > > > > > > > > > > > > -- > > Dieter Klünter | Systemberatung > > http://sys4.de > > GPG Key ID: E9ED159B > > 53°37'09,95"N > > 10°08'02,42"E > > > > > > -- > Dieter Klünter | Systemberatung > http://sys4.de > GPG Key ID: E9ED159B > 53°37'09,95"N > 10°08'02,42"E -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

1 0

RE: TLS QUESTION
by Borresen, John - 0442 - MITLL 11 Mar '14

11 Mar '14

Vielen Danke Dieter; Originally my command to create the client.pem was: grep -A 100 CERTIFICATE cacert.pem > client.pem Then I scp'd that out to the clients. That worked when doing SSL on port 636 (and not wild-card certificates), but it is not working now on TLS over 389 to mm-server1 and mm-server3 with wild-card certs. The cacert.pem and client.pem is on each client. Doing further reading...the client.pem since it was built off the cacert.pem (the server certificate) it should work. Should I use the cacert.pem or the servercrt.pem to create the client.pem? Thanks, John -----Original Message----- From: Dieter Klünter [mailto:dieter@dkluenter.de] Sent: Monday, March 10, 2014 2:41 PM To: Borresen, John - 0442 - MITLL Subject: Re: TLS QUESTION Am Mon, 10 Mar 2014 13:33:53 -0400 schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > Thanks Dieter... > > As I stated I saw Howard Chu's response to an individual in 2005 with > a similar issue and he stated then, " For the slapd server you use the > corresponding TLSCACertificateFile directive. You must use these > configuration directives if you want to accept a self-signed cert." > > I did add the olcTLSCACertificateFile attribute (just forgot to list > it in my original post). Was not certain at the time if the > "olcTLSCertificateFile" should be removed so I did not remove it. > So, before I do remove it, the attribute should be > "olcTLSCACertificateFile" instead of "olcTLSCertificateFile" (and this > should be removed), correct? > > The CA directories on all three servers look like this: > > # ll > total 28 > lrwxrwxrwx 1 root root 10 Jan 24 11:44 600f07a1.0 -> cacert.pem --> > client hash -rw-r--r-- 1 ldap ldap 5136 Jan 17 12:15 cacert.pem --> > Self-signed certificate -rw-r--r-- 1 ldap ldap 1090 Jan 17 12:07 > cert.csr --> Certificate Signing Request -rw-r--r-- 1 ldap ldap 1757 > Jan 17 12:23 client.pem --> Client Certificate PEM -rw-r--r-- 1 ldap > ldap 0 Jan 14 16:20 index.txt drwxr-xr-x 2 ldap ldap 4096 Jan 14 > 16:18 newcerts (empty) drwxr-xr-x 2 ldap ldap 4096 Jan 17 12:06 > private --> server private key directory (cakey.pem) -rw-r--r-- 1 > ldap ldap 3 Jan 17 11:59 serial > This may sound like a dumb question... > > I created the client.pem from the cacert.pem (as indicated on > openssl.org) then copied that to each client. Is there a step I > missed in there? Yes, you have to create a client certificate for each host, while the Common Name must match the FQDN of this host. my blog entry may be of help: https://sys4.de/de/blog/2013/08/20/how-create-and-administer-x509-certifica… -Dieter > If so, where? > > Thanks in advance > > John > -----Original Message----- > From: openldap-technical-bounces(a)OpenLDAP.org > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter > Klünter Sent: Monday, March 10, 2014 12:58 PM To: > openldap-technical(a)openldap.org Subject: Re: TLS QUESTION > > Am Mon, 10 Mar 2014 11:18:14 -0400 > schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > > > All, > > > > > > > > My set up consists of three servers each syncing with each other. > > The host names are: > > > > 1) mm-server1.example.ldap > > > > 2) mm-server2.example.ldap > > > > 3) mm-server3.example.ldap > > > > > > > > Utilizing TLSv1, on all three I have: > > > > olcTLSCertificateFile: > > /usr/local/openldap/etc/openldap/CA/cacert.pem > > this should be opcTLSCAcertificateFile > > > > > olcTLSCertificateKeyFile: > > /usr/local/openldap/etc/openldap/CA/private/cakey.pem > > you are misssing the host certificate, something like > olcTLSCertificateFile /usr/local/openldap/etc/openldap/CA/host.pem > > > > > olcTLSCipherSuite: HIGH:MEDIUM+TLSv1+SSLv3 > > > > > > > > Configured with self-signed wild-card certs, originally configured > > (using openssl 0.9.8) on mm-server2 and exported to the other > > servers. > > > > > > > > When running ldapmodify, ldapsearch, etc with a "-Z", and openssl > > s_client on mm-server1 or mm-server3 or any client pointing back to > > mm-server1 or 3, I receive the following error: > > > > > > > > TLS certificate verification: Error, self signed certificate > > > > TLS: can't connect: error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self > > signed certificate). > > > > ldap_start_tls: Connect error (-11) > > > > additional info: error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self > > signed certificate) > > > > > > > > Running any of those to mm-server2, it works with no such error. > > > > > > > > I am guessing, that since the certs were created on mm-server2, > > originally, that is why it works this way. Also, guessing I missed > > a step somewhere. > > > > > > > > I read online a post from 2005 with a good explanation of > > self-signed from Howard Chu about a similar problem. > > > > > > > > What is the best procedure for creating wild-card certs and sharing > > those out to other servers? The procedure that was used was from > > openssl.org so it was not a fly-by-night weblog. > > > > > > > > What did I miss (besides: a lot)? > > > > > > > > Thanks in advance, > > > > > > > > > > > > John D. Borresen (Dave) > > > > Linux/Unix Systems Administrator > > > > MIT Lincoln Laboratory > > > > Surveillance Systems Group > > > > 244 Wood St > > > > Lexington, MA 02420 > > > > Ph: (781) 981-1609 > > > > Email: john.borresen(a)ll.mit.edu > > > > > > > > > > -- > Dieter Klünter | Systemberatung > http://sys4.de > GPG Key ID: E9ED159B > 53°37'09,95"N > 10°08'02,42"E > -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

2 1

Re: RE : Re: ppolicy not verifying password length (not active !!)
by saurabh ohri 11 Mar '14

11 Mar '14

Thanks David, Self Service Password Also please suggest if the entry for TLS cert need to be made at /etc/ldap.conf or /etc/openldap/ldap.conf or /usr/local/openldap/etc/openldap/ldap.conf(This is the default one with ltb openldap) and can I put file name with publickey.pem. Please suggest with the parameter as default suggest in doc not working. Regards Sam On Tuesday, 11 March 2014 3:58 PM, David Coutadeur <dcoutadeur(a)linagora.com> wrote: Password policy overlay is available by default in the main openldap ltb package. Just use it via the configuration. No need to load the module. You could also need the check-password addon for the ppolicy overlay, available in a separate rpm: openldap-ltb-check-password David -------- Message d'origine -------- De : saurabh ohri Date :11/03/2014 05:49 (GMT+01:00) A : Quanah Gibson-Mount ,Patrick Laimbock ,openldap-technical(a)openldap.org Objet : Re: ppolicy not verifying password length (not active !!) Hi quanah/Patrick, I installed openldap ltb project on a new server as mentioned and following are the list of packages which are currently present but still cannot see ppolicy.la in my system, [root@xxx-xxx-xxx ~]# rpm -qa|grep openldap openldap-ltb-debuginfo-2.4.39-2.el6.x86_64 openldap-clients-2.4.23-34.el6_5.1.x86_64 openldap-2.4.23-34.el6_5.1.x86_64 openldap-ltb-check-password-1.1-8.el6.x86_64 openldap-ltb-2.4.39-2.el6.x86_64 openldap-ltb-contrib-overlays-2.4.39-2.el6.x86_64 Please suggest. Is that i am doing something wrong? Regards Sam On Tuesday, 11 March 2014 10:07 AM, saurabh ohri <sam_ohri(a)yahoo.co.in> wrote: Thanks Quanah for the reply. Does that mean that i need to rebuild the openldap server or just download the ppolicy.la for 2.4.39 version. I installed openldap-ltb-2.4.39-2.el6.x86_64 on rhel6.5. Please suggest. Regards Saurabh 9818925959 On Tuesday, 11 March 2014 12:59 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: --On Monday, March 10, 2014 4:22 PM +0800 saurabh ohri <sam_ohri(a)yahoo.co.in> wrote: > > > Thanks Patrick. It helped me to very much extend but again getting stuck > in pushing password policy on openldap. I got stuck in 2.4.23 and > upgraded to 2.4.39. But still it is an issue. > > Not able to found ppolicy.la in my system but copied the same from > previous version. Hope that id not effecting. That is not ok. You need to build ppolicy with your 2.4.39 build, and use that verison of the module. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ppolicy not verifying password length (not active !!)
by Rodrigo Coutinho 11 Mar '14

11 Mar '14

Hi, I've installed the ppolicy overlay (static), included the shema, loaded the policy to the directory and define it as the default policy. However, to check the policy I've changed a user's password, below the minimum length specified by the policy, and no error was issued. I've used ldappasswd and Apache Directory Studio to change it and none issued no error. Although I did it with the root user, I suppose the policy should issue an error just the same, because I was changing another user's password. What am I missing, here ? Thank you in advance A transmiss�o de mensagens por e-mail n�o � absolutamente segura ou livre de erros. A mensagem pode ser intercetada, alterada, perdida, destru�da, chegar ao destinat�rio com atraso, ou mesmo com v�rus, n�o obstante o IFAP utilizar software anti-v�rus. Esta mensagem, incluindo eventuais ficheiros anexos, pode conter informa��o confidencial ou privilegiada e destina-se a uso exclusivo dos seus destinat�rios. Se n�o for o destinat�rio pretendido, informamos que a recebeu por engano, pelo que, qualquer utiliza��o, distribui��o, reencaminhamento ou outra forma de revela��o a terceiros, impress�o ou c�pia s�o expressamente proibidos. Se recebeu esta mensagem por engano, por favor contacte imediatamente o remetente por e-mail, e apague de imediato a mensagem do seu sistema inform�tico. O IFAP declina qualquer responsabilidade por erros ou omiss�es na presente mensagem e eventuais consequ�ncias, que resultem das situa��es referidas.

8 20

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical