openldap-technical July 2019

openldap-technical@openldap.org

29 participants
22 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

OpenLDAP 2.5 plans and community engagement
by Ondřej Kuzník 13 Aug '19

13 Aug '19

Hi all, as 2.4 has finally stabilised and the ITS list is getting shorter not longer (thanks to Quanah's tireless efforts), the project can finally tackle some of the long-standing pain points. So this post aims to outline where we are/want to move to as well as to start a discussion and hopefully get you, the community, more involved on the road to 2.5 and beyond. We would love to welcome more people to participate in the project and make it more active and resilient. People of various skills and experience can make a difference, I am personally happy to assist anyone who wants to contribute with getting up to speed and start helping out, and for sure I'm not the only one. Also OpenLDAP is about more than just C programming and I'll try to outline the main areas where we want to focus our work in the short term here: One of the pain points in the 2.4 release cycle was the level of testing done on the code before we have released. There are issues with the existing test suite that make testing hard and I will come to how this could be tackled in a later email. In the short term however, we could benefit from having the tests we have run more often and on more diverse environments. If you have a chance to run it regularly, in a loop and report issues picked up, that would be a definite help. If you could help extend the test suite to cover scenarios that are of interest to you and are not appropriately covered yet, even better. Another issue frustrating both users and contributors to the project has been the existing jitterbugs bug tracker (a.k.a. ITS), which has by now outlived its usefulness. Plans to move to a project-hosted Gitlab instance + Bugzilla (via Gitlab's built in Bugzilla integration) are being made and this should make the issue tracker searchable again, help with triage as well as greatly improve the visibility into our release process. Especially after the migration, this would be another opportunity for anyone with just a bit of spare time to help by triaging open issues so we can make timely releases of better quality. I'm sure everyone agrees our website could do with a redesign. We've started looking into this but it has been a slow process so far and if you can contribute here, that might speed things up. It doesn't need much, keeping it a collection of static html pages, just a slight reorganisation of the content that is more friendly to anyone visiting it for the first time plus a simplistic design along the lines of many other open source projects (openssl.org for example) would go a long way. This leads to documentation, much of which is already hosted on the website. While I believe there is good work to be done on the admin guide, it is one of the better parts of our documentation. This is where user feedback on its usefulness is more important, please read it, have people on your team read it and show it people just getting started and report which parts are confusing, how they could be improved. We also intend to document our contributor guidelines in a more readable way. The FAQ site however is on the opposite side of the spectrum and will be removed at some later point. There have been two suggestions how to replace it. We could use Gitlab internal wiki or a static webpage site based on Gitlab pages and we want to transfer over articles that are still relevant. In general, moving to Gitlab should let us integrate CI much better, especially if there are people willing to integrate and manage external runners. As mentioned above, we could definitely do with more regular testing on non-Linux platforms, e.g. *BSD or Windows+MSYS2. Pull requests might then also be automatically tested. Let us know what the pain points have been with OpenLDAP when you were just starting, right now and if you have a suggestion how to make it easier to start using it. Or if you wanted to contribute, has anything discouraged you? There are things we might not be able to influence easily (LDAP itself can be complex), but a fresh look might help direct efforts in the right direction. Thanks ever so much for reading this far. This email is long enough already so I will follow up with another one about my long term plans to overhaul the test infrastructure and other tools that might be worth introducing to help with setting up and managing OpenLDAP deployments. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

11 39

Re: Openldap Acl
by Quanah Gibson-Mount 29 Jul '19

29 Jul '19

--On Sunday, July 28, 2019 11:47 PM +0100 Meryem Fahim <meryem.f97(a)gmail.com> wrote: Hello, Please keep replies on the list. > Hello > Thank you for taking the time to respond.You have asked me to provide you > with my set of ACLs so here it is: > dn: olcDAtabase={0}config,cn=config You're changing the ACLs on the wrong database. That DN is clearly for the cn=config datbase, and so would not apply to the DB that contains your users, etc. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Openldap Access Control
by Meryem Fahim 26 Jul '19

26 Jul '19

HELLO; i'm working on an Openldap project where im supposed to create groups and users and be able to work with phpldapadmin,I've done all of that. Now I want to modify access whereas ensaUser and estUser when logging in will be able to see only the branch they are in(and give that privilege to admin only) I tried so many ACLs (using ldapmodify) but nothing seems to work,when I log in with one of the users I still can see the whole dataBase,I would appreciate some help.thank you

2 1

slapd-sock v2.4.47 not returning LDIF
by Giuseppe De Marco 26 Jul '19

26 Jul '19

Hello everyone, I made a configuration to get slapd-sock to work with a python3 server (gevent). The slapd configuration can be reproduced less then a minute using this ansible playbook: https://github.com/peppelinux/ansible-slapd-eduperson2016 the python3 server is available at the following resource, slapd-sock backend configuration can be found in the README file: https://github.com/peppelinux/pyMultiLDAP It is the following: ldapadd -Y EXTERNAL -H ldapi:/// <<EOF dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModuleLoad: back_sock.la EOF ldapadd -Y EXTERNAL -H ldapi:/// <<EOF dn: olcDatabase={4}sock,cn=config objectClass: olcDbSocketConfig olcDatabase: {4}sock olcDbSocketPath: /var/run/multildap.sock olcSuffix: dc=proxy,dc=unical,dc=it olcDbSocketExtensions: binddn peername ssf EOF I tested that this configuration doesn't have any problems in a Debian 9 installation (slapd 2.4.44) but in a Debian10 (2.4.47) does. Even if I use "servers/slapd/back-sock/searchexample.pl" [1] I get the same faulty result, described as follow: ```` # extended LDIF # # LDAPv3 # base <dc=proxy,dc=unical,dc=it> with scope subtree # filter: uid=mario # requesting: ALL # # search result search: 2 result: 0 Success text: OK ```` As we can see RESULT was found but with any preceeding ldif. Looking into /var/log/slapd.log I found the same behaviour of Debian9 installation: ```` [25-07-2019 10:33:57] slapd debug conn=1036 fd=20 ACCEPT from IP= 127.0.0.1:54674 (IP=0.0.0.0:389) [25-07-2019 10:33:57] slapd debug conn=1036 op=0 BIND dn="cn=admin,dc=testunical,dc=it" method=128 [25-07-2019 10:33:57] slapd debug conn=1036 op=0 BIND dn="cn=admin,dc=testunical,dc=it" mech=SIMPLE ssf=0 [25-07-2019 10:33:57] slapd debug conn=1036 op=0 RESULT tag=97 err=0 text= [25-07-2019 10:33:57] slapd debug conn=1036 op=1 SRCH base="dc=proxy,dc=unical,dc=it" scope=2 deref=0 filter="(objectClass=*)" [25-07-2019 10:33:57] slapd debug conn=1034 op=5 SRCH base="ou=people,dc=testunical,dc=it" scope=2 deref=3 filter="(objectClass=*)" [25-07-2019 10:33:57] slapd debug conn=1034 op=5 SRCH attr=eduPersonPrincipalName schacHomeOrganization mail uid givenName sn eduPersonScopedAffiliation schacPersonalUniqueId schacPersonalUniqueCode userPassword [25-07-2019 10:33:57] slapd debug conn=1034 op=5 SEARCH RESULT tag=101 err=0 nentries=4 text= [25-07-2019 10:33:57] slapd debug sock: fgets failed: Success (0) [25-07-2019 10:33:57] slapd debug conn=1036 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= OK [25-07-2019 10:33:57] slapd debug conn=1036 op=2 UNBIND [25-07-2019 10:33:57] slapd debug conn=1036 fd=20 closed ```` I also tried to use admin credentials, as shown in the slapd log. I also tried to do a fresh slapd installation by hands, on Debian9 slapd-sock works (searchexample.pl <https://github.com/openldap/openldap/blob/master/servers/slapd/back-sock/se…> and pyMultiLdap) but not Debian10. I read that there are two additional features regarding slapd-sock in openldap 2.4.47. These are: - Added slapd-sock DN qualifier for subtrees to be processed (ITS#8051) - Added slapd-sock ability to send extended operations to external listeners (ITS#8714) My doubts: Is there any need to change configuration, following ITS#8714 and ITS#8051, to get it to work in Debian10 ? or Am I facing a bug present in openldap 2.4.47 ? Thank you in advance for everything you would tell me, Cheers [1] https://github.com/openldap/openldap/blob/master/servers/slapd/back-sock/se… -- ____________________ Dott. Giuseppe De Marco CENTRO ICT DI ATENEO University of Calabria 87036 Rende (CS) - Italy Phone: +39 0984 496961 e-mail: giuseppe.demarco(a)unical.it

3 5

Mapping gid numbers
by JC 24 Jul '19

24 Jul '19

My question is not strictly an LDAP one, but perhaps somebody here with experience in the LDAP and Linux worlds can throw some light on it. I understand how to map attributes, as defined in an LDAP server, to other attributes in a Linux when the NSS framework is used in the latter. Is it possible to map values of attributes? Let's say I have an OpenLDAP server that defines a certain group with a gid number 10000. Would it be possible to map that 10000 to (say) 5000 in the Linux system? That is, every time an operation is executed in the Linux system that uses the group information, the gid would be retrieved from the OpenLDAP server as 10000, and automatically be converted to 5000. Can this be done?

4 4

Re: where is debuglevel documented ?
by danielle lampert 23 Jul '19

23 Jul '19

Hello, yes I was asking for the log levels of the command-line tools like ldapsearch. Thanks for your answers. This doc helps ( https://www.openldap.org/doc/admin24/runningslapd.html ) but is not completely right, as levels 4 and 8 don't do anything special. I will rely on the this doc for my tests, thanks again. D.L. Le lun. 22 juil. 2019 à 16:14, Quanah Gibson-Mount <quanah(a)symas.com> a écrit : > --On Monday, July 22, 2019 10:56 AM -0400 Brian Reichert > <reichert(a)numachi.com> wrote: > > > I think that the OpenLDAP server and client share debug flags. I may be > > wrong on this. > > > > https://www.openldap.org/doc/admin24/runningslapd.html > > This is correct. It's trivial to grep the source and confirm this as well. > > --Quanah > > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > >

2 1

Re: Intensive disk write after long-running LDAP activity terminated
by Tamás Rébeli-Szabó 23 Jul '19

23 Jul '19

Quanah, thank you for your warning. We are aware that it is a very old release and a version upgrade is already being planned. But for the moment, that is the currently installed version and that is what produced the strange phenomenon. Regards, tamas Quanah Gibson-Mount <quanah(a)symas.com> ezt írta (időpont: 2019. júl. 22., H, 15:25): > --On Monday, July 22, 2019 2:20 PM +0200 Tamás Rébeli-Szabó > <tamas.rebeli.szabo(a)webvalto.hu> wrote: > > > > > > > > > Hello, > > > > we had a long-running (several days) process doing add and modify > > operations in OpenLDAP 2.4.41 + LMDB backend + SLES 11.3. > > I would note you're talking about OpenLDAP and LMDB releases that are over > 4 years old, past which point numerous issues have been fixed for both. > > LMDB 0.9.15 Release (2015/06/19) > OpenLDAP 2.4.41 Release (2015/06/21) > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Openldap issues user issues after updating user groups
by 王峰 22 Jul '19

22 Jul '19

Hello, wish you happiness! Sorry, take up your precious time. I encountered a problem. In the openldap HA environment, the update user group found that it was not synchronized to the client in time (8 hosts, 5 stations, 3 syncs, not synchronized, waiting for half an hour to complete synchronization). Has anyone encountered such a problem? And would like to know how to troubleshoot such problems, I use openldap soon. thank you very much! 发送自 Windows 10 版邮件应用

2 3

where is debuglevel documented ?
by danielle lampert 22 Jul '19

22 Jul '19

hello the ldapsearch man page ( https://www.openldap.org/software//man.cgi?query=ldapsearch&apropos=0&sekti… ) says : *-d* *debuglevel* Set the LDAP debugging level to *debuglevel*. Where can I find the debuglevel values and their meaning ? best regards D.L.

7 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2019