openldap-technical July 2018

openldap-technical@openldap.org

31 participants
28 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

permissions replication
by Miroslav Misek 13 Aug '18

13 Aug '18

Hi, I am setting up master-slave replication for our off-site office, so it can use authentication against ldap even with internet connectivity issues. Replication itself is working without problems. But it replicates only data and not olcAccess attributes on database. So I have to set them manually. Please is there any way to replicate those attributes too? I found only one way, and it is master-master replication of cn=config database. And it is not usable in our environment. Off-site office don`t have public ip. And it is better for me to have this ldap instance read-only. Thank you, Miroslav Misek

4 4

ldapi and StartTLS
by Norman Gray 07 Aug '18

07 Aug '18

Greetings. I would have thought (possibly naively) that StartTLS was unnecessary when connecting to slapd through a unix socket -- the client and the server are on the same machine, and so don't need to be reassured about each other's identity. However this seems not to be be the case: % ldapsearch -LLL -H ldapi://%2Fvar%2Frun%2Fopenldap%2Fldapi '(uid=foo)' ldap_sasl_interactive_bind_s: Confidentiality required (13) additional info: stronger confidentiality required (same result with ldapi:///). What am I misunderstanding? In the slapd.ldif I have: dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcPidFile: /var/run/openldap/slapd.pid olcSecurity: ssf=128 olcTLSCertificateFile: /usr/local/etc/openldap/certs/XXX.crt olcTLSCertificateKeyFile: /usr/local/etc/openldap/certs/XXX.key olcTLSCACertificateFile: /usr/local/etc/openldap/certs/FOO olcLogLevel: 0 The machine is also listening on ldap://0.0.0.0 and requiring TLS. I don't see anything in the documentation which seems to suggest I can have different TLS rules on different interfaces or protocols (ie, ldap: vs ldapi:) -- am I just missing that? The /usr/local/etc/ldap.conf doesn't mention TLS, so the TLS requirement isn't coming in from there. My practical problem is that I'm trying to get nslcd (on the same machine) to talk to OpenLDAP locally. If there's a certificate problem I can sort that out, but I can't help feeling that that ought to be unnecessary -- that I'm missing something simple. This is 2.4.45 on FreeBSD. Best wishes, Norman -- Norman Gray : https://nxg.me.uk

3 3

<olcMirrorMode> database is not a shadow
by admin＠genome.arizona.edu 02 Aug '18

02 Aug '18

Hello, Was setting up replication for our LDAP server, and was following the guide here, https://wiki.gentoo.org/wiki/Centralized_authentication_using_OpenLDAP#Sett… I had success with this guide but just a problem with authentication, I could see in the ldap debug log for node1 entries like this: Jul 20 16:21:22 node1 slapd[10218]: conn=3497 fd=38 ACCEPT from IP=<node1's IP>:34606 (IP=0.0.0.0:389) Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=0 BIND dn="cn=Manager,dc=genome,dc=arizona,dc=edu" method=128 Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=0 BIND dn="cn=Manager,dc=genome,dc=arizona,dc=edu" mech=SIMPLE ssf=0 Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=0 RESULT tag=97 err=0 text= Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=1 MOD dn="olcDatabase={1}bdb,cn=config" Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=1 MOD attr=olcSyncrepl Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=1 RESULT tag=103 err=0 text= Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=2 MOD dn="olcDatabase={1}bdb,cn=config" Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=2 MOD attr=olcMirrorMode Jul 20 16:21:22 node1 slapd[10218]: slap_client_connect: URI=ldap://node2.genome.arizona.edu DN="cn=ldapreader,dc=genome,dc=arizona,dc=edu" ldap_sasl_bind_s failed (49) Jul 20 16:21:22 node1 slapd[10218]: do_syncrepl: rid=001 rc 49 retrying Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=2 RESULT tag=103 err=0 text= Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=3 UNBIND Jul 20 16:21:22 node1 slapd[10218]: conn=3497 fd=38 closed and in the debug log for node2 entries like this: Jul 20 16:21:22 node2 slapd[25327]: conn=14036 fd=17 ACCEPT from IP=<node1's IP>:56460 (IP=0.0.0.0:389) Jul 20 16:21:22 node2 slapd[25327]: conn=14036 op=0 BIND dn="cn=ldapreader,dc=genome,dc=arizona,dc=edu" method=128 Jul 20 16:21:22 node2 slapd[25327]: conn=14036 op=0 RESULT tag=97 err=49 text= Jul 20 16:21:22 node2 slapd[25327]: conn=14036 op=1 UNBIND Jul 20 16:21:22 node2 slapd[25327]: conn=14036 fd=17 closed It turns out i had literally used credentials="secret" in the add-replication-node1/node2.ldif files! So I went back and used slappasswd to generate a new password and put it into the ldapreader.ldif and use ldapmodify instead this time with success on both nodes, [root@node1 openldap]# cat ldapreader.ldif dn: cn=ldapreader,dc=genome,dc=arizona,dc=edu changetype: modify replace: userPassword userPassword: <hash from slappasswd> [root@node1 openldap]# ldapmodify -x -W -D "cn=Manager,dc=genome,dc=arizona,dc=edu" -f ldapreader.ldif Enter LDAP Password: modifying entry "cn=ldapreader,dc=genome,dc=arizona,dc=edu" [root@node1 openldap]# [root@node2 openldap]# cat ldapreader.ldif dn: cn=ldapreader,dc=genome,dc=arizona,dc=edu changetype: modify replace: userPassword userPassword: <hash from slappwasswd> [root@node2 openldap]# ldapmodify -x -W -D "cn=Manager,dc=genome,dc=arizona,dc=edu" -f ldapreader.conf Enter LDAP Password: modifying entry "cn=ldapreader,dc=genome,dc=arizona,dc=edu" [root@node2 openldap]# Then I updated the add-replication-node1/node2.ldif to modify the entry with the actual password instead of "secret"... on node1 i got two success messages, [root@node1 openldap]# cat add-replication-node1.ldif dn: olcDatabase={1}bdb,cn=config changetype: modify replace: olcSyncrepl olcSyncrepl: rid=001 provider=ldap://node2.genome.arizona.edu binddn="cn=ldapreader,dc=genome,dc=arizona,dc=edu" bindmethod=simple credentials="<actual password>" searchbase="dc=genome,dc=arizona,dc=edu" type=refreshAndPersist timeout=0 network-timeout=0 retry="60 +" dn: olcDatabase={1}bdb,cn=config changetype: modify replace: olcMirrorMode olcMirrorMode: TRUE [root@node1 openldap]# ldapmodify -x -W -D "cn=Manager,dc=genome,dc=arizona,dc=edu" -f add-replication-node1.ldif Enter LDAP Password: modifying entry "olcDatabase={1}bdb,cn=config" modifying entry "olcDatabase={1}bdb,cn=config" [root@node1 openldap]# However when I went to modify the entries on node2, I now got the error <olcMirrorMode> database is not a shadow, [root@node2 openldap]# cat add-replication-node2.ldif dn: olcDatabase={1}bdb,cn=config changetype: modify replace: olcSyncrepl olcSyncrepl: rid=002 provider=ldap://node1.genome.arizona.edu binddn="cn=ldapreader,dc=genome,dc=arizona,dc=edu" bindmethod=simple credentials="<actual password>" searchbase="dc=genome,dc=arizona,dc=edu" type=refreshAndPersist timeout=0 network-timeout=0 retry="60 +" dn: olcDatabase={1}bdb,cn=config changetype: modify replace: olcMirrorMode olcMirrorMode: TRUE [root@node2 openldap]# ldapmodify -x -W -D "cn=Manager,dc=genome,dc=arizona,dc=edu" -f add-replication-node2.ldif Enter LDAP Password: modifying entry "olcDatabase={1}bdb,cn=config" modifying entry "olcDatabase={1}bdb,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcMirrorMode> database is not a shadow [root@node2 openldap]# Now the replication has stopped and there are no connection entries in the ldap debug logs. So what did i do wrong and how to get replication going again? Thanks, -- Chandler / Systems Administrator Arizona Genomics Institute www.genome.arizona.edu

2 4

Keeping a new n-master environment in sync with an old single master env during a migration
by Chris Cardone 02 Aug '18

02 Aug '18

Hello all, I have a question I'm sure some folks have already addressed and hope there is a solution for my problem I am in the process of migrating from an old single master --> multiple slave env running on OpenBSD 4.9 openldap-server-2.4.23p2 - configured with slapd.conf over to 4-master (regional) to 4 slaves (now - more to come regionally) running Ubuntu 16.04 and openldap 2.4.42 - configured with a cn=config database I am trying to keep the environments in sync as we migrate dozens of different environments from the old slaves to the new slaves - which may take as long as 4 months :( I started out by using slapcat to export the contents of the old server, then loading them into the new server. I would originally drop all the data on the new servers and reload from the old. this is now no longer an option, as we migrate to the new servers, i cannot be dropping the entire database and replacing it with the new one - the time it takes to execute such a task creates an outage for users as well as applications that rely on the LDAP database. So im looking for some guidance / options to keep my new LDAP environment in sync with my old, without any service disruptions on either set of systems. Any help would be greatly appreciated!! Christopher

2 1

Number of requests served in ideal condition by version 2.4.46 with lmdb backend.
by Saurabh Lahoti 31 Jul '18

31 Jul '18

Dear All, For preparing a technical scope of OpenLDAP; do we have any maximum threshold of requests served per second by single instance of 2.4.46 with lmdb backend..? Thanks & Kind Regards, Saurabh Lahoti.

3 2

how to run script on event (modify/delete/add)?
by Zeus Panchenko 31 Jul '18

31 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 greetings, please advise how can I run external script on event (LDAP operation)? for example: I am generating config files for users from LDAP data with perl script I want to re-generate config files each time LDAP operation (modify, add, delete) performed how to do that and what is the best way to do that? - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQYIXL6FUmD7SUfqoOveOk+D/ejKgUCW18FeQAKCRCveOk+D/ej KtXaAJ949HG/9hwOP9z5RgvSUfjRR27nQQCgljD0MPOTdZevhdBt2u87Oeq1Frk= =NBxz -----END PGP SIGNATURE-----

4 5

python-ldap validate LDAPObject.modify_ext_s
by Sam Culley 31 Jul '18

31 Jul '18

I am trying to research how I can validate/verify executing an LDAPObject.modify_ext_s request in Python. If I print the response of the result it returns (103, [], 3, []) But I can't find much documentation on what that means? Any ideas? Regards, Sam

2 1

Syncrepl + suffixmassage + uniqueMember
by Steffen Kaiser 27 Jul '18

27 Jul '18

Hi, currently we have three OpenLDAP servers in multi-master mode and with MemberOf . Currently, the base DN is dc=oldorgname,dc=de. The name of the organization changed and all entries should be accessable through base dc=neworgname,dc=de and all attributes with DNs as value shall return this new base. First I tried relay with rwm in this configuration: dn: cn=module{1},cn=config changetype: modify add: olcmoduleload olcModuleLoad: back_relay.la dn: olcDatabase={2}relay,cn=config changetype: add objectClass: olcRelayConfig olcSuffix: dc=neworgname,dc=de olcRelay: dc=oldorgname,dc=de dn: olcOverlay=rwm,olcDatabase={2}relay,cn=config changetype: add objectClass: olcRwmConfig olcRwmRewrite: rwm-suffixmassage "dc=oldorgname,dc=de" But this caused slapd to dump core at different entries, when I query the whole database as administrator pulling all attributes. As this module is "experimental", so I went another way. Should I try another config? Second, I tried to create a consumer server with a separate database using and suffixmassage. olcSyncrepl: {2}rid=004 provider=ldap://server:389/ bindmethod=simpl e binddn="cn=dn" credentials="pwd" s earchbase="dc=oldorgname,dc=de" scope=sub schemachecking=on type=re freshAndPersist retry="5 2 30 2 60 +" interval=00:00:00:30 timeout=0 network-time out=0 keepalive=0:0:0 attrs="*,+" suffixmassage="dc=neworgname,dc=de" The sync proceeded, but I ended with uniqueMember attributes with the old base: dn: cn=team,ou=groups,dc=ou,dc=neworgname,dc=de uniqueMember: uid=user,ou=peolple,dc=ou,dc=oldorgname,dc=de The value of the attribute "member" gets rewritten into the new orgname. Ist this a bug or intentional behaviour? Kind regards, -- Steffen Kaiser

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2018