We are in deployment phase. We have users in midpoint, but not linked with LDAP accounts.
User in midpoint exists. He should have account on LDAP with dn: uid=jsmith,ou=... At the same time, for unkown reason, the account is already in LDAP with dn: uid=jsmith, ou=... (notice the space after first comma).
Recomputing the user should create the LDAP accoun because some assignments are in place.
midPoint tries to create uid=jsmith,ou=... (without space) and fail with Already exists. But there are now TWO shadows, one with and one without space after comma. The "new" (without space) is linked to the user and has no primaryIdentifierValue so it's useless. The "original" (with space) shadow is still in repository and not linked to the user.
The correlation expression is using uid to midpoint name comparision, so the space should not be a problem. The attribute ri:dn has mr:distinguishedName matching rule set.
Why midPoint created this new "invalid" shadow is quite obvious, as the space should probably not be there in first place, but after AlreadyExistsException shouldn't the original found shadow be linked instead and the "new" shadow automatically dropped or something?