Hi Quanah,
Sorry about my delay to answer you, I've been in vacation and away from PC.
I understand that I should use the same name when I'll update this file to make it easy, but it is a new installation and this reason that I need modify this entries.
I've tested your suggestion and delete operation has worked fine, but I've still had the same problem described previously when I've tried add new olcTLSCertificateFile or new olcTLSCertificateKeyFile or new olcTLSCACertificateFile. I don't understand the reason for that.
[root@localhost ldifs]# ldapmodify -Y EXTERNAL -H ldapi:/// -f 5tls.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80)
-- Igor Sousa
Em sex, 28 de jun de 2019 às 21:53, Quanah Gibson-Mount quanah@symas.com escreveu:
--On Friday, June 28, 2019 7:33 PM -0300 Igor Sousa igorvolt@gmail.com wrote:
dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/openldap/certs/ldap.local.crt
replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.local.key
add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/openldap/certs/ca.cert.pem
I would suggest simply using the same filenames as you had before, negating the need to modify the attributes at all. You're likely hitting ITS#8286 with the replace operations. Another idea may be to change replace to a delete+add in the same operation sequence.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Thursday, July 11, 2019 5:29 PM -0300 Igor Sousa igorvolt@gmail.com wrote:
I've tested your suggestion and delete operation has worked fine, but I've still had the same problem described previously when I've tried add new olcTLSCertificateFile or new olcTLSCertificateKeyFile or new olcTLSCACertificateFile. I don't understand the reason for that.
You're likely hitting ITS#8286 with the replace operations. Another
idea may be to change replace to a delete+add in the same operation sequence.
https://www.openldap.org/its/index.cgi/?findid=8286
The details in the ITS aren't as flushed out as they probably should be, but if a configuration element is missing an EQUALITY matching rule, then you generally cannot use a replace OP on them.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount wrote:
--On Thursday, July 11, 2019 5:29 PM -0300 Igor Sousa igorvolt@gmail.com wrote:
I've tested your suggestion and delete operation has worked fine, but I've still had the same problem described previously when I've tried add new olcTLSCertificateFile or new olcTLSCertificateKeyFile or new olcTLSCACertificateFile. I don't understand the reason for that.
You're likely hitting ITS#8286 with the replace operations. Another
idea may be to change replace to a delete+add in the same operation sequence.
https://www.openldap.org/its/index.cgi/?findid=8286
The details in the ITS aren't as flushed out as they probably should be, but if a configuration element is missing an EQUALITY matching rule, then you generally cannot use a replace OP on them.
That's not correct. A replace op always works. It is only [Delete/Add] value that requires an equality rule.
Howard and Quanah,
I think I understand what you have said me, but I am not still understanding what the reason to my ldif doesn't work. Thankfully my environment is a test environment. I have other test environment that has a difference between the first: I modified the first environment database to mdb database while the second is default installation where database is hdb (default).
In the second environment, I can modify olcTLSCertificateFile, olcTLSCertificateKeyFile and olcTLSCACertificateFile normally. For modify the first environment:
1. I stopped sladp service; 2. I got olc configurations from slapcat -n 0 command like: slapcat -n 0
config.ldif;
3. I added olcModuleLoad back_mdb on dn: cn=module{0},cn=config (I verified the olcModulePath and /usr/lib64; 4. I modified on dn: olcDatabase={2}hdb,cn=config the following attributes: - dn: olcDatabase={2}hdb,cn=config to dn: olcDatabase={2}mdb,cn=config - objectClass: olcHdbConfig to objectClass: olcMdbConfig - olcDatabase: {2}hdb to olcDatabase: {2}mdb - structuralObjectClass: olcHdbConfig to structuralObjectClass: olcMdbConfig - And finally, I ran this two command: - cat config.ldif | slapadd -v -F /etc/openldap/slapd.d -n 0 - chown -R /etc/openldap/slapd.d (to solve owner problem after run this command as root)
OBS: I've mounted environment on CentOS 7, added symas' repository and install from yum.
Is possible I have done something wrong in convert process?
-- Igor Sousa
Em qui, 11 de jul de 2019 às 22:56, Howard Chu hyc@symas.com escreveu:
Quanah Gibson-Mount wrote:
--On Thursday, July 11, 2019 5:29 PM -0300 Igor Sousa <
igorvolt@gmail.com> wrote:
I've tested your suggestion and delete operation has worked fine, but I've still had the same problem described previously when I've tried add new olcTLSCertificateFile or new olcTLSCertificateKeyFile or new olcTLSCACertificateFile. I don't understand the reason for that.
You're likely hitting ITS#8286 with the replace operations. Another
idea may be to change replace to a delete+add in the same operation
sequence.
https://www.openldap.org/its/index.cgi/?findid=8286
The details in the ITS aren't as flushed out as they probably should be,
but if a configuration element is missing an EQUALITY matching rule, then you generally
cannot use a replace OP on them.
That's not correct. A replace op always works. It is only [Delete/Add] value that requires an equality rule.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Hi everybody,
I've had some test aiming to understand why when I try to add/replace *olcTLSCACertificateFile*, *olcTLSCertificateFile* and *olcTLSCertificateKeyFile* the ldapmodify command returns "ldap_modify: Other (e.g., implementation specific) error (80)". Then, to remove all other variables, I've done a new simple installation:
*Step 1:* I've done a new CentOS 7 installation;
*Step 2:* I've added symas repo following all steps described by https://repo.symas.com/sofl/rhel7/;
*Step 3: *I've made sure that I've erased any other openldap version before to install symas-openldap server and client;
yum erase openldap-clients openldap-servers
yum -y update
yum install -y symas-openldap-clients symas-openldap-servers
*Step 4:* I haven't done any modification before to replace olcTLSCACertificateFile, olcTLSCertificateFile and olcTLSCertificateKeyFile; *Step 5: *I've generated CA key, CA certificate, ldap key, ldap certificate and I've signed ldap certificate with CA:
echo 0001 > serial touch index.txt openssl genrsa -aes256 -out /etc/pki/CA/private/ca.key.pem 4096 openssl req -new -x509 -days 3650 -key /etc/pki/CA/private/ca.key.pem -extensions v3_ca -out /etc/pki/CA/certs/ca.cert.pem openssl genrsa -aes256 -out /etc/pki/CA/private/ldap.local.key 4096 openssl req -new -key /etc/pki/CA/private/ldap.local.key -out /etc/pki/CA/certs/ldap.local.csr openssl ca -keyfile /etc/pki/CA/private/ca.key.pem -cert /etc/pki/CA/certs/ca.cert.pem -in /etc/pki/CA/certs/ldap.local.csr -out /etc/pki/CA/certs/ldap.local.crt
*Step 6: *I've copy ldap.local.key, ldap.local.crt and ca.cert.pem to /etc/openldap/certs and change the owner group to *ldap*.
chown :ldap /etc/openldap/certs/ldap.local.key
chown :ldap /etc/openldap/certs/ldap.local.crt
chown :ldap /etc/openldap/certs/ca.cert.pem
*Step 7:* I've tried replace *olcTLSCACertificateFile*, *olcTLSCertificateFile *and *olcTLSCertificateKeyFile *with following ldif <tls.ldif>:
dn: cn=config changetype: modify replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.local.key - replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/openldap/certs/ldap.local.crt - add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/openldap/certs/ca.cert.pem
It hasn't mattered what I've done, when I've ran ldapmodify command, it has returned me the same error.
[root@localhost ~]# ldapmodify -Y EXTERNAL -H ldapi:/// -f 5tls.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80)
I can change olcSuffix, change olcRootDN, change olcRootPW and I do other modification by ldif+ldapmodify normally.
Simply I don't understand what it is wrong in this ldif and appreciate your help.
-- Igor Sousa
Em sex, 12 de jul de 2019 às 09:30, Igor Sousa igorvolt@gmail.com escreveu:
Howard and Quanah,
I think I understand what you have said me, but I am not still understanding what the reason to my ldif doesn't work. Thankfully my environment is a test environment. I have other test environment that has a difference between the first: I modified the first environment database to mdb database while the second is default installation where database is hdb (default).
In the second environment, I can modify olcTLSCertificateFile, olcTLSCertificateKeyFile and olcTLSCACertificateFile normally. For modify the first environment:
- I stopped sladp service;
- I got olc configurations from slapcat -n 0 command like: slapcat -n
0 >> config.ldif; 3. I added olcModuleLoad back_mdb on dn: cn=module{0},cn=config (I verified the olcModulePath and /usr/lib64; 4. I modified on dn: olcDatabase={2}hdb,cn=config the following attributes: - dn: olcDatabase={2}hdb,cn=config to dn: olcDatabase={2}mdb,cn=config - objectClass: olcHdbConfig to objectClass: olcMdbConfig - olcDatabase: {2}hdb to olcDatabase: {2}mdb - structuralObjectClass: olcHdbConfig to structuralObjectClass: olcMdbConfig - And finally, I ran this two command: - cat config.ldif | slapadd -v -F /etc/openldap/slapd.d -n 0 - chown -R /etc/openldap/slapd.d (to solve owner problem after run this command as root)
OBS: I've mounted environment on CentOS 7, added symas' repository and install from yum.
Is possible I have done something wrong in convert process?
-- Igor Sousa
Em qui, 11 de jul de 2019 às 22:56, Howard Chu hyc@symas.com escreveu:
Quanah Gibson-Mount wrote:
--On Thursday, July 11, 2019 5:29 PM -0300 Igor Sousa <
igorvolt@gmail.com> wrote:
I've tested your suggestion and delete operation has worked fine, but I've still had the same problem described previously when I've tried
add
new olcTLSCertificateFile or new olcTLSCertificateKeyFile or new olcTLSCACertificateFile. I don't understand the reason for that.
You're likely hitting ITS#8286 with the replace operations. Another
idea may be to change replace to a delete+add in the same operation
sequence.
https://www.openldap.org/its/index.cgi/?findid=8286
The details in the ITS aren't as flushed out as they probably should
be, but if a configuration element is missing an EQUALITY matching rule, then you generally
cannot use a replace OP on them.
That's not correct. A replace op always works. It is only [Delete/Add] value that requires an equality rule.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Igor Sousa wrote:
*Step 7:* I've tried replace *olcTLSCACertificateFile*, *olcTLSCertificateFile *and *olcTLSCertificateKeyFile *with following ldif <tls.ldif>: dn: cn=config changetype: modify replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.local.key - replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/openldap/certs/ldap.local.crt - add: olcTLSCACertificateFile
^^ shouldn't this also be replace: ?
olcTLSCACertificateFile: /etc/openldap/certs/ca.cert.pemIt hasn't mattered what I've done, when I've ran ldapmodify command, it has returned me the same error.
Hi Howard,
Howard Chu wrote:
^^ shouldn't this also be replace: ?
By default, the Openldap-Servers-Symas (or openldap-servers from default repository) doesn't have olcTLSCACertificateFile entry. Due to this, I've used add operation instead of replace.
I've tried to set this entries in the cn=config following the commands below:
systemctl stop slapd slapcat -n 0 >> config.ldif rm -rf /etc/openldap/slapd.d/* cat config.ldif | slapadd -v -F /etc/openldap/slapd.d -n 0 chown ldap:ldap -R /etc/openldap/slapd.d
I've got to set this entries, but slapd hasn't started and when I've checked systemctl status slapd, I've seen as the slapd hasn't got to read key file. I've checked again and ldap user has had privilegies to read all entires has set in *olcTLSCACertificateFile*, *olcTLSCertificateFile *and *olcTLSCertificateKeyFile.*
[root@localhost ~]# systemctl status slapd ● slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Thu 2019-07-18 11:55:29 -03; 2h 5min ago Docs: man:slapd man:slapd-config man:slapd-hdb man:slapd-mdb file:///usr/share/doc/openldap-servers/guide.html Process: 2133 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=1/FAILURE) Process: 2120 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS) Main PID: 1928 (code=exited, status=0/SUCCESS)
Jul 18 11:55:29 localhost.localdomain runuser[2123]: pam_unix(runuser:session): session opened for user ldap by (uid=0) Jul 18 11:55:29 localhost.localdomain slapd[2133]: @(#) $OpenLDAP: slapd 2.4.47 (Mar 11 2019 17:22:04) $ build@c7rpm :/home/build/git/rheldap/RHEL7_x86_64/BUILD...lapd Jul 18 11:55:29 localhost.localdomain slapd[2133]: main: TLS init def ctx failed: -1 Jul 18 11:55:29 localhost.localdomain slapd[2133]: Enter PEM pass phrase: Jul 18 11:55:29 localhost.localdomain slapd[2133]: slapd stopped. Jul 18 11:55:29 localhost.localdomain slapd[2133]: connections_destroy: nothing to destroy. Jul 18 11:55:29 localhost.localdomain systemd[1]: slapd.service: control process exited, code=exited status=1 Jul 18 11:55:29 localhost.localdomain systemd[1]: Failed to start OpenLDAP Server Daemon. Jul 18 11:55:29 localhost.localdomain systemd[1]: Unit slapd.service entered failed state. Jul 18 11:55:29 localhost.localdomain systemd[1]: slapd.service failed.
-----
[root@localhost ~]# ls /etc/openldap/certs -l total 100 -rw-r--r--. 1 root ldap 2078 Jul 18 10:47 ca.cert.pem -rw-r--r--. 1 root root 65536 Jul 15 15:16 cert8.db -rw-r--r--. 1 root root 16384 Jul 15 15:16 key3.db -rw-r--r--. 1 root ldap 3326 Jul 18 10:47 ldap.key.pem -rw-r--r--. 1 root ldap 1732 Jul 18 10:47 ldap.local.csr -rw-r--r--. 1 root ldap 2102 Jul 18 11:55 ldap.local.pem -r--r-----. 1 root ldap 45 Jun 21 16:09 password -rw-r--r--. 1 root root 16384 Jun 21 16:09 secmod.db
OBS: I've changed *olcTLSCACertificateFile*, *olcTLSCertificateFile *and *olcTLSCertificateKeyFile *files to ca.cert.pem, ldap.local.pem and ldap.key.pem respectively.
I've started thinking to test it on a Debian system aiming it works better. I don't have any idea about it.
-- Igor Sousa
--On Thursday, July 18, 2019 3:16 PM -0300 Igor Sousa igorvolt@gmail.com wrote:
Hi Howard,
Howard Chu wrote:
^^ shouldn't this also be replace: ?
By default, the Openldap-Servers-Symas (or openldap-servers from default repository) doesn't have olcTLSCACertificateFile entry. Due to this, I've used add operation instead of replace.
Immaterial. Use replace.
build@c7rpm:/home/build/git/rheldap/RHEL7_x86_64/BUILD...lapd Jul 18 11:55:29 localhost.localdomain slapd[2133]: main: TLS init def ctx failed: -1 Jul 18 11:55:29 localhost.localdomain slapd[2133]: Enter PEM pass phrase:
This clearly indicates your key file is password protected, which is not supported.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Thursday, July 18, 2019 1:08 PM -0700 Quanah Gibson-Mount quanah@symas.com wrote:
build@c7rpm:/home/build/git/rheldap/RHEL7_x86_64/BUILD...lapd Jul 18 11:55:29 localhost.localdomain slapd[2133]: main: TLS init def ctx failed: -1 Jul 18 11:55:29 localhost.localdomain slapd[2133]: Enter PEM pass phrase:
This clearly indicates your key file is password protected, which is not supported.
To be clear, it's not supported to use a password protected key file and then try and start slapd via an automated init system such as systemd. To use a password protected key file requires that you start slapd manually so you can provide the password as part of the startup process so slapd can access it.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Igor Sousa igorvolt@gmail.com schrieb am 18.07.2019 um 19:16 in
Nachricht CAAg2ztWMayH_6_x1DEti_B9TLcm9CXG+5gwWjFZwuR9-DC4E4w@mail.gmail.com:
Hi Howard,
Howard Chu wrote:
^^ shouldn't this also be replace: ?
By default, the Openldap-Servers-Symas (or openldap-servers from default repository) doesn't have olcTLSCACertificateFile entry. Due to this, I've used add operation instead of replace.
I've tried to set this entries in the cn=config following the commands below:
systemctl stop slapd slapcat -n 0 >> config.ldif rm -rf /etc/openldap/slapd.d/* cat config.ldif | slapadd -v -F /etc/openldap/slapd.d -n 0 chown ldap:ldap -R /etc/openldap/slapd.d
I've got to set this entries, but slapd hasn't started and when I've checked systemctl status slapd, I've seen as the slapd hasn't got to read key file. I've checked again and ldap user has had privilegies to read all entires has set in *olcTLSCACertificateFile*, *olcTLSCertificateFile *and *olcTLSCertificateKeyFile.*
Random thought: Could it be "selinux" policy that prtevents reading the file? And does your certificate really have "localhost.localdomain" as subject?
[root@localhost ~]# systemctl status slapd ● slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Thu 2019-07-18 11:55:29 -03; 2h 5min ago Docs: man:slapd man:slapd-config man:slapd-hdb man:slapd-mdb file:///usr/share/doc/openldap-servers/guide.html Process: 2133 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=1/FAILURE) Process: 2120 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS) Main PID: 1928 (code=exited, status=0/SUCCESS)
Jul 18 11:55:29 localhost.localdomain runuser[2123]: pam_unix(runuser:session): session opened for user ldap by (uid=0) Jul 18 11:55:29 localhost.localdomain slapd[2133]: @(#) $OpenLDAP: slapd 2.4.47 (Mar 11 2019 17:22:04) $ build@c7rpm :/home/build/git/rheldap/RHEL7_x86_64/BUILD...lapd Jul 18 11:55:29 localhost.localdomain slapd[2133]: main: TLS init def ctx failed: -1 Jul 18 11:55:29 localhost.localdomain slapd[2133]: Enter PEM pass phrase: Jul 18 11:55:29 localhost.localdomain slapd[2133]: slapd stopped. Jul 18 11:55:29 localhost.localdomain slapd[2133]: connections_destroy: nothing to destroy. Jul 18 11:55:29 localhost.localdomain systemd[1]: slapd.service: control process exited, code=exited status=1 Jul 18 11:55:29 localhost.localdomain systemd[1]: Failed to start OpenLDAP Server Daemon. Jul 18 11:55:29 localhost.localdomain systemd[1]: Unit slapd.service entered failed state. Jul 18 11:55:29 localhost.localdomain systemd[1]: slapd.service failed.
[root@localhost ~]# ls /etc/openldap/certs -l total 100 -rw-r--r--. 1 root ldap 2078 Jul 18 10:47 ca.cert.pem -rw-r--r--. 1 root root 65536 Jul 15 15:16 cert8.db -rw-r--r--. 1 root root 16384 Jul 15 15:16 key3.db -rw-r--r--. 1 root ldap 3326 Jul 18 10:47 ldap.key.pem -rw-r--r--. 1 root ldap 1732 Jul 18 10:47 ldap.local.csr -rw-r--r--. 1 root ldap 2102 Jul 18 11:55 ldap.local.pem -r--r-----. 1 root ldap 45 Jun 21 16:09 password -rw-r--r--. 1 root root 16384 Jun 21 16:09 secmod.db
OBS: I've changed *olcTLSCACertificateFile*, *olcTLSCertificateFile *and *olcTLSCertificateKeyFile *files to ca.cert.pem, ldap.local.pem and ldap.key.pem respectively.
I've started thinking to test it on a Debian system aiming it works better. I don't have any idea about it.
-- Igor Sousa
Quanah Gibson-Mount quanah@symas.com schrieb am 18.07.2019 um 22:35 in
Nachricht <0DBBAC4F8151F9DFD2CCA8D6@[192.168.1.39]>:
--On Thursday, July 18, 2019 1:08 PM -0700 Quanah Gibson-Mount quanah@symas.com wrote:
build@c7rpm:/home/build/git/rheldap/RHEL7_x86_64/BUILD...lapd Jul 18 11:55:29 localhost.localdomain slapd[2133]: main: TLS init def ctx failed: -1 Jul 18 11:55:29 localhost.localdomain slapd[2133]: Enter PEM pass phrase:
This clearly indicates your key file is password protected, which is not supported.
To be clear, it's not supported to use a password protected key file and then try and start slapd via an automated init system such as systemd. To use a password protected key file requires that you start slapd manually so you can provide the password as part of the startup process so slapd can access it.
Well, it wopuldn't really add security, but maybe slapd should have a mechanism to read the private key's password from some file or pipe in the future.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Howard Chu -
Igor Sousa -
Quanah Gibson-Mount -
Ulrich Windl