openldap-technical

openldap-technical@openldap.org

12 participants
9794 discussions

Is existing documentation kind of vague?
by John Lewis 19 Nov '17

19 Nov '17

Hello Everyone. I was trying to implement uidNumber Attribute Auto-Incrementing Method and I read http://www.rexconsulting.net/ldap-protocol-uidNumber.html . I specifically want to point to this line here. > Create a “uidNext” entry (objectClass: uidNext) at an specific > location in the directory to store the incrementing value. Publish > this location in your application programming guides as the well- > known location for obtaining the next UID. Also publish this method > as the required method to retrieve a next UID. But I already know from http://www.openldap.org/doc/admin23/schema.html & http://www.zytrax.com/books/ldap/ch3/ that object classes are defined only. So the writer left out that they defined a schema and what name the called the schema. Maybe it isn't important. What is important is that they used object class "objectclass ( 1.3.6.1.4.1.19173.2.2.2.8" to define it, but I can't find the registration of the object identifier on https://www.ldap.com/ldap-oid- reference or https://www.iana.org/assignments/ldap-parameters/ldap-para meters.xhtml#ldap-parameters-3. It makes perfect scene because it is a PRIVATE ENTERPRISE NUMBER. It would mean that anyone outside of Rex Consulting, Inc. https://www.iana .org/assignments/enterprise-numbers/enterprise-numbers would be using the wrong OID and that the specific object wouldn't be listed. > Under no circumstances should you hijack OID namespace! - OpenLDAP Software 2.4 Administrator's Guide That is a lot of data from a lot of different websites to string together that information. I have a good idea how to implement uidNumber, but I haven't seen it done and I can't do it CORRECT today because I would have to register for a Private Enterprise Number so I won't hijack an OID namespace and that would take up to 30 days and there is no documented contingency plan anywhere. We are all familiar with the the LDAP call out articles that come out every year. All of the articles seem to come from a place of frustration. To be fair I think call out articles are a trend with databases. Do you think existing documentation is kind of vague?

5 19

Re: Is existing documentation kind of vague?
by Shawn McKinney 17 Nov '17

17 Nov '17

> On Nov 17, 2017, at 12:34 AM, William Brown <wibrown(a)redhat.com> wrote: > > Whoa mate - I'm not here to claim that 389 is a better ldap server - we > just do some different things. We acknowledge our limitations and are > really working on them and paying down our tech debt. We want to remove > parts of nspr, replace bdb and more. :) > > I'm here to follow the progress of the openldap project, who have a > team of people I respect greatly and want to learn from, and here to > help discussions and provide input from a different perspective. Openldap and 389 are long-lost siblings, separated during childhood, raised by their respective communities. Now at last perhaps we join again, cooperate, share and enjoy mutual benefit. Welcome! Shawn

1 0

restrict wildcard searches
by Geert Hendrickx 17 Nov '17

17 Nov '17

Hi, Is there a way to restrict (acl?) searches using wildcards? For compliancly reasons, I want to allow certain (actually most) users to search on eg. known email addresses, like: mail=user(a)example.org, but not to retrieve a list of all users, like mail=*(a)example.org. Sizelimit restriction is not enough, because they could still iteratively retrieve everything, without launching an actual dictionary attack on all possible mail addresses, which would be much harder. Geert -- geert.hendrickx.be :: geert(a)hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!

3 2

Re: ssf Security Question
by Quanah Gibson-Mount 15 Nov '17

15 Nov '17

--On Tuesday, November 14, 2017 8:56 PM +0000 Kaya Saman <kayasaman(a)gmail.com> wrote: > access to * > by ssf=128 self write > by ssf=128 anonymous auth > by ssf=128 users read > > > > ># Added ACL for open access to AddressBook in Read and Search only mode > > access to dn.children="ou=AddressBook,dc=domain,dc=com" > by * search > by * read Your second ACL will never be evaluated, since the first ACL matches everything. As noted in the slapd.access(5) man page, ACL processing stops on the first matching ACL. In addition, in your second ACL, the "by * read" will never be processed, because of the match to "by * search". If you're already planning on granting read, there is no point to having by * search there at all. I.e., your ACLs should be: access to dn.children="ou=AddressBook,dc=domain,dc=com" by * read access to * by ssf=128 self write by ssf=128 anonymous auth by ssf=128 users read And I generally doubt you want to give users read to "*", as this means they can read the userPassword values of other users, etc. You might want something more like: access to dn.children="ou=AddressBook,dc=domain,dc=com" by * read access to attrs=userPassword by ssf=128 anonymous auth by ssf=128 self write access to * by ssf=128 self write by ssf=128 users read And yes, you have to remove the global SSF setting if the phone cannot support startTLS on port 389. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Antw: Efficient way to count number of entries in a database?
by Quanah Gibson-Mount 15 Nov '17

15 Nov '17

--On Tuesday, November 14, 2017 12:40 PM +0100 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > Here olmBDBDNCache from cn=Database 1,cn=Databases,cn=Monitor seems to > be close to the number (10762 vs. 10770). That is a BDB specific item, and not relevant to back-mdb databases. In addition, the value is something that is configurable in slapd.conf, so may or may not contain a result that is valid. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Efficient way to count number of entries in a database?
by Karsten Heymann 15 Nov '17

15 Nov '17

Hi Quanah, 2017-11-14 16:46 GMT+01:00 Quanah Gibson-Mount <quanah(a)symas.com>: > mdb_stat -s id2e /path/to/mdb/db | grep Entries > Entries: 3993833 > That's exactly what I needed. Thanks a lot! btw for those using debian as well, mdb_stat is in the lmdb-utils package BR Karsten

1 0

Re: Efficient way to count number of entries in a database?
by Quanah Gibson-Mount 14 Nov '17

14 Nov '17

--On Tuesday, November 14, 2017 4:35 PM +0100 Karsten Heymann <karsten.heymann(a)gmail.com> wrote: > > Currently about 1.5Mio. If you have access to the system and have mdb_stat available, the easiest method is to simply query the database directly: mdb_stat -s id2e /path/to/mdb/db | grep Entries Entries: 3993833 --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Efficient way to count number of entries in a database?
by Karsten Heymann 14 Nov '17

14 Nov '17

Hi, is there a more efficient way to count how many entries a ldap database has than slapcat -b <suffix> | grep ^dn: | wc -l I searched the cn=Monitor backend but it does not seem to export this number. I want to have this for graphing and reporting and as a secondary data point that replication is working as intended. BR Karsten

3 7

proxy/backend pointers
by David LaPorte 14 Nov '17

14 Nov '17

Hello, I've done a bit of research, but having some difficulty determining if my use case is possible. Here's what I'm trying to do: We have an old unsupported application that authenticates users using an LDAP bind. The credential used for authentication (and what all the internal authorizations are tied to) is employee ID. We are moving to LDAP directory that uses email address instead of employee ID as the DN - the employee ID is still present as an attribute in the new directory and the password remains the same. Since I can't modify the problematic application, it’s not going away anytime soon, and it’s the last thing holding up migration to the new directory system, I'm hoping that I can use OpenLDAP as a shim between the application and the new directory to do something like the following: * Collect credentials (employee_id, password) during bind * using a privileged service account, search/bind against the new directory to map employee ID attribute to email address DN (like mod_authz_ldap does it) * return the success/failure as result of original bind I would appreciate any ideas or pointers if this is possible or if there might be a better way. Thanks in advance! Dave David LaPorte david(a)davidlaporte.org

1 0

Re: a question about "Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root()"
by Howard Chu 14 Nov '17

14 Nov '17

James Anderson wrote: > good afternoon; > > we have seen sporadic instances of the “page search root" error: > > dydrad[20250]: [#2224] CREATE-TRANSACTION 8f9e6986-5fd4-c54b-b073-0c134552aa4a R/O => james/test2@d3102d2e-ded8-d740-8340-4b7e5608eb78 (pid=22136 tid=31865) > mdb.c:5276: Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root() > > this happens in a situation where we are simply executing numerous requests which just clear the contents of a two-entry database and then insert two new entries. > > we are using lmdb in the version 0.9.17, which i had understood from the threads in this list to be after the point when this problem was addressed. > is that true or is it expected to still be an open issue at that version? The bug was reported in 0.9.17, so it certainly was not fixed in that version. http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8336 Git shows the fix was released in 0.9.18. You should be using 0.9.21 now. -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical