[midPoint] Issues when linking an existing midPoint user to an existing AD account with different DN
Radovan Semancik
radovan.semancik at evolveum.com
Wed Jul 11 11:27:30 CEST 2018
Hi,
I think I'm quite confused now.
If the "Office123" account exists before the operation, then midPoint
will not generate the DN. It will use the DN of that existing account.
MidPoint will do that because that account was matched by correlation
expression, therefore midPoint thinks it is a legal account to be linked
to a user. MidPoint is not generating the DN in that case. It is using
existing DN. If you want to move that account to a different OU you need
to force a rename. Strong outbound mapping should do the trick. But you
have to be careful not to influence other accounts.
--
Radovan Semancik
Software Architect
evolveum.com
On 06/27/2018 08:01 PM, 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 <mailto: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 Architect
> evolveum.com <http://evolveum.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=example,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 Architect
>> evolveum.com <http://evolveum.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
>>> <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
>>> <http://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
>>> <http://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(ConnectorAPIOperationRunnerProxy.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
>>> <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
>>> <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 <mailto: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 <http://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 <http://www.identicum.com/>
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>>
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
> http://lists.evolveum.com/mailman/listinfo/midpoint
> <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 <http://www.identicum.com/>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180711/ed265f42/attachment.htm>
More information about the midPoint
mailing list