openldap-technical April 2019

openldap-technical@openldap.org

33 participants
39 discussions

Replication delay
by Ángel L. Mateo 07 Apr '19

07 Apr '19

Hello, I've been running a multi master configuration without any problem for years. This running servers are running in 5 ubuntu 14.04 servers with openldap 2.4.43. The configuration is: dn: olcDatabase={3}mdb,cn=config ... olcSyncrepl: {0}rid=31 provider=ldap://canis31.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1 olcSyncrepl: {1}rid=32 provider=ldap://canis32.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1 olcSyncrepl: {2}rid=33 provider=ldap://canis33.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1 olcSyncrepl: {3}rid=34 provider=ldap://canis34.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1 dn: olcOverlay={0}dynlist,olcDatabase={3}mdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {0}dynlist olcDlAttrSet: {0}labeledURIObject labeledURI dn: olcOverlay={1}ppolicy,olcDatabase={3}mdb,cn=config objectClass: olcPPolicyConfig objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {1}ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=Telematica dn: olcOverlay={2}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {2}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 where each server has 4 olcSyncrepl attributes pointing to the other servers. I had no problem with this configuration for years Now I'm deploying an update of these servers in a new ubuntu 18.04 server with openldap 2.4.47. In order to synchronize entries between them, I have linked this new server to one of the other (and this one to the new one). Configuration in the new one (named canis41) is: dn: olcDatabase={3}mdb,cn=config ... olcSyncrepl: {0}rid=39 provider=ldap://canis39.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="60 +" timeout=1 schemache cking=off scope=sub olcSyncrepl: {1}rid=42 provider=ldap://canis42.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="30 +" timeout=1 logbase=" cn=log" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemaCh ecking=on syncdata=accesslog exattrs="pwdFailureTime" dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 dn: olcOverlay={1}ppolicy,olcDatabase={3}mdb,cn=config objectClass: olcPPolicyConfig objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {1}ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=Telematica dn: olcOverlay={2}dynlist,olcDatabase={3}mdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {2}dynlist olcDlAttrSet: {0}labeledURIObject labeledURI where canis39 is one the former servers and canis42 is a new server too synchronizing just with canis41. My problem is that synchronization is working, but sometimes modifications done in the canis3x farm are delayed a lot of time until they are replicated to the new one (sometimes in the order of 40-60 minutes). I'm logging sync logs, but I haven't found much information about these logs. Is there any way to debug it? How? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868889150 Fax: 868888337

7 34

"Authentication failure" on Ubuntu 18.04...
by Robert Heller 07 Apr '19

07 Apr '19

I have a server running CentOS 6 on the bare metal, running the stock CentOS 6 OpenLDAP packages (openldap-2.4.40-16.el6.x86_64, openldap-clients-2.4.40-16.el6.x86_64, openldap-2.4.40-16.el6.i686, openldap-servers-2.4.40-16.el6.x86_64) [yes I know these are old, but they *work* -- "If it ain't broke, don't fix it."]. There are two VMs running on this server, one running Ubuntu 14.04 and the other Ubuntu 18.04. (These two VMs are/will be servers for DRBL.) The Ubuntu 14.04 VM (and all of its diskless clients) are perfectly happy to talk to the OpenLDAP server (slapd) running on the CentOS 6 machine. The Ubuntu 18.04 VM is not. ldapsearch works everywhere though, so it is NOT the server or the core ldap libraries on any of the machines (partitularly the Ubuntu 18.04 VM). I can only assume that there is something fishy with nslcd or the pam/ldap libraries or config on the Ubuntu 18.04 VM. I have checked everything, but I am coming up empty. I am thinking there might be some "trick" to getting LDAP Authentication to work under Ubuntu 18.04 that I am missing. -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

2 2

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 03 Apr '19

03 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2019