openldap-technical

openldap-technical@openldap.org

9937 discussions

search right and attribute existence
by Emmanuel Dreyfus 21 Aug '16

21 Aug '16

Hello I would like to test if an attribute is set without disclosing it. Using an ACL that grants the search right does it: I can do ldapsearch -b dn attr=*' dn and see if I get a result. Problem: it is still possible to brute force the atribute value, by searching x* with x being the first lette,r, then xy* and so on. Is there a way to address this? -- Emmanuel Dreyfus manu(a)netbsd.org

4 4

Directory structure searching
by Gurjot Kaur 19 Aug '16

19 Aug '16

Hi, I am encountered a problem regarding the checking of the directory structure during ldapsearch request. I did slapadd on my LDAP server (OpenLDAP 2.4.44 with MDB backend) for few entries and found the below error as my top entry "ou=people,dc=my-domain,dc=com" was missing from the DB. ############################################################################### /usr/local/sbin/slapadd -v -c -w -f /usr/local/etc/openldap/slapd.conf -l 2_tmp.ldif 578c3c23 mdb_monitor_db_open: monitoring disabled; configure monitor database to enable added: "ou=Test1,ou=people,dc=my-domain,dc=com" (00000005) added: "ou=Test2,ou=people,dc=my-domain,dc=com" (00000006) added: "ou=Test3,ou=people,dc=my-domain,dc=com" (00000007) added: "ou=Test4,ou=people,dc=my-domain,dc=com" (00000008) _#################### 100.00% eta none elapsed none fast! modified: "(null)" (00000001) Closing DB...Error, entries missing! entry 4: ou=people,dc=my-domain,dc=com ############################################################################### The above error is fine. Do the above entries get added to the DB, though the parent node for these entries was not present? Because when I search for the entry using the below ldapsearch command, this gives me the correct result. ############################################################################### ldapsearch -x -D cn=Manager, dc=my-domain,dc=com -w secret -b ou=Test1,ou=people, dc=my-domain,dc=com -s sub "(&(objectclass=organizationalUnit)(ou=Test1*))" -H ldap://0.0.0.0:2016 # extended LDIF # # LDAPv3 # base <ou=Test1,ou=people,dc=my-domain,dc=com> with scope subtree # filter: (&(objectclass=organizationalUnit)(ou=Test1*)) # requesting: ALL # # Test1, people, my-domain.com dn: ou=Test1,ou=people, dc=my-domain,dc=com ou: Test1 objectClass: organizationalUnit companyName: Test1 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ############################################################################### Does this means ldapsearch check just for the specific entry and not the complete directory structure? Thanks in advance. Regards, Gurjot Kaur "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

2 1

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical