Fix Borken UUID Attribute Detection

[blizzz]

With #1729 (downstreamed…) UUID detection got broken. On default installations, the LDAP backend would figure out the correct UUID attribute fetch the value accordingly. Because an empty was replaced wrongly in one place, detection was never really done, instead the UUID was indeed written for users, but falsely using the username.

The UUID is used to recognize users on the directory even when they were moved within the LDAP tree and have a different DN. A fix could lead to the point that this detection will fail, if the wrong value was written.

Affects master and 11.

• Write an integration test specifically for UUID attribute detection
• Figure out why a "fallback value was written at all, usually the user would be skipped
• Most likely needs an update / repair step routine

Also fixes a faulty test.

fyi @MorrisJobke

[mention-bot]

@blizzz, thanks for your PR! By analyzing the history of the files in this pull request, we identified @nickvergessen, @LukasReschke and @MorrisJobke to be potential reviewers.

[MorrisJobke]

@karlitschek @LukasReschke I would love to see this fixed in 11.0.2. Otherwise moving users in the LDAP tree would not be detected properly. I would avoid the risk of delaying this for the next release.

[karlitschek]

backport ia fine

[codecov-io]

Codecov Report

Merging #3521 into master will increase coverage by <.01%.
The diff coverage is 0%.

@@             Coverage Diff              @@
##             master    #3521      +/-   ##
============================================
+ Coverage     54.15%   54.15%   +<.01%     
- Complexity    21039    21040       +1     
============================================
  Files          1306     1306              
  Lines         80292    80292              
  Branches       1250     1250              
============================================
+ Hits          43479    43481       +2     
+ Misses        36813    36811       -2

Impacted Files	Coverage Δ	Complexity Δ
apps/user_ldap/lib/Connection.php	54.45% <ø> (ø)	115 <ø> (ø)	❌
apps/user_ldap/lib/Access.php	17.03% <ø> (ø)	295 <ø> (+1)	✅
lib/private/Security/CertificateManager.php	93.81% <ø> (+1.03%)	38% <ø> (ø)	❌
lib/private/Files/Cache/Propagator.php	96.2% <ø> (+1.26%)	16% <ø> (ø)	❌

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c1bb89d...45615cc. Read the comment docs.

[blizzz]

We should be complete now. Reviews welcome, @MorrisJobke @LukasReschke @rullzer @nextcloud/ldap

[blizzz]

Now, the reproducing the issue is harder than it seemed to be first. On the classical way, via the LDAP wizard, it is very very tough if not impossible to get into this scenario. It seems rather to happen when a more programmatic approach is being used to configure LDAP (e.g. occ commands, or the OCS API). Thus, the possible impact (as affected instances) is far smaller than thought first.

[MorrisJobke]

Code looks good and didn't destroyed my existing setup 👍