openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

Question about OID / feedback on schema
by Mikael Bak 05 Apr '19

05 Apr '19

Hi list, After a previous discussion on this list[1] I've decided to define an object class and some attributes of my own to be able to turn users on/off and to be able to have their subscriptions expire. I got a lot of help from Michael Ströder, who pointed me in the right direction. Thank you for that! What I have so far looks like this: #objectidentifier oszkSchema x-hu-OSZK objectidentifier oszkSchema 1.3.6.1.4.1.4203.666 objectidentifier oszkAttrs oszkSchema:3 objectidentifier oszkOCs oszkSchema:4 attributetype ( oszkAttrs:1 NAME 'oszkAccountActive' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) attributetype ( oszkAttrs:2 NAME 'oszkAccountExpire' SINGLE-VALUE EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) objectclass ( oszkOCs:1 NAME 'oszkPerson' DESC 'OSZK person' SUP inetOrgPerson MUST ( oszkAccountActive ) MAY ( oszkAccountExpire ) ) My question is what I can use for OID in the beginning of the file? I tried to use a private name (beginning with "x-" as described here: http://www.openldap.org/doc/admin24/schema.html That did not work. Using the numeric OID above works, but I'm not sure what numbers are safe to use. This schema is going to be local on one server for the time being. So my question is: Is there a way to know what OID's I can use for private/local use only. I would like to avoid registering my organization with IANA fo now. I did not find that information in the above document. If I missed it and it's there, then I appologize. Secondly, if you find any errors or potential problems with my schema, then please let me know. I'm an LDAP beginner. TIA, Mikael [1] http://www.openldap.org/lists/openldap-technical/201904/msg00006.html

2 1

idassert-authzFrom: Proper way to include only non-anonymous binds
by Patrik Lundin 05 Apr '19

05 Apr '19

Hello, What is the proper way to make sure only non-anonymous binds are allowed to utilize idassert-bind credentials? Reading http://www.openldap.org/faq/data/cache/532.html the following is stated: === Authorize only non-anonymous: idassert-authzFrom "dn:*" === It also states: === The idassert-authzFrom mechanism controls whether a client's identity can be asserted or not. The idassert-authzFrom mechanism basically selects what identities can access the identity assertion feature, and indeed should be considered as the set of values of the authzFrom attribute associated to the administrative identity, with the essential difference that, if not present, by default every identity is authorized, including anonymous. === These excerpts makes me believe that the expected default behaviour is that a missing idassert-authzFrom will allow anyone, even anonymous binds. That a pattern of "*" is supposed to match non-anon binds is also stated in the slapd.conf man page (https://linux.die.net/man/5/slapd.conf): === A pattern of * means any non-anonymous DN. === Then there is this contradictory message I found while looking through the lists: https://www.openldap.org/lists/openldap-technical/200809/msg00096.html It states: === If you want idassert to work also for anonymous operations (not recommended, as this defeats the security model of the remote server, by letting it believe that the proxy authenticated users while it didn't), you need to explicitly enable it using an idassert-authzFrom rule that includes anonymous, like idassert-authzFrom "dn.regex:.*" === This is more in line with my tests, where removing the "idassert-authzFrom" all together stops an anonymous ldapsearch from returning a result, while adding 'idassert-authzFrom "dn:*"' makes it return results for the anon bind. I realize there is a difference between the the line from the FAQ ("dn:*") and the line from the mailing list ("dn.regex:.*") but looking at slap_idassert_authzfrom_parse(): https://github.com/openldap/openldap/blob/b06f5b0493937fc28f2cc86df1d7f464a… ... it appears to me that "*", "dn:*" and "dn.regex:.*" are supposed to be equivalent. I am using the meta backend, but I'm guessing they are sharing code in this case. The man page for slapd-meta does not state what the result of not configuring a "idassert-authzFrom" is though it seems to yield the results I want (that only properly authenticated connections can make use of the idassert-bind credentials). I'm guessing one way to make sure only authenticated clients can do anything is to add "require authc" to the config, but it is hard to tell how these things interact, and it would be nice to know what the expected way to configure idassert-authzFrom is (even if it means leaving it unset). Regards, Patrik Lundin

2 2

Re: Question: n-way multimaster syncrep cn=config and tree
by Dave Macias 04 Apr '19

04 Apr '19

Thank you very much Quanah for your response! > Sort of. If you added the schema and then an object, the other masters > should halt replication at that point until they have a matching schema. That's interesting. > Not really, no. It does depend on the version of OpenLDAP in use, as > there > were some bugs in older OpenLDAP versions that would allow the object to > partially replicate or the object to just get skipped, which could cause > headache. But those issues were fixed. > So then best practice with tree sync is add the schema to all masters first, then an object. which would make sense. > I would say that by doing cn=config replication, you've added a wide > surface area for new issues to occur. I generally view cn=config > replication as more of a beta feature. There are still ongoing issues > being resolved and fixed for it (For example, ITS#8616 in the most recent > 2.4.47 release) Hmm... so would you recommend removing the replication of cn=config for now? Individually adding the schema to each master is feasible for us. Thank you again -Dave

3 4

Re: Help needed: "glued" object.
by Alex Hebra 04 Apr '19

04 Apr '19

Hi Quanah, Thanks for your answer. Here are the details asked: OpenLDAP version 2.4.46. Mirror configuration on node A: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # Global section serverID 1 # database section # syncrepl directive syncrepl rid=001 provider=ldaps://02.host.com bindmethod=simple binddn="cn=root,dc=xxx" credentials=xxx searchbase="dc=xxx" schemachecking=on type=refreshAndPersist retry="10 +" tls_cacert=/usr/local/etc/openldap/cert/cert02.crt mirrormode on Mirror configuration on node B: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # Global section serverID 2 # database section # syncrepl directive syncrepl rid=001 provider=ldaps://01.host.com bindmethod=simple binddn="cn=root,dc=xxx" credentials=xxx searchbase="dc=xxx" schemachecking=on type=refreshAndPersist retry="10 +" tls_cacert=/usr/local/etc/openldap/cert/cert01.crt mirrormode on Thank you very much. On Tue, Apr 2, 2019 at 7:02 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, April 02, 2019 4:59 PM -0300 Alex Hebra <hebraalex(a)gmail.com> > > wrote: > > > > > > > Hi there, > > > > > > I have a very critical OpenLDAP environment running on mirror mode > > configuration. Is has about 800.000 users. > > Hello, > > You failed to provide any information on the release of OpenLDAP you are > using and did not provide any information on the replication mechanism in > use. By the sound of it, you are using standard syncrepl, where this sort > of problem is not uncommon, particularly with older versions of OpenLDAP. > I would suggest you start by noting the version of OpenLDAP in use and > providing information on the setup and configuration of the multimaster > nodes. > > Regards, > Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

5 9

Re: Question: n-way multimaster syncrep cn=config and tree
by Dave Macias 04 Apr '19

04 Apr '19

Ha! Of course. Thank you for support Best Regards, Dave On Apr 3, 2019, 4:41 PM -0400, Quanah Gibson-Mount <quanah(a)symas.com>, wrote: > --On Wednesday, April 03, 2019 5:27 PM -0400 Dave Macias <davama(a)gmail.com> > wrote: > > > > To which I should add -- And is only being fixed for OpenLDAP 2.5 and > > > later. > > > > ...2.5....any ETA on that? ;) > > "When it's ready"? ;) > > We've been reviewing our development process and are waiting on a writeup > from a project member on a new approach going forward to be debated by the > project team and then implemented as our process for 2.5 and future. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Re: Question: n-way multimaster syncrep cn=config and tree
by Dave Macias 03 Apr '19

03 Apr '19

Got it! Very helpful! Thank you! > >> Hmm... so would you recommend removing the replication of cn=config for > >> now? Individually adding the schema to each master is feasible for us. > > > > If it's not required then yes, I personally would not use it at this > > time. For example, ITS#8286, although it only discusses a single matching > > rule, ended up touching numerous files, and it's directly related to > > using cn=config and cn=config replication > > (< > https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h > > =3add82a3bb30b94afd23ff5e2c00c59ca8a931d8>). > > To which I should add -- And is only being fixed for OpenLDAP 2.5 and > later. > ...2.5....any ETA on that? ;) Best, dave

2 1

SLAMD resurrected (LDAP benchmarking tool)
by Quanah Gibson-Mount 03 Apr '19

03 Apr '19

One of my co-workers pointed this out to me the other day. If benchmarking LDAP is something that interests you: <https://nawilson.com/2019/03/18/so-i-guess-slamd-is-a-thing-again/> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Help needed: "glued" object.
by Alex Hebra 03 Apr '19

03 Apr '19

Hi Quanah, Thank your very much. Your reply is quite clear. After that I made a decision to migrate to delta-sync and to increase my session log (I have 800k users and 2.000.000 of entries). Please take a look on my new config after these changes, and let me know if it's ok: Node A: # Accesslog database definitions database mdb suffix cn=accesslog directory /var/db/openldap-data/accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE ##### # primary db config overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 2000000 # accesslog overlay definitions for primary db overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE # scan the accesslog DB every day, and purge entries older than 7 days logpurge 07+00:00 01+00:00 # Global section serverID 1 # database section # syncrepl directive syncrepl rid=001 provider=ldaps://02.host.com bindmethod=simple binddn="cn=root,dc=xxx" credentials=xxx searchbase="dc=xxx" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="10 +" syncdata=accesslog tls_cacert=/usr/local/etc/openldap/cert/certServerID2.crt mirrormode on Node B: # Accesslog database definitions database mdb suffix cn=accesslog directory /var/db/openldap-data/accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE ##### # primary db config overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 2000000 # accesslog overlay definitions for primary db overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE # scan the accesslog DB every day, and purge entries older than 7 days logpurge 07+00:00 01+00:00 # Global section serverID 2 # database section # syncrepl directive syncrepl rid=001 provider=ldaps://01.host.com bindmethod=simple binddn="cn=root,dc=xxx" credentials=xxx searchbase="dc=xxx" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="10 +" syncdata=accesslog tls_cacert=/usr/local/etc/openldap/cert/certServerID1.crt mirrormode on After that I made a change on Node A and it replicated to node B, then I made a change on node B and it replicated to A. So seems it's working. My doubt is how can I make sure it's working with delta-sync mode? Another question, changing to delta-sync can I use more than 2 nodes, for instance, 3 servers receiving writing and replicating between them? Thank you. On Wed, Apr 3, 2019 at 1:09 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, April 03, 2019 11:14 AM -0300 Alex Hebra > <hebraalex(a)gmail.com> wrote: > > > Thanks for your answer. Here are the details asked: > > > > > > OpenLDAP version 2.4.46. > > > > syncprov-sessionlog 100 > > syncprov-sessionlog 100 > > Hi Alex, > > Your sessionlog value is way too small. It needs to be something a little > larger than the entire size of your database (so > 800,000 in your case). > I also see you're using standard syncrepl rather than delta-syncrepl. > > Generally, having a "glued" object on a server indicates that at some > point, the server was in a REFRESH mode (either you populated the server > using syncrepl instead of slapcat, or it had some reason to fall back to > REFRESH at a later date). > > In the REFRESH mode, the server may get entries "out of order". In this > case, a stub (glue) object is created to "hold" the place for tha entry > until it gets fully replicated. Unfortunately, this doesn't always > happen, > and you end up being stuck with the glued object on the server. > > You may be able to force replication of the object onto the server where > it's missing by doing a MOD op against the affected entry on the master > where it exists. If one master is "complete" (I.e., no glued objects), > you > could also slapcat that master and import the database into the othe > rmaster via slapadd to resolve the problem for now. > > Overally, I strongly advise using delta-syncrepl as it largely avoids > these > issues (as long as it never has to fall back to standard syncrepl REFRESH > mode). > > I would note that there was a fix in OpenLDAP 2.4.47 specific to > delta-syncrepl when ppolicy is in use, so if using delta-sync you likely > want that fix. > > --Quanah > > > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

2 1

Question: n-way multimaster syncrep cn=config and tree
by Dave Macias 03 Apr '19

03 Apr '19

Hello, we recently adjusted our sync from n-way multimaster replication of the tree (searchbase="dc=organization,dc=com") and now included our "cn=config" replication. Some concerns/questions I have: Before with only tree replication, it was my understanding that one could NOT add a new schema along with an object unless said schema already existed in the other masters. yes? Our process was to turn off the sync add the schema to each master then normalize. Probably turning off the sync was unnecessary but just to be safe. Regardless if a new object with new schemas was added then one could ruin all the masters. Correct? Ok, so now with cn=config synchronized as well. Does this issue, if an issue, go away? Also, if upgrading one masters openldap software, should the sync be off? Recommendations? Any input is much appreciated. Thank you, Dave

2 1

Help needed: "glued" object.
by Alex Hebra 03 Apr '19

03 Apr '19

Hi there, I have a very critical OpenLDAP environment running on mirror mode configuration. Is has about 800.000 users. Unfortunately I'm facing some critical issues with OpenLDAP and I don't know if it's an issue with replication or not. After some time I found some objects with glue attribute, sometimes on both sides sometimes in just one side. I's bringing a big problem for me, many users can't auth after that and I can't stop this environment. I'd like to understand what's happening and how I could fix this problem. Any help is welcome. Thank you.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical