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
Re: OpenLDAP instances crashes
by Saurabh Lahoti
Dear Leo,
We tried the steps mentioned below using the ReOpenLDAP package provided by
you.
But, we're start at the very first step while running bootstrap.sh &
encountered below errors:
root@pygarg # ./bootstrap.sh
./bootstrap.sh: line 39: git: command not found
Oops, cleanup failed ;(
Could you please guide us further into this..?
----
*Thanks & Kind Regards,*
Saurabh LAHOTI.
*Ideas enlighten Innovation**!!!*
Please consider the environment before printing this mail..!!
On Thu, 23 Aug 2018 at 23:17, Леонид Юрьев <leo(a)yuriev.ru> wrote:
> Hi, Saurabh.
>
> Your custom overlay "mobiuniquemember" now intergated into ReOpenLDAP
> (mobiuniquemember branch).
> Please check it:
>
> git clone https://github.com/leo-yuriev/ReOpenLDAP.git -b mobiuniquemember
> cd ReOpenLDAP
> ./bootstrap.sh
> ./configure --enable-contrib [other relevan options]
> make install
>
> Regards,
> Leonid.
>
>
> ср, 22 авг. 2018 г. в 18:04, Леонид Юрьев <leo(a)yuriev.ru>:
>
>> You could submit source code of your custom overlay to
>> https://github.com/leo-yuriev/ReOpenLDAP, i.e. pull-request into the
>> 'devel' branch.
>>
>> Then I will try fix it and merge-in, in success case you will be able to
>> build and use it with ReOpenLDAP.
>>
>>
>> Regards,
>> Leonid.
>>
>> ср, 22 авг. 2018 г., 17:37 Saurabh Lahoti <saurabh.astronomy(a)gmail.com>:
>>
>>> Dear,
>>>
>>> What is you're recommendation to fix this problem on our side..? It's
>>> been haunting our operational activities on daily basis.. 😓
>>> ----
>>>
>>> *Thanks & Kind Regards,*
>>> Saurabh LAHOTI.
>>> *Mob: +32.499.82.37.88*
>>> *Ideas enlighten Innovation**!!!*
>>> Please consider the environment before printing this mail..!!
>>>
>>>
>>>
>>>
>>>
>>> On Fri, 17 Aug 2018 at 16:43, Brian Reichert <reichert(a)numachi.com>
>>> wrote:
>>>
>>>> On Thu, Aug 16, 2018 at 02:00:20PM +0200, Saurabh Lahoti wrote:
>>>> > Dear,
>>>> >
>>>> > Today, received below error in /var/log/messages with OpenLDAP
>>>> instance
>>>> > crashing.
>>>>
>>>> That looks like either:
>>>>
>>>> - You have a bad SIM (very unlikely)
>>>> - You have a corrupted uniquemember.so.0.0.0 shared library.
>>>> - You may have conflated OpenLDAP packages installed that have a
>>>> critical
>>>> incompatibility amidst the installed binaries/libraries.
>>>>
>>>> It did write a core file; there are many tutorials about exploring
>>>> a core file to help understand why the segfault occurred.
>>>>
>>>> >
>>>> > Aug 16 13:21:07 muledeer kernel: slapd[29253]: segfault at 0 ip
>>>> > 00007fbeddf3af09 sp 00007fb72effc480 error 4 in
>>>> > uniquemember.so.0.0.0[7fbeddf3a000+2000]
>>>> > Aug 16 13:21:08 muledeer abrt[24629]: Saved core dump of pid 16470
>>>> > (/usr/app/ldap/openldap2.4.46/libexec/slapd) to
>>>> > /var/spool/abrt/ccpp-2018-08-16-13:21:07-16470 (472973312 bytes)
>>>> > Aug 16 13:21:08 muledeer abrtd: Directory
>>>> 'ccpp-2018-08-16-13:21:07-16470'
>>>> > creation detected
>>>> > Aug 16 13:21:08 muledeer abrtd: Executable
>>>> > '/usr/app/ldap/openldap2.4.46/libexec/slapd' doesn't belong to any
>>>> package
>>>> > and ProcessUnpackaged is set to 'no'
>>>> > Aug 16 13:21:08 muledeer abrtd: 'post-create' on
>>>> > '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470' exited with 1
>>>> > Aug 16 13:21:08 muledeer abrtd: Deleting problem directory
>>>> > '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470'
>>>> >
>>>> >
>>>> > Could you please guide us in finding probable root of this error..?
>>>> > ----
>>>> >
>>>> > *Thanks & Kind Regards,*
>>>> > Saurabh LAHOTI.
>>>> > *Ideas enlighten Innovation**!!!*
>>>> > Please consider the environment before printing this mail..!!
>>>>
>>>> --
>>>> Brian Reichert <reichert(a)numachi.com>
>>>> BSD admin/developer at large
>>>>
>>>
4 years, 8 months
duplicated naming context when using syncrepl proxy
by Jochen Keutel
Hallo,
I'm using OpenLDAP on Debian 9 (2.4.44) and started to configure
replication: szenario syncrepl proxy (push based replication, see 18.3.5
in OpenLDAP Admin Guide - "primary directory also contains back-ldap
databases"). Configuring the LDAP backend leads unfortunately to a root
DSE showing the same name context twice:
namingContexts: dc=keutel,dc=de
namingContexts: dc=keutel,dc=de
Is this a known problem? Esp. this stops PHPLDAPAdmin from working: It
prints a lot of PHP arrays in this case.
I've set "hidden on" for this backend but the problem remains.
My configuration:
1. slapd.conf on server1 (master):
database ldap
hidden on
suffix "dc=keutel,dc=de"
rootdn "cn=admin,dc=keutel,dc=de"
uri ldaps://server2/
lastmod on
restrict all
acl-bind bindmethod=simple
binddn="cn=replication,dc=keutel,dc=de"
credentials=secret
syncrepl rid=001
provider=ldaps://server1/
binddn="cn=replication,dc=keutel,dc=de"
bindmethod=simple
credentials=secret
searchbase="dc=keutel,dc=de"
type=refreshAndPersist
retry="5 5 300 5"
2. converting this to dynamic config using slaptest gives the following
entry:
dn: olcDatabase={2}ldap
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: {2}ldap
olcHidden: TRUE
olcSuffix: dc=keutel,dc=de
...
3. starting slapd with this dynamic configuration
4. reading rootDSE: attribute namingContexts occurs twice with the same
value.
How can this be solved?
Regards
Jochen.
4 years, 9 months
Problem with ACLs
by Bill Bradford
Trying to give a single user "read only" access to everything in
the database including userPassword info.
Here's the LDIF file I'm using w/ldapmodify:
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange
by dn="cn=Manager,dc=domain,dc=com" write
by dn.exact="uid=romanager,ou=Users,dc=domain,dc=com" read
by anonymous auth
by self write
by * none
olcAccess: {1}to dn.base=""
by * read
olcAccess: {2}to *
by dn="cn=Manager,dc=domain,dc=com" write
by * read
However, authenticating as uid=romanager,ou=Users,dc=domain,dc=com
lets that user read his own password hash, but nobody else's. In
other words it's authenticating just like any other user, and it's
as if the
by dn.exact="uid=romanager,ou=Users,dc=domain,dc=com" read
line is being ignored. The change is being applied as I've looked
at the database files for the config. I've tried restarting slapd, etc.
Any suggestions?
@(#) $OpenLDAP: slapd 2.4.44 (Aug 4 2017 14:23:27) $
Bill
--
Bill Bradford
Houston, Texas USA
4 years, 9 months
empty reqmod attribute
by David Coutadeur
Hi,
I am experiencing a segfault on an OpenLDAP 2.4.44 instance.
The architecture is:
- 2 OpenLDAP
- multimaster mirrormode
- delta-syncrepl
The error seems to be in the syncrepl process, in a particular accesslog
entry.
When I give a look to the entry, I realize that some attributes in
reqmod are empty, which seems strange because the value can't be empty
in the directory. For example:
reqMod: inetUserStatus:=
Does anyone know if this behaviour is normal, and what is happening?
Thanks in advance.
David
4 years, 9 months
Unique overlay confusing
by Ervin Hegedüs
Hi there,
I've followed the docs (and some forums), and made these
modifications:
(OpenLDAP doc:
http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness)
dn: cn=module,cn=config
cn: module
objectClass: olcModuleList
olcModulePath: /usr/lib/ldap/
olcModuleLoad: unique.la
dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcUniqueConfig
olcOverlay: unique
olcUniqueAttribute: uid
olcUniqueAttribute: mail
olcUniqueAttribute: uidNumber
olcUniqueAttribute: sn
olcUniqueAttribute: cn
but I still can set the mail attribute as same e-mail address
for two different users.
I've tried this config too:
dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcUniqueConfig
olcOverlay: unique
olcUniqueUri: ldap:///?uid?sub?
olcUniqueUri: ldap:///?mail?sub?
olcUniqueUri: ldap:///?uidNumber?sub?
olcUniqueUri: ldap:///?sn?sub?
olcUniqueUri: ldap:///?cn?sub?
What em'I missing?
Thanks,
a.
4 years, 9 months
Call fo Papers - Paris Open Source Summit
by Clément OUDOT
Hello,
There is an important event about free software and open source in
Paris in december, with topics about identity management. The CFP is
here: http://cfp.opensourcesummit.paris/
It should close friday but I think the deadline will be reported.
Feel free to propose technical talks or customer success stories (for
example migration from proprietary softwares to free softwares).
Hope to see you soon,
Clément.
4 years, 9 months
Recommended way to transfer data from one cluster to the other?
by Karsten Heymann
Hi,
We're replacing our aging LDAP Cluster (Debian 7, slapd 2.4.40, 2
masters with syncrepl and mirror mode, 2 slaves) with a new cluster of
the same layout (2.4.44, probably 2.4.46, on Debian 9). I now wonder
what the best way is to transfer the data from the old to the new
cluster. As far as I can see, we have three options to transfer the
data:
1) ldapsearch + ldapadd
2) slapcat + slapadd
3) Configure a temporary syncrepl rule on the new masters to fetch the
data from the old ones.
Which one is the preferred one? I would assume slapcat and slapadd,
but I must admit I have not fully understood the purpose of the -S and
-w switch. Should we somehow filter the *CSN-fields from the exported
ldif as I assume they make no sense for the new cluster or are they
automatically fixed when using slapadd with said options?
I'm sorry if this topic has been discussed here before but my
(probably lacking) google skills did not return anything obvious.
Best regards
Karsten
4 years, 9 months
Re: Recommended way to transfer data from one cluster to the other?
by Quanah Gibson-Mount
--On Wednesday, August 29, 2018 12:50 PM +0200 Karsten Heymann
<karsten.heymann(a)gmail.com> wrote:
> Hi Quanah,
>
> Am Di., 28. Aug. 2018 um 21:05 Uhr schrieb Quanah Gibson-Mount
> <quanah(a)symas.com>:
>> --On Tuesday, August 28, 2018 9:48 PM +0200 Karsten Heymann
>> <karsten.heymann(a)gmail.com> wrote:
>>
>> > Which one is the preferred one?
>>
>> Indeed, slapcat + slapadd is the preferred route.
>
> Great, so I was not too far off.
>
>> d) slapadd this second export to the rest of the new cluster
>
> I gess with no extra options regarding replication this time?
Correct. Can just use "-q" at this point.
>> * <http://www.openldap.org/its/index.cgi/?findid=8902>
>
> Ok, didn't know that.
>
> Thanks a lot. I performed a test import following your instructions
> and so far everything looks good.
> Karsten
Glad it's looking good. :) In the future, please keep replies on the list
unless they contain some type of sensitive info (passwords, etc). ;) This
helps ensure others have the possibility of making use of the information.
:)
Warm regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 9 months
Q: Co-existence of OpenLDAP and 389 Directory Server?
by Ulrich Windl
Hi!
As stated some time ago the SUSE Linux Enterprise Server 15 (SLES15) switched from OpenLDAP to 389 Directory Server.
Trying the latter, I see that it still works with BDB (4.8), and setup is easy. It also seems to have modern features like these:
\n+Entry cn=SSHA256,cn=Password Storage Schemes,cn=plugins,cn=config is added
\n+Entry cn=SSHA384,cn=Password Storage Schemes,cn=plugins,cn=config is added
\n+Entry cn=SSHA512,cn=Password Storage Schemes,cn=plugins,cn=config is added
\n+Entry cn=SHA256,cn=Password Storage Schemes,cn=plugins,cn=config is added
\n+Entry cn=SHA384,cn=Password Storage Schemes,cn=plugins,cn=config is added
\n+Entry cn=SHA512,cn=Password Storage Schemes,cn=plugins,cn=config is added
\n+Entry cn=PBKDF2_SHA256,cn=Password Storage Schemes,cn=plugins,cn=config is added
However I wonder if it's possible to integrate a 389DS (ns-slapd, http://www.port389.org/) into an OpenLDAP multi-master configuration. Definitely one cannot sync the configuration section, because it's too different.
For example the ACL Syntax looks like this:
(targetattr="carLicense || description || displayName || facsimileTelephoneNumber || homePhone || homePostalAddress || initials || jpegPhoto || labeledURI || mail || mobile || pager || photo || postOfficeBox || postalAddress || postalCode || preferredDeliveryMethod || preferredLanguage || registeredAddress || roomNumber || secretary || seeAlso || st || street || telephoneNumber || telexNumber || title || userCertificate || userPassword || userSMIMECertificate || x500UniqueIdentifier")(version 3.0; acl "Enable self write for common attributes"; allow (write) userdn="ldap:///self";)
Regards,
Ulrich
4 years, 9 months
