Chris,

not I did not try that. Mostly because I think moving expresses the actual operation more clearly in LDIF. But in the mean time I edited the config LDIF (cutting and pasting the object, then adjusting the DN. I wonder whether the problem might be that the new RDN is the same as the old RDN 😉

Kind regards, Ulrich Windl

From: Christopher Paul chris.paul@rexconsulting.net Sent: Thursday, March 20, 2025 4:22 PM To: Windl, Ulrich u.windl@ukr.de; openldap-technical@openldap.org Subject: [EXT] Re: LDIF for moddn: "ldap_rename: Server is unwilling to perform (53)"

On 3/20/2025 8:16 AM, Windl, Ulrich wrote: Hi!

Reading https://kb.symas.com/en_US/configuration/configure-delta-syncrepl I realized that my syncprov is on the original database, not on the accesslog. So I tried to fix it my “moving” the overlay like this:

dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config changetype: moddn newrdn: olcOverlay={0}syncprov deleteoldrdn: 1 newsuperior: olcDatabase={3}mdb,cn=config

However as I got "ldap_rename: Server is unwilling to perform (53)" I wonder: Is my LDIF wrong, or is it an implementation restriction?

Hi Ulrich,

Did you try delete + add?

dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config changetype: delete

dn: olcOverlay=syncrpov,olcDatabase={3}mdb,cn=config changetype: add ...[etc]...

--

Chris Paul | Rex Consulting | https://www.rexconsulting.net

Hello,

I am working on a use case when I want an openldap meta server to balance requests on multiple backends according to the bindDN of the incoming user.

I succeeded to do this with a meta + rwm configuration as showed below:

overlay rwm rewriteEngine on

# In the context of a BIND operation rewriteContext bindDN # Store user who has logged in an internal variable named binddn (for other LDAP operations) rwm-rewriteRule ".+" "${&&binddn($0)}$0" ":" # If the LDAP operation is a bind, directly rewrite the binddn # If binddn starts by dir1, rewrite suffix to directory1 rewriteRule "^uid=(dir1[^,]+)(.*),dc=domain,dc=com$" "uid=$1$2,dc=directory1,dc=domain,dc=com" ":@I" # Else, rewrite suffix to directory2 rewriteRule "^([^,]+),dc=domain,dc=com$" "$1,dc=directory2,dc=domain,dc=com" ":@I"

# For SEARCH LDAP operations rewriteContext searchDN # Prefix the string to search by the binddn who has connected previously rewriteRule "(.*)" "${**binddn}<>$1" ":I" # If binddn starts by dir1, remove binddn prefix from string and rewrite suffix to directory1 rewriteRule "^uid=dir1[^,]+,[^<]+<>(.*)dc=domain,dc=com(.*)$" "$1dc=directory1,dc=domain,dc=com$2" ":@I" # If binddn not found or does not start by dir1, remove binddn prefix from string and rewrite suffix to directory2 rewriteRule "^.*<>(.*)dc=domain,dc=com(.*)$" "$1dc=directory2,dc=domain,dc=com$2" ":@I" rewriteRule "^.*<>(.*)$" "$1" ":@I"

database      meta suffix        "dc=domain,dc=com" uri"ldap://127.0.0.1:3390/dc=directory1,dc=domain,dc=com" uri"ldap://127.0.0.1:3391/dc=directory2,dc=domain,dc=com"

This is working well, but all operations are returned with the real backend suffix, which can be disturbing for the client application.

I'd like the bind and search results to be rewritten with the virtual suffix (removing dc=directory1 or dc=directory2 part)

I have tried using these server->client rewrite contexts: searchEntryDN, searchAttrDN, matchedDN, or referralDN, but they don't seem to be called.

Does anyone know if it is possible to achieve this?

Thanks for any help!

David

Hello Ondřej,

Le 21/03/2025 à 12:14, Ondřej Kuzník a écrit :

On Fri, Mar 21, 2025 at 10:16:09AM +0100, David Coutadeur wrote:

...

I am working on a use case when I want an openldap meta server to balance requests on multiple backends according to the bindDN of the incoming user.

I succeeded to do this with a meta + rwm configuration as showed below: [...] This is working well, but all operations are returned with the real backend suffix, which can be disturbing for the client application.

I'd like the bind and search results to be rewritten with the virtual suffix (removing dc=directory1 or dc=directory2 part)

I have tried using these server->client rewrite contexts: searchEntryDN, searchAttrDN, matchedDN, or referralDN, but they don't seem to be called.

Hi David, I assume you mean the contexts mentioned in slapo-rwm manpage when it comes to suffixmassage? That should work.

Yes, I am using the contexts mentionned in slapo-rwm man page.

One precision : I have loaded all the rules in the overlay rwm before any database definition, otherwise the rules where not applied.

Note that the suffixmassage is exactly what I want to do, but suffixmassage alone is not able to direct my request to one backend or the other according to the binddn.

My own experience with rwm is very limited, others might have more and better advice here, but one thing that stands out to me is that since you're not using rwm to decide which DB is going to serve the request, you can just move the rewriting rules into the meta's own context and I would hope that helps things out if stuff wasn't being connected right.

I started to do that, but unfortunately the rewriterules where never called.

Thanks for your help anyway :)

Regards,

Hi Nadya,

Thanks for your answer !

In my first attempts, I configured rewrite engine inside the meta backend, but without success.

Nor rewriteContext default, not any specific context was ever triggered in this situation.

As a concrete example, I provide below a full configuration that never triggers any rewrite.

Regards,

David

include         /usr/local/openldap/etc/openldap/schema/core.schema include         /usr/local/openldap/etc/openldap/schema/cosine.schema include         /usr/local/openldap/etc/openldap/schema/inetorgperson.schema

logLevel 256

pidfile         slapd.pid argsfile        slapd.args

# Load dynamic backend modules: # moduleload    back_ldap.la modulepath      /usr/local/openldap/libexec/openldap moduleload      argon2.la moduleload      back_mdb.la moduleload      back_meta.la moduleload      back_ldap.la moduleload      dynlist.la moduleload      memberof.la moduleload      ppolicy.la moduleload      syncprov.la moduleload      unique.la moduleload      rwm.la

access to dn.base=""  by * read access to dn.base="cn=subschema"  by * read access to * by * write

####################################################################### # meta database #######################################################################

database      meta

suffix        "dc=domain,dc=com"

uri "ldap://127.0.0.1:3390/dc=directory1,dc=domain,dc=com" uri "ldap://127.0.0.1:3391/dc=directory2,dc=domain,dc=com"

rewriteEngine on

# In the context of a BIND operation rewriteContext bindDN # Store user who has logged in an internal variable named binddn (for other LDAP operations) rewriteRule ".+" "${&&binddn($0)}$0" ":" # If the LDAP operation is a bind, directly rewrite the binddn # If binddn starts by prefix1 or prefix2, rewrite suffix to directory1 rewriteRule "^uid=(prefix1[^,]+|prefix2[^,]+)(.*),dc=domain,dc=com$" "uid=$1$2,dc=directory1,dc=domain,dc=com" ":@I" # Else, rewrite suffix to directory2 rewriteRule "^([^,]+),dc=domain,dc=com$" "$1,dc=directory2,dc=domain,dc=com" ":@I"

# For SEARCH LDAP operations rewriteContext searchDN # Prefix the string to search by the binddn who has connected previously rewriteRule "(.*)" "${**binddn}<>$1" ":I" # If binddn starts by prefix1 or prefix2, remove binddn prefix from string and rewrite suffix to directory1 rewriteRule "^uid=prefix1[^,]+,[^<]+<>(.*)dc=domain,dc=com(.*)$" "$1dc=directory1,dc=domain,dc=com$2" ":@I" rewriteRule "^uid=prefix2[^,]+,[^<]+<>(.*)dc=domain,dc=com(.*)$" "$1dc=directory1,dc=domain,dc=com$2" ":@I" # If binddn not found or does not start by prefix1 or prefix2, remove binddn prefix from string and rewrite suffix to directory2 rewriteRule "^.*<>(.*)dc=domain,dc=com(.*)$" "$1dc=directory2,dc=domain,dc=com$2" ":@I" rewriteRule "^.*<>(.*)$" "$1" ":@I"

rewriteContext searchResult rewriteRule "dc=directory1,dc=domain,dc=com" "dc=domain,dc=com" ":@I" rewriteRule "dc=directory2,dc=domain,dc=com" "dc=domain,dc=com" ":@I"

Le 24/03/2025 à 14:10, nivanova@symas.com a écrit :

Hi David, I am not proficient in the rwm either, but I know that back-meta can be configured with its own rewrite engine, and it can definitely be configured to rewrite results. You could move this config in the database definition (without "overlay rwm"), and use rewriteContext searchResult to rewrite the search results. I haven't tested this myself in ages, but I hope it works in your case, there's a lot of examples in the slapd-meta man page.

Best Regards, Nadya

Hi Nadya,

Thanks for your explanation about the rewrite engine in back-meta! I now understand why it was never called.

Indeed, the rewrite context you provided below is doing exactly what I needed. Thank you very much!

Your help is very much appreciated :)

Regards

David

Le 28/03/2025 à 13:31, Nadezhda Ivanova a écrit :

Hi David, I played a bit with your config, and I found out the following: Unfortunately it seems that the back-meta rewrite engine works per-target, so in your configuration it is actually only applied to the second target, and therefore would not work as intended. There is currently no way to configure it per database, so your original approach of using the rwm overlay is indeed the best. I was able to make it rewrite search entry DNs by adding the following at the end of the rwm overlay config:

rewriteContext searchEntryDN rewriteRule "^([^,]+),dc=directory.,dc=domain,dc=com$" "$1,dc=domain,dc=com" ":@I"

I hope that's helpful!

Best Regards, Nadya

---

*From: *"David Coutadeur" <david.coutadeur@gmail.com>
*To: *"nivanova" <nivanova@symas.com>, openldap-technical@openldap.org
*Sent: *Wednesday, March 26, 2025 10:59:38 AM
*Subject: *Re: can rwm rewrite suffix from backend response?


Hi Nadya,

Thanks for your answer !

In my first attempts, I configured rewrite engine inside the meta
backend, but without success.

Nor rewriteContext default, not any specific context was ever
triggered in this situation.


As a concrete example, I provide below a full configuration that
never triggers any rewrite.


Regards,

David



include         /usr/local/openldap/etc/openldap/schema/core.schema
include         /usr/local/openldap/etc/openldap/schema/cosine.schema
include
        /usr/local/openldap/etc/openldap/schema/inetorgperson.schema


logLevel 256


pidfile         slapd.pid
argsfile        slapd.args

# Load dynamic backend modules:
# moduleload    back_ldap.la
modulepath      /usr/local/openldap/libexec/openldap
moduleload      argon2.la
moduleload      back_mdb.la
moduleload      back_meta.la
moduleload      back_ldap.la
moduleload      dynlist.la
moduleload      memberof.la
moduleload      ppolicy.la
moduleload      syncprov.la
moduleload      unique.la
moduleload      rwm.la

access to dn.base=""  by * read
access to dn.base="cn=subschema"  by * read
access to * by * write


#######################################################################

# meta database
#######################################################################


database      meta

suffix        "dc=domain,dc=com"

uri "ldap://127.0.0.1:3390/dc=directory1,dc=domain,dc=com"
uri "ldap://127.0.0.1:3391/dc=directory2,dc=domain,dc=com"

rewriteEngine on

# In the context of a BIND operation
rewriteContext bindDN
# Store user who has logged in an internal variable named binddn
(for other LDAP operations)
rewriteRule ".+" "${&&binddn($0)}$0" ":"
# If the LDAP operation is a bind, directly rewrite the binddn
# If binddn starts by prefix1 or prefix2, rewrite suffix to
directory1
rewriteRule
"^uid=(prefix1[^,]+|prefix2[^,]+)(.*),dc=domain,dc=com$"
"uid=$1$2,dc=directory1,dc=domain,dc=com" ":@I"
# Else, rewrite suffix to directory2
rewriteRule "^([^,]+),dc=domain,dc=com$"
"$1,dc=directory2,dc=domain,dc=com" ":@I"

# For SEARCH LDAP operations
rewriteContext searchDN
# Prefix the string to search by the binddn who has connected
previously
rewriteRule "(.*)" "${**binddn}<>$1" ":I"
# If binddn starts by prefix1 or prefix2, remove binddn prefix
from string and rewrite suffix to directory1
rewriteRule "^uid=prefix1[^,]+,[^<]+<>(.*)dc=domain,dc=com(.*)$"
"$1dc=directory1,dc=domain,dc=com$2" ":@I"
rewriteRule "^uid=prefix2[^,]+,[^<]+<>(.*)dc=domain,dc=com(.*)$"
"$1dc=directory1,dc=domain,dc=com$2" ":@I"
# If binddn not found or does not start by prefix1 or prefix2,
remove binddn prefix from string and rewrite suffix to directory2
rewriteRule "^.*<>(.*)dc=domain,dc=com(.*)$"
"$1dc=directory2,dc=domain,dc=com$2" ":@I"
rewriteRule "^.*<>(.*)$" "$1" ":@I"

rewriteContext searchResult
rewriteRule "dc=directory1,dc=domain,dc=com" "dc=domain,dc=com" ":@I"
rewriteRule "dc=directory2,dc=domain,dc=com" "dc=domain,dc=com" ":@I"





Le 24/03/2025 à 14:10, nivanova@symas.com a écrit :

    Hi David,
    I am not proficient in the rwm either, but I know that back-meta can be configured with its own rewrite engine, and it can definitely be configured to rewrite results. You could move this config in the database definition (without "overlay rwm"), and use rewriteContext searchResult to rewrite the search results. I haven't tested this myself in ages, but I hope it works in your case, there's a lot of examples in the slapd-meta man page.

    Best Regards,
    Nadya