[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 16:13:34 CEST 2018
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(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
">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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180627/e3da9a28/attachment.htm>
More information about the midPoint
mailing list