role based authorization -> dynacl module?
by Daniel Tröder
Hello everyone,
I am in the process of implementing a role concept via ACLs and hope for
a hint so that I don't invent the wheel a second time.
Specifically, it is about identity management for schools. A user
(object) can have several roles in multiple schools. Permissions on
other LDAP objects can thus differ depending on the role(s) the user and
the object have in the same school(s).
For example, a user could have been assigned the following roles that
are scattered over several schools:
→ "Teacher" in school 1
→ "School admin" in school 2
→ "Parent" in school 3
→ both "Teacher" and "Staff" in school 4
ACLs should now be defined accordingly, e.g.
→ the role "teacher" at school X can reset the password for the role
"student" at school X
→ the role "teacher" at school X *cannot* reset the password for the
role "student" of school Y
→ the role "school administrator" at school X can reset the password for
the roles "student" and "teacher" at school X
→ ...
So far I have not seen any way to map such a construct via groups or
sets without including a separate ACL for each group, which is a
performance issue.
Is there another way to map the role concept besides implementing an own
dynacl module?
Greetings,
Daniel
4 years, 5 months
back-mdb and alias dereferencing
by Henrik Bohnenkamp
Hi,
I would like to bring up the problem with back-mdb and
alias-dereferening again. There is Bug ITS#7657 for this already, and
in
http://www.openldap.org/lists/openldap-technical/201504/msg00008.html
the problem was also addressed. Probably in other places as well, but
I did not find anything else in the archives.
I would like to reconfigure all my LDAP clusters to use back-mdb,
however, I can't: my LDAP tree has about 2 Mio entries, 600000 of
which are alias entries.
I observe that when using back-mdb and making search request with
search scope "sub" and deref=always, than this search request will
take seconds before a response... in contrast, with deref=never, the
same search request takes only millisecs. It does not matter whether
there are aliases in the search scope or not... with deref=always it
always takes seconds, each request keeping one CPU thread very busy.
So if many requests come in with sub/always (which unfortunately
happens a lot because many LDAP clients just set deref=always as a
default) it is a sure way to bring down an LDAP cluster configured with
back-mdb.
The problem has haunted me for a while (incidents, incidents :-), and
I have tried to find out where it comes from. I would like to share my
conjectures here.
A search request with sub/always eventually ends up in the function
search_aliases(..), located in back-mdb/search.c (code/linenumbers is
from v2.4.46 ):
157 /* Find all aliases in database */
158 MDB_IDL_ZERO( aliases );
159 rs->sr_err = mdb_filter_candidates( op, isc->mt, &af, aliases,
160 curscop, visited );
161 if (rs->sr_err != LDAP_SUCCESS || MDB_IDL_IS_ZERO( aliases )) {
162 return rs->sr_err;
163 }
164 oldsubs[0] = 1;
165 oldsubs[1] = e_id;
166
167 MDB_IDL_ZERO( visited );
168 MDB_IDL_ZERO( newsubs );
169
170 cursoro = 0;
171 ido = mdb_idl_first( oldsubs, &cursoro );
172
173 for (;;) {
174 /* Set curscop to only the aliases in the current scope. Start with
175 * all the aliases, then get the intersection with the scope.
176 */
177 rs->sr_err = mdb_idscope( op, isc->mt, e_id, aliases, curscop );
After adding a bit of extra debug code, I could see in the logs that
the time is actually spent in line 177, i.e. the mdb_idscope function.
What I believe is happening is the following: in line 159 the index
list of all aliases in the DB is constructed and put into the
"aliases" list. The list comes from the objectClass index, but since
there are so many alias entries, the index contains not an explicit
list, but a range... a range that covers basically *all* 2 Mio entries
in the DB. (this happens also with the hdb backend, so the fact that
"aliases" is a range is perhaps part, but not cause of the problem).
Then the for loop is entered in 173, and mdb_idscope in 177 is
called. The idea there is to compute the intersection of alias list
"aliases" and search scope, i.e. get all aliases that are in the
actual search scope.
This is done by walking through the 2 millions indexes represented by
the range in "aliases", and deciding whether the id is in the scope or
not. This, if I understand correctly, by walking up the LDAP tree from
leaf towards root (actually walking up the structure of the dn2id DB)
... if we encounter the search base on the way, the alias is part of
the search scope, if we reach the root, then not.
Computing this intersection is what costs time, and it does not
depend on whether the intersection is empty or not.
Apparently it is done differently in back_hdb and by extension,
back_bdb. I have not analysed that code there in detail but I believe
the intersection is computed by actually looking at 2 different ID
lists, one containing the aliases (range) again, the other one the
actual IDs of the search scope. Which, it appears, is more efficient.
So the problem seems to be to compute the relevant aliases to start
expanding from. The way it is done now the complexity seems to be
linear in the number of aliases, if not number of entries on the LDAP
tree.
For my own use cases at least it would be much more efficient to just
do a tree traversal of the search scope, pick up the relevant aliases
and put them in the list. I believe even for large trees this would
work quite well... if I search my whole tree for entries with
objectClass=alias (deref=never, of course), this is amazingly fast. I
am currently looking into how something like that could be
implemented, but I need to dive much deeper in the code before I could
come up with something worth considering.
What are the views of the developers on this? Does the analysis sound
plausible? Could a fix be easily obtained?
I'm willing to try out any patch thrown my way. Somewhere is written
that mdb will replace hdb/bdb eventually ... I believe this problem
needs a fix before that can happen.
Henrik
--
Henrik Bohnenkamp
Senior Sysadmin
Linux & Applications Operation
United Internet Corporate Services GmbH | Brauerstraße 50 | 76135 Karlsruhe | Germany
Phone: +49 721 91374 - 4159
E-mail: hbohnenkamp atatatat united-internet.de | Web: www.united-internet.de
Amtsgericht Montabaur / HRB 23031
Geschäftsführer: Verena Amann, Markus Kadelke, Frank Krause, Guido Mannshausen
Member of United Internet
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient of this e-mail, you are hereby
notified that saving, distribution or use of the content of this
e-mail in any way is prohibited. If you have received this e-mail in
error, please notify the sender and delete the e-mail.
4 years, 8 months
Fixing slapo-nops (ITS#8759)
by manu＠netbsd.org
Hello
Following ITS#8759, I am looking for ideas about how to fix slapo-nops.
This overlays suppress nilpotent operations that replace an attribute
values by the same values. The code is in
contrib/slapd-modules/nops/nops.c
The problem is that slapo-nops assumes it can free the nilpotent struct
Modifications after removing them from the list, but for instande
slapo-memberof uses struct Modifications allocated on the stack.
Not freeing in slapo-nops is not a fix, since unlinked struct
Modifications will not be freed anywhere else, and we will get a memory
leak.
Would it make sense to add a SLAP_MOD_ONSTACK flag in struct
Modification's sm_flags so that we can tell the difference? Any other
idea?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
4 years, 8 months
Setting up syncrepl
by Fabiano Sidler
Hi folks!
I'm trying to set up a working multi-master syncrepl. Both servers I can
connect to (using Apache Directory Studio), but nothing is synced. Starting
slapd with -d 16384 -d 32768 (sync + none) only produces the following logs
on both servers:
---
5b0b0988 do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT
5b0b0988 do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT
5b0b0992 do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT
---
This is my configuration:
---
dn: cn=config
objectClass: olcGlobal
cn: config
olcPidFile: /var/run/openldap/slapd.pid
olcTLSCACertificateFile: /usr/local/etc/openldap/ca
olcTLSCertificateFile: /usr/local/etc/openldap/crt
olcTLSCertificateKeyFile: /usr/local/etc/openldap/key
olcAuthzRegexp: {0}"gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=admin,$basedn"
olcAuthzRegexp: {1}"uid=root,cn=$domain,cn=gssapi,cn=auth" "cn=admin,$basedn"
olcAuthzRegexp: {2}"uid=dc(1|2),cn=$domain,cn=gssapi,cn=auth" "cn=admin,$basedn"
olcServerID: 1 ldap://dc1.$domain/
olcServerID: 2 ldap://dc2.$domain/
olcSaslRealm: $domain
olcLogLevel: 0
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
include: file:///usr/local/etc/openldap/schema/core.ldif
include: file:///usr/local/etc/openldap/schema/cosine.ldif
include: file:///usr/local/etc/openldap/schema/inetorgperson.ldif
include: file:///usr/local/etc/openldap/schema/dyngroup.ldif
include: file:///usr/local/etc/openldap/schema/ppolicy.ldif
include: file:///usr/local/etc/openldap/schema/nis.ldif
include: file:///usr/local/etc/openldap/schema/hdb.ldif
include: file:///usr/local/etc/openldap/schema/samba.ldif
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/local/libexec/openldap
olcModuleLoad: {0}back_mdb
olcModuleLoad: {2}syncprov
olcModuleLoad: {2}rwm
olcModuleLoad: {3}back_relay
#olcModuleLoad: {4}smbk5pwd
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by * none
olcRootDN: $rootdn
olcSyncrepl: {0}rid=001 provider=ldap://dc1.$domain/ bindmethod=simple binddn="cn=admin,$basedn" credentials="secret" searchbase="cn=config" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1
olcSyncrepl: {1}rid=002 provider=ldap://dc2.$domain/ bindmethod=simple binddn="cn=admin,$basedn" credentials="secret" searchbase="cn=config" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1
olcMirrorMode: TRUE
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcSuffix: $basedn
olcRootDN: cn=admin,$basedn
olcDbDirectory: /var/db/openldap/$domain
olcSyncrepl: {0}rid=004 provider=ldap://dc1.$domain/ bindmethod=simple binddn="cn=admin,$basedn" credentials="secret" searchbase="$basedn" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1
olcSyncrepl: {1}rid=005 provider=ldap://dc2.$domain/ bindmethod=simple binddn="cn=admin,$basedn" credentials="secret" searchbase="$basedn" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1
olcMirrorMode: TRUE
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
---
What's the problem?
Best wishes,
Fabiano
4 years, 9 months
Re: removing ppolicy overlay
by Frank Swasey
The lack of responses indicates that people either do not use ppolicy or once used, they never remove it.
For future reference here's the procedure that I've worked up:
shutdown slapd on all MMR members
slapcat the database
edit the database to remove all "pwd*" attributes and all entries that are pwd* objectClass
edit the slapd.conf file (if you are using slapd.d you are on your own)
replace the database (delete, and slapadd)
Empty the accesslog database if you are using that
start slapd
Copy your edited database to the rest of your servers and use the tried and true "nuke & repave" process to delete the existing database, edit the config, slapadd the edited database
- Frank
> On Apr 16, 2018, at 11:09, Frank Swasey <Frank.Swasey(a)uvm.edu> wrote:
>
> Is there a recommended way to discontinue the use of the ppolicy overlay?
>
> The only way I've found that works is to stop the ldap server and using slapcat/edit/slapadd eradicate all the ppolicy attributes (combined with removing the ppolicy overlay and schema from the slapd.conf file).
>
> I'm attempting this on RHEL7 with OpenLDAP 2.4.46 (local built).
>
> Thanks,
> - Frank
4 years, 9 months
Duplicate Password Policies and Can Not Rest User Password
by Daniel Howard
Hello,
I have two issues. One is I gave myself redundant *ppolicy* overlays I
can't delete. The other is I don't know why I can not reset a user's
password.
The first is that in a rush, late at night, I ended up with multiple
(duplicate) Password Policy Overlays. I went back and tried to delete
these, but:
$ *sudo ldapmodify -Q -Y EXTERNAL -H ldapi:///*
dn: olcOverlay={5}ppolicy,olcDatabase={1}hdb,cn=config
changetype: delete
deleting entry "olcOverlay={5}ppolicy,olcDatabase={1}hdb,cn=config"
ldap_delete: Server is unwilling to perform (53)
It looks like this is a known consideration, per
http://www.zytrax.com/books/ldap/ch6/slapd-config.html#use-overlays and
that I'll have to cowboy the server config to get the redundant overlays
removed.
root@ldap0:~# *slapd -V*
@(#) $OpenLDAP: slapd (Ubuntu) (May 31 2017 21:52:16) $
buildd@lgw01-30
:/build/openldap-tnOaja/openldap-2.4.31/debian/build/servers/slapd
Okay, so what is that overlay? Pretty simple stuff:
dn: olcOverlay={2}ppolicy,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {2}ppolicy
olcPPolicyDefault: cn=passwordDefault,ou=Policies,dc=qxxxxxxxxd,dc=com
olcPPolicyHashCleartext: FALSE
olcPPolicyUseLockout: FALSE
olcPPolicyForwardUpdates: FALSE
(But defined four times ... {2..5})
What is the problem, then? The problem is I can not set a user's password.
root@ldap0:~#
*/usr/bin/ldappasswd -y /etc/ldapscripts/ldapscripts.passwd -D
cn=admin,dc=qxxxxxxxxd,dc=com -x -H ldap://localhost -T /tmp/ldapsetpasswd
uid=zachary,ou=People,dc=qxxxxxxxxd,dc=com*
Result: No such attribute (16)
Say what?
dn: uid=zachary,ou=People,dc=qxxxxxxxxd,dc=com
structuralObjectClass: account
entryUUID: cd55cc80-f8a5-1037-976e-9da738d41e24
creatorsName: cn=admin,dc=qxxxxxxxxd,dc=com
createTimestamp: 20180530223739Z
pwdFailureTime: 20180530223741Z
pwdFailureTime: 20180530224243Z
pwdFailureTime: 20180530224244Z
pwdFailureTime: 20180530224306Z
pwdFailureTime: 20180530224307Z
pwdFailureTime: 20180530224354Z
pwdFailureTime: 20180530224538Z
pwdFailureTime: 20180530224541Z
entryCSN: 20180530224541.157285Z#000000#000#000000
modifiersName: cn=admin,dc=qxxxxxxxxd,dc=com
modifyTimestamp: 20180530224541Z
entryDN: uid=zachary,ou=People,dc=qxxxxxxxxd,dc=com
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
Maybe the user is locked out?
root@ldap0:~# *ldapmodify -Q -Y EXTERNAL -H ldapi:/// -D
cn=admin,dc=qxxxxxxxxd,dc=com*
dn: uid=zachary,ou=People,dc=qxxxxxxxxd,dc=com
changetype: modify
delete: pwdFailureTime
modifying entry "uid=zachary,ou=People,dc=qxxxxxxxxd,dc=com"
ldap_modify: Constraint violation (19)
additional info: pwdFailureTime: no user modification allowed
Q1: Any bright idea on removing the redundant ppolicy overlays?
Q2: Any bright idea on what's up with resetting zachary's password?
Thanks,
-danny
--
http://dannyman.toldme.com
4 years, 9 months
MDB_INVALID: File is not an LMDB file
by Chris Trenkamp
My program suddenly started returning this error, "MDB_INVALID: File
is not an LMDB file" whenever it tries to open the database file. It
is running on Windows.
I made a copy of the database, compiled lmdb with MDB_DEBUG set to 2
and ran this program:
#include <stdio.h>
#include "lmdb.h"
int main(int argc, char* argv[]) {
int rc;
MDB_env *env;
rc = mdb_env_create(&env);
printf("%d\n", rc);
rc = mdb_env_open(env, "./brokedb", 0, 0644);
printf("%d\n", rc);
}
And it gave this output:
0
mdb_env_read_header:4040 page 0 not a meta page
-30793
Does anyone know how this might have happened, and things to look for
in my program that might have caused this? Is there a way to recover
the data from the file?
Thanks.
4 years, 9 months
search abandoned by pagedResult nentries=0
by jehan procaccia INT
Hello
I have a software (zimbra) that request my openldap server regularly in
order to update the "Global Address List" (for mail auto-completion)
It request the openldap with a simple search filter after binding
however, although it seems to start fine, the result ends with
May 24 20:40:48 ldapmt slapd[16434]: conn=1003 op=2 SEARCH RESULT
tag=101 err=0 nentries=0 text=search abandoned by pagedResult size=0
nentries=0 and no result is returned
I do see the request in the ldap logs
May 24 20:40:48 ldapmt slapd[16434]: conn=1003 op=2 SRCH
base="dc=telecom,dc=fr" scope=2 deref=3 filter="(|(mail=*)(sn=*))"
If I do the exact same request (binddn, bindpassw, searchbase, ldapuri,
scope, deref, filter) from the zimbra server itself,
I do get a correct result with nentries=6505
I don't understand why when the zimbra software does the same request,
it fails with nentries=0 text=search abandoned by pagedResult !?
what is that message "search abandoned by pagedResult" means ?
how can I further debug that problem ? ( I already set loglevel to acl
filter stats )
Regards
4 years, 9 months
.so version numbers for dlopen'd objects
by Paul B. Henson
I'm trying to get the OpenBSD openldap port updated to use modules,
currently it just builds everything into a monolithic binary. They are
objecting to the existence of the version number in the shared objects for
the modules:
-rwxr-xr-x 1 henson henson 1773576 May 21 12:54 back_bdb-2.4.so.2.10.7
-rwxr-xr-x 1 henson henson 864 May 21 12:54 back_bdb.la
lrwxrwxrwx 1 henson henson 22 May 21 12:54 back_bdb.so ->
back_bdb-2.4.so.2.10.7
They say that shared objects which are intended to be dlopen'd, as opposed
to linked to, should not include version numbers, and it should look like:
-rwxr-xr-x 1 henson henson 1773576 May 21 12:54 back_bdb-2.4.so
-rwxr-xr-x 1 henson henson 864 May 21 12:54 back_bdb.la
What is the openldap developer perspective on this?
Thanks.
4 years, 10 months
