openldap-technical

openldap-technical@openldap.org

7 participants
9901 discussions

Modification of objectClass failing: how can I get details?
by Côme Chilliet 16 Aug '16

16 Aug '16

Hello, I’m trying to modify an LDAP node to change its objectClasses: dn: cn=canon-c5250,ou=printers,ou=systems,dc=xxx,dc=xxx cn: canon-c5250 description:: Q2Fub24gSVIgQURWIEM1MjUwIA== labeledURI: ipp://127.0.0.1 ipHostnumber: 127.0.0.1 macAddress: 12:12:12:12:12:12 objectClass: top objectClass: gotoPrinter I want to remove gotoPrinter objectClass which is flagged as OBSOLETE and instead use fdPrinter, ipHost and ieee802Device. I try with an ldif with the following content: dn: cn=canon-c5250,ou=printers,ou=systems,dc=xxx,dc=xxx changetype: modify replace: objectClass objectClass: fdPrinter objectClass: ieee802Device objectClass: ipHost objectClass: top I get: ldapadd -D cn=admin,dc=xxx,dc=xxx -f modify.ldif -W ldap_modify: Object class violation (65) How can I get more information? I don’t know which violation that could be, as I am able to insert a second object with no problem which looks like what I want: dn: cn=test-print,ou=printers,ou=systems,dc=xxx,dc=xxx changetype: add cn: test-print description: test labeledURI: ipp://127.0.0.1 ipHostnumber: 127.0.0.1 macAddress: 12:22:12:12:22:22 objectClass: fdPrinter objectClass: ieee802Device objectClass: ipHost objectClass: top Here are the classes definitions: objectclass (1.3.6.1.4.1.10098.1.2.1.31 NAME 'gotoPrinter' DESC 'GOto - Gonicus Terminal Concept, objectclass' SUP top STRUCTURAL OBSOLETE MUST ( cn ) MAY ( labeledURI $ description $ l $ gotoPrinterPPD $ macAddress $ ipHostNumber $ gotoUserPrinter $ gotoUserAdminPrinter $ gotoGroupPrinter $ gotoGroupAdminPrinter $ printerWindowsInfFile $ printerWindowsDriverDir $ printerWindowsDriverName) ) objectclass ( 1.3.6.1.4.1.38414.16.2.5 NAME 'fdPrinter' DESC 'FusionDirectory printer class' MUST ( cn ) MAY ( labeledURI $ fdPrinterWindowsInfFile $ fdPrinterWindowsDriverDir $ fdPrinterWindowsDriverName $ fdPrinterUsers $ fdPrinterAdminUsers)) Côme

2 1

RE: OpenLDAP Upgrade from OpenLDAP 2.1 to 2.4 - ACL Issues
by Madden, Joe 10 Aug '16

10 Aug '16

Hi List, I've managed to answer my own question by reading the change log between the versions - Who would have figured the answer would have been there! OpenLDAP 2.4 Introduced the requirement to have search permission on the parent DN when search a subtree. Therefore I had to update my ACL's to this: # Allow a user to update their password access to attrs=userPassword by dn="uid=support,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=backup,ou=users,dc=oursystem,dc=co,dc=uk" write by self write by * auth #As of OpenLDAP 2.4.X you are required to provide search to the DN which you search though to find a attribute. #We have therefore permitted search though the system for any authenticated user. The ACL's below line by dnattr=uniqueMember #Controls what the user can actually read. access to dn="ou=applications, dc=oursystem,dc=co,dc=uk" by users search # Allow write and read access to the applications tree for specific users # Normal users will only be able to see what they are a member of access to dn.subtree="ou=applications,dc=oursystem,dc=co,dc=uk" by dn="uid=support,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=backup,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=tomcat, ou=users,dc=oursystem,dc=co,dc=uk" read by dn="uid=apache, ou=users,dc=oursystem,dc=co,dc=uk" read by dnattr=uniqueMember read # Allow write and read access to the users tree for specific users # Normal users will only be able to their own node access to dn.subtree="ou=users,dc=oursystem,dc=co,dc=uk" by dn="uid=support,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=backup,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=apache,ou=users,dc=oursystem,dc=co,dc=uk" read by self write # Allow write and read access for specific users # Normal users will only be able to their own node access to dn.subtree="dc=oursystem,dc=co,dc=uk" by dn="uid=support,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=backup,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=apache, ou=users,dc=oursystem,dc=co,dc=uk" read by self read The new section added is : #As of OpenLDAP 2.4.X you are required to provide search to the DN which you search though to find a attribute. #We have therefore permitted search though the system for any authenticated user. The ACL's below line by dnattr=uniqueMember #Controls what the user can actually read. access to dn="ou=applications, dc=oursystem,dc=co,dc=uk" by users search Thanks Joe. -----Original Message----- From: Madden, Joe Sent: 09 August 2016 14:55 To: openldap-technical(a)openldap.org Subject: OpenLDAP Upgrade from OpenLDAP 2.1 to 2.4 - ACL Issues Hi List, Hoping someone can help us out with our ACL problems post upgrading on our test system. We've upgraded from OpenLDAP 2.1 to 2.4 with success. The directory is fine and the ACLS below work as expected minus the line [by dnattr=uniqueMember read] Please see our ACL's below: # Allow a user to update their password access to attrs=userPassword by dn="uid=support,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=backup,ou=users,dc=oursystem,dc=co,dc=uk" write by self write by * auth # Allow write and read access to the applications tree for specific users # Normal users will only be able to see what they are a member of access to dn.subtree="ou=applications,dc=oursystem,dc=co,dc=uk" by dn="uid=root,dc=oursystem,dc=co,dc=uk" write by dn="uid=support,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=backup,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=tomcat, ou=users,dc=oursystem,dc=co,dc=uk" read by dn="uid=apache, ou=users,dc=oursystem,dc=co,dc=uk" read by dnattr=uniqueMember read # Allow write and read access to the users tree for specific users # Normal users will only be able to their own node access to dn.subtree="ou=users,dc=oursystem,dc=co,dc=uk" by dn="uid=root,dc=oursystem,dc=co,dc=uk" write by dn="uid=support,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=backup,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=apache,ou=users,dc=oursystem,dc=co,dc=uk" read by self write # Allow write and read access for specific users # Normal users will only be able to their own node access to dn.subtree="dc=oursystem,dc=co,dc=uk" by dn="uid=root,dc=oursystem,dc=co,dc=uk" write by dn="uid=support,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=backup,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=apache, ou=users,dc=oursystem,dc=co,dc=uk" read by self read The apache, tomcat, root, support users work as expected and can access their respective accounts. We have a number of Unique Members who are members of DN's under dc=oursystem,dc=co,dc=uk. For Example: DN: cn=online_application_1,ou=our_online_application_1,ou=applications,dc=oursystem,dc=co,dc=uk We have uniqueMember attribute which contains the dn for users For Example: uid=user1,ou=users,dc=oursystem,dc=co,dc=uk As I understand it by dnattr=uniqueMember read on openldap 2.1 allowed the user to login to the ldap server, search the DN's under the ou=applications,dc=oursystem,dc=co,dc=uk for uniqueMember which contained there own DN. This worked and our applications authenticated on OpenLDAP 2.1. Since upgrading to 2.4 this ACL does not work in this way and I suspect it's by dnattr=uniqueMember read which is the problem. Does anyone have any help to offer on how to proceed? Is there a better way to do the ACL in question? Thanks Joe

1 0

OpenLDAP Upgrade from OpenLDAP 2.1 to 2.4 - ACL Issues
by Madden, Joe 09 Aug '16

09 Aug '16

Hi List, Hoping someone can help us out with our ACL problems post upgrading on our test system. We've upgraded from OpenLDAP 2.1 to 2.4 with success. The directory is fine and the ACLS below work as expected minus the line [by dnattr=uniqueMember read] Please see our ACL's below: # Allow a user to update their password access to attrs=userPassword by dn="uid=support,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=backup,ou=users,dc=oursystem,dc=co,dc=uk" write by self write by * auth # Allow write and read access to the applications tree for specific users # Normal users will only be able to see what they are a member of access to dn.subtree="ou=applications,dc=oursystem,dc=co,dc=uk" by dn="uid=root,dc=oursystem,dc=co,dc=uk" write by dn="uid=support,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=backup,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=tomcat, ou=users,dc=oursystem,dc=co,dc=uk" read by dn="uid=apache, ou=users,dc=oursystem,dc=co,dc=uk" read by dnattr=uniqueMember read # Allow write and read access to the users tree for specific users # Normal users will only be able to their own node access to dn.subtree="ou=users,dc=oursystem,dc=co,dc=uk" by dn="uid=root,dc=oursystem,dc=co,dc=uk" write by dn="uid=support,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=backup,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=apache,ou=users,dc=oursystem,dc=co,dc=uk" read by self write # Allow write and read access for specific users # Normal users will only be able to their own node access to dn.subtree="dc=oursystem,dc=co,dc=uk" by dn="uid=root,dc=oursystem,dc=co,dc=uk" write by dn="uid=support,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=backup,ou=users,dc=oursystem,dc=co,dc=uk" write by dn="uid=apache, ou=users,dc=oursystem,dc=co,dc=uk" read by self read The apache, tomcat, root, support users work as expected and can access their respective accounts. We have a number of Unique Members who are members of DN's under dc=oursystem,dc=co,dc=uk. For Example: DN: cn=online_application_1,ou=our_online_application_1,ou=applications,dc=oursystem,dc=co,dc=uk We have uniqueMember attribute which contains the dn for users For Example: uid=user1,ou=users,dc=oursystem,dc=co,dc=uk As I understand it by dnattr=uniqueMember read on openldap 2.1 allowed the user to login to the ldap server, search the DN's under the ou=applications,dc=oursystem,dc=co,dc=uk for uniqueMember which contained there own DN. This worked and our applications authenticated on OpenLDAP 2.1. Since upgrading to 2.4 this ACL does not work in this way and I suspect it's by dnattr=uniqueMember read which is the problem. Does anyone have any help to offer on how to proceed? Is there a better way to do the ACL in question? Thanks Joe

1 0

openldap client cert validation
by Matwey V. Kornilov 06 Aug '16

06 Aug '16

Hello, I am running openldap 2.4.41 and I've failed to setup client certificate validation. TLS works well until olcTLSVerifyClient is set to demand. Then I see ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) at client side. And connection_read(11): TLS accept failure error=-1 id=1021, closing at the serveri side. So, I've configured /etc/openldap/ldap.conf as the following to provide client TLS certificate paths: TLS_CACERT /path/to/myroot.pem TLS_CACERTDIR /var/lib/ca-certificates/pem/ TLS_CERT /path/to/my.crt TLS_KEY /path/to/my.key However, when I run openssl s_server -Verify 0 -accept 636 ... I see the following: ERROR 140680155473552:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate:s3_srvr.c:3309: shutting down SSL CONNECTION CLOSED ACCEPT So, this means that ldapsearch doesn't sent out its client certificate. I've also checked with strace tool that it even doesn't access certificate file. So, I am little stuck here. I understand that I am doing something wrong, but I cannot figure out what.

3 4

Re: openldap client cert validation
by Howard Chu 06 Aug '16

06 Aug '16

Matwey V. Kornilov wrote: > After inspecting source code I've just found that TLS_KEY and TLS_CERT > are ignored if located in /etc/openldap/ldap.conf. > Why does it not written in man ldap.conf(5) explicitly? The ldap.conf(5) manpage says clearly "This is a user-only option." > I've spent two days of my precious life to dig it out. Yes, not reading carefully is a sure way to waste time. > Now it works. > > 2016-08-06 16:07 GMT+03:00 Matwey V. Kornilov <matwey.kornilov(a)gmail.com>: >> Hello, >> >> I am running openldap 2.4.41 and I've failed to setup client certificate >> validation. TLS works well until olcTLSVerifyClient is set to demand. >> Then I see >> >> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >> >> at client side. >> And >> >> connection_read(11): TLS accept failure error=-1 id=1021, closing >> >> at the serveri side. >> So, I've configured /etc/openldap/ldap.conf as the following to provide >> client TLS certificate paths: >> >> TLS_CACERT /path/to/myroot.pem >> TLS_CACERTDIR /var/lib/ca-certificates/pem/ >> TLS_CERT /path/to/my.crt >> TLS_KEY /path/to/my.key >> >> However, when I run openssl s_server -Verify 0 -accept 636 ... >> I see the following: >> >> ERROR >> 140680155473552:error:140890C7:SSL >> routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a >> certificate:s3_srvr.c:3309: >> shutting down SSL >> CONNECTION CLOSED >> ACCEPT >> >> So, this means that ldapsearch doesn't sent out its client certificate. >> I've also checked with strace tool that it even doesn't access >> certificate file. >> >> So, I am little stuck here. I understand that I am doing something >> wrong, but I cannot figure out what. > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

How do I allow root to edit mdb database?
by John Lewis 06 Aug '16

06 Aug '16

How do I allow root aka dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external to edit olcDatabase={1}mdb,cn=config. I am trying to configure ldapscripts <https://packages.debian.org/jessie/ldapscripts>, but the idea of having a password in the clear is just disturbing. Ldapscripts is in sbin and needs to be ran by someone with root privileges anyways. The easiest way of getting around having a password in the clear would be SASL binding root and mapping it to olcRootDN: when it binds so root can modify the directory tree when it executes ldapscripts.

6 12

RE: openldap-technical Digest, Vol 105, Issue 2
by Kruger, P (Justid) 03 Aug '16

03 Aug '16

You could check fort he logfiles. But to get logging detailed, you need to set the loglevel. You can save ldap logging to a separate logfile and added logging level. Below is what I've done under Linux to achieve this (nano is the editor, which could also be vi). mkdir /var/log/ldap/ touch /var/log/ldap/ldap.log chown ldap.ldap /var/log/ldap -R nano /etc/rsyslog.conf Add the following rule tot his file # Save LDAP messages to /var/log/ldap/ldap.log local4.* /var/log/ldap/ldap.log Add log rotation to prevent an ever growing log file. nano /etc/logrotate.d/ldap.log /var/log/ldap/ldap.log { missingok } service rsyslog restart Met vriendelijke groet, Peter Kruger Adviseur IT-beheer .................................................................................. Ministerie van Justitie Justitiële Informatiedienst Technologie/IT-beheer Egbert Gorterstraat 6 | 7607 GB | Almelo | 2.15 Postbus 337 | 7600 AH | Almelo .................................................................................. T 088 99 89060 M 06 511 016 92 p.kruger(a)justid.nl www.justid.nl .................................................................................. werkt op: ma, di, wo, do .................................................................................. Van: Côme Chilliet [mailto:come@opensides.be] Verzonden: dinsdag 2 augustus 2016 15:32 Aan: openldap-technical(a)openldap.org Onderwerp: Modification of objectClass failing: how can I get details? Hello, I'm trying to modify an LDAP node to change its objectClasses: dn: cn=canon-c5250,ou=printers,ou=systems,dc=xxx,dc=xxx cn: canon-c5250 description:: Q2Fub24gSVIgQURWIEM1MjUwIA== labeledURI: ipp://127.0.0.1 ipHostnumber: 127.0.0.1 macAddress: 12:12:12:12:12:12 objectClass: top objectClass: gotoPrinter I want to remove gotoPrinter objectClass which is flagged as OBSOLETE and instead use fdPrinter, ipHost and ieee802Device. I try with an ldif with the following content: dn: cn=canon-c5250,ou=printers,ou=systems,dc=xxx,dc=xxx changetype: modify replace: objectClass objectClass: fdPrinter objectClass: ieee802Device objectClass: ipHost objectClass: top I get: ldapadd -D cn=admin,dc=xxx,dc=xxx -f modify.ldif -W ldap_modify: Object class violation (65) How can I get more information? I don't know which violation that could be, as I am able to insert a second object with no problem which looks like what I want: dn: cn=test-print,ou=printers,ou=systems,dc=xxx,dc=xxx changetype: add cn: test-print description: test labeledURI: ipp://127.0.0.1 ipHostnumber: 127.0.0.1 macAddress: 12:22:12:12:22:22 objectClass: fdPrinter objectClass: ieee802Device objectClass: ipHost objectClass: top Here are the classes definitions: objectclass (1.3.6.1.4.1.10098.1.2.1.31 NAME 'gotoPrinter' DESC 'GOto - Gonicus Terminal Concept, objectclass' SUP top STRUCTURAL OBSOLETE MUST ( cn ) MAY ( labeledURI $ description $ l $ gotoPrinterPPD $ macAddress $ ipHostNumber $ gotoUserPrinter $ gotoUserAdminPrinter $ gotoGroupPrinter $ gotoGroupAdminPrinter $ printerWindowsInfFile $ printerWindowsDriverDir $ printerWindowsDriverName) ) objectclass ( 1.3.6.1.4.1.38414.16.2.5 NAME 'fdPrinter' DESC 'FusionDirectory printer class' MUST ( cn ) MAY ( labeledURI $ fdPrinterWindowsInfFile $ fdPrinterWindowsDriverDir $ fdPrinterWindowsDriverName $ fdPrinterUsers $ fdPrinterAdminUsers)) Côme

1 0

Re: password policies not functioning properly
by Kruger, P (Justid) 02 Aug '16

02 Aug '16

Just found the problem and the solution to the problem that policies were not working. It occurred that there was also a (probably mistakenly) second config module activated. The module I had configured with ppolicy, was not used. The extra module that was active, did not have the ppolicy overlay loaded. After correcting this, all seems to work as expected.

1 0

password policies not functioning as expected
by Kruger, P (Justid) 02 Aug '16

02 Aug '16

Just found the problem and the solution. It occurred that there was also a (probably mistakenly) second config module activated. The module I had configured with ppolicy, was not used. The extra module that was active, did not have the ppolicy overlay loaded. After correcting this, all seems to work as expected. -----Oorspronkelijk bericht----- Van: openldap-technical [mailto:openldap-technical-bounces@openldap.org] Namens openldap-technical-request(a)openldap.org Verzonden: donderdag 28 juli 2016 14:00 Aan: openldap-technical(a)openldap.org Onderwerp: openldap-technical Digest, Vol 104, Issue 21 Send openldap-technical mailing list submissions to openldap-technical(a)openldap.org To subscribe or unsubscribe via the World Wide Web, visit http://www.openldap.org/lists/mm/listinfo/openldap-technical or, via email, send a message with subject or body 'help' to openldap-technical-request(a)openldap.org You can reach the person managing the list at openldap-technical-owner(a)openldap.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openldap-technical digest..." Send openldap-technical mailing list submissions to openldap-technical(a)openldap.org When replying, please edit your Subject: header so it is more specific than "Re: openldap-technical digest..." Today's Topics: 1. Re: need to recover slapd password and upgrade openldap (Dan Hyatt) 2. Re: Antw: Intermediate certificates not being sent (Nat Sincheler) 3. Re: sizelimit (Maily Peng) 4. Missing user entries after restoring a backup ldif (Matt Spaulding) 5. password policies not functioning properly (Kruger, P (Justid)) 6. Re: sizelimit (Dieter Kl?nter) 7. Re: Antw: Intermediate certificates not being sent (Ulrich Windl) ---------------------------------------------------------------------- Message: 1 Date: Tue, 26 Jul 2016 12:15:00 -0500 From: Dan Hyatt <dhyatt(a)dsgmail.wustl.edu> To: Aaron Richton <richton(a)nbcs.rutgers.edu>, dhyatt(a)wustl.edu Cc: openldap-technical(a)openldap.org Subject: Re: need to recover slapd password and upgrade openldap Message-ID: <b5a9dc49-8420-ef20-0779-d65ddfcdcad7(a)dsgmail.wustl.edu> Content-Type: text/plain; charset=windows-1252; format=flowed So, a more simple question... Can I install a current version of OpenLDAP on a current RedHat/Centos server (specially built for this purpose. Then use slapcat to export the information from the old server, import it to the new server, where the admin password is not corrupt. Can I import the schemas or are there likely substantial changes to the schemas across versions? My goals are to create a new LDAP server running Centos/Redhat, transfer 20 users and allow them to keep their existing passwords, allow them to access my servers, and allow them authentication to samba. and create an LDAP slave (or cluster) not sure if syncrepl is the current way to go. I have root to the server, but I do not have the admin password to the Openldap 2.2 as it became corrupted somehow. On 07/24/2016 09:15 PM, Aaron Richton wrote: > On Fri, 22 Jul 2016, Dan Hyatt wrote: > >> My admin openLDAP 2.2 password became corrupt in the last week and I >> cannot > [...] >> I found some instructions which seem simple risky and no backout >> strategy. Simply running >> http://techiezone.rottigni.net/2011/12/change-root-dn-password-on-openldap/ >> > > That link (apparently from 2011) doesn't apply to your software from > 2003. There's no back-config in OpenLDAP 2.2. So don't try that... @(#) $OpenLDAP: slapd 2.2.13 (Nov 26 2010 07:45:22) $ mockbuild@x86-003.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.2.13/openldap-2.2.13/build-servers/servers/slapd > > [...] >> Having the LDAP on two separate hyper visors (with local disks) to >> avoid the storage/authentication chicken/egg >> Is there a better upgrade plan > > Are you saying that your one and only LDAP server uses itself for its > own A&A? Authentication and Authorization? The server provides authentication and authorization for my group. The server only does LDAP and home dirs. I want to upgrade it to Centos 6.8 or Centos 7 (that is equal to redhat 6.8 or redhat 7) on a hypervisor with a slave running the current favored release. > > [...] >> I have the log files, is there a way to backout to last week without >> the admin password (which became corrupt last week). > > I'm not sure what you're referring to by "log files." The general-case > OpenLDAP backup tool is slapcat(8). Hopefully you have been running it > routinely. The resulting LDIF can be easily inspected; if you have > enough backups, you might even be able to find one without corruption. We took over responsibility the LDAP in December, there was not a happy handoff... no documenation..just the password and had to move it to the new VLAN. ------------------------------ Message: 2 Date: Tue, 26 Jul 2016 08:20:14 -0700 From: Nat Sincheler <fai1107(a)macrotex.net> To: Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de>, openldap-technical(a)openldap.org Subject: Re: Antw: Intermediate certificates not being sent Message-ID: <991f77f9-fd05-eb9b-7f07-f350c4a7bc68(a)macrotex.net> Content-Type: text/plain; charset=windows-1252; format=flowed On 7/25/2016 11:24 PM, Ulrich Windl wrote: >>>> Nat Sincheler <fai1107(a)macrotex.net> schrieb am 25.07.2016 um 19:06 in > Nachricht <c19c2a3a-3c90-5baa-43c7-800b050ea5b7(a)macrotex.net>: >> We have an OpenLDAP server that is listening on port 636 over ldaps. >> When I run >> >> openssl s_client -showcerts -connect ldap-server:636 >> >> I only see the host certificate. The intermediate and root certificates >> do *not* come through. > > If I di that on one of outr servers, I get: > Root CA > Intermediate CA > Server Certificate > > ... > New, TLSv1/SSLv3, Cipher is AES256-SHA > Server public key is 2048 bit > >> >> For this server I have in the file slapd.d/cn=config.ldif the setting >> >> olcTLSCACertificatePath: /etc/ssl/certs > > Hi! > > Here it works with these settings: > olcTLSCACertificatePath: /etc/ssl/certs > olcTLSCertificateFile: /etc/ssl/servercerts/slapd.pem > olcTLSCertificateKeyFile: /etc/ssl/private/slapd.key > > Could it be a permissions problem? Did you try to check the certificate chain with openssl (preferrable as LDAP user)? When I run the openssl s_client command I get no errors, but I also get no intermediate or root certificates sent. I see this in the output: "No client certificate CA names sent". It appears that OpenLDAP is not sending the intermediate or root certificates. However, if I put all the intermediate and root certificates into a single file and point olcTLSCACertificateFile at this file, those intermediate certificates _are_ sent. So, it appears that olcTLSCACertificateFile sends the certificates but but olcTLSCACertificatePath does not. Am I misunderstanding the purpose olcTLSCACertificatePath? Thanks. > > Regards, > Ulrich > >> >> I checked and all the intermediate and root certificates are in >> /etc/ssl/certs soft-linked via the usual OpenSSL rehash hash, e.g., >> >> lrwxrwxrwx 1 root root 42 Jul 14 19:03 b4261fc2.0 -> >> /etc/ssl/certs/incommon-usertrust-2024.pem >> >> Any idea why the intermediate and root certificates do not get sent to >> the LDAPS client? Is there something in the LDAP log that might give me >> a clue as to what is going on? > > > > ------------------------------ Message: 3 Date: Tue, 26 Jul 2016 19:47:27 +0200 From: Maily Peng <mpeng(a)keyyo.com> To: Frank Swasey <Frank.Swasey(a)uvm.edu> Cc: openldap-technical(a)openldap.org Subject: Re: sizelimit Message-ID: <6fedd3fe-f1c4-9897-0eae-3c77159add6d(a)keyyo.com> Content-Type: text/plain; charset="windows-1252"; Format="flowed" Hello Frank, Nope, the limits directive are unlimited on the provider. First of all, I need to have access to all of the entries on the consumers , in order to check EntryCSN between provider and consumers. I use the python script : check_syncrepl_extended that needs to bind provider and consumer via the same dn. That's why I could not use rootdn . ( not the same between slapd servers) . thank you Le 26/07/2016 ? 19:09, Frank Swasey a ?crit : > You have shown us what the syncrepl, sizelimit and limits look like on > your consumer. Have you got that limits directive also set up on your > provider? It is the provider that needs to allow your replication DN > to obtain unlimited entries. > >

1 0

In-Reply-To: AdHrvUgXFwns0ylwRzawJ6D0CewYvg==
by Kruger, P (Justid) 02 Aug '16

02 Aug '16

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical