[midPoint] Issues when linking an existing midPoint user to an existing AD account with different DN
Ivan Noris
ivan.noris at evolveum.com
Thu Jun 28 09:11:18 CEST 2018
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 <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
--
Ivan Noris
Senior Identity Engineer
evolveum.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180628/47a66e53/attachment.htm>
More information about the midPoint
mailing list