openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

Re: Facing issues with Symas LDAP upgrade from 2.4 to 2.5
by anil kumar pathuri 24 Jul '24

24 Jul '24

hi Quanah, Hope you are doing well. Thank you for your email. PFA This is what I did: Installed openldap 2.4.44 --> Upgraded to Symas OpenLDAP 2.4.57 --> Upgrading from Symas OpenLDAP 2.4.57 to Symas OpenLDAP 2.6.7 ***PS: I am not using slapd.conf, what should I do in this case. Regards, Anil P On Fri, 17 May 2024 at 01:57, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thursday, May 16, 2024 7:55 PM +0000 anilkumar.pathuri7(a)gmail.com > wrote: > > > Hi Team, GM > > Successful while trying to upgrade from openLDAP 2.4.44 to > SymasLDAP2.4.57 > > > > Facing issues while trying to upgrade to 2.5.x and 2.6.x from > > SymasLDAP2.4.57 https://repo.symas.com/soldap2.5/upgrading/ > > > > Issues while trying to upgrade from SymasLDAP2.4.57 to SymasLDAP 2.5.17. > > 1. config error processing olcDatabase={2}mdb,cn=config > > UNKNOWN attributeDescription "OLCDBINDEX" inserted > > Providing a config snippet is not particularly useful. > > You also say issue going from 2.5.x to 2.6.x but then you say the error is > in going from 2.4.57 to 2.5.17. > > Your error generally indicates that you're missing a module load on the > MDB > backend module. > > --Quanah > >

7 13

How to synchronize between different DC domains
by 2458943823＠qq.com 24 Jul '24

24 Jul '24

OpenLDAP version: 2.4.44 Requirement: How to configure the slapd.conf file to successfully synchronize user information between master and slave servers from different DCs, to keep the user DC consistent with the slave server DC. Current issue: 1. When filling in the syncrepl synchronization rule with suffixmassage "dc=ws,dc=sip,dc=com" "dc=ws,dc=slave2,dc=sip,dc=com", it shows Error: parse_syncrepl_line: unable to parse "suffixmassage".

3 6

question about partial replication
by Frédéric Goudal 24 Jul '24

24 Jul '24

Hello, I’m trying to build a partial replication, but due to the structure of our ldap directory I’m wondering how to do : I have an ou branch for people that I want to replicate (ou=people,<prefix>) I have an ou branch for groups that I want to replicate (ou=groups,<prefix>) I have an ou branche for sudo that I want to replicate (ou=sudo,<prefix>) I guess that the setup for that is to replicate on <prefix> base and just filter on the objectClass BUT… my problem is that I have another ou branch for some people (ou=otherPeople,<prefix>) that I don’t want to replicate, but that contains exactly the same objects than then ou=people,<prefix> branch, so I can not use a filter on objectClass, there is no specific attribut that allow to say if an object belongs to ou=otherPoeple ou to ou=People I wonder what is the correct solution to achieve my goal. I was wondering if I could put several olcSyncrepl on the database with the same provider but one for every ou that I want to replicate ? Or is there a better way to do ? Thanks in advance — Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11

2 4

Openldap 2.6.8 installation some minor questions
by Frédéric Goudal 23 Jul '24

23 Jul '24

Hello, I have just ran into un install from source of 2.6.8 on an ubuntu24.04 server. I have had some minor problems with systemd, but maybe it’s my fault. I have compiled openldap with —with-tls and —with-systemd But on the service file there was no ldaps:// in url list, maybe it’s normal ? On the service file there is a reference of a /etc/sysconfig/slapd Environment file but this file is not installed with the make install, maybe I did miss a point ? And I wonder for the location of the slapd.service file, it is put in the main /usr/lib/systemd/system . As I have not put openldap in the main /usr/ hierarchy directory but /usr/local (that is the default), I was expecting to find slapd.service in /etc/systemd/system directory. I have not found a place in the configure tool to tell where to put the service file. Any thoughts on these points ? — Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical