Novell Identity Manager is a very powerful tool. In its first release, some people at Novell had suggested that it was so complex and powerful, there was no way they could ever release it as a red-box product. That was release 1.0, and I have to say, probably a good point! With each ensuing release the product gets better and better. Each driver is developed somewhat independently of the others, and they all benefit from features and fixes at the core of the product.
With the latest releases, it is ALMOST possible to do a Click > Next style install, for some of the drivers. When you get some experience with the product, think back about how impressive a task Novell has accomplished by building such powerful and useful cookie-cutter installs.
One downside is that because Identity Manager is a composite product that runs on top of eDirectory as a native module (compiled per platform, lots of platforms!), as a Java-based service, with some kind of remote driver on some other platform, the error messages you get can be quite diverse. Some of the error codes are oddly obscure, but once you understand which is the important part, you will quickly learn what the issues really are.
Here are some of my personal favorites. I would love to see people contribute some of their personal favorites. That will help build a searchable library of what the common errors are, and most importantly, explanations of how to read them and proceed to troubleshoot them.
UniqueSPIException (Error -601)
This error is actually pretty common. You would see it in iManager, Identity Manager, Console One, and pretty much any Java application that can access eDirectory. For example:
com.novell.admin.common.exceptions.UniqueSPIException: (Error -601) The object name entered could not be found in the context specified. Refer to Help for all listings of possible causes and solutions
In this case, this is the Java class that Novell uses to pass back eDirectory errors. 601 is object not found (i.e., no such entry), 602 is rarely seen but is no such value, 603 is attribute not found, and 604 is no such class.
The key thing to note, before going off on a tangent, is that the UniqueSPIException Java error is really saying, eDirectory returned an error, go deal with eDirectory to resolve it.
-601 is basic and means that the object you referenced (like cn=admin.o=acme. or more commonly in an Identity Manager trace format \ACME\ADMIN) cannot be found. It’s probably due to a typo, or the rule assumes the object exists but it does not. Start thinking about why the referenced object is not there. There are many scenarios to generate this error, but the hope is this is enough of an explanation for you to look in the trace, see what the object referenced is, how the distinguished name (DN) got chosen (or created or whatever), and fix the issue at hand.
-602 is almost never seen, and I am not sure how I would troubleshoot it, to be honest.
-603 is very common: “attribute not found”. This is not highly common in Identity Manager, but in iManager this is often a dead giveaway that the schema extensions that the snap-in is expecting are not there. The snap-in tried to read or write (probably read) an attribute it was expecting, but is not there.
A fairly common example: When you apply Security services 2.05 patch to your tree, it includes new schema modifications to support some really cool new password policy options. The new Password management snapins try to use these, but the Security Services patch is smart and does NOT blindly extend your schema when you apply it. That is left as an exercise for the administrator to extend the schema after testing that all is healthy in the tree, at an appropriate time. (I suppose that’s a bit of a stretch, since you can probably extend schema whenever you want, as long as the tree is healthy and in synch.)
So as you try to set a policy, it will try to read and write new attributes that are not yet available. When reading, it will get the 603 error. The write will probably throw a 608 error.
-604 would happen if you try to read an object while specifying an object class that is not in the tree. This is often caused by typos in rules.
-605 is “no such partition”, and I cannot think of an Identity Manager context to generate one of those.
-606 is “object already exists”. This is pretty common. It usually means your matching rule screwed up. That is, if the event fires on an unassociated object, then it passes through the matching rule. It really should match at that point. If not, it goes through the Creation and Placement rules to get ready to make the object in the target system. However, if Matching failed, and you correctly generate the same target name as the one that already exists, you will get a -606 error. Look at the trace to see why it did not match, and troubleshoot from there.
-607 is “not effective class”, and I have never seen this one in action. I suppose if you try to make an object in eDirectory with Object classes that are only Auxiliary or Structural classes, you would get one of these. But it would take a bit of effort to trigger one of these errors.
-609 “illegal attribute” is pretty common. One thing Identity Manager does magically for you is to add any auxiliary classes needed in eDirectory, if the attribute is not in the base class of the object. For example, you may decide to add your acmeSomeValue attribute somwhere in the Publisher channel. This attribute is part of the Aux class acmeAddOnClass in your tree. You won’t have to modify Object Class in your rule; the engine will add the object class to make sure all is well. That is when things are working. When they are not, for some reason, the engine tries to add an attribute that the object is not allowed to contain, based on its object class. For more details see: http://www.novell.com/communities/node/2290/auxiliary-classes-and-identity-manager
This is most common when you write directly to eDirectory but skip or short-circuit the engine’s default behavior. (To see how the Active Directory driver handles this, refer to: http://www.novell.com/communities/node/2508/ad-driver-default-rule-oddity)
The best way to troubleshoot this is to look at the add or modify document in the trace, and see what attributes are being added or modified on the user. Then using some kind of schema tool, look at the object class the object has – User plus any aux classes – and find the attribute that is not part of that set.
It is a bit of a pain, since the operation is atomic and fails or succeeds as one operation, without reporting WHICH attribute was the problem. This would be a huge time saver if the engine could tell us which attribute is missing. My personal suspicion is that the engine is using the eDirectory API’s through Jclient, which does not support this function. Oh, well …
-610 is “illegal name”. Usually you have constructed an invalid target name somehow. Look at the name and see what is wrong. This is pretty hard to do in Identity Manager even on purpose, but a more common Java app might be DXCMD which when you login expects admin.acme, and .admin.acme would be considered an illegal NDS name.
-611 is “illegal containment”, and I have personally never triggered this one. I could imagine that if you had a container object, and you tried to place an object in it that is not specified by the schema, this error would occur. There must be an obvious example, but I am drawing a blank on it – it’s pretty rare.
-612 is “cannot have multiple values”. This would occur if you try to add an attribute to an already populated single-valued attribute. This is why you so often see a “remove all values” before an add in the trace. Single-value attributes need to have their values replaced, not added.
613 is syntax violation. This is VERY common as you are getting a driver going. The most common example is an attribute that requires Distinguished Name (DN) syntax. Setting a DN syntax attribute to blank is not allowed. This usually happens when your construction of the value or search for the value failed for some reason. Be careful when using DN syntax attributes! They are very powerful, but you need to remember that before letting the document flow to eDirectory, you should check whether there actually is a value for the attribute.
This error also is atomic, so you could see an add document with 20 attributes, and one of them is bad. Have fun tracking it down. The better you understand schema the faster you will troubleshoot it! Watch out for data that is too long for the attribute (e.g., an attribute sized to 8 characters; adding an 11-character value is not valid). DN syntax is an example of too ‘short’ a value, sort of.
There are many other possible error codes that could be reported. For the official complete set, see TID 10080995 at:
For the next article in this series, I will talk about other Java-based error codes that are generic. You’ll really need to read further into them to resolve the problem.
If you have any such examples, please write them up and submit them! The more, the merrier – and the better – we will all be for it!