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, 7 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, 10 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, 10 months
sql backend & upate data
by Arianna Milazzo
Hello!
I use openLDAP with a sql backend.
I use mySQL with InnoDB engine.
Well, if I modify a data on db, I can't see the new value on openLDAP until
I restart it. :O
I can't restart openLDAP every time I modify something!
Any solution?
Thanks,
Arianna
4 years, 11 months
Performance problem with slapd instances.
by Saurabh Lahoti
Dear,
We've started observing strange & peculiar performance behavior for slapd
instances. While ldap bind response is more than 1.5 second on one server
then on another it's just 0.006 seconds.
Both the servers have similar OS, system resources & ldap version.
OS: RHEL 6.9
LDAP: 2.4.44
Backend: bdb
Could you please suggest some probable causes..?
Thanks & Kind Regards,
Saurabh Lahoti.
4 years, 11 months
replicating memberOf attribute
by Chris
Hi,
We are using a provider and three consumers that are not syncing the
memberOf attributes of inetOrgPerson entries.
memberof and refint modules are loaded on the provider and
inetOrgPersons' memberOf attributes are correctly updated on the provider.
How can I troubleshoot this?
Thanks.
Chris.
4 years, 11 months
Debian getting rid of nis and adding rfc2307bis
by malcolm moore
Are there any instructions for this anywhere ?
I've been seaching and struggling now for several
days and I can't work out how to do it. It can't
be as difficult as i am making it
Ta
Mal
4 years, 11 months
Re: OPenLDAP instances frequently crashes
by Saurabh Lahoti
Dear,
Just before crash below message logged into system logs of servers:
Jun 11 23:01:37 musang kernel: Out of memory: Kill process 22184 (slapd)
score 888 or sacrifice child
Jun 11 23:01:37 musang kernel: Killed process 22184, UID 0, (slapd)
total-vm:52226320kB, anon-rss:37170216kB, file-rss:1044kB
Although, my physical RAM size is 38 GB & actual database size is 32 GB.
Why is it not managing memory appropriately with the help from swap...?
----
*Thanks & Kind Regards,*
Saurabh LAHOTI.
On Wed, 13 Jun 2018 at 15:57, Quanah Gibson-Mount <quanah(a)symas.com> wrote:
> --On Wednesday, June 13, 2018 8:56 AM +0200 Michael Ströder
> <michael(a)stroeder.com> wrote:
>
> > On 06/12/2018 06:15 AM, Saurabh Lahoti wrote:
> >> Frequently, our OpenLDAP instances crashes thereby leading us into
> severe
> >> disastrous results & outages for business.
> >>
> >> While going through slapd logs, it always says " bdb_db_open: database:
> >> unclean shutdown detected; attempting recovery"
> >>
> >> What could possibly go wrong here..?
> >
> > Which OpenLDAP version are you using? Which OS?
>
> What does openldap log before it crashes?
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
4 years, 11 months
Meta backend and attributes mapping
by ROY Grégory
Hello,
I try somehow to do what I explain below. But without success...
I think I'm doing badly for the attribute mapping, maybe it would be better with the rwm overlay?
Could someone put me on the right track?
-> I have this :
----------------------------------------------------------------------------------------------------------------------------------------------------
dc=domain1,dc=local dc=domain2, dc=local
|__ou=users |__ou= apps
|__ou=standard |__ou= app1
|__cn = JOHN DOE | |__cn = DOEJOHN
|__ att: sAMAccountName= DOEJOHN | |__att: Appval=valuex
|__att: phonenumber=0102030405 |__ou= app2
|__cn= DOEJOHN
|__att: Appval=valuey
----------------------------------------------------------------------------------------------------------------------------------------------------
-> and i wan't to do this :
----------------------------------------------------------------------------------------------------------------------------------------------------
dc=meta,dc=local
|_ou=users
|_cn= DOEJOHN
|_att: phonenumber=0102030405
|_att: App1val=valuex
|_att: App2val=valuey
----------------------------------------------------------------------------------------------------------------------------------------------------
-> I do it this way, with the meta backend :
----------------------------------------------------------------------------------------------------------------------------------------------------
#########################################################################
defaultsearchbase dc=meta,dc=local
### database META #####################################################
database meta
suffix dc=meta,dc=local
rootdn "cn=admin,dc=meta,dc=local"
rootpw secret
## AD1 USERS ###
uri "ldap://ad.domain1.local:389/ou=users,dc=meta,dc=local"
suffixmassage "ou=users,dc=meta,dc=local" "ou=users,ou=standard,dc=domain1,dc=local"
idassert-bind bindmethod=simple
binddn="CN=reader,DC=domain1,DC=local"
credentials="password"
mode=self
idassert-authzFrom "dn.regex:.*"
access to *
by * read
map attribute uid sAMAccountname
## AD2 APP 1 ###############
uri "ldap://ad.domain2.local:389/ou=users,dc=meta,dc=local"
suffixmassage "ou=users,dc=meta,dc=local" "ou=app1,ou=apps,dc=domain2,dc=local"
idassert-bind bindmethod=simple
binddn="CN=reader,DC=domain2,DC=local"
credentials="password"
mode=self
idassert-authzFrom "dn.regex:.*"
access to *
by * read
map attribute uid cn
map attribute App1val Appval
## AD2 APP 2 ###############
uri "ldap://ad.domain2.local:389/ou=users,dc=meta,dc=local"
suffixmassage "ou=users,dc=meta,dc=local" "ou=app2,ou=apps,dc=domain2,dc=local"
idassert-bind bindmethod=simple
binddn="CN=reader,DC=domain2,DC=local"
credentials="password"
mode=self
idassert-authzFrom "dn.regex:.*"
access to *
by * read
map attribute uid cn
map attribute App2val Appval
lastmod off
----------------------------------------------------------------------------------------------------------------------------------------------------
I get this result, and it does not really correspond to what I want to get .... :
----------------------------------------------------------------------------------------------------------------------------------------------------
[root@server openldap]# ldapsearch -x "uid=DOEJOHN" -H 'ldap://localhost/' -b dc=meta,dc=local -LLL phonenumber App1val App2val
dn: cn=JOHN DOE,ou=users,dc=meta,dc=local
phonenumber: 0102030405
dn: cn=DOEJOHN,ou=users,dc=meta,dc=local
App1val: valuex
dn: cn=DOEJOHN,ou=users,dc=meta,dc=local
App2val: valuey
----------------------------------------------------------------------------------------------------------------------------------------------------
Regards,
--
Greg
4 years, 11 months
warning about rootdn privileges
by Chris Hoogendyk
When one's Google Foo fails, turn to an appropriate list.
I would like to get rid of these warnings (rootdn is always granted unlimited privileges). First,
it's annoying that our cron always spits back an email. Second, one assumes that where there is a
warning, there might be something that should be done differently. I've tried searching, but it
seems this warning always comes up in conjunction with some other error that someone is concerned
about. This particular warning is always ignored in the discussion of the error of concern as far as
I have been able to find.
5b2472a5 /usr/local/etc/openldap/slapd.conf: line 170: rootdn is always granted unlimited privileges.
5b2472a5 /usr/local/etc/openldap/slapd.conf: line 293: rootdn is always granted unlimited privileges.
5b2472a5 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable
5b2472a5 /usr/local/etc/openldap/slapd.conf: line 170: rootdn is always granted unlimited privileges.
5b2472a5 /usr/local/etc/openldap/slapd.conf: line 293: rootdn is always granted unlimited privileges.
5b2472a5 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable
I don't think I need to include anything about my slapd.conf, because this is more a general
question of what causes this warning, and what is the recommended guidance for avoiding it.
--
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geosciences Departments
(*) \(*) -- 315 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<hoogendyk(a)bio.umass.edu>
---------------
Erdös 4
4 years, 11 months
