Generic Single-valued Schema Enforcement

0 Likes

It is a frequent problem for AD and many other drivers that the schema of the target application does not match the schema of eDirectory. In Active Directory in particular, the use of multi-valued attributes, while supported, tends to be the exception rather than the rule. eDirectory tends in the opposite direction.



A major challenge of AD drivers is that AD's behavior when an attribute does not meet the schema requirements is that it acts much like a database – it treats a directory update like an atomic database operation. If anything is wrong, everything is rejected. For that reason, often users complain that a percentage of their users did not sync.



The most common example is usually the "Description" attribute, which in eDirectory is multi-valued, and people often fill it with notes about what changes they have manually made to eDirectory objects. By default this is mapped to description in AD, but this is a single-valued attribute. So every user who has more than one value in Description in eDirectory fails to sync anything to AD. And often, 1 out of 250 users are in this state.



Nothing is more frustrating to the end client than what appears to be inconsistent and unpredictable behavior. Most of the reactions I hear to this are similar to, "I guess IDM isn't really ready for primetime". Even when we as directory consultants identify the root cause, they insist that the system "just work".



Now we could play whack-a-mole with these attributes, fixing them one at a time, which is what I used to do. But with IDM 3.5 and some of the new tokens it became possible to read the driver's settings and take appropriate actions, which is what this policy does.



The requirement is that you actually import the schema from the application for this to work properly. The AD driver delivered functionality has an early AD schema built-in, but if the client is using a later "functional level" of the domain or forest, or if they have extended the schema with Microsoft or third party directory enabled applications, those schema extensions should be imported using the schema policy's "Import Application Schema" capability. NOTE: Not all drivers support the <query-schema> command, most notably, eDirectory drivers do not.



The schema gets stored as an XML document in the attribute DirXML-ApplicationSchema on the driver object. This rule will read that into a driver scoped node-set variable (since it is static data) if it is not already populated; this means it should only be read in once.



This rule should sit in the Output Transformation so it can operate in the application name space after the schema map policy has been applied. The rule will iterate through each attribute that is in the current command being sent to the connected system and retrieve the attribute name. It then looks up whether that attribute is single or multi-valued from the application schema; if the attribute is single valued, the first value being sent to Active Directory will be saved in a variable, the value stripped and replaced with only the single value.



The rule works as follows:



  1. Optional: Read the application schema from the driver set if it is not already there

  • Iterate through the command document, for each attr-name you find:
    1. Get the attribute definition from the attribute schema

  • Get the value of the multi-valued flag from the attribute

  • If the attribute is single-valued
    1. Get the first value using the operation attribute token

  • Strip all the values

  • Set the value of the attribute using the set destination attribute token



The cool thing here is that we read the application schema only once, after that we operate on the node set using XPATH to decide what to do, making this a very efficient memory only operation.



It is important to note that in the AD schema, some attribute names are associated with inherited classes; for example, you might inherit telephoneNumber from person and the fact that it is OK for a user to have a telephoneNumber is implied because user is defined as inheriting from person. This means you have to find the attribute wherever it is in the application schema document, not just underneath the class.




<rule>
<description>[CIS] Handle Multi-to-single valued conversions</description>
<comment xml:space="preserve">Generic Rule which reads the application schema from AD and determines if it needs to take only the first value from a multi-valued eDirectory attribute
</comment>
<conditions>
<or>
<if-operation mode="case" op="equal">modify</if-operation>
<if-operation mode="case" op="equal">add</if-operation>
</or>
</conditions>
<actions>
<do-if>
<arg-conditions>
<and>
<if-local-variable name="APP-SCHEMA" op="not-available"/>
</and>
</arg-conditions>
<arg-actions>
<do-set-local-variable name="APP-SCHEMA" scope="driver">
<arg-node-set>
<token-xml-parse notrace="true">
<token-base64-decode notrace="true">
<token-src-attr name="DirXML-ApplicationSchema" notrace="true">
<arg-dn>
<token-global-variable name="dirxml.auto.driverdn"/>
</arg-dn>
</token-src-attr>
</token-base64-decode>
</token-xml-parse>
</arg-node-set>
</do-set-local-variable>
</arg-actions>
<arg-actions/>
</do-if>
<do-for-each>
<arg-node-set>
<token-xpath expression=".//@attr-name"/>
</arg-node-set>
<arg-actions>
<do-set-local-variable name="CLASS" scope="policy">
<arg-string>
<token-class-name/>
</arg-string>
</do-set-local-variable>
<do-set-local-variable name="ATTR-DEF" notrace="true" scope="policy">
<arg-node-set>
<token-xpath expression="$APP-SCHEMA/schema-def/class-def/attr-def[@attr-name=$current-node]"/>
</arg-node-set>
</do-set-local-variable>
<do-set-local-variable name="MULTI-VALUED" scope="policy">
<arg-string>
<token-xpath expression="$ATTR-DEF[1]/@multi-valued"/>
</arg-string>
</do-set-local-variable>
<do-if>
<arg-conditions>
<and>
<if-local-variable mode="nocase" name="MULTI-VALUED" op="equal">false</if-local-variable>
</and>
</arg-conditions>
<arg-actions>
<do-set-local-variable name="VALUE" scope="policy">
<arg-string>
<token-op-attr name="$current-node$"/>
</arg-string>
</do-set-local-variable>
<do-strip-op-attr name="$current-node$"/>
<do-set-dest-attr-value name="$current-node$">
<arg-value>
<token-local-variable name="VALUE"/>
</arg-value>
</do-set-dest-attr-value>
</arg-actions>
<arg-actions/>
</do-if>
</arg-actions>
</actions>
</rule>


Labels:

How To-Best Practice
Comment List
  • in reply to jetco1
    "
    add the do-for-each end tag to the line before before the action end tag line

    "
  • Before giving this a try I copied the xml into XML Copy Editor. I enabled Check Well-formedness and it found a missing end tag for Line 78. The missing end tag is for the do-for-each tag. I added the do-for-each end tag to the line before the end tag

  • Hello, still cannot get this working, opened the subscriber channel, went to the schema mapping policy, opened the one policy that was there, pressed refreshed application schema, schema refresh successful was displayed but LDAP error still occurs on multivalued attributes. Not sure were I have gone wrong. I may have to stick with my multiple rules (whack a mole). Thanks
  • in reply to MigrationDeletedUser
    To import the application schema, open the schema map and click the import application schema button. If you have not done this your application schema will not match your actual AD schema.
  • Applied this to the Output transform on the AD driver (IDM3.6.1) and accounts still fail to be moved (LDAP error on Department as it has multiple entries). Could some one be more clear on "Import ApplicationSchema" (how to do?, do I export the schema from AD somehow and import it into eDir using iManager's Schema - Extend Schema?). Using ConsoleOne I did look at the attribute "DirXML-ApplicationSchema" on the AD driver but it is not in a readable format, just full of numbers. Any help would be appreciated. Just need some clarity on how this works.

    Thanks
  • Good and very useful rule!

    Looks like the action is missing it's end tag.

    Best regards,
    Tobias
Related
Recommended