[midPoint] Issues when linking an existing midPoint user to an existing AD account with different DN
Ezequiel Alonso
ealonso at identicum.com
Thu Jun 28 23:17:58 CEST 2018
Hi,
I got confused with the documentation because they was not using boolean
values. I suggest to modify the documentation (here for example
https://wiki.evolveum.com/display/midPoint/Connector+Development+Guide#
ConnectorDevelopmentGuide-DiscoverySupport) for prevent confusion between
secondaryIdentifier in schema and secondaryIdentifier in schemaHandling.
Not modifying the schema and setting secondaryIdentifier to true solved the
issue.
Thank you so much guys!
2018-06-28 4:11 GMT-03:00 Ivan Noris <ivan.noris at evolveum.com>:
> Hi,
>
> are you setting the secondaryIdentifier in <schema> or <schemaHandling>?
>
> Because in AD, distinguished name is also secondary identifier (primary is
> objectGUID) so if you override <schema>, that will probably not work
> without having dn also there.
>
> You should use schema handling for that as in the email you referenced
> earlier: http://lists.evolveum.com/pipermail/midpoint/2016-June/
> 001923.html
>
> Have you already tried that?
>
> Example:
>
> ...
>
> <attribute>
> <ref>ri:sAMAccountName</ref>
> *<secondaryIdentifier>true</secondaryIdentifier>*
> <displayName>Login name</displayName>
> <description></description>
> <outbound>
> <strength>strong</strength>
> <source>
> <path>$user/name</path>
> </source>
> </outbound>
> </attribute>
>
> ...
>
> This will set the sAMAccountName as secondary identifier and AFAIK it will
> be an *additional* secondary identifier. So DN + sAMAccountName are both
> secondary identifiers.
> And, it will survive refetching/refresh of resource schema.
>
> I remember I have seen this, but I have no customer/project where I
> actually used that.
>
> Best regards,
> Ivan
>
>
> On 27.06.2018 20:01, Ezequiel Alonso wrote:
>
> 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/pip
>> ermail/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.AbstractSchemaTra
>> nslator.toDn(AbstractSchemaTranslator.java:1389)
>> at com.evolveum.polygon.connector.ldap.schema.AbstractSchemaTra
>> nslator.toDn(AbstractSchemaTranslator.java:1372)
>> at com.evolveum.polygon.connector.ldap.ad.AdLdapConnector.
>> searchByUid(AdLdapConnector.java:246)
>> at com.evolveum.polygon.connector.ldap.AbstractLdapConnector.ex
>> ecuteQuery(AbstractLdapConnector.java:464)
>> at com.evolveum.polygon.connector.ldap.AbstractLdapConnector.ex
>> ecuteQuery(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(DelegatingMe
>> thodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at org.identityconnectors.framework.impl.api.local.operations.C
>> onnectorAPIOperationRunnerProxy.invoke(ConnectorAPIOperation
>> RunnerProxy.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(DelegatingMe
>> thodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at org.identityconnectors.framework.impl.api.local.operations.T
>> hreadClassLoaderManagerProxy.invoke(ThreadClassLoaderManager
>> Proxy.java:96)
>> at com.sun.proxy.$Proxy224.getObject(Unknown Source)
>> at sun.reflect.GeneratedMethodAccessor1314.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at org.identityconnectors.framework.impl.api.DelegatingTimeoutP
>> roxy.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.evolveu
>> m.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.toStri
>> ng().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
>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
> --
> Ivan Noris
> Senior Identity Engineerevolveum.com
>
>
> _______________________________________________
> 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/20180628/1e527e8c/attachment.htm>
More information about the midPoint
mailing list