openldap-technical August 2016

openldap-technical@openldap.org

27 participants
36 discussions

Missing user entries after restoring a backup ldif
by Matt Spaulding 19 Aug '16

19 Aug '16

Hello, I restored an ldap database using the command: slapadd -l /my/file.ldif The restore went completely without error. But when I go to do an ldapsearch I find that some of the users that should be in the database are not there. I go back and edit my ldif backup file and search for the uids of the users and confirm that they are in fact in the ldif file. Why would something like this happen? Best Regards, Matt

2 1

Re: Can't modify pwdChangedTime as "admin"
by PenguinWhispererThe . 19 Aug '16

19 Aug '16

Thanks for that good pointer Dieter. Although it will force the user to change his password I'm not sure this will do the trick in our case. We have a custom passwd script that keeps both ldap and nis in sync. With the above I believe the Nis password won't be updated. So is there a way to actually update the pwdChangedTime? (Even out of pure curiosity) Thanks On Aug 17, 2016 11:38, "Dieter Klünter" <dieter(a)dkluenter.de> wrote: Am Wed, 17 Aug 2016 10:46:58 +0200 schrieb "PenguinWhispererThe ." <th3penguinwhisperer(a)gmail.com>: > Hi all, > > I've noticed that after a password reset pwdChangedTime gets updated. > > This is fine. We do have a policy in place that doesn't let you > modify your password again within a few days. > > I'd like to reset/change this pwdChangedTime so the user can reset his > password himself after logging in with the supplied password. However > deleting/modifying pwdChangedTime doesn't work. > > How should I resolve this? > I'm pretty sure this is not an ACL issue as my user matches the first > entry and is allowed to write all. > > I've seen some docs from IBM about removing pwdChangedTime being > possible but that might not apply to openldap. > man slapo-ppolicy(5), read carefully the comments on pwdReset. -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

3 3

replicator account password encrypted and entries are hidden in ldap viewer
by Kruger, P (Justid) 18 Aug '16

18 Aug '16

We succesfully installed openldap with: - Replication - Password policy After applying config policy with olcPPolicyHashCleartext: TRUE the password the replicator user password gets encrypted with ssha. Although, according to what I've read, the password with simple bind should not be encrypted, it seems that replication still is functioning. Questions: Can anybody tell me if should be expected to cause a problem? How do you handle the replication user and password in regards to encrypted passwords? Second problem we are facing is that the replication OU and underlaying account are not visible anymore. With slapcat the OU is still visible in the LDIF file, but not in the LDAP viewer. If I'm not mistaken, the record is of the type GLUE, which might indicate that it is not properly replicated and therefore not visible? Question: Does anybody know what can be the problem here? Or how to solve this without reinstalling OpenLDAP with a clean database? Thanks in advance, Peter Kruger

2 1

Can't modify pwdChangedTime as "admin"
by PenguinWhispererThe . 17 Aug '16

17 Aug '16

Hi all, I've noticed that after a password reset pwdChangedTime gets updated. This is fine. We do have a policy in place that doesn't let you modify your password again within a few days. I'd like to reset/change this pwdChangedTime so the user can reset his password himself after logging in with the supplied password. However deleting/modifying pwdChangedTime doesn't work. How should I resolve this? I'm pretty sure this is not an ACL issue as my user matches the first entry and is allowed to write all. I've seen some docs from IBM about removing pwdChangedTime being possible but that might not apply to openldap. Thanks in advance!

2 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2016