[Bug]: Login for LDAP Users impossible after moving in LDAP

[Zyzonix]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

When moving users from an OU in a LDAP to another, they can only login once, on second try the login fails, because the LDAP request seems to use the old OU-path. Nothing else was changed.

The logs then provide the following message:
{"reqId":"dLQaQHOHPXBRxGQfbofe","level":0,"time":"2026-08-12T20:47:09+00:00","remoteAddr":"XXX.XXX.XXX.XXX","user":"--","app":"user_ldap","method":"POST","url":"/index.php/login","scriptName":"/index.php","message":"Calling LDAP function ldap_bind with parameters ["(resource)","cn=USER.NAME,ou=OLD-OU,ou=STAFF,dc=DOMAINCONTROLLER,dc=TLD","REMOVED SENSITIVE VALUE"]","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0","version":"34.0.2.1","data":{"app":"user_ldap"}}
Then bind fails, because under this CN the user cannot be find anymore.

I am using PostgreSQL and looked up also the database, there the LDAP DN is correct.
Updated all users after moving with:
occ ldap:check-user --update --all-seen-users
Also rebooted the machine.

What I am also wondering about; when changing the user base-DN from dc=DOMAINCONTROLLER,dc=TLD (this base-DN is required, because there are users in different OUs) to OU=USERSdc=DOMAINCONTROLLER,dc=TLD in the plugins settings, then everything works fine?
it works fine again.

I cannot find from where the script takes this cache?

Steps to reproduce

Use LDAP plugin, move users in LDAP, then try to login with them.

Expected behavior

Simply use latest OU for user, to allow login.

Nextcloud Server version

34

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.4

Web server

Apache (supported)

Database engine version

PostgreSQL

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "overwriteprotocol": "https",
        "trusted_domains": [
            "sub.domain.tld",
            "sub1.domain.tld",
            "sub2.domain.tld"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "https:\/\/sub.domain.tld",
        "dbtype": "pgsql",
        "version": "34.0.2.1",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "proxy": "10.0.0.1:3128",
        "loglevel": 0,
        "maintenance": false,
        "maintenance_window_start": 1,
        "lost_password_link": "disabled",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "default_phone_region": "DE",
        "mail_smtpsecure": "ssl",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauth": 1,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "465",
        "auth.bruteforce.protection.enabled": false,
        "app_install_overwrite": [
            "radio",
            "dokuwiki",
            "dashboardcharts"
        ],
        "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory"
    }
}

List of activated Apps

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

Additional info

No response

[Zyzonix]

If there is anything I can reset, just let me know. Completely removing the LDAP plugin config and resetting up everything didn't help. Just changing the base DN works for some reasons.

[come-nc]

@Zyzonix Hello.

I believe this is a consequence of #54429
There is a 30 days TTL for this new cache.
It’s a local cache, I’m not sure how to reset it. It depends whether what is actually used as local cache on your instance.

What bugs me is that you say the mapping was updated in DB, so the change was picked, it should’ve been put in the cache as well.
Do you have only one or several web servers?

[Zyzonix]

@come-nc
Okay, what could be used for local caching, where can I look up what we are using?
There is only one webserver on this machine. And yes, when searching on PGSQL everything seems fine.