[midPoint] Issues when linking an existing midPoint user to an existing AD account with different DN
Radovan Semancik
radovan.semancik at evolveum.com
Wed Jun 27 17:30:08 CEST 2018
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
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(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
> <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
> http://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180627/14cc8353/attachment.htm>
More information about the midPoint
mailing list