[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:43:12 CEST 2018
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
//
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
>
>
> 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
>
>
>
>
> _______________________________________________
> 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/fac55fe1/attachment.htm>
More information about the midPoint
mailing list