Re: a question about "Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root()"
by Howard Chu
James Anderson wrote:
> good afternoon;
>
> we have seen sporadic instances of the “page search root" error:
>
> dydrad[20250]: [#2224] CREATE-TRANSACTION 8f9e6986-5fd4-c54b-b073-0c134552aa4a R/O => james/test2@d3102d2e-ded8-d740-8340-4b7e5608eb78 (pid=22136 tid=31865)
> mdb.c:5276: Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root()
>
> this happens in a situation where we are simply executing numerous requests which just clear the contents of a two-entry database and then insert two new entries.
>
> we are using lmdb in the version 0.9.17, which i had understood from the threads in this list to be after the point when this problem was addressed.
> is that true or is it expected to still be an open issue at that version?
The bug was reported in 0.9.17, so it certainly was not fixed in that version.
http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8336
Git shows the fix was released in 0.9.18. You should be using 0.9.21 now.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5 years, 10 months
Re: your mail
by Howard Chu
Dave Horsfall wrote:
> On Mon, 13 Nov 2017, Suneet Shah wrote:
>
>> Hi Openldap
>> http://bit.ly/2zC6jTU
>> Thank you
>>
>> Suneet
>
> Is there some reason why spam is allowed on this list?
This email address was a legitimate participant on this list, you can find
their posts from 2011-2015 in the archive.
Probably his email account has been compromised, we'll turn it off.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5 years, 10 months
a question about "Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root()"
by James Anderson
good afternoon;
we have seen sporadic instances of the “page search root" error:
dydrad[20250]: [#2224] CREATE-TRANSACTION 8f9e6986-5fd4-c54b-b073-0c134552aa4a R/O => james/test2@d3102d2e-ded8-d740-8340-4b7e5608eb78 (pid=22136 tid=31865)
mdb.c:5276: Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root()
this happens in a situation where we are simply executing numerous requests which just clear the contents of a two-entry database and then insert two new entries.
we are using lmdb in the version 0.9.17, which i had understood from the threads in this list to be after the point when this problem was addressed.
is that true or is it expected to still be an open issue at that version?
if that version is still susceptible, what avenues are customary to upgrade to a version closer to the latest release.
we have tried to substitute 0.9.70, but it does not appear possible to do that, due to library incompatibilities, unless we unload/reload all databases.
best regards, from berlin,
---
james anderson | james(a)dydra.com | http://dydra.com
5 years, 10 months
Question regarding using OpenLDAP as a proxy to multiple AD servers
by Mārtiņš Mieriņš
Hi,
I'm new to OpenLDAP, I've been reading documentation for some time but
cannot figure out whether there is solution.
We have many products in our company that are using sAMAccountName
(from Active Directory server) as login credentials for authentication
purpose. Now we have an additional requirement to support
authentication of users from another Active Directory server. Since
many products do not allow to specify more than one LDAP server the
idea is to configure OpenLDAP proxy that will then forward requests to
either AD servers. Nevertheless the format of login credentials has to
stay the same.
So the final goal is to be able to authenticate users of both AD
directories via binding against OpenLDAP proxy using sAMAccountName
(can add some other data in DN but it has to be static).
1. Can OpenLDAP be configured to accept sAMAccountName and domain as
bind DN and then forward it to either AD servers depending on domain
name?
2. If not, can OpenLDAP be configured to perform search (including
filtering by sAMAccountName field) behind the scenes and then bind by
using DN of a found user?-> all this happens when user tries to bind
against OpenLDAP proxy
3. Any other solutions?
BR,
Martins
5 years, 10 months
let slapo-ppolicy set pwdFailureTime
by Michael Ströder
HI!
I'm using back-sock as overlay to intercept bind *requests* and send
them to an external listener which returns success(0) or
invalidCredentials(49).
I'd like to avoid having to deal with operational attributes in the
user's entry. Therefore in case of invalidCredentials(49) I'd like
slapo-ppolicy to add attribute value to 'pwdFailureTime'.
The order of overlays in slapd.conf is:
overlay sock
sockops bind
overlay ppolicy
overlay lastbind
overlay rwm
From my understand the requests go from bottom up
rwm -> lastbind -> ppolicy -> back-sock
.....continue...... returns success(0)
or invalidCredentials(49)
and vice versa the response go through
back-sock -> ppolicy -> lastbind -> rwm
It partially works:
(/) I see update of 'authTimestamp' by slapo-lastbind.
(/) If back-sock listener returns success(0) slapo-ppolicy correctly
checks password expiry in the response chain and returns
invalidCredentials(49) with appropriate ppolicy response controls.
(x) But the attribute 'pwdFailureTime' is not set in case back-sock
listener returns invalidCredentials(49).
Reading source of ppolicy_bind_response() one of the first things is to
check for rs->sr_err == LDAP_INVALID_CREDENTIALS and add another
'pwdFailureTime' value.
So it should work. But it doesn't. Any clue what I'm doing wrong?
Ciao, Michael.
5 years, 10 months
Re: Replication problem with attributes
by Quanah Gibson-Mount
--On Thursday, November 09, 2017 12:39 PM +0100 Dennis Meyer
<snooops84(a)gmail.com> wrote:
> olcAccess: {0}to attrs=userPassword by self write by anonymous auth by *
> none
> olcAccess: {1}to attrs=loginShell,gecos by dn="cn=admin,dc=localdomain"
> write by self write by * read
> olcAccess: {2}to attrs=shadowLastChange by self write by * read
> olcAccess: {3}to * by * read
> olcAccess: {4}to attrs=userPassword,shadowLastChange by self write by
> anonymous auth by dn="cn=admin,dc=localdomain" write by
> dn="cn=mirrormode,dc=localdomain" read by * none
ACL {4} will never be evaluated, because ACL parsing stops on the first
match, which will be ACL {3} (access to everything by anyone read). Even
if you fix that problem, ACL {4} would still be unlikely to be evaluated
due to ACL {0} as well.
> Any Ideas how could solve this?
Fix your ACLs. ;) Something like:
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by
dn="cn=admin,dc=localdomain" write by dn="cn=mirrormode,dc=localdomain" read
olcAccess: {1}to attrs=loginShell,gecos by dn="cn=admin,dc=localdomain"
write by self write by * read
olcAccess: {2}to attrs=shadowLastChange by self write by
dn="cn=admin,dc=localdomain" write by * read
olcAccess: {3}to * by dn="cn=admin,dc=localdomain" write by * read
Note that "by * none" at the end of an ACL is implicit, so it's not
required to list it explicitly.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
5 years, 10 months
Replication problem with attributes
by Dennis Meyer
Hi,
i have setup a new multimaster with mirrormode = true cluster with
Debian 9 and openldap 2.4.44.
There are two Servers ldap1 and ldap2.
As its just a lab Environment there is no need to hide passwords and stuff:
/etc/ldap/slapd.d/cn=config/olcDatabase={1}mdb.ldif
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 8fb04e78
dn: olcDatabase={1}mdb
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=localdomain
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * non
e
olcAccess: {1}to attrs=loginShell,gecos by dn="cn=admin,dc=localdomain" writ
e by self write by * read
olcAccess: {2}to attrs=shadowLastChange by self write by * read
olcAccess: {3}to * by * read
olcAccess: {4}to attrs=userPassword,shadowLastChange by self write by anonym
ous auth by dn="cn=admin,dc=localdomain" write by dn="cn=mirrormode,dc=loca
ldomain" read by * none
olcLastMod: TRUE
olcRootDN: cn=admin,dc=localdomain
olcRootPW:: e1NTSEF9Z05GbEJIRHE1aTNpa0ZsYVk0WVh3VTM4SkF0VkF0b3Q=
olcDbCheckpoint: 512 30
olcDbIndex: member,memberUid eq
olcDbIndex: cn pres,sub,eq
olcDbIndex: uid pres,sub,eq
olcDbIndex: displayName pres,sub,eq
olcDbIndex: default sub
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: mail,givenName eq,subinitial
olcDbIndex: dc eq
olcDbIndex: objectClass,entryCSN,entryUUID eq
olcDbMaxSize: 1073741824
structuralObjectClass: olcMdbConfig
entryUUID: e9f1dcca-5978-1037-8f17-b1d4dc2a991d
creatorsName: cn=admin,cn=config
createTimestamp: 20171109090544Z
olcMirrorMode: TRUE
olcSyncrepl: {0}rid=001 provider=ldap://10.211.55.20:389 bindmethod=simple b
inddn="cn=mirrormode,dc=localdomain" credentials=iechi1Eid_ie:quu searchbas
e="dc=localdomain" schemachecking=on type=refreshAndPersist retry="60 +"
entryCSN: 20171109101419.176516Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20171109101419Z
Here is my Database, its on both ldap servers identical - i dumped
this on both servers and ran a diff
slapcat:
dn: dc=localdomain
objectClass: top
objectClass: dcObject
objectClass: organization
o: localdomain
dc: localdomain
structuralObjectClass: organization
creatorsName: cn=admin,dc=localdomain
entryUUID: 1854fd30-597f-1037-9872-eb46faf4f5e0
createTimestamp: 20171109094959Z
entryCSN: 20171109094959.802699Z#000000#000#000000
modifiersName: cn=admin,dc=localdomain
modifyTimestamp: 20171109094959Z
contextCSN: 20171109100725.365127Z#000000#000#000000
dn: cn=admin,dc=localdomain
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9Z05GbEJIRHE1aTNpa0ZsYVk0WVh3VTM4SkF0VkF0b3Q=
structuralObjectClass: organizationalRole
entryUUID: e9f75c72-5978-1037-8289-d381257e6532
creatorsName: cn=admin,dc=localdomain
createTimestamp: 20171109090545Z
entryCSN: 20171109090545.033599Z#000000#000#000000
modifiersName: cn=admin,dc=localdomain
modifyTimestamp: 20171109090545Z
dn: cn=mirrormode,dc=localdomain
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: mirrormode
description: Syncrepl user for mirrormode operation
structuralObjectClass: organizationalRole
entryUUID: 49734c42-5979-1037-9e9b-d338d82a2242
creatorsName: cn=admin,dc=localdomain
createTimestamp: 20171109090825Z
userPassword:: e1NTSEF9T3hzeUVnanhLTThZSDJjK3JweG1sM2pWOG5USEkwS1c=
entryCSN: 20171109100725.365127Z#000000#000#000000
modifiersName: cn=admin,dc=localdomain
modifyTimestamp: 20171109100725Z
And this is the error i get only on ldap1 after setting up replication
on both servers:
Nov 9 12:36:16 ldap1 slapd[17296]: Entry (cn=admin,dc=localdomain):
object class 'simpleSecurityObject' requires attribute 'userPassword'
Nov 9 12:36:16 ldap1 slapd[17296]: null_callback : error code 0x41
Nov 9 12:36:16 ldap1 slapd[17296]: syncrepl_entry: rid=001 be_add
cn=admin,dc=localdomain failed (65)
Nov 9 12:36:16 ldap1 slapd[17296]: do_syncrepl: rid=001 rc 65 retrying
Any Ideas how could solve this?
Best regards
Dennis
5 years, 10 months
Re: disk write on old 2.4.9
by Howard Chu
richard lucassen wrote:
> On Wed, 8 Nov 2017 11:35:40 +0100
> richard lucassen <mailinglists(a)lucassen.org> wrote:
>
>> Is there a way to limit these disk writes? I didn't touch the standard
>> Ubuntu settings, except for the usual settings like SSL.
>
> I found an old setting that seems to do the job:
>
> shm_key 100
>
> In that old setting it was set to 100, the man page says:
>
> shm_key _integer_
> Specify a key for a shared memory BDB environment. By default the BDB
> environment uses memory mapped files. If a non-zero value is
> specified, it will be used as the key to identify a shared memory
> region that will house the environment.
>
> Is that integer a sort of label or does it mean something else?
It means what it says - it is a shared memory key. Read the ipcs(1) manpage.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5 years, 10 months
disk write on old 2.4.9
by richard lucassen
Hello list,
I have an ***old*** Ubuntu-8.04 running 2.4.9. I know, this is old, but
there are no security issues here. This slapd contains a small database
which is modified rarely. OTOH, there are many read operations. The
backend is hdb. As these boxes are running on a CF-disk I'd like to
limit disk writes, but when the database is queried, the backend is
being updated (slapd started at 11:25, read operation at 11:31):
# ls -altr /var/lib/ldap/
total 768
drwxr-xr-x 3 root root 4096 2013-11-11 20:28 ..
-rw-r--r-- 1 openldap openldap 96 2017-11-08 09:36 DB_CONFIG
-rw------- 1 openldap openldap 8192 2017-11-08 11:25 objectClass.bdb
-rw------- 1 openldap openldap 8192 2017-11-08 11:25 dn2id.bdb
-rw------- 1 openldap openldap 123193 2017-11-08 11:25 log.0000000001
-rw------- 1 openldap openldap 65536 2017-11-08 11:25 id2entry.bdb
drwx------ 2 openldap openldap 4096 2017-11-08 11:25 .
-rw-r--r-- 1 openldap openldap 2048 2017-11-08 11:25 alock
-rw------- 1 openldap openldap 24576 2017-11-08 11:31 __db.005
-rw------- 1 openldap openldap 565248 2017-11-08 11:31 __db.004
-rw------- 1 openldap openldap 98304 2017-11-08 11:31 __db.003
-rw------- 1 openldap openldap 2629632 2017-11-08 11:31 __db.002
-rw------- 1 openldap openldap 8192 2017-11-08 11:31 __db.001
Is there a way to limit these disk writes? I didn't touch the standard
Ubuntu settings, except for the usual settings like SSL.
Richard.
--
richard lucassen
http://contact.xaq.nl/
5 years, 11 months
