Provide a command similar to the reuse_account flag to remap ldap users

[jvillafanez]

Ref https://github.com/owncloud/enterprise/issues/5449

Allow remaping the LDAP user if it's the only one possible. This could happen if the LDAP user has been moved AND the directory_uuid has also changed, but the target username is the same.
The behavior should be similar than syncing the backend with the "reuse_account" flag, but in a more controlled way.

Note that this WON'T solve the collisions that could be happening. If 2 or more LDAP users could match the same username, the remap will be aborted.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
21 Code Smells

0.0% Coverage
15.7% Duplication

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
21 Code Smells

0.0% Coverage
15.5% Duplication

[jvillafanez]

Note that I've rebased the code and I had to fix things (6bf21d8). It should work, but consider the PR as untested due to the last commit.

[dj4oC]

Adds occ ldap:remap-user — an admin CLI command that re-points an existing ownCloud account's stored LDAP dn/directory_uuid mapping to a different LDAP entry found by username.

Findings

Security — CWE-863 Incorrect Authorization / identity-mapping change, escalating per policy (LDAP attribute/identity mapping is a never-auto-fix zone):

• This directly rewrites the identity binding (directory_uuid + dn) that ownCloud uses to recognize "this account is that LDAP entry" — i.e., it's the LDAP analogue of an account-takeover primitive if invoked against the wrong target. It requires prior occ (admin/server) access, which bounds the blast radius, but the command itself does no confirmation beyond "exactly one LDAP candidate for this username" — it does not verify the new UUID belongs to the same person as the old one (e.g. comparing DN's OU, or requiring --force-style explicit acknowledgement of the identity change).
• No audit-log entry is written. Remapping a user's directory identity is exactly the kind of security-relevant admin action the audit-log ground rule calls out (permission/identity changes). If owncloud/core or this app has an audit-log/activity subsystem hook available to apps, this command should write to it; right now the only record is CLI stdout.

Stability: remapUser() throws \UnexpectedValueException for the 0-candidates and >1-candidates cases, which execute() catches and reports — reasonable. getMappedUUIDAndDN()/isAllowed() look correct.

Test coverage: no test file included in this diff for RemapUser, AbstractMapping::replaceUUIDAndDN(), Manager::findUsersByUsername(), or User_Proxy::findUsername() — all net-new logic, zero coverage.

Verdict

Commenting, not blocking outright given the admin-only trigger surface — but this needs a maintainer decision on (a) whether an audit-log entry is required here and (b) whether stronger same-identity confirmation is warranted, before merge. Tests should be added regardless.

🤖 Automated review by Claude Code (security · stability · performance · coverage)

---

Generated by Claude Code