openldap-technical August 2018

openldap-technical@openldap.org

27 participants
29 discussions

Problem with "force user to password reset at first login
by Rajagopal Rc 30 Oct '23

30 Oct '23

Hi, I am trying to force users to change their password at first login or after password reset by administrator. Tried following: 1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non of the users get prompt to change their password at first login. 2) used the 'pwdReset TRUE' attribute in users attributes, and it won't prompt to change the password and didn't allow to login i observe below messages in log "slapd[12684]: connection restricted to password changing only slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are restricted to bind/unbind/abandon/StartTLS/modify password" slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify password" Please help me configure the option to force all users to change their password at first login or after pwd reset by administrator. Thanks & Regards Raj Tata Consultancy Services Mailto: rajagopal.rc(a)tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

5 9

role based authorization -> dynacl module?
by Daniel Tröder 11 Oct '18

11 Oct '18

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 13

Re: OpenLDAP instances crashes
by Saurabh Lahoti 14 Sep '18

14 Sep '18

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 >>>> >>>

3 4

duplicated naming context when using syncrepl proxy
by Jochen Keutel 05 Sep '18

05 Sep '18

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.

3 4

Problem with ACLs
by Bill Bradford 31 Aug '18

31 Aug '18

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

3 11

empty reqmod attribute
by David Coutadeur 31 Aug '18

31 Aug '18

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

2 4

Unique overlay confusing
by Ervin Hegedüs 30 Aug '18

30 Aug '18

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.

5 17

Call fo Papers - Paris Open Source Summit
by Clément OUDOT 29 Aug '18

29 Aug '18

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.

1 0

Recommended way to transfer data from one cluster to the other?
by Karsten Heymann 29 Aug '18

29 Aug '18

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

3 2

Re: Recommended way to transfer data from one cluster to the other?
by Quanah Gibson-Mount 29 Aug '18

29 Aug '18

--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>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2018