RE: el9 bind ip address

[Quanah Gibson-Mount]

--On Thursday, May 23, 2024 11:33 PM + Marc  
wrote:




> I don't really get what is wrong with how it was:
>
> "As I mentioned already, use systemd drop-in file (see `man 5
> systemd.unit` for more details). Or use `systemctl edit --full
> slapd.service`."


As previously mentioned, you will need to ask RedHat their reasoning.



The quote is part of the answer of redhat. I am not sure if it makes
sense to ask any further there. Especially since I am not really familiar
with this transition wanting to run everything via this systemd.




Ah, ok... that's an odd response.  Having it so you can configure how ldap 
should listen should be a trivial override like it was before IMHO.


--Quanah

RE: el9 bind ip address

[Quanah Gibson-Mount]

--On Wednesday, May 22, 2024 9:31 PM + Marc  
wrote:



I don't really get what is wrong with how it was:

"As I mentioned already, use systemd drop-in file (see `man 5
systemd.unit` for more details). Or use `systemctl edit --full
slapd.service`."



As previously mentioned, you will need to ask RedHat their reasoning.

--Quanah

Re: How to setup replication in openldap 2.6.7

[Quanah Gibson-Mount]

--On Monday, May 20, 2024 6:05 AM + kalybox2...@gmail.com wrote:


How to setup replication in openldap 2.6.7
Please let me know



Essentially the same way as in OpenLDAP 2.4, 2.5, etc... I suggest reading 
the OpenLDAP documentation.  The test suite also has multiple tests showing 
different replication setups.


--Quanah

Re: Facing issues with Symas LDAP upgrade from 2.4 to 2.5

[Quanah Gibson-Mount]

--On Thursday, May 16, 2024 7:55 PM + anilkumar.pathu...@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

Re: [openldap 2.4]olcdbcheckpoint parameter is not working

[Quanah Gibson-Mount]

--On Wednesday, May 15, 2024 5:19 AM + norihisa.kim...@ctc-g.co.jp 
wrote:



To whom it may concern,

Could you confirm if the following understanding is correct?

Regarding the olcDbCheckpoint parameter in openldap-2.4.46-18,
it is mentioned in the 2.4 manual


OpenLDAP 2.4 is a historic, unsupported release.  You failed to state what 
backend you are using, which is material to your general question.


There are multiple options for running a modern, supported release of 
OpenLDAP if you are unable to build it on your own:


Symas OpenLDAP (https://repo.symas.com)
LTB project ()

Regards,
Quanah

Re: failed to add jpegPhoto attribute to sql backend

[Quanah Gibson-Mount]

--On Sunday, May 12, 2024 3:58 AM +0700 Muchammad Nur Hidayat 
 wrote:




Thank you for the clarification.
At the moment i have to add binary data manually in mysql. It's works
pretty well since I never perform any db config.

Hope it will be fixed in the latest update.


I will re-iterate that back-sql is entirely experimental, unmaintained, and 
it should not be used with a production environment.  It is also magnitudes 
slower than the native back-mdb backend, so if you're only using the mysql 
instance for LDAP, it would be much better to switch to the native, 
supported backend database.


Regards,
Quanah

RE: [EXTERNAL] Re: How to properly monitor MDB usage

[Quanah Gibson-Mount]

I accidentally dropped this email, replying so it shows up ont he list.

--Quanah

--On Wednesday, May 8, 2024 2:13 PM + Bradley T Gill  
wrote:





If you want a monitor, Nagios XI is a pretty affordable and effective
way.  MDB monitoring is part of it.



From: Quanah Gibson-Mount 
Sent: Tuesday, May 7, 2024 11:56 AM
To: Benjamin Renard ;
openldap-technical@openldap.org
Subject: [EXTERNAL] Re: How to properly monitor MDB usage



--On Tuesday, May 7, 2024 6: 07 PM +0200 Benjamin Renard
 wrote: > Hi, > > I'm looking for the
right method to monitor the usage of an MDB database > according to the
limit of its size imposed via the






--On Tuesday, May 7, 2024 6:07 PM +0200 Benjamin Renard

 wrote:




Hi,







I'm looking for the right method to monitor the usage of an MDB database



according to the limit of its size imposed via the parameter



olcDbMaxSize. Currently, I am using the following command:




If you are using a modern version of OpenLDAP, you can simply query the

monitor backend to get the necessary information to calculate usage, no

need to use mdb_stat at all.



--Quanah

Re: failed to add jpegPhoto attribute to sql backend

[Quanah Gibson-Mount]

--On Wednesday, May 8, 2024 9:52 AM +0700 Muchammad Nur Hidayat 
 wrote:








hi I'm having trouble adding the jpegPhoto attribute to sql, slapd is
sending the jpeg data to argv[2] as binary, not hex or base64. So it
can't be passed to the add_proc query in sql. is there an option or
configuration to set it to hex or base64.




As noted in the slapd-sql man page, that backend is entirely experimental 
and unsupported.  You use it at your own risk.


--Quanah

Re: how to identify users or service accounts that have write access

[Quanah Gibson-Mount]

--On Tuesday, May 7, 2024 3:38 PM -0700 Christopher Paul 
 wrote:




You start to answer this with an ldapsearch on the cn=config backend,
filtering on "olcaccess=*" and returning the olcaccess attribute values.


That's assuming they have something that can read olcAccess from cn=config. 
They could also be using slapd.conf, which may not have cn=config exposed. 
Better to follow your instructions about the documentation so they can 
learn how to read their configuration for slapd.


--Quanah

Re: how to identify users or service accounts that have write access

[Quanah Gibson-Mount]

--On Tuesday, May 7, 2024 10:09 PM + kalybox2...@gmail.com wrote:


In openldap 2.4, how to identify users or service accounts that have
write access. Can we do ldapsearch and find out?



Write access is controlled via the ACL statements of your slapd 
configuration.


I would also note that OpenLDAP 2.4 has been deprecated for several years 
and is no longer supported.


Regards,
Quanah

Re: How to properly monitor MDB usage

[Quanah Gibson-Mount]

--On Tuesday, May 7, 2024 6:07 PM +0200 Benjamin Renard 
 wrote:



Hi,

I'm looking for the right method to monitor the usage of an MDB database
according to the limit of its size imposed via the parameter
olcDbMaxSize. Currently, I am using the following command:


If you are using a modern version of OpenLDAP, you can simply query the 
monitor backend to get the necessary information to calculate usage, no 
need to use mdb_stat at all.


--Quanah

Not affected: gitlab cve-2023-7028

[Quanah Gibson-Mount]

Hello,

Community members may be aware of 



I wanted to note that the OpenLDAP self hosted gitlab instance is not 
affected by this vulnerability as we regularly update our gitlab instance.


Regards,
Quanah

Re: Query for attribute before adding new entry.

[Quanah Gibson-Mount]

--On Wednesday, May 1, 2024 6:39 PM -0500 Shawn McKinney 
 wrote:




How about the slapo-unique overlay to enforce uniqueness across the DIT
on the shared attribute and ldapmodify -c to continue on errors?

Or, what am I missing here about the req's?


That might be a solution? There's not enough detail in the requirements to 
say either way.


--Quanah

Re: Query for attribute before adding new entry.

[Quanah Gibson-Mount]

--On Wednesday, May 1, 2024 10:56 PM + "Singley, Norman" 
 wrote:





Hi All.



I have had a question come down from our Enterprise information team –



We currently create a separate identity in oldap for students vs
faculty/staff, but want to start creating only one identity going
forward.



The DN in the ldif is unique for these two identities, but they do share
a common attribute.



Is there a way in the ldapmodify add process to query the whole directory
for an attribute coming from the ldif file, and then if it doesn't
exist reject the add for that identity, and then of course go on
processing the rest of the file?



My gut says no, or at least not without some scripting that I am not
familiar with.


There's not a lot of detail here that makes it easy to answer, but in 
general I'd suggest using something like python-ldap, and then:


query for attribute
exists? reject
doesn't exist?
modify or add

It even has an LDIF parser, so you could theoretically give it your LDIF 
file and have it process per-entry as noted above.  You could do something 
similar with Perl's perl-ldap module as well.


--Quanah

RE: Replication Questions

[Quanah Gibson-Mount]

--On Tuesday, April 30, 2024 8:26 AM + BECOT Jérôme 
 wrote:




Is it included in the last 2.5 ?


The bug lists what the target release is.  In this case, 2.6.8.  It will 
not be included in 2.5.


--Quanah

RE: ldclt ldap performance testing

[Quanah Gibson-Mount]

--On Friday, April 26, 2024 5:42 PM + Marc  
wrote:



I just searched a bit and did some requests on https files and it looks
like most are reporting results between 100 - 200. So I guess this is
sort of ok.


So probably it would be faster if I authenticate users via a 'manager'
bind and wich has access to user dn/passwords? Or is it possible to use
an existing bind and 'switch' to a different user bind?


I've no clue what your question is really about, what you want to do, or 
why.


--Quanah

RE: cache userPassword with bind

[Quanah Gibson-Mount]

--On Thursday, April 25, 2024 8:24 AM + Marc  
wrote:



I am just testing if some application is efficiently authenticating with
a simple bind (and not doing searches) In a later stage I would like to
maybe optimize authenticating against ldap with credential caching.  When
I saw this I just thought I could do something with it. (In another
thread I posted about having binds max out at 150req/s, while searches
are ~9000req/s)


Again, you've failed to provide any useful information about your setup, 
along with using an ldap benchmarking tool I've never heard of, so it's 
difficult to really draw any conclusions.  Binds are always going to be 
slower than other operations since they involve things such as TLS (if 
used), DNS, and other items.  Well written LDAP clients bind, and then use 
a persistent connection to do their operations.


As far as ldctl, as best I can tell, it's a single host based benchmark 
system, which is generally not a valid way to benchmark LDAP, since clients 
are generally distributed.  In the past I've been trivially able to 
overwhelm the client's ability to do networking with tools like that. 
Valid LDAP benchmarking tools are distributed in nature (slamd, jmeter, 
etc) which better reflect real world traffic patterns.


--Quanah

RE: cache userPassword with bind

[Quanah Gibson-Mount]

--On Wednesday, April 24, 2024 8:37 PM + Marc  
wrote:



Am just testing with an alpine linux container and an ldap db with ~10
entries, almost nothing. Yet when I look in top res memory is 700MB. So I
assume everything is already cached, but I don't really get then this
logging. I don't even get why 700MB is being used, my data is probably a
few 100KB.


It's the ACL cache, which is internal and you have no control over.

You've provided virtually no information on your environment's 
configuration for slapd.  I would note that if you're seeing "result not in 
cache" then you have your logging level turned up insanely high on the 
server, which will slow down everything.


--Quanah

RE25 testing call (2.5.18) #1

[Quanah Gibson-Mount]

his is the first testing call for OpenLDAP 2.5.18.  Depending on the 
results, this may be the only testing call.


Generally, get the code for RE25:



Extract, configure, and build.

Execute the test suite (via make test) after it is built.  Optionally, cd 
tests && make its to run through the regression suite.


Thanks!

OpenLDAP 2.5.18 Engineering
   Fixed libldap exit handling with OpenSSL3 again (ITS#9952)
   Fixed slapd-meta with dynlist (ITS#10164)
   Fixed slapd-meta binds when proxying internal op (ITS#10165)
   Fixed slapo-accesslog startup initialization (ITS#10170)
   Fixed slapo-dynlist with abandoned operations (ITS#10044)
   Build
   Fixed build with gcc14.x (ITS#10166)
   Fixed back-perl with clang15 (ITS#10177)
   Minor Cleanup
   ITS#10171
   ITS#10173
   ITS#10179
   ITS#10186


Regards,
Quanah

RE26 testing call (2.6.8) #1

[Quanah Gibson-Mount]

This is the first testing call for OpenLDAP 2.6.8.  Depending on the 
results, this may be the only testing call.


Generally, get the code for RE26:



Extract, configure, and build.

Execute the test suite (via make test) after it is built.  Optionally, cd 
tests && make its to run through the regression suite.


Thanks!

OpenLDAP 2.6.8 Engineering
   Fixed libldap exit handling with OpenSSL3 again (ITS#9952)
   Fixed slapd-meta with dynlist (ITS#10164)
   Fixed slapd-meta binds when proxying internal op (ITS#10165)
   Added slapo-nestgroup overlay (ITS#10161)
   Added slapo-memberof 'addcheck' option (ITS#10167)
   Fixed slapo-accesslog startup initialization (ITS#10170)
   Fixed slapo-dynlist with abandoned operations (ITS#10044)
   Build
   Fixed build with gcc14.x (ITS#10166)
   Fixed back-perl with clang15 (ITS#10177)
   Contrib
   Added slapo-alias contrib module (ITS#10104, ITS#10182)
   Fixed slapo-autogroup to work with slapo-dynlist (ITS#10185)
   Documentation
   Fixed slapo-memberof exattr requirements (ITS#7400)
   Fixed slapo-memberof is no longer deprecated (ITS#7400)
   Minor Cleanup
   ITS#10103
   ITS#10171
   ITS#10172
   ITS#10173
   ITS#10179
   ITS#10186
   ITS#10188
   ITS#10193

Regards,
Quanah

Re: timeout and network-timeout values of zero for syncrepl in LAN replication

[Quanah Gibson-Mount]

--On Monday, April 8, 2024 3:08 PM +0900 Christopher Paul 
 wrote:




Hello OpenLDAP-technical list,

I'm curious about community perspectives on a specific LDAP replication
timeout and network-timeout settings:


Setting "timeout=0" or "network-timeout=0" within a syncrepl/olcSyncrepl
definition for replication settings is not the best practice for LAN
environments. These parameters, when set to zero, instruct syncrepl to
wait indefinitely for connections and replication operations to conclude.


Within a LAN context, establishing new connections should ideally occur
in less than a second. Delays beyond a couple of seconds should kick in
the retry logic. This suggests that a more fitting network-timeout range
is between 1 to 5 seconds.

Concerning the "timeout" parameter, the ideal range might be between 60
to 120 seconds, to handle operations exceeding a minute, but again,
kicking in retry logic if they exceed two minutes. I admit that my stance
on the "timeout" setting is tentative, given that search operation
duration hinges more on the provider's responsiveness rather than network
speed alone.

This approach ensures that LDAP replication remains both responsive and
resilient, without compromising on efficiency or performance. Thoughts?


It's generally never been an issue in the networks I've been on.  Also with 
refreshAndPersist these settings are only for the initial connection.  If I 
was doing refreshOnly I'd definitely want to tweak them.  I'd make sure and 
set the tcp keepalive settings as well for sync replication, because the 
biggest grief I've had since moving to syncrepl around 2006 is with 
firewalls and other network devices.


There was someone I corresponded with many years ago who was doing syncrepl 
in an unstable network environment (their nodes were distributed across 
Mexico IIRC, and the links were not stable), and managed to get it solid 
when tweaking the parameters you mention.  If they're still active, it'd be 
interesting to hear their feedback.


--Quanah

Re: Strange search result in logs

[Quanah Gibson-Mount]

--On Wednesday, March 27, 2024 11:28 AM +0100 Frédéric Goudal 
 wrote:



Hello,

I'm trying to analyse the requests done to my ldapserver from a  nas.
While browsing the logs I found the following entries :

I have no specific ACL on the ip quering.



Do you have any "limits" directives in your configuration?

--Quanah

RE: [EXTERNAL] how to migrate an openldap server to a new linux server

[Quanah Gibson-Mount]

--On Wednesday, March 27, 2024 1:07 AM + xpzhang1...@gmail.com wrote:


I did ldapsearch to export schema from source ldap server, cmd is:
ldapsearch -x -LLL -H "ldap://xxx:389; -D
"cn=admin,ou=AdminUsers,dc=example,dc=com" -W -b "cn=schema" -o
ldif-wrap=no > source-schema.ldif

but ldapadd this ldif to target server still report:
[root@phx-ldap-ol8 openldap]# ldapadd -H ldap:/// -D
"cn=admin,dc=oracle,dc=com" -W -f /tmp/source-schema.ldif adding new
entry "dc=example,dc=com"
ldap_add: Object class violation (65)


That will not give you schema usable for ldapadd.

--Quanah

RE: [EXTERNAL] how to migrate an openldap server to a new linux server

[Quanah Gibson-Mount]

--On Tuesday, March 26, 2024 11:57 PM + xpzhang1...@gmail.com wrote:


I gave a try like this way:
I installed an openldap 2.6 as target server, started it up with initial
slapd.ldif.  Then I tried to ldapadd entries that exported from source
server, but failed on the first entry, error message:

the ldif file like:
dn: dc=example,dc=com
dc: example
objectClass: top
objectClass: domain
objectClass: nisDomainObject
nisDomain: example.com

What's wrong with objectClass??



You're missing the schema that defines it.

--Quanah

RE: [EXTERNAL] how to migrate an openldap server to a new linux server

[Quanah Gibson-Mount]

--On Monday, March 25, 2024 6:42 PM + xpzhang1...@gmail.com wrote:


Tech Folks, thanks for your replies.
In real world, we often face such tasks to take over a thing that not
belong to you, and you even only have limited access to that thing.

Is there a way figuring out configuration, schema, and etc from ldif
files generated by ldapsearch from source server? then to configure a
fresh target openldap server with those information to have the target
server exactly same as source server?


You can query the cn=subschema entry for the server schema, but that 
doesn't mean all the schema returned is in use.


However, without having the server configuration (including what overlays, 
etc, are in use) you cannot reproduce the server functionality.  IF it 
exposes the configuration via cn=config with ldapsearch, then you could get 
the configuration that way.  Without the configuration, you could be 
missing critical pieces such as password policies, uniqueness constraints, 
etc.  You also have no idea whether or not your "ldapsearch" output 
includes the full database or only a portion of the database (or even just 
portions of entries) since you have no idea what limitations via ACLs have 
been placed on your search.


Regards,
Quanah

RE: Help debugging slave slapd issues

[Quanah Gibson-Mount]

--On Monday, March 25, 2024 6:06 PM + Christopher Paul 
 wrote:



Those aren't errors.


But a deferral is not optimal, is it? I think the question "hints about
way to debug" is probably a good one. The brute force method to fix this
would be to add consumers and spread out the load. Horizontal scaling is
the main benefit of a replicated architecture.


Deferrals are common, they are not necessarily indicative of an issue, and 
without more detail there's no way to determine there is an issue that 
needs to be addressed or not.


--Quanah

Re: Help debugging slave slapd issues

[Quanah Gibson-Mount]

--On Monday, March 25, 2024 3:49 PM + BECOT Jérôme 
 wrote:




Hello,


On all different OpenLDAP 2.4 and 2.5 slaves of 2.4 servers, we see a lot
of deferring errors:
slapd[37277]: connection_input: conn=32974 deferring operation: too many
executing
or
slapd[37277]: connection_input: conn=32974 deferring operation: pending
operations


Those aren't errors.

--Quanah

RE: [EXTERNAL] how to migrate an openldap server to a new linux server

[Quanah Gibson-Mount]

--On Monday, March 25, 2024 4:51 PM + xpzhang1...@gmail.com wrote:


Because port 22 is not open, I can't ssh or rlogin to the server. only
can run ldapsearch such client commands.  nmap to the server only see
port 389 and 636 open. I don't know how the server owner maintain,
startup/stop the server.



The only way to get a known good backup of the server is to be able to log 
into the server so you can obtain not only the database, but also the slapd 
configuration.  Since you lack access to this system, it sounds like you're 
not supposed to have that level of access.


--Quanah

Re: Configure replication without a plaintext password.

[Quanah Gibson-Mount]

--On Friday, March 8, 2024 5:42 PM + mbala...@opentext.com wrote:


How to configure olcSyncrepl without a plaintext password? I tried using
credentials="{SSHA256}jRlrKRCcrhYo7SqbPDc5WkoSxaHc8y/e0DPWaAnveUkQpQ7wEOW
hsw==" format. Does olcSyncrepl accepts password in {SSHA256} format?




You will need to use a passwordless SASL mechanism, as others have noted. 
If you peruse the test suite, you will see that test068-sasl-tls-external 
configures SASL/EXTERNAL certificate authentication in an OpenLDAP server. 
I use SASL/EXTERNAL certificate authentication in my replication setup.


Regards,
Quanah

Re: OpenLDAP SQL

[Quanah Gibson-Mount]

--On Tuesday, March 5, 2024 3:59 PM + Howard Chu  wrote:


kimkihoon  wrote:

I'm trying to use mysql external db server for openLDAP db.
I just read this README file from openldap
github(https://github.com/openldap/openldap/blob/master/servers/slapd/ba
ck-sql/rdbms_depend/README) But it seems only localhost server can be
used.
Can anyone tell me how?


Examples in documentation are only examples, nothing more. You can use
any valid ODBC configuration but nobody has time to write every possible
config value and use case out.



I would add that back-sql is experimental, unmaintained, and known to have 
numerous bugs.  Additionally SQL is not a good fit as a backend to LDAP and 
will be significantly slower than using a native database such as back-mdb.


--Quanah

Re: Fwd: New Ldap 2.6.6 in Kubernetes

[Quanah Gibson-Mount]

--On Friday, March 1, 2024 12:57 PM +0530 Jignesh Patel  
wrote:









We have set up a new docker OpenLDAP Version 2.6.6 on Kubernetes.


We could migrate all the data except the following two
attributesauthTimestamp and 
lastLoginTime 
not working in personalized schema.


How to configure them?


On the surface, it sounds like you didn't migrate your slapd configuration.

--Quanah

RE: Disable uniqueness for mail Attribute

[Quanah Gibson-Mount]

--On Friday, March 1, 2024 1:46 PM + CALDEIRA JAVIEL Sandro 
 wrote:



Hi Geert,

You are right. phpldapadmin was blocking this import. I ran manually
ldapadd  and it worked.


Hi,

Good catch Geert. I've been advising people against using phpldapadmin for 
nearly 20 years, for differing reasons. Looks like that advice should still 
stand.



Also, just to note, this sounds like you're not importing your database 
correctly, unless you want to destroy replication and invalidate your 
cluster.


The supported method for exporting and importing a database is slapcat to 
export, slapadd to import.


Regards,
Quanah

RE: Disable uniqueness for mail Attribute

[Quanah Gibson-Mount]

--On Thursday, February 29, 2024 8:11 PM + CALDEIRA JAVIEL Sandro 
 wrote:



Hi Quanah,

I am running openldap from bitnami docker -
https://github.com/bitnami/containers/tree/main/bitnami/openldap/2.6/debi
an- 12

So there is not slapd.conf:
$ slapcat -n 0
could not stat config file
"/opt/bitnami/openldap/etc/openldap/slapd.conf": No such file or
directory (2)
slapcat: bad configuration file!


So clearly not using slapd.conf.  I realize you do have to specify -F 
/path/to/slapd/config for the slapcat to work.


But since you searched the config and there's no slapo-unique loaded, 
you're not using it.  This would imply that your database has bad data in 
it, where there are duplicate values for the "mail" attribute IN a single 
entry like:


uid=joe,ou=whatever,dc=example,dc=org
...
mail: j...@example.com
mail: j...@example.com


Would count as duplicates, for example.  Most likely validation checks 
during slapadd were improved between 2.4 and 2.6, so those errors are now 
being caught.  You'll need to clean your database to be correct.


--Quanah

RE: Disable uniqueness for mail Attribute

[Quanah Gibson-Mount]

--On Thursday, February 29, 2024 1:35 PM + CALDEIRA JAVIEL Sandro 
 wrote:



Hi Quanah,

I am not sure how slapo-unique works. I am struggling with the syntax. How
can I check current config concerning it?


Does your configuration even use slapo-unique? That's the first question 
you need to answer.  Assuming you are using cn=config, you can use slapcat 
-n 0 -l /tmp/config.ldif to export your full configuration and examine it 
to see if it uses the unique overlay at all.


--Quanah

Re: Disable uniqueness for mail Attribute

[Quanah Gibson-Mount]

--On Wednesday, February 28, 2024 7:34 AM + CALDEIRA JAVIEL Sandro 
 wrote:



Hi,

I have a legacy ldap instance (openlda-2.4) which has in the same
redundant user info containing mail attribute among others (objectclass:
inetOrgPerson) in 2 different ous (objectclass: organizationalUnit). I
know it is a bad design for ldap users structure but I am not allowed to
change it in a short time. When I tried to migrate this ldap database to
openldap 2.6 I realize this is not possible anymore. I identified it is
just related to mail attribute because if I omit mail attribute or use a
different value for mail, then all data is imported properly.


Do you use the slapo-unique overlay?

The only uniqueness requirement on mail out of the box is that for any 
specific entry, the mail value must be unique.  There is no requirement 
*across* subtrees that it be unique unless the configuration loads and uses 
slapo-unique to do this.


If you have duplicate values for 'mail' within a given entry, then you need 
to fix that.


--Quanah

Re: postscript(subject:I lost all data(perhaps))

[Quanah Gibson-Mount]

--On Tuesday, February 13, 2024 11:12 AM +0900 長田 泰志 
 wrote:



Sorry!

There was something missing in the question you asked earlier, so I'll
add it.

c.The method of restoring the slave (2.6.3) system uses ldapadd to
restore the backup data obtained by ldapsearch, so the entryUUID has been
changed.


This is not a valid way to backup and restore data.  The correct way to 
backup and restore is with slapcat to export and slapadd to import it.  As 
you've followed in invalid path for your migration, the result is expected.


I would additionally note that OpenLDAP 2.6.3 is quite old.  The current 
stable release in the OpenLDAP 2.6 series is 2.6.7.


Regards,
Quanah

Re: ldapi issue

[Quanah Gibson-Mount]

--On Monday, February 12, 2024 5:09 PM + Chili Mili 
 wrote:



find / -type s
find: '/proc/9/map_files': Permission denied
/usr/var/run/ldapi

The Unix socket file located inside the container is at
/usr/var/run/ldapi. I have tried to mount it to the host system but
encountered the same result.

any idea?


This sounds like the slapd process is being told to use a different 
location than the compile time default for the unix socket, which is why 
ldapi:/// doesn't work (it defaults to the compile time location).  You'll 
have to explicitly pass the location OR change the startup to just use the 
default location.


--Quanah

Re: Openldap 2.4 -> Openldap 2.6.3 replication hurdles

[Quanah Gibson-Mount]

--On Thursday, January 25, 2024 9:48 AM +0200 Viktor Keremedchiev 
 wrote:



If I use olcServerID: 1 ldaps://prod-ldap1.domain.com - server doesn't
start post ldapmodify.


Sounds like this doesn't match the options passed to slapd at startup.  I 
do note your missing a port at the end of the URI which may be why.


--Quanah

Re: Upgrade from 2.4.x to 2.6.x

[Quanah Gibson-Mount]

--On Tuesday, February 6, 2024 2:29 PM + Sajesh Singh  
wrote:




Good day OpenLDAP folks. I am looking to upgrade our current OpenLDAP to
the latest 2.6 release from my current install of 2.4.44. I am wondering
if:


1) Is it possible to have one master running 2.4.44 and another running
the latest 2.6 replicating to each other?
2) Is replication possible between hosts that have a mixture of:
a) slapd.conf & cn=config
b) hdb and mdb


It will depend somewhat on what you're replicating.  If your 2.6 cn=config 
has 2.6 specific config options, then you cannot replicate cn=config. 
There's no such thing as "slapd.conf" replication.  If you're not 
replicating configurations, just the primary hdb/mdb database, the it 
doesn't matter if one set of systems is using cn=config and the other set 
is using slapd.conf.


The way in which the underlying database is stored (hdb/mdb) does not 
matter in terms of replication, because what's replicated are LDIF 
operations, not binary data.


--Quanah

Re: The unique overlay: enforcing uniqueness in the union of trees

[Quanah Gibson-Mount]

--On Tuesday, February 6, 2024 4:27 PM + Norman Gray  
wrote:




Store what department(s) they belong to as attribute in their user entry.


I take the point, and I certainly wouldn't organise things this way if
_I_ were king.

In this case, though, dept1, dept2, and so on, are separate
administrative domains, in both IT terms and real bureaucratic ones, and
this is an attempt to bring some sort of coherence to a bit of historic
anarchy (and yes, there is an ou=staff layer in the middle of the real
trees).

Everyone more-or-less agrees on the names and uidNumbers in dept1, but
there might be a local 'norman' in both dept2 and dept3, or people in
those trees with historically colliding UIDs.  The result is that systems
in dept2 will acknowledge users in ou=dept1 and ou=dept2, users in dept3
acknowledge ou=dept1 and dept3 but ignore ou=dept2, and so on.  I expect
that names will soon no longer be created in the deptN trees (pretty
please?), in favour of the dept1 tree, and the ou=staff parts of those
will atrophy, but I'll be retired by then.

If there's a different way of approaching that particular problem,
though, right now is the time for me to be rethinking this, so I'm open
to challenge.


Ah, ok I thought you were setting up a new server.  Since it was 
historically done this way, yeah, best thing is to slowly fix the data 
until it can be done correctly.  Sounds like it would take an institutional 
commitment to resolving the collisions to ever fix this fully.


--Quanah

Re: The unique overlay: enforcing uniqueness in the union of trees

[Quanah Gibson-Mount]

--On Tuesday, February 6, 2024 12:29 PM + Norman Gray  
wrote:





Greetings.

How should I use the 'unique' overlay to enforce uniqueness of an
attribute across two trees?

I'd have thought that the following would work, to enforce uniqueness
across ou=dept1 and ou=dept2, but it doesn't seem to.


Questions about slapo-unique aside, this is a horrific way to organize your 
data tree.  I'd strongly advise creating a tree for people, like:


cn=people,dc=example,dc=com

uid=x,cn=people,dc=example,dc=com
uid=y,cn=people,dc=example,dc=com

Store what department(s) they belong to as attribute in their user entry.

--Quanah

otp vs totp

[Quanah Gibson-Mount]

--On Thursday, February 1, 2024 10:55 AM +0100 Bastian Tweddell 
 wrote:



The reason was, that we use it as a TOTP-only solution.
I had a testsetup with slapo-otp as well, but this module required
userPassword + TOTP, IIRC; where we cannot not have userPassword.

Our setup is to use TOTP as 2FA for ssh logins against the centralized
LDAP infrstructure. The ssh-login 1FA is ssh pubkey (also in LDAP) and
2FA is TOTP. To achieve this we use a PAM module which does an ldapbind
against the user-DN which has the userPassword schema '{TOTP1}'.

Maybe I wrong or outdated here and slapo-opt also supports TOTP-only
authentication now?


After discussion in today's project team meeting, we've opened an issue to 
have this supported by slapo-otp in the future:




If you follow that bug, once a solution is in, we'd always welcome testing 
of it. :)


Regards,
Quanah

Re: UNKNOWN attributeDescription "..." inserted.

[Quanah Gibson-Mount]

--On Thursday, February 1, 2024 10:55 AM +0100 Bastian Tweddell 
 wrote:



Our setup is to use TOTP as 2FA for ssh logins against the centralized
LDAP infrstructure. The ssh-login 1FA is ssh pubkey (also in LDAP) and
2FA is TOTP. To achieve this we use a PAM module which does an ldapbind
against the user-DN which has the userPassword schema '{TOTP1}'.

Maybe I wrong or outdated here and slapo-opt also supports TOTP-only
authentication now?


Ok, makes sense. Yeah, OTP does not support that scenario at this time.

--Quanah

Re: UNKNOWN attributeDescription "..." inserted.

[Quanah Gibson-Mount]

--On Wednesday, January 31, 2024 4:16 PM + Howard Chu  
wrote:



Note that contrib modules are explicitly not maintained by the Project.
You'll need to find someone in the community to fix these issues for you.


I'd also wonder why you're not using the official OTP overlay:



which is maintained by the project.

Regards,
Quanah

RE: [EXTERNAL] Re: Openldap 2.4 -> Openldap 2.6.3 replication hurdles

[Quanah Gibson-Mount]

--On Wednesday, January 24, 2024 4:42 PM + Bradley T Gill 
 wrote:





We stay in the 2.5 LTS branch.  2.6 is more of a Dev Branch if I
understand it correctly.


2.5 is the current LTS release.  2.6 was the new 'feature' branch.  It may 
become the next LTS.  I've personally run it in production at a high volume 
100% uptime environment for over 2 years.


--Quanah

Re: Openldap 2.4 -> Openldap 2.6.3 replication hurdles

[Quanah Gibson-Mount]

--On Wednesday, January 24, 2024 8:28 AM +0200 Viktor Keremedchiev 
 wrote:



Hello,
I'm somewhat not experienced with LDAP on the server side of things
I'm importing openldap 2.4. into 2.6.3. (rockylinux 9). My goal is to 2
have 2 N-way (or multi-master*) ldap nodes. I've changed hdb to mdb,
created accesslog folder, fixed permissions, SSL etc
The import doesn't throw any errors. My understanding is that I need to
have cn=config replication, as well as my small dc=domain,dc=com,
replication as well


It is not required to have cn=config replication. And I would note that 
OpenLDAP 2.6.3 is fairly old at this point with significant fixes done to 
the 2.6 series since its release.  I'd advise using a current release of 
OpenLDAP 2.6.



The cn=config replication I call via this on both nodes followed by
restarts


dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1


Each server must have its own, unique, serverID.  If you are going to use 
cn=config replication, then you *must* use the


olcServerID: # URI

format.



Now once I do that I've experimented with changing the olcLogLevel and
it seems to work. The rid's on each node are different server2 has
rid=002, server 1 has rid=001 as well as different olcServerID


RIDs must be unique INSIDE a particular server, but different servers can 
use the same RID values.



What am I doing wrong? Perhaps more than one thing


I'd suggest starting with just getting back-mdb replication working between 
the nodes.


Side note, your configuration for the accesslog DB is missing an index on 
'reqDN'.


--Quanah

Re: Performance tuning in Openldap 2.4

[Quanah Gibson-Mount]

--On Wednesday, January 24, 2024 3:53 AM + kalybox2...@gmail.com wrote:


Hello Team,

What are the various Tuning parameters that we should look at for
performance tuning Openldap 2.4? 1. Indexing (See logs and find out if
any unindexed searches, and index them as needed) 2. DB_CONFIG tuning
various parameters such as cachesize etc

Anything else, please let me know.


First thing would be to establish which OpenLDAP backend you are using.  If 
you are using a BDB based backend (back-bdb, back-hdb) then the first thing 
you need to do is migrate to the LMDB based backend, back-lmdb.  That would 
be required prior to upgrading to OpenLDAP 2.5 or later, as well.


Beyond that, I would strongly advise reading the section on indexing in the 
OpenLDAP 2.5 admin guide.  Indexing may or may not be beneficial depending 
on the specific use case.


Regards,
Quanah

Re: Upgrade Openldap software from 2.4 to 2.6

[Quanah Gibson-Mount]

--On Wednesday, January 24, 2024 12:07 AM + kalybox2...@gmail.com wrote:


Hello,
I would like to upgrade the openldap software from 2.4 to 2.6 version.
Can you please describe the high level steps involved?
Is it going to be in place upgrade?
Or we need to install a new 2.6 instance and export the data from old 2.4
and import into 2.4? Pleas elet me know


I would start with reading the UPGRADE section of the Admin guide for 
OpenLDAP 2.5, since that covers moving from OpenLDAP 2.4 to OpenLDAP 2.5. 
You may also find  useful.


Regards,
Quanah

RE: [EXTERNAL] How to check the version of openldap running

[Quanah Gibson-Mount]

--On Monday, January 22, 2024 8:51 PM + Bradley T Gill  
wrote:





Install location/bin/ldapsearch -VV


That tells you the version of the client ldapsearch binary.  It may or may 
not match the server.  Better to read the slapd(8C) man page which 
documents the options to slapd to get the version information.


--Quanah

Re: How to check the version of openldap running

[Quanah Gibson-Mount]

--On Monday, January 22, 2024 5:54 PM + kalybox2...@gmail.com wrote:


How to check the current openldap version software running? I am told its
2.4.  But is there a command to validate?


Hello,

This is literally documented in the options section of the man page for 
slapd(8C): 
. 
slapd also generally logs what version it is when it starts (although some 
OS builds strip this out).  If you installed slapd via some packaging 
method (yum, apt, etc), then those tools will tell you the version of slapd 
as well.


Regards,
Quanah

Re: RE25 testing call (2.5.17) #1

[Quanah Gibson-Mount]

--On Saturday, January 20, 2024 9:19 PM + Howard Chu  
wrote:

Thanks for the feedback. This was a merge conflict from mdb.master. You
have the correct fix above, and it's now committed in mdb.RE/0.9
5eb93a3b8a3b6139da9321117ea013ea6c95c2c4

The fix will have to be merged to RE25 and RE26 as well.



Thanks for the report Armin, and thanks for the quick fix Howard.  This is 
now updated for RE25, RE26, and master.


Regards,
Quanah

Re: RE25 testing call (2.5.17) #1

[Quanah Gibson-Mount]

I sent this yesterday, but many people didn't get it due to the mailman 
upgrade issue that's now resolved.


Thanks!

--Quanah

--On Thursday, January 18, 2024 11:26 AM -0800 Quanah Gibson-Mount 
 wrote:



This is the first testing call for OpenLDAP 2.5.17.  Depending on the
results, this may be the only testing call.

Generally, get the code for RE25:

<https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_
5/openldap-OPENLDAP_REL_ENG_2_5.tar.gz>

Extract, configure, and build.

Execute the test suite (via make test) after it is built.  Optionally, cd
tests && make its to run through the regression suite.

Thanks!

OpenLDAP 2.5.17 Engineering
Fixed liblber missing newline on long msg (ITS#10105)
Fixed libldap exit handling with OpenSSL3 (ITS#9952)
Fixed libldap with TLS and multiple ldap URIs (ITS#10101)
Fixed libldap OpenSSL cipher suite handling (ITS#10094)
Fixed libldap OpenSSL 3.0 and Diffie-Hellman param files
(ITS#10124)
Fixed libldap timestamps on Windows (ITS#10100)
Fixed lloadd to work when resolv.conf is missing (ITS#10070)
Fixed lloadd handling of closing connection (ITS#10083)
Fixed slapd handling of regex testing in ACLs (ITS#10089)
Fixed slapd-asyncmeta when remote suffix is empty (ITS#10076)
Fixed slapo-dynlist so it can't be global (ITS#10091)
Build
Fixed lloadd type mismatches (ITS#10074)
Fixed builds for Windows (ITS#10117)
Fixed build with clang16 (ITS#10123
Documentation
Fixed slapo-homedir(5) attribute name for
olcHomedirArchivePath (ITS#10057)
Minor Cleanup
ITS#10059
ITS#10068
ITS#10109
ITS#10110
ITS#10129
ITS#10130
ITS#10135
ITS#10144
ITS#10145
ITS#10153

Regards,
Quanah

Re: RE26 testing call (2.6.7) #1

[Quanah Gibson-Mount]

I sent this yesterday, but many people didn't get it due to the mailman 
upgrade issue that's now resolved.


Thanks!

--Quanah

--On Thursday, January 18, 2024 11:25 AM -0800 Quanah Gibson-Mount 
 wrote:



This is the first testing call for OpenLDAP 2.6.7.  Depending on the
results, this may be the only testing call.

Generally, get the code for RE26:

<https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_
6/openldap-OPENLDAP_REL_ENG_2_6.tar.gz>

Extract, configure, and build.

Execute the test suite (via make test) after it is built.  Optionally, cd
tests && make its to run through the regression suite.

Thanks!

OpenLDAP 2.6.7 Engineering
Fixed liblber missing newline on long msg (ITS#10105)
Fixed libldap exit handling with OpenSSL3 (ITS#9952)
Fixed libldap with TLS and multiple ldap URIs (ITS#10101)
Fixed libldap OpenSSL cipher suite handling (ITS#10094)
Fixed libldap OpenSSL 3.0 and Diffie-Hellman param files
(ITS#10124)
Fixed libldap timestamps on Windows (ITS#10100)
Fixed lloadd to work when resolv.conf is missing (ITS#10070)
Fixed lloadd handling of closing connection (ITS#10083)
Fixed lloadd tiers to be correctly linked on startup (ITS#10142)
Fixed slapd handling of regex testing in ACLs (ITS#10089)
Fixed slapd sync replication with glued database (ITS#10080)
Fixed slapd local logging on Windows (ITS#10092)
Fixed slapd-asyncmeta when remote suffix is empty (ITS#10076)
Fixed slapo-dynlist so it can't be global (ITS#10091)
Build
Fixed lloadd type mismatches (ITS#10074)
Fixed builds for Windows (ITS#10117)
Fixed build with clang16 (ITS#10123)
Documentation
Fixed slapo-homedir(5) attribute name for
olcHomedirArchivePath (ITS#10057)
Minor Cleanup
ITS#10059
ITS#10068
ITS#10098
ITS#10109
ITS#10110
ITS#10129
ITS#10130
ITS#10135
ITS#10143
ITS#10144
ITS#10145
ITS#10153

Regards,
Quanah

RE25 testing call (2.5.17) #1

[Quanah Gibson-Mount]

This is the first testing call for OpenLDAP 2.5.17.  Depending on the 
results, this may be the only testing call.


Generally, get the code for RE25:



Extract, configure, and build.

Execute the test suite (via make test) after it is built.  Optionally, cd 
tests && make its to run through the regression suite.


Thanks!

OpenLDAP 2.5.17 Engineering
   Fixed liblber missing newline on long msg (ITS#10105)
   Fixed libldap exit handling with OpenSSL3 (ITS#9952)
   Fixed libldap with TLS and multiple ldap URIs (ITS#10101)
   Fixed libldap OpenSSL cipher suite handling (ITS#10094)
   Fixed libldap OpenSSL 3.0 and Diffie-Hellman param files (ITS#10124)
   Fixed libldap timestamps on Windows (ITS#10100)
   Fixed lloadd to work when resolv.conf is missing (ITS#10070)
   Fixed lloadd handling of closing connection (ITS#10083)
   Fixed slapd handling of regex testing in ACLs (ITS#10089)
   Fixed slapd-asyncmeta when remote suffix is empty (ITS#10076)
   Fixed slapo-dynlist so it can't be global (ITS#10091)
   Build
   Fixed lloadd type mismatches (ITS#10074)
   Fixed builds for Windows (ITS#10117)
   Fixed build with clang16 (ITS#10123
   Documentation
   Fixed slapo-homedir(5) attribute name for 
olcHomedirArchivePath (ITS#10057)

   Minor Cleanup
   ITS#10059
   ITS#10068
   ITS#10109
   ITS#10110
   ITS#10129
   ITS#10130
   ITS#10135
   ITS#10144
   ITS#10145
   ITS#10153

Regards,
Quanah

RE26 testing call (2.6.7) #1

[Quanah Gibson-Mount]

This is the first testing call for OpenLDAP 2.6.7.  Depending on the 
results, this may be the only testing call.


Generally, get the code for RE26:



Extract, configure, and build.

Execute the test suite (via make test) after it is built.  Optionally, cd 
tests && make its to run through the regression suite.


Thanks!

OpenLDAP 2.6.7 Engineering
   Fixed liblber missing newline on long msg (ITS#10105)
   Fixed libldap exit handling with OpenSSL3 (ITS#9952)
   Fixed libldap with TLS and multiple ldap URIs (ITS#10101)
   Fixed libldap OpenSSL cipher suite handling (ITS#10094)
   Fixed libldap OpenSSL 3.0 and Diffie-Hellman param files (ITS#10124)
   Fixed libldap timestamps on Windows (ITS#10100)
   Fixed lloadd to work when resolv.conf is missing (ITS#10070)
   Fixed lloadd handling of closing connection (ITS#10083)
   Fixed lloadd tiers to be correctly linked on startup (ITS#10142)
   Fixed slapd handling of regex testing in ACLs (ITS#10089)
   Fixed slapd sync replication with glued database (ITS#10080)
   Fixed slapd local logging on Windows (ITS#10092)
   Fixed slapd-asyncmeta when remote suffix is empty (ITS#10076)
   Fixed slapo-dynlist so it can't be global (ITS#10091)
   Build
   Fixed lloadd type mismatches (ITS#10074)
   Fixed builds for Windows (ITS#10117)
   Fixed build with clang16 (ITS#10123)
   Documentation
   Fixed slapo-homedir(5) attribute name for 
olcHomedirArchivePath (ITS#10057)

   Minor Cleanup
   ITS#10059
   ITS#10068
   ITS#10098
   ITS#10109
   ITS#10110
   ITS#10129
   ITS#10130
   ITS#10135
   ITS#10143
   ITS#10144
   ITS#10145
   ITS#10153

Regards,
Quanah

Re: Plans for the next LTS release?

[Quanah Gibson-Mount]

Hi Sergio,

I'm requesting Matt Hardin to answer this.

Regards,
Quanah

--On Wednesday, January 3, 2024 10:30 PM -0500 Sergio Durigan Junior 
 wrote:



On Thursday, September 28 2023, Sergio Durigan Junior wrote:


Hi there,

Two years ago I sent an announcement mentioning that the OpenLDAP 2.5.x
series was accepted for a Micro Release Exception in Ubuntu Jammy
(20.04).  This meant that I'd be able to release any updates to the
2.5.x series on Jammy, which I have been doing since then.

We are now getting ready to work on the next Ubuntu LTS release, which
will come out next April.  I seem to remember upstream discussions
mentioning that the next OpenLDAP LTS release would likely be the 2.7.x
series, but I don't remember seeing anything else about it.  Are there
any plans to start working on the OpenLDAP LTS major series?


Hi,

Just reiterating my question above, it would be great to have more
information regarding plans for the next OpenLDAP LTS release.

Thanks,

--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14

Re: libldap with openssl

[Quanah Gibson-Mount]

--On Wednesday, January 10, 2024 4:38 PM -0300 dextá 
 wrote:




Quanah,


Regarding ltb, which package contains libldap?



Ok looks like LTB project doesn't separate it out.



and Symas?
https://repo.symas.com/repo/deb/main/release25/pool/main/s/symas-openldap/


Pretty apparent:

symas-openldap-lib

--Quanah

Re: libldap with openssl

[Quanah Gibson-Mount]

--On Wednesday, January 10, 2024 4:01 PM -0300 dextá 
 wrote:




hello, thanks for the answers!!

@quanah, Is it possible to install only libldap with openssl and not the
whole of openldap?


I know the Symas packages provide libldap separately from the server 
package.  I believe the LTB project does as well.


Regards,
Quanah

Re: Modify default port 389 to custom port 11389 for openldap-servers

[Quanah Gibson-Mount]

--On Wednesday, January 10, 2024 10:49 PM +0530 Kaushal Shriyan 
 wrote:



Please guide me. Thanks in advance.


Read the slapd(8C) man page, specifically the '-h' option.

I would additionally note that the Symas packages you are using include 
configuration files for what URI(s) slapd should use with the -h argument 
for 2.4, and for 2.5+ it can source a configuration file for systemd for 
those URI(s).


Regards,
Quanah

Re: Backup and restore OpenLdap server 2.4.59.

[Quanah Gibson-Mount]

--On Tuesday, January 2, 2024 10:38 PM +0530 Kaushal Shriyan 
 wrote:




Hi,



I am running OpenLdap server 2.4.59 on Red Hat Enterprise Linux release
8.8 (Ootpa) OS in standalone mode without any replication. 


# rpm -qa | grep openldap
symas-openldap-servers-2.4.59-1.el8.x86_64
openldap-2.4.46-18.el8.x86_64
symas-openldap-2.4.59-1.el8.x86_64
symas-openldap-clients-2.4.59-1.el8.x86_64
# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.8 (Ootpa)
#



As per this https://repo.symas.com/, I see 2.5 LTS and 2.6 current
feature release, I am not sure which one I need to upgrade from 2.4 →
2.5 or 2.6? Also, is there a way to back up and restore OpenLdap server
2.4.59?



You can upgrade from 2.4 to 2.5 or 2.6.  There are upgrade instructions on 
the Symas website you linked to and in the OpenLDAP administrators guide. 
I would additionally note that you should familiarize yourself with the 
"slapcat" and "slapadd" utilities, for backing up both the binary and 
configuration databases.


Regards,
Quanah

Re: libldap with openssl

[Quanah Gibson-Mount]

--On Wednesday, January 10, 2024 2:22 PM -0300 Lucas Castro 
 wrote:




Em 10/01/2024 13:59, dextá escreveu:

Hello,

Is there a way to compile only the libldap with OpenSSL? I ask because
I have installed on Debian 12 a version that uses GnuTLS, and I need
to change it to OpenSSL.


Hello Dexter,

Debian openldap is already build against openSSL. Guess there's some
other package on your debian that require GnuTLS installed.

But openldap is really build against openSSL.


This is incorrect.  The OpenLDAP shipped by Debian is built against GnuTLS, 
not OpenSSL.  If an OpenSSL linked version of OpenLDAP for Debian is 
desired, I would suggest using the packages from Symas or the LTB project.






Regards,
Quanah

Re: superuser and normal user in OpenLdap services

[Quanah Gibson-Mount]

--On Wednesday, December 13, 2023 11:31 PM +0530 Kaushal Shriyan 
 wrote:



Please guide me. Thanks in advance.


The "rootdn" for a database has full access to that database regardless of 
ACLs.


--Quanah

Re: SSL certificate install

[Quanah Gibson-Mount]

--On Wednesday, December 13, 2023 7:51 AM + Jean-Luc Chandezon 
 wrote:





Hello dear community,



I'm trying to enable LDAPS. I don't understanrd what is cause error.
Is anybody have an idea please?



This almost always means that the slapd process cannot access one or more 
of the file(s) in question, due to some type of permission issue.


--Quanah

Re: lloadd and cn=config

[Quanah Gibson-Mount]

--On Thursday, December 7, 2023 5:23 PM +0100 Stefan Kania 
 wrote:



I added:
--
database config
rootdn "cn=admin,cn=config"
rootpw config
--
to the slapd.conf. After adding slapd is still working with slapd.conf
then I converted the slapd.conf with:
slaptest -F /opt/symas/etc/openldap/slapd.d -f
/opt/symas/etc/openldap/slapd.conf


My question was more, once you add the database config block, if you 
ldapsearch the cn=config database it generates, does it match what you get 
from slatpest conversion.


--Quanah

Re: lloadd and cn=config

[Quanah Gibson-Mount]

--On Wednesday, December 6, 2023 8:11 PM +0100 Stefan Kania 
 wrote:



Hi Ondrej,

I restarted with a new test.
Now I'm having 2 loadbalancer one is configured via cn=config and one
over slapd.conf. Both are configured exactly the same. Same binduser,
same ldap-server same everything.
For my test I started tcpdump on the loadbalancer and on the two
ldap-server.



Out of curiosity -

If you define a:

database config

section in slapd.conf, and then make it so you can connect to the config db 
and dump it via ldapsearch, does it match your cn=config database you're 
working from? or have the same issue if you use that dump as the 
configuration?


--Quanah

Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?

[Quanah Gibson-Mount]

--On Friday, December 1, 2023 1:02 PM -0800 Christopher Paul 
 wrote:



In summary, I see great value to continuing to support the slapd.conf
file-based config, especially for production, and I see a lot of risk
induced by deprecating it and forcing people to use OLC.  OpenLDAP
project, would you please consider to not deprecate slapd.conf?


As has been noted numerous times, slapd.conf is unordered and a constant 
source of configuration errors and unexpected behavior since people 
routinely throw statements in the wrong place.  I would also note that you 
are literally running a cn=config system with slapd.conf, even if it 
doesn't appear that way to you, since slapd just automatically turns 
slapd.conf into a cn=config db (although it may not function as desired due 
to preceding note).


For myself, being able to update the servers on the fly has allowed me to:

a) Push ACL changes w/o restart
b) Push indexing changes w/o restart
c) Push schema changes w/o restart
d) Push log level changes w/o restart (Particularly useful when debugging 
problems in a live environment)


I keep my cn-config db in git & use a test environment confirm changes 
prior to pushing them live in production.



--Quanah

Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?

[Quanah Gibson-Mount]

--On Friday, December 1, 2023 11:04 PM +0100 Geert Hendrickx 
 wrote:



databaseconfig
rootdn  cn=config


This is the default value as noted in slapd.conf(5). No need to specify it 
explicitly.



rootpw  .


May be better to set up cert auth and do a SASL mapping if you need to make 
config changes from an external host. If you don't need an external host, 
use LDAPI + EXTERNAL with a mapping for the root user or similar.


--Quanah

Re: Need assistant to Implement and Configure OpenLDAP for users authentication from Multi-Domain

[Quanah Gibson-Mount]

--On Thursday, November 23, 2023 12:21 PM + Sunil  Sharma 
 wrote:



  • What would be the Best OS for OpenLDAP currently, is it Linux,
CentOS or any other?


Generally any current linux distribution with a current openldap release.


  • We have users from Multi-Domain where these domains do not have any
trust relationship between each other and we need to authenticate the
users from multi-Domain for UC applications (CUCM, CUC, CER, UCCE,
Expressways and Jabber).



We are looking if we can sync the user database from
these multidomain to a single OpenLDAP server and then from this OpenLDAP
to UC applications using single search base for authentication, is this
possible?


Probably?

--Quanah

Re: Replication issue during performance test with MMR configuration and LastBind enabled

[Quanah Gibson-Mount]

--On Thursday, November 23, 2023 5:33 PM + falgon.c...@gmail.com wrote:


b) olcLogLevel: stats sync
- We running our tests with stats only. Meheni probably left this
configuration to check before sending the config here.


My point was more that it should be a multi-valued attribute with unique 
values not a single valued attribute with 2 strings in the value.




e) Why do you have separate credentions for the monitor db?
- sorry for this i don't understand the word credentions. Do you mean
credentials ?


Yes, typo


h) For your benchmark test, this is probably not frequent enough, as the
purge will never run since you're saying only data - We've run endurance
tests to include purging. This settings is from a month ago and we have
change this settings multiples times for testing differents setup.To add
the purge during tests, we actually  set it to 00+01:00 00+00:03. In the
final configuration we will probably set it too : 03+00:00 00+00:03. We
found that purging every 3 minutes reduced the impact on performance.


While correct that frequent purging is better, you missed my overall point, 
which is that when you're testing you likely want to purge data on a 
shorter timescale when doing a benchmark.




I repost a previous question here too : What are the exact messages or
errors messages we should find in case of a collision problem?



*If* there are collisions, you'll see the server falling back to REFRESH 
mode.  But only if you have "sync" logging enabled.



syncrepl.c: Debug( 
LDAP_DEBUG_SYNC, "do_syncrep2: %s delta-sync lost sync on (%s), switching 
to REFRESH\n",
syncrepl.c: Debug( LDAP_DEBUG_SYNC, 
"do_syncrep2: %s delta-sync lost sync, switching to REFRESH\n",


--Quanah

Re: Replication issue during performance test with MMR configuration and LastBind enabled

[Quanah Gibson-Mount]

--On Tuesday, November 7, 2023 12:56 PM + falgon.c...@gmail.com wrote:


Hello, sorry for the delay.
Thank's for the answers,


Generally, with something like lastbind, you'll run into collissions of
the  timestamp, which will cause a lot of havoc with replication.  It is
not the  only case where this can occur.  I highly advise reading the
caveats in the  admin guide about MPR replication.


Yes, that's what we thought at first, but with the various tests we've
carried out, we're doubtful about the collision problem. When testing
with a single account that BIND more than 500 times per second, we can't
reproduce the problem. The same applies to 10 accounts looping at 500
BIND/s.


So I'm looking at your configuration and have some question:

a) olcPasswordCryptSaltFormat: $6$rounds=1$%.16s -> Why are you using 
crypt passwords?  OpenLDAP ships with multiple, secure module for password 
hashing, such as argon2.  I'd advise using that.  Note that crypt is 
non-portable.



b) olcLogLevel: stats sync

This generally should be:

olcLogLevel: stats
olcLogLevel: sync

c) olcPasswordHash: {CRYPT} -> See (a)

d) I'd suggest not using a root password at all for cn=config, and use 
EXTERNAL auth over ldapi.  If you are going to use one, upgrade to argon2


e) Why do you have separate credentions for the monitor db?

f) Delete this index: olcDbIndex: pwdLastSuccess eq,pres

g) olcSpReloadHint: TRUE -> This setting should *not* be on the main DB, 
delete it from

dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config

h) For your benchmark test, this is probably not frequent enough, as the 
purge will never run since you're saying only data > 1 day old:

olcAccessLogPurge: 01+00:00 00+04:00

i) For the accesslog DB, are you sure this is a large enough size? 
olcDbMaxSize: 2147483648 or are you hitting 2GB?




Also it appears you're running this test on two slapds running on the same 
server?  That's an incredibly bad idea, since the I/O will conflict 
massively between the two processes writing to disk.

Re: Access to cn=monitor from read-only ldap

[Quanah Gibson-Mount]

--On Tuesday, November 21, 2023 3:27 PM +0100 Kevin Cousin  
wrote:




Hi List,



I've got an LDAP architecture with one read-write OpenLDAP (primary)  and
some read-only OpenLDAP  (replica).



I load the cn=monitor backend on the primary? is it sufficient to have
the cn=monitor backend on the slave too or should I activate it on the
replicas ?


I generally enable cn=config on all my ldap servers, so I can gather their 
individual statistics. Lots of monitoring software out there supports 
cn=monitor as well (Datadog, Grafana, etc)


--Quanah

Re: syncrepl between 2.4.57.0.1 and 2.6.2-3

[Quanah Gibson-Mount]

--On Thursday, November 16, 2023 2:50 PM + michael.fr...@airbus.com 
wrote:




Meanwhile we have found a non - technical workaround to just skip the
solaris scenario - this means that we can close this topic.

Thanks you guys (also Stefan) for the support an your time !



Glad you got it resolved, not sure why Solaris behaves differently.

--Quanah

Re: Issue with refint and rwm overlay

[Quanah Gibson-Mount]

--On Monday, November 6, 2023 10:08 PM + Maksim Saroka 
 wrote:




Hello,


Sorry for bothering you, guys. We really appreciate your work. That was
just an urgent deal for us. The last request: could you please point us
to the docs that explain to us how slapd.conf file should be composed in
the right way?


The manual pages cover what options are valid in what sections.

--Quanah

Re: syncrepl between 2.4.57.0.1 and 2.6.2-3

[Quanah Gibson-Mount]

--On Tuesday, November 7, 2023 9:10 AM + michael.fr...@airbus.com wrote:


Hi Quanah,

thanks for the feedback.

So, as you can see in the logs, i reduced the scope for replication to a
single group to see more clearly what is happening.


Again, partial replication has *very* specific requirements.  If you 
changed your config to do partial replication when it wasn't, then you 
aren't making it possible to see more clearly what is happening, you're 
breaking things.


Are your consumers supposed to replicate the entire DB? Yes or no?

--Quanah

Re: syncrepl between 2.4.57.0.1 and 2.6.2-3

[Quanah Gibson-Mount]

--On Monday, November 6, 2023 2:00 PM + michael.fr...@airbus.com wrote:


Dear list,

here is additional sync log after initially established proper sync and
then the consumer openldap service on (solaris, 2,4) is restarted:

Config on Consumer - only with one group in syncrepl:

olcSynrepl
{0}rid=004 provider=ldaps://xsdfsxcxc01.xxx1.s.XXX.yyy.zzz:636
binddn="cn=mmrepl,ou=services,dc=XXX,dc=yyy,dc=zzz" bindmethod=simple
credentials=gdfgdfhgdfh123 searchbase="dc=XXX,dc=yyy,dc=zzz"
type=refreshAndPersist retry="60 +"
filter="(|(&(objectClass=posixGroup)(ou:dn:=XXXCoreUserGroups)))"
scope=sub attrs="*,+" schemachecking=off olcSynrepl
{1}rid=044
provider=ldaps://04nsgdfgdfhgdfh02.04.s.XXX.yyy.zzz:636
binddn="cn=mmrepl,ou=services,dc=XXX,dc=yyy,dc=zzz" bindmethod=simple
credentials=gdfgdfhgdfhR6804! searchbase="dc=XXX,dc=yyy,dc=zzz"
type=refreshAndPersist retry="60 +"
filter="(|(&(objectClass=posixGroup)(ou:dn:=XXXCoreUserGroups)))"
scope=sub attrs="*,+" schemachecking=off


You're doing partial replication, which has very strict requirements.  The 
logs show it cannot find the CSN recorded in the DB, and this is likely why.


--Quanah

Re: OpenLDAP 2.4 (released October 2007) - Question

[Quanah Gibson-Mount]

--On Wednesday, November 1, 2023 6:04 PM + Steffano Festa 
 wrote:





Hi team,



Is the OpenLDAP 2.4 (released October 2007) still actively maintained? Or
can we consider it as EOL?


OpenLDAP 2.4 reached EOL in 2021, as announced here:



Regards,
Quanah

Re: No matter what I try I get: ldap_modify: Insufficient access (50)

[Quanah Gibson-Mount]

--On Friday, October 27, 2023 8:15 PM +0200 Alejandro Imass 
 wrote:



Again for future people reading this, if you encounter ACL issues and you
want to modify the LDIF database in /etc/openldap/slapd.d don't do it
manually.


Your advice here is generally wrong.





You mean they SHOULD edit them manually ?
I'm actually suggesting to use slapadd and slapmodify directly on the
filesystem if everything else fails. 
What's wrong with that suggestion?


You should have a properly configured system that allows modification of 
cn=config via ldap* commands while the system is online.  slapmodify can be 
useful in specific circumstances but it's not the best solution here.


--Quanah

Re: No matter what I try I get: ldap_modify: Insufficient access (50)

[Quanah Gibson-Mount]

--On Friday, October 27, 2023 10:51 AM +0200 Alejandro Imass 
 wrote:



Again for future people reading this, if you encounter ACL issues and you
want to modify the LDIF database in /etc/openldap/slapd.d don't do it
manually.


Your advice here is generally wrong.

--Quanah

Re: No matter what I try I get: ldap_modify: Insufficient access (50)

[Quanah Gibson-Mount]

--On > --On Thu> Try the following (and replace with the correct URL):


$ ldifmodify -x -H ldap://localhost/ -D cn=config -W << EOF
  > dn: olcDatabase={0}config,cn=config
  > changetype: modify
  > add: olcRootPW
  > olcRootPW: {SSHA}cZbRoOhRew8MBiWGSEOiFX0XqbAQwXUr
  > EOF


There doesn't appear to be an old olcRootPW value either, so that
wouldn't
work.





Thanks for your response.


There actually is one in dn: olcDatabase={1}mdb,cn=config


That's immaterial, it has no relation to the ability to modify cn=config. 
You should have a method for doing online modifications of the config DB.


--Quanah

Re: syncrepl between 2.4.57.0.1 and 2.6.2-3

[Quanah Gibson-Mount]

--On Thursday, October 26, 2023 8:07 AM + "Frank, Michael" 
 wrote:



Can someone state why this mission is hopeless in detail or should the
setup work basically ?


I would suspect the replication DN doesn't have full read access to the 
object, but fairly difficult to know w/o more information.  Do the 
entryUUIDs match between the provider and the consumer after the initial 
replication is done?  I.e., if the consumer can't read the provider 
entryUUID when it replicates the object initially, it'll generate a new 
one.  A later sync would not find it's local entryUUID in the provider's 
db, so then delete it since it's not present, etc.


--Quanah

Re: Replication issue during performance test with MMR configuration and LastBind enabled

[Quanah Gibson-Mount]

--On Tuesday, October 24, 2023 10:01 AM +0200 Óscar Remírez de Ganuza 
Satrústegui  wrote:



What architecture would you suggest for implementing lastbind?
Is it better to use a Master-Slave with the chain overlay to send the
lastbind writes from the slave to the master?


If you want the value to have general meaning for most deployments, yes. 
Generally I'd go with Multi-provider replication in a active/passive 
configuration, with some number of read only consumer nodes, where the read 
only nodes forward their updates to the active provider.


--Quanah

Re: No matter what I try I get: ldap_modify: Insufficient access (50)

[Quanah Gibson-Mount]

--On Thu> Try the following (and replace with the correct URL):


$ ldifmodify -x -H ldap://localhost/ -D cn=config -W << EOF
 > dn: olcDatabase={0}config,cn=config
 > changetype: modify
 > add: olcRootPW
 > olcRootPW: {SSHA}cZbRoOhRew8MBiWGSEOiFX0XqbAQwXUr
 > EOF


There doesn't appear to be an old olcRootPW value either, so that wouldn't 
work.


Generally, they'll need to export their DB via slapcat to an LDIF file, and 
then either add an olcRootPW value to it and re-import it, or add a SASL 
mapping for the root user so that EXTERNAL works, and re-import it.


--Quanah

Re: We cannot connect to TLS/SSL ldaps using openldap's built-in tools

[Quanah Gibson-Mount]

--On Friday, October 13, 2023 5:40 AM + 228844...@qq.com wrote:

.(

800B77514E7F:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure:../ssl/record/rec_layer_s3.c:1584:SSL alert number 40


You haven't stated what TLS library your openldap binary is linked to. 
Since OpenSSL s_client also fails, it sounds like your certs may be invalid 
(or in an incompatible format).  Hard to guess really what the issue is 
with the information provided.


--Quanah

Re: Openldap version / behavior wih duplicates

[Quanah Gibson-Mount]

--On Monday, October 16, 2023 8:46 AM + maudez.e...@neuf.fr wrote:


Hello
I have a system that has evolved from version 2.4.24 to version 2.4.44.
Before, when I put synchronizations (Syncrepl) between OpenLDAP
instances, duplicates (duplicate uid but OK for the DN because different
branch) were OK. With version 2.4.44, synchronization errors are observed.
Regards




The OpenLDAP 2.4 series is historic and not supported.  The 2.4.44 release 
is over 7 years old.  You should be using a current release series 
(OpenLDAP 2.5 or OpenLDAP 2.6).  Numerous replication issues were also 
fixed post 2.4.44.


If you cannot build OpenLDAP yourself, I suggest checking available 
resources such as:


Symas' OpenLDAP builds: https://repo.symas.com

LTB project OpenLDAP builds: https://ltb-project.org

Both provide pre-built binaries for a number of Linux distributions.

Regards,
Quanah

Re: Issue with refint and rwm overlay

[Quanah Gibson-Mount]

--On Friday, October 13, 2023 12:11 AM +0300 Maksim Saroka 
 wrote:



Hello,


Thank you for the quick response!



"cn=config is deterministic" what does it mean? Could you please
explain us the benefits in this case.



The slapd.conf file may or may not be ordered correctly.  I.e., database 
specific option may occur outside of a database definition.  Slapd will do 
its *best* to order the slapd.conf file that it is provided in a sensical 
way, but it may not match what was intended by the author, so it is not 
determinitistic.  With cn=config, everything is ordered, so it is 
deterministic.


Also, keep in mind that answers on the mailing list are done on a time 
available basis.  Don't send an email prodding for a reply.


---Quanah

Re: Replication issue during performance test with MMR configuration and LastBind enabled

[Quanah Gibson-Mount]

--On Monday, October 16, 2023 9:33 AM +0200 Falgon  
wrote:






Hello,
I'm working on the same project as Meheni.

Thanks for your answer, we'll try version 2.6 OpenLDAP using the
lastbind-precision.


However we have several questions for the current version we're using.

Is this a known problem and referenced somewhere? (we haven't found it)


Generally, with something like lastbind, you'll run into collissions of the 
timestamp, which will cause a lot of havoc with replication.  It is not the 
only case where this can occur.  I highly advise reading the caveats in the 
admin guide about MPR replication.



Is it normal to find no replication error logs even in stats + sync mode?


No. You'd have to provide more information.



--Quanah

Re: Trying to create master/slave solution with syncrepl

[Quanah Gibson-Mount]

--On Friday, October 13, 2023 10:42 AM +0200 Christoph Pleger 
 wrote:



So, I switched from ldaps to ldap, and suddenly, the synchronozation
worked. But I have no idea what the the problem with ldaps is. Isn't it
enough to just write an ldaps uri instead of an ldap uri?



If you read the man page, you will see there is a setting to provide the CA 
cert as part of the syncrepl stanza.


--Quanah

RE: Trying to create master/slave solution with syncrepl

[Quanah Gibson-Mount]

--On Thursday, October 12, 2023 4:11 PM + Marc  
wrote:



I am trying to create an OpenLDAP master/slave solution with syncrepl,
but I have not been successful so far.

I followed the suggestions of this site, with another sync password:

https://www.itzgeek.com/how-tos/linux/configure-openldap-master-slave-
replication.html

One thing I made different, on the master server, I created the
replication user with a userPassword: in SSHA-Format instead of clear
text.


I have clear text (older os), maybe that is it?


If a password is set using the LDAPv3 password modify extended operation, 
then the server will hash it.  If the password is changed using an 
ldapmodify operation or an ldapadd operation, and it is in cleartext, the 
server will not hash it UNLESS ppolicy is also active on the server and it 
has been configured to intercept and hash passwords cleartext passwords. 
See the slapo-ppolicy man page on how to configure tihs.



For the rest of the questions, I advise reading the OpenLDAP admin guide 
and not following instructions on random websites which are often incorrect.



I'd also note that OpenLDAP offers many secure password hashing mechanisms 
as the default SSHA is not considered secure.  I've been moving to ARGON2 
generally.  You would need to know if the provider of your OpenLDAP 
packages included argon2 support in their build.


--Quanah

Re: refresh and persistant not always persisting :-)

[Quanah Gibson-Mount]

--On Wednesday, October 11, 2023 4:49 PM +0200 cYuSeDfZfb cYuSeDfZfb 
 wrote:





Hi,


Of course I add many more details like detailed configs and logs, just
ask.


We have a 4-host MMR setup, that all replicate to the three others,
relevant snippets from the config:

We wondered what could cause this behaviour, and started thinking in the
direction of long-lived tcp connections that perhaps are used in
refreshAndPersist functionality. (much like in IMAP idle)


Is anything special needed to make refreshAndPersistwork reliably through
firewalls, and across subnets? Does refreshAndPersistwork use (some kind
of) long-lived network connections..? Is there a kind of "keepalive"
setting that we could try..?


Read the section on keepalive settings.  This is a common issue with 
firewalls and why those settings were introduced.  I usually use 
keepalive=240:10:30 to go under the (usually default) 5 minute disconnect 
most firewalls have.


--Quanah

Re: Issue with refint and rwm overlay

[Quanah Gibson-Mount]

--On Tuesday, October 10, 2023 4:43 PM +0200 Maksim Saroka 
 wrote:





Hello,

We have a strange situation with refint and rwm overlays on ldap
replica. Looks like those overlays depend on each other and on position
in the slapd.conf file regarding database section. However refint
overlay is working in any position if rwm overlay is not specified. Here
are the examples with positions in the file:

Refint overlay work if:
1.  
   rwm overlay section   
   database section   
   refint overlay section

Refint overlay does not work if:
1. 
   database section
   refint overlay section
   rwm overlay section
2. 
   rwm overlay section   
   refint overlay section
   database section

Could you please explain to us the root cause of that as I can't find any
explanation in the docs.



Hi,

A couple notes:

1. You really should use cn=config and not slapd.conf, as cn=config is 
deterministic.

2. In the first case above, "rwm" is probably ending up as a global overlay
3. In the third case above, "rwm" and "refint" are probably both ending up 
as global overlays

4. You never tried:

database section
rwm overlay
refint overlay

Finally, module load order can matter in certain circumstances, 
particularly with overlays that interact with one another.  One reason why 
syncprov (in a replicated environment) should always be the first overlay 
in a database section.


--Quanah

Re: Replication issue during performance test with MMR configuration and LastBind enabled

[Quanah Gibson-Mount]

--On Tuesday, October 10, 2023 9:30 PM +0200 Ziani Meheni 
 wrote:





Hello, we are working on a project and we've come across a problem with
the replication after performance testing :


You need to use OpenLDAP 2.6 and then set the:

  lastbind-precision

value. I use 5 minutes.

--Quanah

Re: error while setting password policy

[Quanah Gibson-Mount]

--On Tuesday, October 3, 2023 11:57 PM -0400 Jignesh Patel 
 wrote:




We are using LDAP version 2.5.16 .


when we try to set policy
we are getting this error olcAttributeTypes: value #0 olcAttributeTypes:
Duplicate attributeType:
"1.3.6.1.4.1.42.2.27.8.1.1" slapadd: could not add entry
The .ldif file is as attached.


And if we don't import than we are getting pException:  [LDAP result
code 17 - undefinedAttributeType] pwdAttribute: attribute type undefined


I suggest carefully reading the release notes for OpenLDAP 2.5, 
specifically around the changes to ppolicy since the 2.4 series.


--Quanah

Re: setup two DNs on one single Openldap server running on Red Hat Enterprise Linux release 8.8 (Ootpa)

[Quanah Gibson-Mount]

--On Tuesday, October 3, 2023 10:24 PM +0200 Jérôme BECOT 
 wrote:




I guess it is a problem of terminology, I should have use baseDN I guess.


Sure... but the question was about two admin users both under the same base 
:)


--Quanah

Re: Openldap version / behavior wih duplicates

[Quanah Gibson-Mount]

--On Tuesday, October 3, 2023 2:02 PM + maudez.e...@neuf.fr wrote:


Hello,
I notice a different behavior between versions OpenLDAP 2.4 and OpenLDAP
2.6 for synchronization management and duplicates. In the version
OpenLDAP 2.4, there is no error when duplicates are found (different
branch in openldap) during synchronizations (syncrepl) With version
OpenLDAP 2.6, synchronizations are in error
Do you know why?




You don't provide enough context to answer this question.

Regards,
Quanah

Re: setup two DNs on one single Openldap server running on Red Hat Enterprise Linux release 8.8 (Ootpa)

[Quanah Gibson-Mount]

--On Monday, October 2, 2023 12:47 PM +0200 Jérôme BECOT 
 wrote:



Hello,

It is not possible to have two different DN on the same database, because
the rootDN is unique. But you can configure multiple databases on the
same server, that works quite independently (every db has its own set of
overlays/config/replication). When you create the databases, you must
ensure that they don't live in the same directory (defaults to
/var/lib/ldap).


There's no need for it to be a rootdn, generally I suggest avoiding using 
the rootdn for backends at all.  The only rootdn that *might* need to be 
used is the one for cn=config, but that's entirely separate.


--Quanah

Re: setup two DNs on one single Openldap server running on Red Hat Enterprise Linux release 8.8 (Ootpa)

[Quanah Gibson-Mount]

--On Monday, October 2, 2023 2:26 PM +0530 Kaushal Shriyan 
 wrote:



Is there a way to set up two DN's in OpenLDAP server?


dn: cn=admin,dc=corporate,dc=mydomain,dc=com 

dn: cn=admin,dc=checker,dc=mydomain,dc=com


This is trivial to create as 2 different entries in your dc=mydomain,dc=com 
database.  There's no need for them to be rootdns, you can simply give them 
manage access to whatever they need to control.


--Quanah

RE: openldap + bind-dyndb-ldap + bind

[Quanah Gibson-Mount]

--On Thursday, September 21, 2023 12:30 AM + Marc 
 wrote:



If I enable this module, does it mean that this slapd stops receiving
updates from the master?


No, it's perfectly fine to run syncprov on consumers as well.

--Quanah

Re: slapd-watcher -i X refreshing unexpectedly...?

[Quanah Gibson-Mount]

--On Wednesday, September 13, 2023 1:54 PM +0200 cYuSeDfZfb cYuSeDfZfb 
 wrote:



It feels like perhaps there is something wrong in the way the -i X option
is implemented.


Please file a report at https://bugs.openldap.org/

--Quanah

Re: assert error + core dump slapd v 2.6.6

[Quanah Gibson-Mount]

--On Wednesday, September 13, 2023 6:19 PM +0200 Frédéric Goudal 
 wrote:




Hello,

Openldap version 2.6.6 compiled on ubuntu 22.4 LTS

For test purpose I'm trying to add an object with objectClass
top+person at the root of my openldap (which is not empty),  The dn is
cn=toto,dc=my,dc=domain

When I do something on this object, the slapd server crash, but when
restarted the operation has been done. It seems that it is the accelog
database that is causing a problem


You should file an issue report at https://bugs.openldap.org

--Quanah

Re: Enable debug logging on OpenLDAP 2.4.59 server running on Red Hat Enterprise Linux 8.7 (Ootpa)

[Quanah Gibson-Mount]

--On Thursday, August 31, 2023 10:23 AM +0530 Kaushal Shriyan 
 wrote:




Hi,



I have the below settings as
per https://www.openldap.org/doc/admin25/slapdconfig.html. I did check
both /var/log and /etc/default/ on RHEL 8.7 but was unable to locate
the log files. 


# grep olcLogLevel /etc/openldap/slapd.d/cn=config.ldif


You'd need to clarify on what you're trying to achieve.  Log level is not 
debug.


--Quanah