openldap-technical July 2024

openldap-technical@openldap.org

20 participants
19 discussions

LDAP search API failing if search filter contains escape character before equals to sign
by c.venugopal521＠gmail.com 19 Jul '24

19 Jul '24

Hi Team, We are working on migration of nsldap C sdk to OpenLDAP C sdk for our application client code. As part of this activity, from our application, we are sending one search query using search API (Ex: ldap_search_ext_s) to one of LDAP servers with a filter: smVariableName=dzORGS\=\= In this search filter, escape character (\) is added for equals to (=) symbols. We expected a successful result for this query as we have a valid entry. But the LDAP search call failed. By high level investigation, it was identified that the search call did not reach the LDAP server and OpenLDAP API internally returned failure status by saying BAD filter. Note: With the same client application code (where search filter and search API is same), using nsldap C SDK, we are able to execute the query successfully and able to see results. Could you please let me know if I missed any specific configuration/setting in OpenLDAP APIs before making a search? OR Do we need to change the search filter value (remove escape character) for OpenLDAP APIs?

2 1

slapo-remoteauth "remoteauth_store on" and password changes
by Christopher Paul 17 Jul '24

17 Jul '24

Hi OpenLDAP-Technical, Thank you, OpenLDAP Project Team for slapo-remoteauth. It is much simpler to set up compared to SASL. I have one comment relating to using "remoteauth_store on" and the possibility of being able to handle upstream password changes. According to the manual, and confirmed by testing, slapo-remoteauth is only engaged when the userPassword value is not present. In order for upstream AD password changes to propagate when using "remoteauth_store on", it would seem to be very useful to also engage the overlay when the userPassword value is present and a simple BIND fails with err=49. The downside of this would be high-frequency repeated err=49 BIND failures causing undesirable upstream load and lockouts, but perhaps this could be mitigated by limiting it to a configurable number of upstream failures before setting a value on some attribute say "remoteauth_enabled=False" to cause remoteauth to disengage entirely for the specific user until reset to True. Thanks, -- Chris Paul | Rex Consulting |https://www.rexconsulting.net

2 1

OpenLDAP authentication acts very slow when Active Directory is unreachable
by maupas.alexis＠hotmail.com 12 Jul '24

12 Jul '24

Hello everyone, I am currently struggling with my OpenLDAP configuration (v2.5.13 on Debian 12). I want my OpenLDAP server to host a local database and to act as a proxy to an Active Directory database. Both databases should be merged to centralise authentication. Through my research, I've discovered slapd-meta to merge multiple databases. Here is a small schema of what I expect : |--------> Local database (LDIF) "ou=local" META "dc=example,dc=com" ---| |--------> Proxy Active Directory "cn=Users,dc=addomain,dc=com" I am able to regroup accounts from both Active Directory and local OpenLDAP databases within the same naming context "dc=example,dc=com". Available accounts within "dc=example,dc=com" : - cn=userad,dc=example,dc=com (From Active Directory database) - cn=userldap,dc=example,dc=com (From local OpenLDAP database) For my Windows devices, I use pGina to manage user authentication against my OpenLDAP server. Once pGINA is correctly configured, I can easily and quickly connect with all available accounts from AD and LDAP (userad et userldap). My "only" problem is when the Active Directory server is down or unreachable. I am obviously no longer able to connect with Active Directory accounts. However, authentication with OpenLDAP accounts (userldap) becomes very slow and sometimes I can't connect. In fact, OpenLDAP server keeps trying to reach Active Directory for every request even if it's unreachable. This behaviour seems to slow the OpenLDAP searches within the local LDAP database a lot. I've tried implementing different types of timeout in order to stop reaching unreachable servers but it doesn't make the authentication for LDAP accounts go any faster. Here is my slapd.conf : #################BOF################### ### SCHEMAS include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/microsoft.minimal.schema include /etc/ldap/schema/rfc2307bis.schema ### MODULES modulepath /usr/lib/ldap #Path moduleload back_ldap #Module for ldap database moduleload back_meta #Module for meta database ### MAIN SETTINGS pidfile /run/slapd/slapd.pid argsfile /run/slapd/slapd.args ### DATABASES DEFINITION ## GENERAL ## ## LOCAL DATABASE CONFIG ## database ldif suffix "ou=local" directory "/var/lib/ldap" rootdn "cn=ldapadm,ou=local" rootpw "*****" access to * by dn="cn=admin,dc=example,dc=com" write by * read by * search ## MAIN DATABASE TO REGROUP BOTH REMOTE AND LOCAL DATABASE## database meta suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw "*****" ## PROXY TO LOCAL DB ## uri "ldap://127.0.0.1/dc=example,dc=com" lastmod off suffixmassage "dc=example,dc=com" "ou=local" rebind-as-user idassert-bind bindmethod=simple binddn="cn=ldapadm,ou=local" credentials="*****" mode=none idassert-authzFrom "*" ## PROXY TO Active Directory ## uri "ldap://AD-ip:389/dc=example,dc=com" readonly yes lastmod off suffixmassage "dc=example,dc=com" "cn=Users,dc=addomain,dc=com" protocol-version 3 rebind-as-user idassert-bind bindmethod=simple binddn="cn=Administrator,cn=Users,dc=addomain,dc=com" credentials="*****" mode=none flags=override idassert-authzFrom "*" map attribute uid sAMAccountName #################EOF################### Any help or suggestion on how to authenticate with local OpenLDAP accounts even if the Active Directory server is down would be appreciated. Have a good day. Alexis

2 3

OpenSSL 3.0 support with OpenLDAP 2.6.7 for SSL support
by venugopal chinnakotla 10 Jul '24

10 Jul '24

Hi Team, We are working on migration of nsldap C sdk to OpenLDAP c sdk for our application client code. As part of this activity, we have chosen openssl 3.0 as SSL provider with OpenLDAP. *OpenSSL Version is:* OpenSSL 3.0.10 1 Aug 2023 (Library: OpenSSL 3.0.10 1 Aug 2023) Could you please confirm from your side on support of OpenSSL 3.0 with OpenLDAP 2.6.7 and 2.6.8 versions? -- Thanks, *c.venugopal*

2 1

Configure multi-master replication OpenLDAP using https://repo.symas.com/soldap2.5/rhel8/
by Kaushal Shriyan 08 Jul '24

08 Jul '24

Hi, I am running OpenLdap server 2.5.18 on Red Hat Enterprise Linux release 8.10 (Ootpa) OS to enable multimaster replication on both nodes (node 1 and node 2). Currently on Node1 I am encountering the *ldap_modify: Insufficient access (50) *issue *Node1* # rpm -qa | grep openldap symas-openldap-clients-2.5.18-1.el8.x86_64 symas-openldap-servers-selinux-1.0.6-2.el8.noarch openldap-2.4.46-18.el8.x86_64 symas-openldap-servers-2.5.18-1.el8.x86_64 symas-openldap-libs-2.5.18-1.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.10 (Ootpa) # # pwd /opt/symas/etc/openldap # ls -l total 20 -rw-r--r-- 1 symas symas 247 May 23 20:21 ldap.conf.default drwxr-xr-x 2 symas symas 4096 Jun 26 16:02 schema -rw------- 1 symas symas 2901 Jun 27 17:55 slapd.conf -rw------- 1 symas symas 2710 May 23 20:21 slapd.conf.default -rw------- 1 symas symas 2761 May 23 20:21 slapd.ldif.default # # cat syncprov_mod.ldif dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov.la dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov # ldapadd -Y EXTERNAL -H ldapi:/// -f syncprov_mod.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=module{0},cn=config" *ldap_modify: Insufficient access (50)* # Am I missing anything? Please guide me. Best Regards, Kaushal

3 3

Querying the default password policy
by Windl, Ulrich 08 Jul '24

08 Jul '24

Hi! I just discovered a problem (reading "man slapo-ppolicy" in old 2.4 OpenLDAP): It seems one can configure a "default policy", but it cannot be queried. At least https://serverfault.com/a/644658/407952 suggests that, and after reading "man slapo-ppolicy" I did not find something different. Why isn't there some "olc" attribute for it? So far we did not set the default policy, but assigned one to each user. However I wanted to write a utility that would evaluate the changes if a default password policy were added. For obvious reasons I don't want to hard-code the policy name into the utility, and the utility may run on any server, not just LDAP-Servers to query them. However digging in the configs, I found in dn: olcOverlay={2}ppolicy,olcDatabase={1}hdb,cn=config the attribute "olcPPolicyDefault", wondering why it isn't documented. So far, so good, but how would an ACL allowing to read that attribute look like? It seems I cannot specify that specific attribute within the olcPPolicyConfig object class within the corresponding cn=config subtree: I can allow access to the attribute name globally, or to all attributes of the object class, and "attrstyle" can only be used for a specific value. So how should I allow access to that attribute for my special user running the utility? Kind regards, Ulrich

3 5

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2024