[midPoint] Issues when linking an existing midPoint user to an existing AD account with different DN
Ezequiel Alonso
ealonso at identicum.com
Wed Jun 27 20:01:24 CEST 2018
Hello Radovan and thank you for your answer,
The are not two accounts. There IS
*CN=User123,OU=Office123,OU=People,DC=example,DC=net* but SHOULD BE
*CN=User123,OU=People,DC=example,DC=net*.
The issue appears when the account exists in an unknown DN (
*CN=User123,OU=Office123,OU=People,DC=example,DC=net*) that is not equal to
the DN generated by the DN mapping (*CN=User123,OU=People,DC=example,DC=net*
).
We agree with the 5 steps you mention, but after the "already exist"
exception, midPoint tries to create the user account instead of linking
with the existing account and recompute the DN.
When we assign the AD resource to the user, midPoint search the account and
throws "entry already exists".
https://pastebin.com/xHmRy2r1
But if we set sAMAccountName as secondaryIdentifier midPoint generates an
invalid DN.
https://pastebin.com/BhZsDGFV
2018-06-27 12:43 GMT-03:00 Radovan Semancik <radovan.semancik at evolveum.com>:
> Ah, I forgot one thing: this whole process will work correctly only if
> midPoint can detect that the account which conflicted with
> CN=User123,OU=People,DC=
> example,DC=net is in fact CN=User123,OU=Office123,OU=People,DC=example,DC=net.
> There is no standard way to do this. AD won't tell which account has
> conflicted. It also won't tell which attribute caused the conflict. And
> from the LDAP-compliant point of view there should not be any conflict. But
> there is a way ... kind of hack. You can add samAccountName (or a similar
> attribute) as an additional secondary identifier for the AD resource. In
> that case midPoint will try to look up the conflicting account using both
> DN and samAccountName. And that's how it discovers which account was the
> cause of the conflict.
>
> I think we have this configuration in some AD samples.
>
> --
> Radovan Semancik
> Software Architectevolveum.com
>
>
>
>
> On 06/27/2018 05:30 PM, Radovan Semancik wrote:
>
> Hi,
>
> MidPoint cannot link those two accounts immediately. MidPoint has no way
> of knowing that *CN=User123,OU=People,DC=example,DC=net* and
> *CN=User123,OU=Office123,OU=People,DC=example,DC=net* should be the same
> account. Those have different identifiers (GUIDs and DNs). In fact, in any
> real LDAP server it is perfectly possible for such accounts to exist at the
> same time. And this may be actually desired configuration in some
> deployment. Well, AD is slightly special here. But midPoint will not behave
> differently just because it talks to AD. Correlation rule won't help here
> either. At least not directly. Correlation rule is applied only to accounts
> that do not have owner already. But the new account that is just created
> has an owner. Therefore correlation rules is not applied.
>
> MidPoint supports this situation. But it should go like this:
> 1. MidPoint tries to create new account CN=User123,OU=People,DC=exampl
> e,DC=net
> 2. Create operation fails, because there is already account with username
> User123 ... and that account has DN
> *CN=User123,OU=Office123,OU=People,DC=example,DC=net*
> 3. MidPoint forgets about operation 1. for a while. MidPoint tries to
> figure out what to do with the account that was just "discovered" (that
> Office123 account)
> 4. Correlation rule is used at this point. In your case the correction
> rule should correlate user123 with his existing Office123 account.
> 5. Operation 1. is restarted. Everything is recomputed. MidPoint figures
> out that it no longer needs to create User123 account on AD because such
> account already exist.
>
> This is what we call "self healing" or "consistency mechanism". The usual
> problem here is that it depends on the connector to positively detect
> "account already exist" situation. Which may seem as an easy task. But it
> is not. There are many error conditions that are reported in various ways -
> especially with old and non-standard-compliant resources such as Active
> Directory. So there may be problem. Please make sure that the connector
> detect the "object not found" situation correctly. If there is any other
> error then midPoint will stop at step 3 because in that case midPoint is
> not sure what is going on. And the default behavior is to be conservative:
> we would do nothing rather than risking wrong action which could cause
> damage. And that may be what is happening in your case. The error below is "
> InvalidAttributeValueException". Is should be "ObjectNotFoundException".
>
> For that reasons and also for other various reasons this approach may be
> quite fragile. Original purpose of this process was to handle rare cases of
> forgotten accounts, accounts that were manually created by resource
> administrators and similar rare cases. I would recommend to reconsider the
> initial migration process. Maybe it would be better to import all the
> accounts from HR systems (or other source system), then correlate them with
> AD and only then start to assign roles which try to create new accounts?
>
> --
> Radovan Semancik
> Software Architectevolveum.com
>
>
>
> On 06/27/2018 04:13 PM, Ezequiel Alonso wrote:
>
> Hi Guys,
>
> We continued trying to fix this issue using this snippet found in
> "ad-ldap-medusa-exchange" in resource schema because we found a similar
> issue in the mailing list (http://lists.evolveum.com/
> pipermail/midpoint/2016-June/001923.html) and they proposed to use a
> secondaryIdentifier.
>
> <xsd:complexType name="user">
> <xsd:annotation>
> <xsd:appinfo>
> <ra:resourceObject/>
> <ra:identifier>ri:objectGUID</ra:identifier>
> <ra:secondaryIdentifier>ri:sAMAccountName</ra:secondaryIdentifier>
> <ra:displayNameAttribute>ri:dn</ra:displayNameAttribute>
> <ra:namingAttribute>ri:dn</ra:namingAttribute>
> <ra:nativeObjectClass>user</ra:nativeObjectClass>
> </xsd:appinfo>
> </xsd:annotation>
> </xsd:complexType>
>
> but we are getting this error:
>
> 2018-06-27 06:21:49,463 [] [pool-4-thread-143] ERROR
> (com.evolveum.midpoint.provisioning.ucf.impl.connid.ConnIdUtil): ConnId
> Exception org.identityconnectors.framework.common.exceptions.InvalidAttributeValueException
> in connector:c87a0797-4be5-4fde-b6f2-770832f4a87f(ConnId
> com.evolveum.polygon.connector.ldap.ad.AdLdapConnector v1.5.1):
> ConnectorSpec(resource:dad0110d-77ed-408d-a1a8-044dee06facb(LDAP
> SigleDomain), name=null, oid=c87a0797-4be5-4fde-b6f2-770832f4a87f) while
> getting object identified by ConnId UID 'fcda49c9-ec77-499e-a39b-70c1582d8051':
> Invalid DN 'username': ERR_04202 A value is missing on some RDN
> org.identityconnectors.framework.common.exceptions.
> InvalidAttributeValueException: Invalid DN 'username': ERR_04202 A value
> is missing on some RDN
> at com.evolveum.polygon.connector.ldap.schema.
> AbstractSchemaTranslator.toDn(AbstractSchemaTranslator.java:1389)
> at com.evolveum.polygon.connector.ldap.schema.
> AbstractSchemaTranslator.toDn(AbstractSchemaTranslator.java:1372)
> at com.evolveum.polygon.connector.ldap.ad.
> AdLdapConnector.searchByUid(AdLdapConnector.java:246)
> at com.evolveum.polygon.connector.ldap.AbstractLdapConnector.
> executeQuery(AbstractLdapConnector.java:464)
> at com.evolveum.polygon.connector.ldap.AbstractLdapConnector.
> executeQuery(AbstractLdapConnector.java:124)
> at org.identityconnectors.framework.impl.api.local.
> operations.SearchImpl.rawSearch(SearchImpl.java:193)
> at org.identityconnectors.framework.impl.api.local.
> operations.SearchImpl.search(SearchImpl.java:130)
> at sun.reflect.GeneratedMethodAccessor1348.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.identityconnectors.framework.impl.api.local.operations.
> ConnectorAPIOperationRunnerProxy.invoke(ConnectorAPIOperationRunnerPro
> xy.java:98)
> at com.sun.proxy.$Proxy223.search(Unknown Source)
> at org.identityconnectors.framework.impl.api.local.
> operations.GetImpl.getObject(GetImpl.java:67)
> at sun.reflect.GeneratedMethodAccessor1314.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.identityconnectors.framework.impl.api.local.operations.
> ThreadClassLoaderManagerProxy.invoke(ThreadClassLoaderManagerProxy.
> java:96)
> at com.sun.proxy.$Proxy224.getObject(Unknown Source)
> at sun.reflect.GeneratedMethodAccessor1314.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.identityconnectors.framework.impl.api.
> DelegatingTimeoutProxy.invoke(DelegatingTimeoutProxy.java:99)
>
> And we are generating DN this way:
>
> <attribute id="3">
> <c:ref>ri:dn</c:ref>
> <displayName>Distinguished Name</displayName>
> <limitations>
> <minOccurs>0</minOccurs>
> <access>
> <read>true</read>
> <add>true</add>
> <modify>true</modify>
> </access>
> </limitations>
> <matchingRule xmlns:mr="http://prism.evolveum.com/xml/ns/public/
> matching-rule-3">mr:distinguishedName</matchingRule>
> <outbound>
> <strength>strong</strength>
> <source>
> <c:path>$user/fullName</c:path>
> </source>
> <source>
> <c:path>$user/locality</c:path>
> </source>
> <source>
> <c:path>$user/activation/effectiveStatus</c:path>
> </source>
> <expression>
> <script xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:type="c:ScriptExpressionEvaluatorType">
> <code>
> if (effectiveStatus?.value.toString().toLowerCase().
> equals('disabled'))
> {
> return basic.composeDnWithSuffix('CN', fullName,
> 'OU=Disabled,OU=People,DC=example,DC=net');
> } else {
> if (locality.toString().toLowerCase() == "argentina")
> {
> return basic.composeDnWithSuffix('CN', fullName,
> 'OU=AR,OU=People,DC=example,DC=net')
> } else {
> return basic.composeDnWithSuffix('CN', fullName,
> 'OU=People,DC=example,DC=net')
> }
> }
> </code>
> </script>
> </expression>
> </outbound>
> </attribute>
>
> Thanks in advance!
>
> 2018-06-01 18:01 GMT-03:00 Ezequiel Alonso <ealonso at identicum.com>:
>
>> Hi,
>>
>> We are working with "*ad-ldap-medusa-medium*" resource synchronizing
>> midPoint users against existing AD accounts as part of the initial
>> migration.
>>
>> Newest AD accounts should be on "*OU=People,DC=example,DC=net*" and
>> older accounts maybe already placed on many different DNs on "
>> *OU=UnpredictableOfficeNumber,OU=People,DC=example,DC=net*"
>>
>> We have already created the users on midPoint taking into account that
>> the correlation matching rule is user/name == sAMAccountName. So, at this
>> point we can see that the shadow users are presented as unlinked.
>>
>> If the account DN is equal to the resource mapping generated DN, the
>> account gets linked when we assign the resource to the user. But if the
>> existing account DN is not equal to the resource generated DN (For example,
>> resource is generating "*CN=User123,OU=People,DC=example,DC=net*" but
>> the account exist on "
>> *CN=User123,OU=Office123,OU=People,DC=example,DC=net*"), we are getting
>> the following issue when we assign the AD resource to the user:
>> midPoint is not linking the account and it tries to create the user in "
>> *CN=User123,OU=People,DC=example,DC=net*" instead of modifying the user
>> DN to "*CN=User123,OU=People,DC=example,DC=net*" (we added strength
>> strong to dn mapping and we also tested with strength weak), so we are
>> getting the next error message:
>>
>> "*Couldn't add object. Object already exists: Object already exists on
>>> the resource*".
>>
>>
>> It's strange because if we import the account manually from the resource,
>> it is linking midPoint user with AD account and modifying the DN.
>>
>> Our goal is to link existing midPoint user with existing AD account by
>> matching name against sAMAccountName and override the unpredictable and
>> unknown DN with a more friendly DN, if its possible or at least link the
>> user without modifying the DN.
>>
>> --
>> *Ezequiel Alonso*
>> Identicum S.A.
>> Jorge Newbery 3226, Buenos Aires, Argentina
>> <https://maps.google.com/?q=Jorge+Newbery+3226>
>> Tel: +54 (11) 4552-3050
>> www.identicum.com
>>
>
>
>
> --
> *Ezequiel Alonso*
> Identicum S.A.
> Jorge Newbery 3226, Buenos Aires, Argentina
> <https://maps.google.com/?q=Jorge+Newbery+3226>
> Tel: +54 (11) 4552-3050
> www.identicum.com
>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
--
*Ezequiel Alonso*
Identicum S.A.
Jorge Newbery 3226, Buenos Aires, Argentina
<https://maps.google.com/?q=Jorge+Newbery+3226>
Tel: +54 (11) 4552-3050
www.identicum.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180627/37495daa/attachment.htm>
More information about the midPoint
mailing list