openldap-technical

openldap-technical@openldap.org

9 participants
9902 discussions

Re: slapo-smbk5pwd build fixes
by Quanah Gibson-Mount 29 Nov '16

29 Nov '16

--On Saturday, November 05, 2016 7:30 PM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Saturday, November 05, 2016 6:30 PM +0200 Emmanuel Dreyfus > <manu(a)netbsd.org> wrote: > >> Hello >> >> slapo-smbk5pwd does not link with newer OpenSSL,because the old des_* >> API was removed. This simple patch uses the new (but available for a >> long time) DES_* API to fix that: >> http://www.openldap.org/its/index.cgi/Incoming?id=8525;selectid=8525 > > Hi Emmanuel, > > The openldap-devel list would be the appropriate place to raise and > discuss this. I will try and look into it further on Monday. This is now in RE24, scheduled for the 2.4.45 release. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

replicate cn=config with exception of "ACLs"
by Stanislav Kopp 29 Nov '16

29 Nov '16

Hello, at the moment we're using master<->slave setup with slapd 2.4.31 using old slapd.conf. I want to migrate all to "cn=config" and if possible replicate cn=config DB to slaves for sake maintenance simplicity, but with exception ofr ACLs rules, because master and slaves have different ACLs. Is it possible, or ist it a good idea in general? The plus of slapd.conf was that I can deploy the same ACL file on all slaves with some automation (e.g. puppet). Thanks, Stan

1 0

Re: OID syntax and NAMEs
by Howard Chu 29 Nov '16

29 Nov '16

Michael Ströder wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Eventual I'd like to have a constraint like this: >>> >>> # check whether appropriate password policy is assigned >>> constraint_attribute structuralObjectClass,pwdPolicySubentry >>> set "this/structuralObjectClass & this/pwdPolicySubentry/aeApplicableSOC" >> >> Not possible without custom code. > > Hmm, are this/structuralObjectClass and this/pwdPolicySubentry generally > unusable in set-constraints? > > Or does it not work because of the different matching rules? Yes, because of the matching rule issue. This seems to be a deficiency in either ASN.1 or the LDAP spec, I'm not sure which. The problem is that numeric OIDs are obviously unique, but there's no guarantee that string names are. Moreover, the same name might apply to the OID of an attribute, or an objectclass, or a syntax, or some other entity, and there's no way to tell the objectIdentifierMatch rule which context is relevant. So, we can only match on numeric OIDs. -- -- 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: OID syntax and NAMEs
by Howard Chu 28 Nov '16

28 Nov '16

Michael Ströder wrote: > HI! > > I've declared an attribute type like this with LDAP syntax OID: > > ( 1.3.6.1.4.1.5427.1.389.100.4.18 > NAME 'aeApplicableSOC' > DESC 'AE-DIR: structural object classes for which policy is applicable' > EQUALITY objectIdentifierMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 > X-ORIGIN 'AE-DIR' ) > > Which is pretty similar to this: > > ( 2.5.4.0 > NAME 'objectClass' > DESC 'RFC4512: object classes of the entity' > EQUALITY objectIdentifierMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) > > Now I wonder why I can't use the object class NAMEs instead of the OIDs as > attribute or assertion values, e.g. why I can't find the entries with filter > (aeApplicableSOC=aeUser). > > This reminds me a bit of the similar OID vs. NAME issue with 'pwdAttribute' in > 'pwdPolicy' entries. It's the exact same issue. The objectIdentifierMatch function only works with numeric OIDs. The ppolicy overlay inserts its own matching function to make the name work. > > Eventual I'd like to have a constraint like this: > > # check whether appropriate password policy is assigned > constraint_attribute structuralObjectClass,pwdPolicySubentry > set "this/structuralObjectClass & this/pwdPolicySubentry/aeApplicableSOC" Not possible without custom code. > > 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

Re: Ldap not reachable/tuning
by Quanah Gibson-Mount 28 Nov '16

28 Nov '16

--On Friday, November 25, 2016 7:05 PM +0100 Thomas Hummel <thomas.hummel(a)pasteur.fr> wrote: > Hello, > > I'm using a simple setup on CentOS Linux release 7.2.1511 > (Core)/openldap-servers-2.4.40-9 /cn=config/mdb : one provider with the > syncprov overlay and 2 syncrepl consumers. The DIT itself is about 10000 > dn in size (about 3000 active users). > > Everything works fine except that sometimes, some clients report > (temporary) failure to reach the consumers (NAS servers for instance). Hi Thomas, A few notes: a) The CentOS7 build is hacked to support a broken TLS implementation. b) The version (2.4.40) is quite old, and has numerous known problems (it was a particularly broken release). I would also note the CentOS7 build has on occassion had its own problems introduced by patches from RedHat that do not exist in stock OpenLDAP builds. See <http://www.openldap.org/software/release/changes.html> for a list of changes since 2.4.40 was released. c) Nothing you presented indicates any issue on the server side. It could, for example, be an issue with your clients, a firewall, packet shaper, etc. d) You should fully disable rate limiting for rsyslogd. Then find out what the server side reports during the periods of time when you see issues with the client connections. You may wish to examine the LTB builds (<http://ltb-project.org/wiki/download#openldap>) if you are unable to build OpenLDAP yourself, or if you require support for your OpenLDAP installation, Symas (the company I work for) has support options. Hope this helps! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

OID syntax and NAMEs
by Michael Ströder 28 Nov '16

28 Nov '16

HI! I've declared an attribute type like this with LDAP syntax OID: ( 1.3.6.1.4.1.5427.1.389.100.4.18 NAME 'aeApplicableSOC' DESC 'AE-DIR: structural object classes for which policy is applicable' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 X-ORIGIN 'AE-DIR' ) Which is pretty similar to this: ( 2.5.4.0 NAME 'objectClass' DESC 'RFC4512: object classes of the entity' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) Now I wonder why I can't use the object class NAMEs instead of the OIDs as attribute or assertion values, e.g. why I can't find the entries with filter (aeApplicableSOC=aeUser). This reminds me a bit of the similar OID vs. NAME issue with 'pwdAttribute' in 'pwdPolicy' entries. Eventual I'd like to have a constraint like this: # check whether appropriate password policy is assigned constraint_attribute structuralObjectClass,pwdPolicySubentry set "this/structuralObjectClass & this/pwdPolicySubentry/aeApplicableSOC" Ciao, Michael.

1 0

"attr" Warning in slapcat
by Kilian 26 Nov '16

26 Nov '16

Hi, having a strange warning: # /usr/sbin/slapcat -b dc=foo,dc=bar,com 583422d0 /etc/ldap/slapd.d: line 1: "attr" is deprecated (and undocumented); use "attrs" instead. Then, the normal output of slapcat follows. The thing is, /etc/ldap/slapd.d is a *folder* and in the entire /etc/ldap folder, including subdirs, the string "attr" does not occur. Btw, The contents of /etc/ldap/slapd.d are: -rw------- 1 openldap openldap 2386 Jun 5 13:51 cn=config.ldif drwxr-x--- 6 openldap openldap 4096 Nov 20 20:32 cn=config Can anyone give me a hint, what is going on? Best, Kilian

3 3

Ldap not reachable/tuning
by Thomas Hummel 25 Nov '16

25 Nov '16

Hello, I'm using a simple setup on CentOS Linux release 7.2.1511 (Core)/openldap-servers-2.4.40-9 /cn=config/mdb : one provider with the syncprov overlay and 2 syncrepl consumers. The DIT itself is about 10000 dn in size (about 3000 active users). Everything works fine except that sometimes, some clients report (temporary) failure to reach the consumers (NAS servers for instance). All I see in the logs is that when this happens, the time windows loosely match a moment where log rate limiting is dropping messages (for debugging purpose, I disabled journald ratelimiting and doubled default rsyslog one - still some drops occur on a regular basis). So I assume it happens when slapd is kind of busy... Here are some question about that : - First tuning attempt : ------------------------- I noticed that olcDbMaxReaders value was set to 0 (not by me!) I changed it to olcDbMaxReaders: 512 I thought the problem didn't occur anymore but I was wrong. -> Is there any guideline about how to setup MaxReaders ? - Second tuning attempt : ------------------------- I thought maybe replication was responsible (I'm using refreshAndPersist mode) so I raised the size of the sessionLog (from 100 to 800). I read the doc again and I'd like to know if the following understanding is correct : - thanks to contextCSN and the sync cookies, replication CAN be stateless - if we want it stateless, syncprov HAS TO use the present phase, which basically is like sending the whole DIT except that for unchanged entries, only names are sent - if and ONLY IF a state is used (in the form of a sessionLog), then delete phase can be used (and if the sessionLog can hold enough since the last sync) As a matter of fact, at the opposite of the present phase, in the delete phase, syncprov has to 'remember' (i.e store in a sessionLog) which entries has been deleted. -> this assumes that delete phase is more efficient than the present phase, right ? -> if for some reason (for instance sessionLog being too small, delete phase can not be used) syncprov HAS TO fall back to present phase, correct ? -> does using the sessionLog MAKE SENSE AT ALL when using refreshAndPersist mode ? -> is there any guideline to choose the right size for the sessionLog ? - Third tuning attempt ------------------------- I also raised the checkpoint values. -> Is there any guideline here as well ? Thanks. -- Thomas HUMMEL

1 1

support for openssl-1.1.0c
by A. Schulze 25 Nov '16

25 Nov '16

hello, I played with git://git.openldap.org/openldap.git and wrote a patch to support compilation using openssl-1.1.0c Just created a ITS item: http://www.openldap.org/its/index.cgi/Incoming?id=8533 The patch is available here: ftp://ftp.openldap.org/incoming/andreas-schulze-161125.patch maybe some people want to review the code... Hope that helps to step further for 2.4.45 !? Andreas

1 0

Allow to pass on "undefined" filters in back-perl
by W.Siebert＠t-systems.com 25 Nov '16

25 Nov '16

Hi all, I have now the same problem, but with back-perl. We have so one kind of LDAP broker implemented. Reason is to split authentication and authorization by sending the LDAP-bind to one server(Authentication) and LDAP-search for group membership to another (Authorization). Unfortunately one of 6 authorization server is a Microsoft Active Directory, expects LDAP_MATCHING_RULE_IN_CHAIN, and so I get "Bad filter, "(?=undefined)". It is possible to implement a similar workaround as in the back-meta bellow? I think a generally config option to deactivate the filters sanity check were very useful, not for me only. Kind regards Waldemar ------------------------------------------------------------------------------- Hi all, I had exactly the same problem last June. Pierangelo Masarati helped me understanding the problem. He even provided the code for a contrib module to solve this issue. You can search the list for the subject "back_meta does not like my LDAP_MATCHING_RULE_IN_CHAIN filter". I have "packed" all of it into a github repo at https://github.com/cbueche/openldap-passthru and announced it to the list on 6.6.2014. It would be nice if the maintainer take it over to the official openldap tarball within contrib/slapd-modules/mr_passthru/ so future needs are "officially" covered. I think the LDAP_MATCHING_RULE_IN_CHAIN filters will find their use for many other people. Markus: I can help you for the implementation if needed. Feel free to provide for more functionality. Regs, Charles On 23.10.14 08:17, Markus.Storm(a)t-systems.com wrote: > Hi Howard, > > have you had a chance to look into this? > We're a bit desperate over here, short of alternative solutions. > > Regards > Markus > >> -----Original Message----- >> From: Storm, Markus >> Sent: Thursday, September 18, 2014 8:44 AM >> To: 'Howard Chu'; openldap-technical(a)openldap.org >> Subject: AW: allow to pass on "undefined" filters in meta >> >>> -----Ursprüngliche Nachricht----- >>> Von: Howard Chu [mailto:hyc@symas.com] >>> Gesendet: Mittwoch, 17. September 2014 18:17 >>> An: Storm, Markus; openldap-technical(a)openldap.org >>> Betreff: Re: allow to pass on "undefined" filters in meta >>> >>> Markus.Storm(a)t-systems.com wrote: >>>> Hi >>>> I've run into a problem trying to deploy back-meta in front of an >>>> Active Directory target. >>> What is the exact filter you are trying to use? >> a filter such as >> >> (&(objectclass=user) >> (|(memberOf:1.2.840.113556.1.4.1941:=CN=GRP_AAA_ADM,OU=Groups,OU=AAA,OU=Se >> rvers,DC=lab,DC=net) >> (memberOf:1.2.840.113556.1.4.1941:=CN=GRP_BBB_ADM,OU=Groups,OU=AAA,OU=Serv >> ers,DC=lab,DC=net))) >> >> The problem is with the matching rule to be used :1.2.840.113556.1.4.1941: >> That translates into LDAP_MATCHING_RULE_IN_CHAIN which makes the server >> recursively check for nested group membership. That's a feature in AD but >> not supported in OpenLDAP (or at least not by simply specifying that matching >> rule, and to rework the query is no option). >> >>>> I believe that to resolve it, I need to get a new option implemented. >>>> I need to issue a request through a back-meta proxy . That query >>>> happens to contain a matching rule which is not implemented in >>>> OpenLDAP so slapd does not know to evaluate the query. The target >>> that >>>> the query will ultimately be passed on to (an Active Directory) does >>> know to process the query, though. >>>> OpenLDAP, however, considers the filter to be "undefined" and thus >>>> on relaying the request to the AD target, back-meta replaces a >>>> portion >>> of >>>> the original query with a "(?=undefined)" filter as documented in >>> e.g. >>>> slapd-meta manpage "noundeffilter" option. >>>> But I need the original query to be passed on. It's in fact a >>>> _valid_ LDAP request, just OpenLDAP happens to be unable to parse it. >>>> But at least in my setup, slapd does not have to do _/anything/_ >>>> about the query other than to pass it on, so I find it inacceptable >>>> that it replaces the query just because it doesn't understand it. >>>> Please, can you add an option switch to the code to allow for >>>> passing on original queries *without* replacing undefined portions ? >>>> I have not found any other solution to my problem. I tried to make >>>> OpenLDAP aware of the undefined portion by adding the matching rule >>> to >>>> the schema but I failed. Seems that would need to be planted into >>>> the code, and not being a programmer, that's not as easy as it is >>>> with expanding the schema by some new attributes. >>>> Also, while of course any parser/feature enhancement will always be >>>> appreciated, I would think that to implement the matching rule is >>> not >>>> the best way of fixing things: I believe there will always be >>>> situations where OpenLDAP cannot parse the input while another LDAP >>> server can. >>>> For a proof of concept, I hacked servers/slapd/back-meta/map.c >>> (around >>>> line 581as of 2.4.39) and but - again, I'm not a programmer - I >>> feel >>>> incapable of turning this into a full-blown patch free of side >>>> effects, also I want the modification to become available to anyone. >>>> So I'm hoping for you to implement the switch mentioned above, maybe >>>> as a third possible setting for the "noundeffilter" option. >>>> Thanks a lot in advance, >>>> best regards >>>> Markus Storm

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