slapo-unique spins its wheels on a non-trivial olcUniqueURI spec
by Norman Gray
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
1 year, 6 months
Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount
--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 year, 7 months
[Q] ModRDN object via Net::LDAP::Control::SyncRequest
by Zeus Panchenko
-----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 year, 7 months
Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount
--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 year, 7 months
Openldap 2.4.x log details for error 49
by François Pernet
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
1 year, 7 months
Is there a simple document that explains the various admin passwords?
by Paul Pathiakis
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.
1 year, 7 months
Re: search request not blocked by ACLs
by Manuela Mandache
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>
>
1 year, 7 months
ldap_add: Insufficient Access (50)
by Paul Pathiakis
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 year, 7 months
Re: search request not blocked by ACLs
by Manuela Mandache
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
Regards,
Manuela
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
1 year, 7 months
