openldap-technical September 2019

openldap-technical@openldap.org

20 participants
25 discussions

LDAPcon 2019 schedule
by Michael Ströder 16 Sep '19

16 Sep '19

HI! LDAPcon 2019 conference program is now publicly available: https://cfp.ldapcon.org/ldapcon2019/schedule/ Hope to see you all in Sofia in November: https://ldapcon.org/2019/ Ciao, Michael.

2 1

slapo-unique spins its wheels on a non-trivial olcUniqueURI spec
by Norman Gray 13 Sep '19

13 Sep '19

Greetings. I'm having difficulty creating a non-trivial olcUniqueURI spec. Can anyone advise me? The problems are: * A plausible-looking spec in olcUniqueURI causes slapadd to spin its wheels indefinitely. * The manpage doesn't make it terribly clear what I should expect from a plausible-looking spec. Details follow: I want to specify something like dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueURI: ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub The idea is that the uidnumber attribute should be unique across the two OUs, ou=dept-A and ou=dept-B. If I do this, however, then slapadd spins its wheels: $ rm -R /usr/local/etc/openldap/slapd.d/* $ su -m ldap -c "slapadd -d255 -n 0 -F /usr/local/etc/openldap/slapd.d -l /usr/local/etc/openldap/slapd.ldif" ... ... 5d77d377 >>> dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <<< dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config>, <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <= str2entry(olcOverlay=unique,olcDatabase={1}mdb,cn=config) -> 0x800d4eca8 5d77d377 oc_check_required entry (olcOverlay=unique,olcDatabase={1}mdb,cn=config), objectClass "olcUniqueConfig" 5d77d377 oc_check_allowed type "objectClass" 5d77d377 oc_check_allowed type "olcOverlay" 5d77d377 oc_check_allowed type "olcUniqueURI" 5d77d377 oc_check_allowed type "structuralObjectClass" 5d77d377 >>> dnNormalize: <olcOverlay={1}unique> 5d77d377 <<< dnNormalize: <olcOverlay={1}unique> 5d77d377 ==> unique_db_init 5d77d377 ==> unique_new_domain <ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub> 5d77d377 >>> dnPrettyNormal: <ou=dept-A,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-A,o=example>, <ou=dept-A,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> ... ^C and so on and on and on, apparently indefinitely. slapo-unique(5) says that the syntax here is: unique_uri <[strict ][ignore ]URI[URI...]...> Configure the base, attributes, scope, and filter for uniqueness checking. Multiple URIs may be specified within a domain, allowing complex selections of objects. Multiple unique_uri statements or olcUniqueURI attributes will create independent domains, each with their own independent lists of URIs and ignore/strict settings. Keywords strict and ignore have to be enclosed in quotes (") together with the URI. The LDAP URI syntax is a subset of RFC-4516, and takes the form: ldap:///[base dn]?[attributes...]?scope[?filter] (I'm taking it that there should be a space between those `URI[URI...]`) in servers/slapd/overlays/unique.c, the comment above `unique_new_domain` says instead * domain_specs look like * * [strict ][ignore ]uri[[ uri]...] * e.g. "ldap:///ou=foo,o=bar?uid?sub ldap:///ou=baz,o=bar?uid?sub" * "strict ldap:///ou=accounts,o=bar?uid,uidNumber?one" * etc * So that's clearly permitting multiple URIs -- perhaps the quotes are required (as the manpage hints). But if I try olcUniqueURI: "ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub" ...then I get 5d77d617 ==> unique_new_domain <"ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub"> 5d77d617 olcUniqueURI: value #0: <"ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub"> invalid ldap urilist from slapadd (so that's not the problem). But the example there does look VERY much like what I tried. So: * I'm pretty sure I shouldn't be able to make slapadd spin its wheels like that. * The manpage text might be a little too telegraphic. While I'm sure it's not _wrong_, it is quite hard to go from that text to a working spec with any confidence. Googling olcUniqueURI produces very little of use. Is this not the correct way to do this? This looks somewhat similar, in symptoms and module, to ITS#8162, but it does seem distinct. Thanks for any pointers. Best wishes, Norman -- Norman Gray : https://nxg.me.uk

3 4

Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount 12 Sep '19

12 Sep '19

--On Thursday, September 12, 2019 12:23 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Thanks for quick response, i will consider your recommendations but i > wanted to understand when does consumer go to REFRESH mode? When it detects an inconsitency or error of some type. > 5d7a6178 send_ldap_result: err=66 matched="" text="subordinate objects > must be deleted first" > 5d7a6178 syncrepl_del_nonpresent: rid=001 be_delete dc=example,dc=com (66) > 5d7a6178 => bdb_entry_get: ndn: "dc=example,dc=com" And here is the error. It would appear it's getting the deletes out of sequence as it was requested to delete a parent before a child. I'd also note that back-bdb/hdb are deprecated. I will re-iterate that you need to update to a current release. Anything else is just a waste of time. Please see the change log: <https://www.openldap.org/software/release/changes.html> I'd also heavily advise using back-mdb with the current release and using delta-syncrepl. I would also note that some overlays have undefined behavior in an MMR environment (such as ppolicy as documented in the slapo-ppolicy(5) man page). YMMV with such overlays in use. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

[Q] ModRDN object via Net::LDAP::Control::SyncRequest
by Zeus Panchenko 12 Sep '19

12 Sep '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, please advise, how can I catch ModRDN object in syncrepl cosumer? I use perl Net::LDAP on ldapmodrdn I successfully catch LDAP_SYNC_MODIFY event with Net::LDAP::Entry object, DN of which contains *new* rdn ... but how to know/get the old one? accesslog DB doesn't contain reqDN for new rdn yet ... I'm using the example code from Net::LDAP::Control::SyncRequest - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQYIXL6FUmD7SUfqoOveOk+D/ejKgUCXXqZHwAKCRCveOk+D/ej KsoLAKCiqf/sGKpYLy0xUybyLCXtkTTVkQCcCfTAoMcwhC+JWHcxvHzeLrppc5w= =cVqP -----END PGP SIGNATURE-----

1 0

Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount 12 Sep '19

12 Sep '19

--On Thursday, September 12, 2019 10:57 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Any help? > > > On Tue, Sep 10, 2019 at 9:39 AM rammohan ganapavarapu > <rammohanganap(a)gmail.com> wrote: > > > Hi, > > > I have 2 nodes MMR setup with openldap 2.4.44-21 version, i see these > messages in the one of the two server logs, and looks like on consumer > side some of the entries are getting deleted. Sounds like it went into REFRESH. I'd strongly advise: a) Updating to the latest OpenLDAP release (there have been numerous MMR related fixes in the 3.5 years since 2.4.44 was released) and b) Using delta-syncrepl Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Openldap 2.4.x log details for error 49
by François Pernet 11 Sep '19

11 Sep '19

Hi all, We have a solution running on which openldap is the identity repository. OpenLDAP 2.4 is installed (on CentOS) also with policy. The system is able to send traps when authentication problem occurs, based on the slapd generated logs. Unfortunatly the log contains such error: "Jun 5 11:27:16 vms slapd[32101]: conn=1174 op=0 RESULT tag=97 err=49 text=" when the password entered generates an "invalid crendentials" message. This is fine, but the error could mean the following: * Wrong user or password * Expired account * Account locked or disabled * User must change its password Question is : is it possible to find a way to have the details for error 49 ? (this error message is far too generic) Many thanks in advance FPernet

2 1

Is there a simple document that explains the various admin passwords?
by Paul Pathiakis 11 Sep '19

11 Sep '19

Hi, I am trying to figure out all the various passwords and access controls. I seem unable to get my previously documented systems/configurations to work. I understand that slaptest is supposed to convert my slapd.conf to a new configuration and everything should be fine going forward. However, I'm having various password and access issues. Basically, I use my ldap.conf file and everything seems good. I start slapd and it works fine. I perform an ldap search and everything seems fine as it returns my domain. After that, I try to import my memberof.ldif file and it gives me an access issue. ldapadd -f /etc/openldap/memberof.ldif -v -D "cn=config" -H ldap://192.168.2.113 -W -c dn: cn=module,cn=config cn: module objectClass: olcModuleList objectclass: top olcModuleLoad: memberof.la olcModulePath: /usr/lib64/openldap dn: olcOverlay=memberof,olcDatabase={0}config,cn=config objectclass: olcconfig objectclass: olcMemberOf objectclass: olcoverlayconfig objectclass: top olcoverlay: memberof ldap_initialize( ldap://192.168.2.113:389/??base ) Enter LDAP Password: ldap_bind: Invalid credentials (49) Obviously, that's a password problem. My question is why? What step did I miss in my documentation? Thank you! P.

3 8

slapd and LetsEncrypt certificates: does a cert renewal necessitate a server restart?
by Jean-Francois Malouin 10 Sep '19

10 Sep '19

Hi, As the subject say, I'm contemplating the use of LetsEncrypt TLS certificates. Is there a way to make slapd aware of a cert renewal (they happen every 90 days) without restarting it, ie, with minimal service interruption? thanks, jf

6 6

Re: search request not blocked by ACLs
by Manuela Mandache 10 Sep '19

10 Sep '19

Le lun. 9 sept. 2019 à 18:25, Quanah Gibson-Mount <quanah(a)symas.com> a écrit : > > > --On Thursday, September 5, 2019 10:35 AM +0200 Manuela Mandache > <manuela3mandache(a)gmail.com> wrote: > > > > > > > > > > > > > > > Le mer. 4 sept. 2019 à 16:00, Quanah Gibson-Mount <quanah(a)symas.com> a > > écrit : > > > > --On Wednesday, September 4, 2019 1:56 PM +0200 Manuela Mandache > > <manuela3mandache(a)gmail.com> wrote: > > > >> olcAccess: {0}to * by dn.base="cn=admin,cn=config" manage by > >> dn.base="cn=adm > >> in,dc=example,dc=com" manage by * break > >> olcAccess: {1}to dn.base="" by * read > >> olcAccess: {2}to dn.base=cn=Subschema by * read > >> olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=userPassword by * > >> auth > >> olcAccess: {4}to dn.subtree="dc=example,dc=com" attrs=entry by * read > >> olcAccess: {5}to dn.subtree="dc=example,dc=com" attrs=cn,mail by * read > >> olcAccess: {6}to * by anonymous none by * read > > > > On what cn=config entry have you set these ACLs? > > > > > > > > > > They're on > > olcDatabase={2}mdb,cn=config > > This is the DB containing the actual data of the directory, with > > olcSuffix: dc=example,dc=com > > Given that, I would make the following notes: > > a) rootDNs are never subject to ACLs, so the access for cn=admin,cn=config > manage in {0} is suspect, as I would infer that is a rootdn. > > b) ACL {1} is invalid for this database. It should be set in the dn: > olcDatabase={-1}frontend,cn=config database > > c) ACL {2} is invalid for this database. See solution listed in (b) > > d) ACL {3} should only give auth access to anonymous, not * > > e) ACLs 3-5 should be rewritten to drop the dn.subtree="dc=example,dc=com" > bit entirely. You're already only setting ACLs for that database, no need > to list that restriction. You can also combine ACLs 4 & 5. > > olcAccess: {3} to attrs=userPassword by anonymous auth > olcAccess: {4} to attrs=entry,cn,mail by * read > olcAccess: {5} to * by anonymous none by * read > > Hello Quanah, Thank you for the detailed analysis of the ACLs - I wrote them based on very old inherited ones, but this is no excuse. Although I (believed I had) thoroughly RTFM, I feel like I only begin to really understand the way they must be defined. Well, back to the drawing board. Do poorly written ACLs have a strong impact on performance? > As for your question in general, I don't think you understand how ACLs > work > in relation to incoming search requests. The server did exactly what your > ACLs said it should do: It provided no information when someone tried to > search for data using an attribute that access is not granted to, and > correctly returned 0 entries. It sounds as though you expected the > connection to be dropped when the search was initiated because it was > filtering off of sn. No, I didn't think the connection would be dropped, but I thought no data which are never to be returned would be searched. E.g.: - there are three branches in the directory, ou=people,dc=example,dc=com, ou=dogs,dc=... and ou=carpets,...; - a user has read rights on ou=dogs and none on the two other branches; - this user makes a search with -b dc=example,dc=com and no filter. As far as I understand, the whole content is recovered, then the people and the carpets are dropped and only the dogs are returned. I expected the request to be parsed against the ACLs before performing the actual search in the directory, and so this search to be done only on ou=dogs. Maybe this example is completely different from the one in my first post: It's true that I do not know how requests-and-ACLs actually work. Is there some documentation I could read on the topic? Best regards, Manuela > That is now how things work. > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

ldap_add: Insufficient Access (50)
by Paul Pathiakis 09 Sep '19

09 Sep '19

Hi all, I'm trying to restore/move a database from one machine to another and start making sure that my client uses all the correct .ldif files. Now, I've always done a slapcat to an ldif file and used sed in place to modify/remove all the extraneous entries from the dump so I can reload. Strangely, this doesn't look like it's working this time around. I get the "Insufficient access (50) additional info: no write access to parent" Seems obvious that I don't have some type of access at the beginning of the load near the base of the tree. (After I get this, I'm inundated with ldap_add: No such object (32) since it wasn't able to write things into a non-existent structure further down) I see a potential problem in that the tree was originally defined as dc=example,dc=com and, now, everything lives in: dc=hq,dc=example,dc=com . Is that the problem? If so, what's the easiest way around it? Ldap.conf has: BASE dc=example,dc=com Slapd.conf has: access to attrs=userPassword by self write by anonymous auth by dn="uid=syncuser,dc=hq,dc=example,dc=com" read by * compare access to attrs=sambaLMPassword,sambaNTPassword by dn="uid=syncuser,dc=hq,dc=example,dc=com" read by * none access to * by self write by * read access to dn.subtree="dc=hq,dc=example,dc=com" by self write by set="[cn=itlevel1,ou=Groups,dc=hq,dc=example,dc=com]/member* & user" write by set="[cn=ntadmins,ou=Groups,dc=hq,dc=example,dc=com]/member* & user" write by * break authz-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=root,dc=hq,dc=example,dc=com" database mdb suffix "dc=hq,dc=example,dc=com"rootdn "cn=root,dc=hq,dc=example,dc=com" Thank you all! P.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2019