openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

FW: Accessing ppolicy attributes as non-admin in 2.4
by Windl, Ulrich 07 Jul '24

07 Jul '24

As I think the message had been blocked (I'm still receiving messages, but seem to be unable to send due to address mis-matching), I'm re-sending it. Please ignore if it had been delivered. From: Windl, Ulrich Sent: Thursday, June 20, 2024 9:53 AM To: openldap-technical <openldap-technical(a)openldap.org> Subject: Accessing ppolicy attributes as non-admin in 2.4 Hi! Yes, we are still running an old 2.4 OpenLDAP (mostly because it still has "hdb"), but anyhow: There's a request to search for accounts where the password will expire soon according to configured ppolicies. I wrote the code, realizing that a normal user cannot read other users policy attributes, while the admin user can. As the process should run automatically, I don't want to add admin credentials for that kind of reporting. Instead I added a new user role and tried to add access to the attributes, but somehow it does not work. I think I did not make an error, but ACL configuration can be tricky. So the question is: Can it be done in 2.4, and if so, what might be wrong in this config (lines unfolded, sorry): olcAccess: {0}to * by dn.exact="uid=syncrepl,ou=system,dc=..." read by group/organizationalRole/roleOccupant.exact="cn=LDAP-Manager,dc=roles,dc=..." write by * break olcAccess: {1}to dn.children="dc=roles,dc=..." attrs=roleOccupant by * none olcAccess: {2}to attrs=pwdAccountLockedTime,pwdAllowUserChange,pwdChangedTime,pwdCheckQuality,pwdExpireWarning,pwdFailureCountInterval,pwdGraceAuthNLimit,pwdGraceUseTime,pwdHistory,pwdInHistory,pwdLockoutDuration,pwdMaxFailure,pwdMaxRecordedFailure,pwdMinAge,pwdMinLength,pwdMustChange,pwdPolicySubentry,pwdRe\ set,pwdSafeModify,shadowExpire,shadowInactive,shadowLastChange,shadowMax,shadowMin,shadowWarning by dn.exact="uid=PP-Checker,ou=system,dc=..." read break olcAccess: {3}to attrs=userPassword,userPKCS12 by self write by * auth olcAccess: {4}to attrs=shadowLastChange by self write by * read olcAccess: {5}to attrs=pwdHistory,pwdGraceUseTime,pwdChangedTime by self read by * none olcAccess: {6}to * by * read The account in question is ="uid=PP-Checker,ou=system,dc=..." obviously, and the "cn=LDAP-Manager,dc=roles,dc=..." can access the attributes. The account is like this: dn: uid=PP-Checker,ou=system,dc=... objectClass: top objectClass: account objectClass: simpleSecurityObject structuralObjectClass: account uid: PP-Checker The Admin object looks like this: dn: cn=LDAP-Manager,dc=roles,dc=... objectClass: organizationalRole cn: LDAP-Manager description: Administrative Access to LDAP Directory roleOccupant: uid=me-for-example,ou=people,dc=... roleOccupant: uid=another,ou=people,dc=... structuralObjectClass: organizationalRole Any help on this is highly appreciated. If you think something else is wrong, also tell me please. Alternatively you could give an answer on https://superuser.com/q/1844359/964771 Kind regards, Ulrich

2 11

[2.5.16] Filter Replication Issue
by Pierre Marty 04 Jul '24

04 Jul '24

Hi, When using a filter on a replicated branch, it seems that deletion updates are still propagated... The cluster in use is a 4 nodes master-master with the following settings: olcsyncrepl: rid=4 provider="ldaps://url" type=refreshAndPersist retry="5 10 60 +" timeout=5 network-timeout=10 keepalive=60:10:5 schemachecking=off searchbase="dc=root,dc=com" scope=sub bindmethod=sasl saslmech=external tls_cacertdir=/usr/local/openldap/etc/openldap/certs tls_cert=/usr/local/openldap/etc/openldap/certs/cert.crt tls_key=/usr/local/openldap/etc/openldap/certs/cert.key tls_cipher_suite=HIGH tls_reqcert=demand filter="(!(objectclass=MyOwnClass))" The objectclass is as follow: dn: MyOwnClass=state,ou=initials,dc=root,dc=com AF-UID: state objectClass: MyOwnClass objectClass: top STATE: UP structuralObjectClass: MyOwnClassThe replication account does not possesses any access to this element :olcAccess: to dn.exact="MyOwnClass=state,ou=initials,dc=root,dc=com" by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn.exact="cn=status,ou=serviceaccounts,dc=root,dc=com" read by dn.exact="cn=confldap,ou=serviceaccounts,dc=root,dc=com" manage by * none Yet, when MyOwnClass=state,ou=initials,dc=root,dc=com is deleted the following logs appear: serverA : op=1 DEL dn="MyOwnClass=state,ou=initials,dc=root,dc=com" serverA : op=1 syncprov_matchops: recording uuid for dn=MyOwnClass=state,ou=initials,dc=root,dc=com on opc=0x7ff5a00157c0 serverB : op=0 syncprov_matchops: recording uuid for dn=MyOwnClass=state,ou=initials,dc=root,dc=com on opc=0x7f158c0015c8 serverB : syncrepl_del_nonpresent: rid=003 be_delete MyOwnClass=state,ou=initials,dc=root,dc=com (0) serverB : op=1 SRCH base="MyOwnClass=state,ou=initials,dc=root,dc=com" scope=2 dereIs it an expected behavior? When updating the value or renaming the object, no replication is noticed. Have a good day,-- Pierre Marty Ingénieur Logiciel / OSSA pmarty(a)linagora.com (+33) 067 530 3612 ------------------ ossa(a)linagora.com (+33) 080 005 4689 - 3 ------------------ GROUPE LINAGORA Villa Good Tech 37 Rue Pierre Poli 92130 Issy-les-Moulineaux (+33) 097 263 9776

3 2

dummy values for absent attributes ?
by Geert Hendrickx 04 Jul '24

04 Jul '24

Hi We are facing a proprietary application that insists on the presence of certain attributes that are optional in our objectclass schema, and not all objects have them. So we are considering to provision dummy values to all objects that currently don't have these attributes, but that would impact a large number of objects, which I'd like to avoid. (And we'd also have to adjust business logic to always add those attributes in the future, whereas they are truly optional in our data model.) Is there an OpenLDAP overlay that can insert dummy values for missing attributes? For arbitrary objects? (I read about slapo-translucent, but I think it requires each object to be present in the transcluent database?) Geert

4 3

Re: sync repl issue
by Luo, Frank 27 Jun '24

27 Jun '24

OK. Thanks. we just use the RPM package from OEL8. Do you know if 2.6 RPM is available on OEL8? On Fri, Jun 21, 2024 at 1:06 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > > --On Friday, June 21, 2024 1:35 PM -0400 "Luo, Frank" <luoy(a)miamioh.edu> > wrote: > > > sorry. it is 2.4.46 and I believe it is standard syncrepl ( I could > > not find syncdata in slapd.conf). > > Hi, > > The OpenLDAP 2.4 series has been deprecated for several years, and numerous > issues with replication have been fixed in the later release series. I > would strongly advise upgrading to a supported release, in particular the > OpenLDAP 2.6 series. You've most likely encountered one of the many known > and (later) fixed issues with syncrepl in the 2.4 series. > > Regards, > Quanah > > > >

4 5

Q: Reset a locked user's password
by Windl, Ulrich 23 Jun '24

23 Jun '24

Hi! I have a question related to policy and a user with an expired password and all grace logins consumed, like this: pwdChangedTime[0] 20231127075102Z pwdGraceUseTime[0] 20240429142254Z pwdGraceUseTime[1] 20240430112006Z pwdGraceUseTime[2] 20240527074731Z pwdGraceUseTime[3] 20240528114912Z pwdGraceUseTime[4] 20240528130249Z pwdFailureTime[0] 20240611082600.348275Z How can the user change his password? The user cannot log in anymoe, obviously. If the user could log in he would have admin privileges. I had the idea to delete the grace logins via ldapmodify, but the result (for version 2.4) was: ldap_modify: Constraint violation (19) additional info: pwdGraceUseTime: no user modification allowed So what are the options (for the user himself and for an admin)? Regards, Ulrich

3 5

Re: sync repl issue
by Luo, Frank 21 Jun '24

21 Jun '24

sorry. it is 2.4.46 and I believe it is standard syncrepl ( I could not find syncdata in slapd.conf). Thanks On Fri, Jun 21, 2024 at 10:52 AM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > > --On Friday, June 21, 2024 9:59 AM -0400 "Luo, Frank" <luoy(a)miamioh.edu> > wrote: > > > refreshAndPersist, mirrormode on for node 01 and 02 , off for node 03 and > > Hi, you didn't answer these two questions: > > Standard syncrepl or delta syncrepl? What version of OpenLDAP? > > Thanks! > > --Quanah > >

2 1

Re: sync repl issue
by Luo, Frank 21 Jun '24

21 Jun '24

refreshAndPersist, mirrormode on for node 01 and 02 , off for node 03 and 04 Thanks On Thu, Jun 20, 2024 at 7:22 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > > --On Thursday, June 20, 2024 4:48 PM -0400 "Luo, Frank" <luoy(a)miamioh.edu> > wrote: > > > Hi, all > > > > We have a 4 nodes set up, n01 and n02 have mirror mode on and they are > > provider and consumer to each other. n03's provider is n01 and n04's > > provider is n02. Each has contexcsn as followings so I think they are > > all in sync. > > > > However I have a node n04 missing some data (one entry I found so > > far). How to explain this and how to troubleshoot? Thanks a lot! > > What version of OpenLDAP? What kind of sync replication (standard, delta? > refreshonly, refreshAndPersist?) etc. > > --Quanah > >

2 1

sync repl issue
by Luo, Frank 20 Jun '24

20 Jun '24

Hi, all We have a 4 nodes set up, n01 and n02 have mirror mode on and they are provider and consumer to each other. n03's provider is n01 and n04's provider is n02. Each has contexcsn as followings so I think they are all in sync. However I have a node n04 missing some data (one entry I found so far). How to explain this and how to troubleshoot? Thanks a lot! Frank n01 contextCSN: 20180628172040.692013Z#000000#001#000000 contextCSN: 20180628172039.214361Z#000000#002#000000 contextCSN: 20240620192402.726831Z#000000#015#000000 contextCSN: 20240620193606.038191Z#000000#016#000000 n02 contextCSN: 20180628172040.692013Z#000000#001#000000 contextCSN: 20180628172039.214361Z#000000#002#000000 contextCSN: 20240620192402.726831Z#000000#015#000000 contextCSN: 20240620193606.038191Z#000000#016#000000 n03 contextCSN: 20180628172040.692013Z#000000#001#000000 contextCSN: 20180628172039.214361Z#000000#002#000000 contextCSN: 20240620192402.726831Z#000000#015#000000 contextCSN: 20240620193606.038191Z#000000#016#000000 n04 contextCSN: 20180628172040.692013Z#000000#001#000000 contextCSN: 20180628172039.214361Z#000000#002#000000 contextCSN: 20240620192402.726831Z#000000#015#000000 contextCSN: 20240620193606.038191Z#000000#016#000000

2 1

Complete removal of an attribute
by Benjamin Renard 19 Jun '24

19 Jun '24

Hello, I'm trying to find out the correct way to completely remove an attribute from an existing LDAP database. So far, I've been doing the following: - Deleting this attribute from all existing entries in the directory: ldapsearch -Y EXTERNAL -H ldapi:/// \ -b o=root '(toRemove=*)' dn -LLL | \ sed 's/^dn: $.*$$/dn: \1\nchangetype: modify\ndelete: toRemove/' | \ ldapmodify -Y EXTERNAL -H ldapi:/// - Removing all references to this attribute from the configuration (schema, index, ACLs, ...) My problem is that slapschema still throws an error about this attribute: 6669bbb2 UNKNOWN attributeDescription "TOREMOVE" inserted. I have double-checked and there are no references to this attribute in a database dump. In this situation, a dump/restore solves the problem, but this requires a service interruption that I would like to avoid. Do you have any ideas on how to work around this issue? Regards, -- Benjamin Renard - Easter-eggs 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37 - mailto:brenard@easter-eggs.com

2 2

[openLDAP 2.5] slapd silently stops
by BECOT Jérôme 13 Jun '24

13 Jun '24

Hello, We have to servers configured as Proxy with back_ldap. They stop almost everyday with a SIGABRT in the service log. Nothing in the standard logs when they stop. I'd like to increase the log level to args, but I'm not sure if it would help me. Any help appreciated. Regards Jerome

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical