Article

Problem

In the shipping rules for the Active Directory driver, in the Subscriber channel, Create policy set, there is the following rule:

<rule>
<description>Create User objects</description>
<comment>Special processing for users. A DirXML-ADAliasName is
generated which becomes the NT logon name (sAMAccountName) in Active
Directory. Also, a default password is generated. If the user has a
distribution password and you have enabled password sync, the
distribution password will override the password generated here. The
generated password passes the default Active Directory '3 of 4' rule
by appending 'Dirxml1' to the password. You can make this more secure
by using data that varies by user.</comment>
conditions>
  <and>
    <if-class-name op="equal">User</if-class-name>
    </and>
  </conditions>
<actions>
  <do-veto-if-op-attr-not-available name="Full Name"/>
  <do-set-dest-attr-value name="DirXML-ADAliasName">
    <arg-value type="string">
      <token-substring length="20">
      <token-replace-all
regex="^a-zA-Z0-9\x21\x23-\x29\x2d\x2e\x40\x5e-\x60\x7b\x7d\x7e\xc0-\xf6\xf8-\xff\x410-\x44f"
replace-with="">
      <token-src-name/>
      </token-replace-all>
      </token-substring>
    </arg-value>
  </do-set-dest-attr-value>
  <do-set-src-attr-value name="DirXML-ADAliasName">
    <arg-value type="string">
      <token-substring length="20">
      <token-replace-all
regex="^a-zA-Z0-9\x21\x23-\x29\x2d\x2e\x40\x5e-\x60\x7b\x7d\x7e\xc0-\xf6\xf8-\xff\x410-\x44f"
replace-with="">
      <token-src-name/>
      </token-replace-all>
      </token-substring>
    </arg-value>
&  lt;/do-set-src-attr-value>
  <do-set-dest-password>
    <arg-string>
      <token-op-attr name="Surname"/>
      <token-text xml:space="preserve">Dirxml1</token-text>
    </arg-string>
  </do-set-dest-password>
</actions>
</rule>

Basically, this does a couple of things:

1. On User creates (add events) it does a veto if Full name is missing, because AD requires a Full Name attribute, much like eDirectory requires Surname as a mandatory attribute.

2. It takes the Source Name of the User (basically the CN assumes the default naming attribute; if you swap your naming attribute, it will be used instead) and cuts it down to 20 characters. That's the maximum allowed in the AD side, for the pre-NT name that it will be used for.

3. It removes any weird characters that are allowed in eDirectory names but not in the old style NT name.

4. It sets the value on the destination attribute DirXML-AliasName (which is mapped to samAccountName in AD, which is used as the short name in AD).

Now for the troublesome bit: it sets the same value back on the source object.

The problem is, you will pretty much always get the following error when this executes:

<nds dtdversion="3.5" ndsversion="8.x">
  <source>
    <product version="3.5.2.20070719 ">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <output>
    <status event-id="sample-event" level="error">Code(-9010) An
exception occurred: novell.jclient.JCException: modifyEntry -608
ERR_ILLEGAL_ATTRIBUTE<application>DirXML</application>
      <module>Active Directory</module>
      <object-dn>\ACMEIDVAULT\acme\employees\active\Aatestfour</object-dn>
      <component>Subscriber</component>
    </status>
  </output>
</nds>

The -608 error happens because the attribute being added to the user, and DirXML-AliasName is not in the base User class. It is stored in the DirXML-ApplicationAttrs auxiliary class.

This rule baffles me, since it pretty much should never work and always cause a 608 error. When you do a set source attribute you do not get the auto addition of needed aux classes. The same is true when you do a set destination attribute with direct=true.

I would love to know what the thinking behind this rule is. There must be a good reason, and just because I cannot think of one does not mean it does not exist.

Any takers from Novell?

Solution

The error is really easy to fix ...

1. Add a do-set-src-attr-value of "Object Class".

2. Add a value of "DirXML-ApplicationAtts" to add the object class, just before the set source attribute of the DirXML-AliasName.

You should be OK now. You have extended the object to include the aux class with the attribute, and you can successfully add the attribute to it.

Thus it is more of an annoyance, and in the end, the attribute gets set when it syncs back from Active Directory after the user create anyway. You could probably get away with just deleting the rule as well. But again, there may be a good reason for keeping it that I cannot think of, so I would rather fix it than remove it.