Uploaded image for project: 'MidPoint'
  1. MidPoint
  2. MID-5083

Reconciliation problem with unknown intents: will not fix the previously unknown intents for which there is definition now

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Critical
    • Resolution: Fixed
    • 3.9
    • 3.9.1, 4.0
    • None
    • MID-101 training

    • Internal

    Description

      The CSV file contains the following data:

      "login","fname","lname","enumber","dep","dis","password","groups","phone"
      "hacker","","","","","true","hackedSecretPassword","",""
      "admin","Admin","Admin","","","false","secret","",""
      "_tjru68","Test","Test","","","false","secret","",""
      "_x000090","Mel","Austenberg Test","","","false","secret","",""
      

      The definition of this resource contains only one account intent. There is a condition though so only accounts not starting with underscore are considered to be default intent:

              	<objectSynchronization>
      	            <!--
      	                The synchronization for this resource is enabled.
      	                It means that the synchronization will react to changes detected by
      	                the system (live sync task, discovery or reconciliation) -->
                          <name>Default account</name>
                          <description>The default account name does NOT start with "_"</description>
      <!-- <objectClass>ri:AccountObjectClass</objectClass> -->
                          <kind>account</kind>
                          <intent>default</intent>
      	            <enabled>true</enabled>
      	
                          <condition>
                              <script>
                                 <code>
      //                            name = basic.lc(shadow.getName().toString())
                                    name = basic.getAttributeValue(shadow, "login")
                                    log.info("XXX Synchronization condition for account/default; name (getName()) = {}; name (getAttributeValue) = {}; evaluated to {}", shadow.getName(), name, !name?.startsWith('_'))
                                    return !name?.startsWith('_')
                                 </code>
                              </script>
                          </condition>
      	            <correlation>
      	                <q:description>
      	                    Correlation expression is a search query.
      	                    Following search queury will look for users that have "employeeNumber"
      	                    equal to the "enumber" attribute of the account.
                                  The condition will ensure that "enumber" is not
                                  empty, otherwise it would match any midPoint user
                                  with empty "employeeNumber" attribute, such as "administrator".
      	                    The correlation rule by default looks for users, so it will not match
      	                    any other object type.
      	                </q:description>
      	                <q:equal>
      	                    <q:path>c:employeeNumber</q:path>
                                    <expression>
                                      <path>$account/attributes/ri:enumber</path>
                                    </expression>
      	                </q:equal>
                              <condition>
                                  <script>
                                      <code>basic.getAttributeValue(shadow, 'enumber') != null</code>
                                  </script>
                              </condition>
      	            </correlation>
      	
      	            <!-- Confirmation rule may be here, but as the search above will
      	                 always return at most one match, the confirmation rule is not needed. -->
      	
      	            <!-- Following section describes reactions to a situations.
      	                 The setting here assumes that this resource is authoritative,
      	                 therefore all accounts created on the resource should be
      	                 reflected as new users in IDM.
      	                 See http://wiki.evolveum.com/display/midPoint/Synchronization+Situations
      	             -->
      	            <reaction>
      	                <situation>linked</situation>
                              <synchronize>true</synchronize>
      	            </reaction>
      	            <reaction>
      	                <situation>deleted</situation>
      	                <synchronize>true</synchronize>
                              <action>
                                  <handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/action-3#unlink</handlerUri>
                              </action>
      	            </reaction>
      	            <reaction>
      	                <situation>unlinked</situation>
      	                <synchronize>true</synchronize>
                              <action>
                                  <handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/action-3#link</handlerUri>
                              </action>
      	            </reaction>
      	            <reaction>
      	                <situation>unmatched</situation>
      	                <synchronize>true</synchronize>
                              <action>
                                  <handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/action-3#inactivateShadow</handlerUri>
                              </action>
      	            </reaction>
      		</objectSynchronization>
      

      This works. But for the accounts that start with underscore, the intent is set to "unknown". Not even recon is needed for that, it's sufficient to go to Resource - my resource - Accounts - Resource and list the accounts. They're fetched and intent is set as "unknown" for the underscore-starting shadows.

      Later I enable the following config for the second intent:

             	<objectSynchronization>
                          <name>Test account</name>
                          <description>The test account name starts with "_"</description>
      <!--                     <objectClass>ri:AccountObjectClass</objectClass> -->
                          <kind>account</kind>
                          <intent>test</intent>
      	            <enabled>true</enabled>
                          <condition>
                              <script>
                                 <code>
      //                            name = basic.lc(shadow.getName().toString())
                                    name = basic.getAttributeValue(shadow, "login")
                                    log.info("XXX Synchronization condition for account/test; name (getName()) = {}; name (getAttribute) = {}; evaluated to {}", shadow.getName(), name, name.startsWith('_'))
                                    return name?.startsWith('_')
                                 </code>
                              </script>
                          </condition>
      	
      	            <correlation>
      	                <q:description>
      	                    Correlation expression is a search query.
      	                    Following search queury will look for users that have "name"
      	                    equal to the account name without the first character. We assume that
                                  the first character is "_" because of the condition above.
      	                    The correlation rule by default looks for users, so it will not match
      	                    any other object type.
      	                </q:description>
      	                <q:equal>
                                  <q:matching>polyStringNorm</q:matching>
                                  <q:path>c:name</q:path>
                                      <expression>
                                          <script>
                                              <code>
                                              n = shadow.getName().toString()
                                              n.substring(1)
                                              </code>
                                          </script>
                                      </expression>
      	                </q:equal>
      	            </correlation>
      	            <reaction>
      	                <situation>linked</situation>
                              <synchronize>true</synchronize>
      	            </reaction>
      	            <reaction>
      	                <situation>deleted</situation>
      	                <synchronize>true</synchronize>
                              <action>
                                  <handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/action-3#unlink</handlerUri>
                              </action>
      	            </reaction>
      	            <reaction>
      	                <situation>unlinked</situation>
      	                <synchronize>true</synchronize>
                              <action>
                                  <handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/action-3#link</handlerUri>
                              </action>
      	            </reaction>
      	            <reaction>
      	                <situation>unmatched</situation>
      	                <synchronize>true</synchronize>
                              <action>
                                  <handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/action-3#inactivateShadow</handlerUri>
                              </action>
      	            </reaction>
      		</objectSynchronization>
      

      Running reconciliation (dry run or standard) will not get rid of the "unknown" intent, and that makes me unable to synchronize the "test" accounts.

      Removing the shadows and reconciling again now with the second intent configuration works OK, but that's not an option for the training.

      The same situation works for 3.8.

      I can provide the full resource privately.

      Attachments

        Activity

          People

            vix Ivan Noris
            vix Ivan Noris
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: