Novell Identity Manager has a lot of different connected systems available and each has its own unique set of errors.
I would love to see Novell document all the various possible errors that can come up in each different driver, but the reality is that it is almost an impossible task.
However just because it is hard, does not mean it is worth doing. Rather than just annoy documentation writers at Novell about adding more troubleshooting steps (which I still continue to do) I also want to contribute on my own. You can see the fruits of my labours below. Now to be fair, recently the driver documentation have shown more content in the Troubleshooting section. This is a very good thing, but as always, I do not feel it goes far enough.
In the first four parts of this article series,
I started listing error codes I found when implementing a new Active Directory driver.
I have done this before for other drivers, like the JDBC driver. You can read that series at:
Here is the first article in a series for the eDirectory driver:
Error Codes of the eDirectory Driver for Identity Manager - Part 1
Then there is the beginning of a series on the SAP HR driver:
Error Codes of the SAP HR driver for Identity Manager - Part 1
You can see my optimism by naming the first article as part 1.
As you can imagine with so many different drivers for Novell Identity Manager, I probably will not run out of topics for a long time, and I hope to continue writing more and more.
Back to the Active Directory driver, as I continued working through the process of deploying a new set of drivers, I found even more errors than I had covered in the first four articles, so here comes part five of a continuing series.
As always, I encourage any one else who wants too, to contribute this style of article. The more error codes we get published, with the actual text of the error code, a suggestion of what was going on, and how you resolved it, the easier it will be for others who encounter it to resolve it for themselves.
Right now, there are not enough articles about Identity manager driver error codes out there, so these are my attempts to rectify that situation.
Please help contribute any errors you may have dealt with. Lets make Google searching more useful on this topic!
Anyway, on with the errors:
LDAP_OTHER 80 error, Group create, backslash in name:
nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20051114_120000" instance="\NE_IDN\ACME\ACME-NEIDN-DriverSet\ACME-AD" version="3.1">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="ACME12#20090428201707#7#1" level="error" type="driver-general">
<ldap-err ldap-rc="80" ldap-rc-name="LDAP_OTHER">
<client-err ldap-rc="80" ldap-rc-name="LDAP_OTHER">Other</client-err>
<server-err>00000523: SysErr: DSID-031A0FB6, problem 22 (Invalid argument), data 0</server-err>
<server-err-ex win32-rc="1315"/>
</ldap-err>
<operation-data unmatched-src-dn="CN=Lan/Wan,OU=SND,OU=CIS,OU=ACME"/>
</status>
</output>
</nds>
Here we have an event for a group create, where the name of the group, had a forward slash (/) in the group name. YOu can see it is called Lan/Wan, from the operation-data node, unmatched-src-dn. It says: CN=Lan/Wan,OU=SND,OU=CIS,OU=ACME
A forward slash is not a valid character in an old style NetBIOS complaint name. The name of a group object has similar restrictions to sAMAccountName on User objects. Really the driver should validate this field for Groups as well as Users, but since it does it for Users already with a handy dandy Regular Expression, that I have no interest in parsing and trying to understand, lets just fix this problem by changing Subscriber channel create rule to add this Regex replace all to clean the CN of the Group up.
<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>
This is basically copied from the rule for Users just one or two rules away.
This is an instance where I think it would have been really worthwhile for the default driver configuration in the comments section for the rule that uses this nice long regular expression, to take the five minutes to explain what it is doing. You know, list the illegal characters, and then what each element of the regular expression is stripping out. Seems like the right place to do it is in the driver configuration, and it is just comment tagged XML so it does not waste CPU much to leave it there in every driver.
Move user in AD based on DirXML-ADContext changing:
In this example, we had a deeply structured Active Directory tree, a structured LDAP authentication tree, and linking the two in the middle, a flat Identity Vault tree. We needed to carry structural information from the LDAP tree to the Active Directory tree and vica versa. To do that, we leveraged an existing attribute, DirXML-ADContext, and made our DN structures identical in both trees.
It is worth noting that the DN of an Active Directory user has at the end of it, a virtual bit, for the Domain name of the Active Directory tree. Usually of the form dc=domain,dc=com even in it so in eDirectory, in the structured LDAP tree, we actually store the users in a dc=com object, with a child domain object of dc=domain. (Well we used real names, but you get the point). In fact we actually had three Active Directory trees, part of a single forest with an empty root domain, with a dc=americas, dc=asiapc, and a dc=emea set of containers.
In the LDAP tree, we were able to present a single view of that to LDAP applications, which in Active Directory would have to be presented as three separate directory instances. eDirectory can host multiple partitions on a single server, unlike Active Directory which is limited to a single domain (their equivalent of an eDirectory partition) on a single server. (Actually eDirectory on Unix can even run multiple eDirectory instances on a single server, listening on different IP addresses, and thus run multiple trees on a single server. We often use this feature for development labs, when there is not enough hardware (or virtual hardware) for another development box).
Here is the engine trace of the event.
[05/05/09 16:12:57.540]:ASIAPAC-AD ST:
<nds dtdversion="3.5" ndsversion="8.x">
<source>
<product version="3.6.0.4294">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<move class-name="user" event-id="mta-gwlab#20090505201256#1#1" qualified-src-dn="O=ACME\OU=Users\CN=tgwuser3" src-dn="\ACME-LAB-IDV\ACME\Users\tgwuser3" src-entry-id="34100">
<association>89cc58e90b3eda4da716bc06194428ce</association>
<parent dest-dn="CN=tgwuser3,OU=Japan,dc=asiapac,dc=acme,dc=corp"/>
</move>
</input>
</nds>
[05/05/09 16:12:57.542]:ASIAPAC-AD ST:Remote Interface Driver: Document sent.
[05/05/09 16:12:57.611]:ASIAPAC-AD :Remote Interface Driver: Received.
[05/05/09 16:12:57.612]:ASIAPAC-AD :
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20080229_143300" instance="\ACME-LAB-IDV\ACME\Drivers\IDM\ASIAPAC-AD" version="3.5.3">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="mta-gwlab#20090505201256#1#1" level="error" type="driver-general">
<message>rename failed.</message>
<ldap-err ldap-rc="80" ldap-rc-name="LDAP_OTHER">
<client-err ldap-rc="80" ldap-rc-name="LDAP_OTHER">Other</client-err>
<server-err>00002089: UpdErr: DSID-031B0CE4, problem 5012 (DIR_ERROR), data 2
</server-err>
<server-err-ex win32-rc="8329"/>
</ldap-err>
</status>
</output>
</nds>
This is another instance of an LDAP_OTHER with an ldap_rc of 80 like above. The previous example was a problem 22, invalid argument.
This time we have a problem 5012, DIR_ERROR.
Here is the Remote Loader Trace view of that event.
DirXML: [05/05/09 16:11:22.81]: Loader: Calling subscriptionShim->execute()
DirXML: [05/05/09 16:11:22.81]: Loader: XML Document:
DirXML: [05/05/09 16:11:22.81]: <nds dtdversion="3.5" ndsversion="8.x">
<source>
<product version="3.6.0.4294">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<move class-name="user" event-id="mta-gwlab#20090505201256#1#1" qualified-src-dn="O=ACME\OU=Users\CN=tgwuser3" src-dn="\ACME-LAB-IDV\ACME\Users\tgwuser3" src-entry-id="34100">
<association>89cc58e90b3eda4da716bc06194428ce</association>
<parent dest-dn="CN=tgwuser3,OU=Japan,dc=asiapac,dc=acme,dc=corp"/>
</move>
</input>
</nds>
DirXML: [05/05/09 16:11:22.81]: ADDriver: parse command
className user
destDN
eventId mta-gwlab#20090505201256#1#1
association 89cc58e90b3eda4da716bc06194428ce
DirXML: [05/05/09 16:11:22.81]: ADDriver: parse rename
DirXML: [05/05/09 16:11:22.81]: ADDriver: Connect using ldap_bind: user=idm-asia, domain=asiapac, password=***, method=negotiate, server=localhost, sign=yes, seal=yes ssl=no
DirXML: [05/05/09 16:11:22.82]: ADDriver: ldap_bind connection succeeded
DirXML: [05/05/09 16:11:22.84]: ADDriver: move CN=Test3 GWUser,OU=Shanghai,OU=bogota,DC=asiapac,DC=acme,DC=corp to CN=tgwuser3,OU=Japan,dc=asiapac,dc=acme,dc=corp
DirXML: [05/05/09 16:11:22.87]: Loader: subscriptionShim->execute() returned:
DirXML: [05/05/09 16:11:22.87]: Loader: XML Document:
DirXML: [05/05/09 16:11:22.87]: <nds ndsversion="8.7" dtdversion="1.1">
<source>
<product version="3.5.3" asn1id="" build="20080229_143300" instance="\ACME-LAB-IDV\ACME\Drivers\IDM\ASIAPAC-AD">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status level="error" type="driver-general" event-id="mta-gwlab#20090505201256#1#1">
<message>rename failed.</message>
<ldap-err ldap-rc="80" ldap-rc-name="LDAP_OTHER">
<client-err ldap-rc="80" ldap-rc-name="LDAP_OTHER">Other</client-err>
<server-err>00002089: UpdErr: DSID-031B0CE4, problem 5012 (DIR_ERROR), data 2
</server-err>
<server-err-ex win32-rc="8329"/>
</ldap-err>
</status>
</output>
</nds>
In this case, the <parent dest-dn=> node was pointing at a full object path, with CN=tgwuser3 at the beginning. Well that won't work. Although in the case of Active Directory, we find that it often can use a CN (container) object to contain other objects. Well that sounds redundant. For example, a very common error when deploying the Active Directory driver for the first time, usually in a test lab, is to leave your users in the default Users container in Active Directory.
Well for the driver to work, you need to specify where the scope of the containers in Active Directory are. Coming from an eDirectory world you would say, thats easy. OU=Users,dc=myDomain,dc=com. Well it turns out that the qualifier for a Container object is actually CN=, which we would normally (from an eDirectory perspective) consider for end nodes, like users, not containers. Easy enough to fix once you realize it has happened. Just change the Global Configuration Variable that defines the path in Active Directory.
Interestingly enough, I asked someone once, why the default CN=Users container in Active Directory installs, and finally got an insightful answer. The Container object more closely matches the containment rules for an NT Domain, than does an Organization or an Organizational Unit. Thus to enable transitioning from NT domains to Active Directory, you could move all your objects to a Container, and know that containment would allow it to work correctly.
In my example above, I happen to know that the cn=tgwuser3 is a test user object and not a container, and thus we have violated Active Directory containment rules, trying to move a user (actually the tgwuser3) from one container to a nonexistent container, that could not contain it, even if we wanted it too.
Move events from different drivers can be subtly different, and need to be handled in slightly different ways. In order to try and capture some of that complexity in a single location, I started this open call article:
Open Call for IDM Move Event Documents
In that article you can see the difference between a move event coming from an Active Directory driver on the Publisher channel, versus one sent through an eDirectory driver on the Subscriber channel. Above we have an example of an Active Directory driver, but on the Subscriber channel, which is again, just slightly different. I included XPATH examples to select the destination DNs for each type of move event you might see, which I hope people will find helpful.
LDAP_NOT_ALLOWED_ON_RDN, ldap-rc 67 error:
[05/05/09 16:44:14.700]:ASIAPAC-AD ST:Remote Interface Driver: Sending...
[05/05/09 16:44:14.700]:ASIAPAC-AD ST:
<nds dtdversion="3.5" ndsversion="8.x">
<source>
<product version="3.6.0.4294">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<modify class-name="user" event-id="Xidv1#20090505204413#1#1" from-merge="true" qualified-src-dn="O=ACME\OU=Users\CN=tgwuser3" src-dn="\ACME-LAB-IDV\ACME\Users\tgwuser3" src-entry-id="34100">
<association>89cc58e90b3eda4da716bc06194428ce</association>
<modify-attr attr-name="title">
<add-value>
<value timestamp="1241556253#1" type="string">Sir</value>
</add-value>
</modify-attr>
<modify-attr attr-name="cn">
<add-value>
<value naming="true" timestamp="1241118879#31" type="string">tgwuser3</value>
</add-value>
</modify-attr>
<modify-attr attr-name="unixHomeDirectory">
<remove-all-values/>
<add-value>
<value timestamp="1241118880#33" type="string">/home2/Test3 GWUser</value>
</add-value>
</modify-attr>
</modify>
</input>
</nds>
[05/05/09 16:44:14.703]:ASIAPAC-AD ST:Remote Interface Driver: Document sent.
[05/05/09 16:44:14.729]:ASIAPAC-AD :Remote Interface Driver: Received.
[05/05/09 16:44:14.730]:ASIAPAC-AD :
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20080229_143300" instance="\ACME-LAB-IDV\ACME\Drivers\IDM\ASIAPAC-AD" version="3.5.3">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="Xidv1#20090505204413#1#1" level="error" type="driver-general">
<ldap-err ldap-rc="67" ldap-rc-name="LDAP_NOT_ALLOWED_ON_RDN">
<client-err ldap-rc="67" ldap-rc-name="LDAP_NOT_ALLOWED_ON_RDN">Not allowed on RDN</client-err>
<server-err>000020B1: UpdErr: DSID-030F0AE8, problem 6004 (CANT_ON_RDN), data 0
</server-err>
<server-err-ex win32-rc="8369"/>
</ldap-err>
</status>
</output>
</nds>
With an Active Directory driver, you should not schema map CN in eDirectory to CN in Active Directory. It turns out that the schemata do not match, and that CN in eDirectory is multi valued, whereas in Active Directory it is a single valued attribute.
If you ever look in Console One at a user and see a value in the Other Name field on the General tab, that is a second or third instance of a CN attribute value.
This causes LDAP tools that are looking at CN as the naming attribute no end of stomach upset, and the query often names the user as cn=Jsmith uid=smithj,ou=this,o=that which is why we usually use uniqueID for LDAP tools to query against.
I used to think that uniqueID was single valued, but recently went and actually looked at schema and much to my chagrin, found out it was actually a multi valued attribute.
I imagine a multi valued uniqueID attribute on a user would make things a bit strange for an LDAP tool querying it as well.
Now you could handle this in DirXML Policy by watching for this kind of an event, and if it is an add attribute only event, adding in a <remove-all-values> node to convert that to a set destination attribute style event, which would avoid this problem. You can use reformat operation attribute to do this for you in one step if you would like. You can read more of my thoughts on reformat operational attribute in this article:
Reformat Operation Attribute
If you wanted to handle this error completely you should also decide what to do if there is more than one add attribute value for CN. If there is more than one, you ought to make a decision. Either only use the first one, or perhaps flatten and comma separate the values (Probably makes more sense in the case of an attribute like Location, than CN) or do something with it.
You will see this problem in a bunch of different attributes, where eDirectory is multi valued but Active Directory is not. This can be painful. I think Telephone number, Location, Description, Facsimile Telephone Number are just a couple of examples. We have a really neat generic rule my boss wrote that parses the application schema that is stored on the driver object, which on the first driver startup reads the schema out of Active Directory and stores it in a large XML attribute on the driver object.
As an exercise for the reader I leave the process of using that to decide if each operational attribute in the event document is a single or multi valued attribute. This allows you to handle all of schema with one rule, instead of one flattening rule for every attribute you identify. There is a weakness in this, as the application schema stored on the driver is actually not 100% accurate and we have found errors creep in, and I am not sure of the exact cause of that.
Well that's about it for this article, stay tuned for the next in the series, I still have more error codes to work though, and I hope others will take up my charge and start writing these sort of articles as well.
Support
Documentation
Learning Services
Partner Programs