AD Driver Default Rule Oddity
Novell Cool Solutions: Tip
By Geoffrey Carman
Digg This -
Posted: 26 Sep 2007
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="18.104.22.16870719 ">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.
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.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com