[midPoint] midPoint creating duplicate AD account instead of linking

João Paulo Ribeiro joparibeiro at gmail.com
Fri Sep 26 18:03:08 CEST 2025


Hi Carlos and Yakov,

Thanks for your suggestions!

Carlos, I went ahead with your recommendation and flagged the
userPrincipalName attribute with secondaryIdentifier=true. That solved the
GUI error, and midPoint is now applying the necessary updates to the AD
shadow account perfectly, just as expected.

However, as I was digging into the logs, I saw an interesting behavior. It
seems that even with the new setting, midPoint's first step is still to
attempt an "add" operation for a new user with the same userPrincipalName
(I can see an OperationLog: Add REQ Entry...). The key difference is that
this operation is now logged as a warning instead of a hard error. Right
after this warning, the logs show the expected MoveAndRename and Modify
operations being successfully applied to the existing account.

Em sex., 26 de set. de 2025 às 11:41, Carlos Ferreira <carlos18619 at gmail.com>
escreveu:

> João,
>
> Have you already tried the "secondaryIdentifier" option on the attribute
> resource configuration?
>
>
> Something like this:
>
>
>
>
>
>
>
> *            <attribute id="3190">
> <ref>ri:sAMAccountName</ref>                <tolerant>true</tolerant>
>           <exclusiveStrong>false</exclusiveStrong>
> <secondaryIdentifier>true</secondaryIdentifier>                <outbound>*
>
>
>
> Em qui., 25 de set. de 2025 às 12:54, João Paulo Ribeiro via midPoint <
> midpoint at lists.evolveum.com> escreveu:
>
>> Hello!
>>
>> I have a midPoint deployment with an authoritative (inbound) resource and
>> an outbound Active Directory resource. There's a specific situation where a
>> user that I haven't imported into midPoint yet already has an account in
>> Active Directory (outbound). In this scenario, when I import the user from
>> the authoritative resource, I would expect midPoint to link the existing
>> Active Directory account (UNLINKED -> LINKED). However, it's trying to
>> create another account in AD, and because of that, the following error is
>> being thrown:
>>
>> ObjectAlreadyExistsException:
>> org.identityconnectors.framework.common.exceptions.AlreadyExistsException(Error
>> adding LDAP entry CN=username,OU=users,DC=example,DC=com:
>> constraintViolation: 000021C8: AtrErr: DSID-03200BD1, #1:??0: 000021C8:
>> DSID-03200BD1, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 90290 (
>> *userPrincipalName*)?? (19))
>>
>> I have already checked the correlation and synchronization rules on both
>> the inbound (authoritative) and outbound (AD) resources, and they seem
>> correct. In fact, if I try to run the "import" for the existing AD account
>> while it's in the UNLINKED state, it performs the expected operation: it
>> LINKS the account with its respective focus and applies the necessary
>> updates. The problem really happens when I try to run the "import" from the
>> authoritative resource, in which case midPoint doesn't detect the
>> pre-existing AD account for the user.
>>
>> Has anyone else experienced this?
>>
>> Versions:
>> midPoint 4.8.7
>> AdLdapConnector 3.7.4
>>
>> Thanks in advance!
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> https://lists.evolveum.com/mailman/listinfo/midpoint
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20250926/0970a896/attachment.htm>


More information about the midPoint mailing list