openldap-technical November 2017

openldap-technical@openldap.org

32 participants
47 discussions

Re: Is existing documentation kind of vague?
by Howard Chu 19 Nov '17

19 Nov '17

MJ J wrote: > I actually like 389 a lot and I have used Netscape DS extensively in > managing international telecom networks about 15 years ago. There are > quite many management features that are superior to OpenLDAP still to > this day, but I simply cannot use it anymore because of the lack of > scalability. I know the original Netscape DS devs quite extensively... There are certainly some obvious deficiences remaining in cn=config, and we're working on addressing as many as possible for 2.5. But I'd be curious to see your list of issues. > > -mike > > On Fri, Nov 17, 2017 at 8:34 AM, William Brown <wibrown(a)redhat.com> wrote: >> On Fri, 2017-11-17 at 08:27 +0200, MJ J wrote: >>> No matter how you wrap poll() and select(), they will always be >>> poll() >>> and select() - you will always run loops around an ever increasing >>> stack of file descriptors while doing I/O. BDB is always going to >>> have >>> the same old problems... That's what I'm talking about - sacrificing >>> performance for platform portability (NSPR). >>> >>> FreeIPA could be multi-tenant i.e.support top-level and subordinate >>> kerberos realms if it supported a more sensible DIT layout. I know >>> because I have built such a system (based on OpenLDAP) and deployed >>> it >>> internationally. Probably the best piece of code to come out of the >>> project is bind-dyndb-ldap. >> >> 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. >> >> There are things that today openldap does much better than us for >> certain - and there are also some things that we do differently too >> like DNA plugin uid allocation, replication etc, >> >> There are also project focusses and decisions made to improve >> supportability in systems like FreeIPA - we can discuss them forever, >> but reality is today, FreeIPA is not targeting multi-tennant >> environments because the majority of our consumers don't want that >> functionality. We made a design decision and have to live with it. I'm >> providing this information to help give the ability for people to >> construct an informed opinion. >> >> >> As mentioned, I'm not here to throw insults and criticisms, I'm here to >> have positive, respectful discussions about technology, to provide >> different ideas, and to learn from others :) >> >> Thanks, >> >>> >>> On Fri, Nov 17, 2017 at 4:49 AM, William Brown <wibrown(a)redhat.com> >>> wrote: >>>> On Thu, 2017-11-16 at 05:54 +0200, MJ J wrote: >>>>> Sure, it can be improved to become invulnerable to the >>>>> academically >>>>> imaginative race conditions that are not going to happen in real >>>>> life. >>>>> That will go to the very bottom of my list of things to do now, >>>>> thanks. >>>>> >>>>> FreeIPA is a cool concept, too bad it's not scalable or multi- >>>>> tenant >>>>> capable. >>>> >>>> It's a lot more scalable depending on which features you >>>> enable/disable. It won't even be multi-tenant due to the design >>>> with >>>> gssapi/krb. >>>> >>>> At the end of the day, the atomic UID/GID alloc in FreeIPA is from >>>> the >>>> DNA plugin from 389-ds-base (which you can multi-instance on a >>>> server >>>> or multi-tentant with many backends). We use a similar method to AD >>>> in >>>> that each master has a pool of ids to alloc from, and they can >>>> atomically request pools. This prevents the race issues you are >>>> describing here with openldap. >>>> >>>> So that's an option for you, because those race conditions *do* and >>>> *will* happen, and it will be a bad day for you when they do. >>>> >>>> >>>> Another option is an external IDM system that allocs the uid's and >>>> feeds them to your LDAP environment instead, >>>> >>>> Full disclosure: I'm a core dev of 389 directory server, so that's >>>> why >>>> I'm speaking in this context. Not here to say bad about openldap or >>>> try >>>> to poach you, they are a great project, just want to offer >>>> objective >>>> insight from "the other (dark?) side". :) >>>> >>>>> >>>>> On Wed, Nov 15, 2017 at 11:09 PM, Michael Ströder <michael@stroed >>>>> er.c >>>>> om> wrote: >>>>>> MJ J wrote: >>>>>>> TLDR; in a split-brain situation, you could run into trouble. >>>>>>> But >>>>>>> this >>>>>>> isn't the only place. Efffective systems monitoring is the >>>>>>> key >>>>>>> here. >>>>>>> >>>>>>> Long answer; >>>>>>> [..] >>>>>>> The solution I posted has been in production in a large, >>>>>>> dynamic >>>>>>> company for several years and never encountered a problem. >>>>>> >>>>>> Maybe it works for you. But I still don't understand why you >>>>>> post >>>>>> such a >>>>>> lengthy justification insisting on your MOD_INCREMENT / read- >>>>>> after- >>>>>> write >>>>>> approach with possible race condition even in a single master >>>>>> deployment >>>>>> while there are two proper solutions with just a few lines code >>>>>> more: >>>>>> >>>>>> 1. delete-by-value to provoke a conflict like the original >>>>>> poster >>>>>> mentioned by pointing to >>>>>> http://www.rexconsulting.net/ldap-protocol-uidNumber.html >>>>>> >>>>>> 2. MOD_INCREMENT with pre-read control >>>>>> >>>>>> Of course none of the solutions work when hitting multiple >>>>>> providers >>>>>> hard in a MMR setup or in a split-brain situation. One has to >>>>>> choose a >>>>>> "primary" provider then. >>>>>> BTW: AFAIK with FreeIPA each provider has its own ID range to >>>>>> prevent that. >>>>>> >>>>>> Ciao, Michael. >>>>> >>>>> >>>> >>>> -- >>>> Sincerely, >>>> >>>> William Brown >>>> Software Engineer >>>> Red Hat, Australia/Brisbane >>>> >>> >>> >> -- >> Sincerely, >> >> William Brown >> Software Engineer >> Red Hat, Australia/Brisbane >> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Is existing documentation kind of vague?
by Howard Chu 19 Nov '17

19 Nov '17

MJ J wrote: > I had a requirement to build a centrally managed SSO system that > replicated subordinate subtrees (kerberos, identities, roles, > permissions, resources, dns, etc) to the respective sites and handle > tens of thousands of concurrent requests per second. I determined that > FreeIPA was unable to perform this mission due to 1) inflexible DIT, > 2) inflexible management tooling, and 3) lack of scalability. So, I > built a system to achieve those goals. And it really wasn't rocket > science. Perhaps I will write a book about it and ask for competent > reviewers from the OL community. Would be happy to review it. > On Fri, Nov 17, 2017 at 4:21 PM, Michael Ströder <michael(a)stroeder.com> wrote: >> MJ J wrote: >>> I know because I have built such a system (based on OpenLDAP) and >>> deployed it internationally. >> So what makes your system special, which goals does it reach and how? >> >> Ciao, Michael. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

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 16 Nov '17

16 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 14 Nov '17

14 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical November 2017