Novell Identity Manager is a big product with lots of moving parts. It can be quite daunting to get started working with it. Just as bad, the deeper you dig, the more complexity you discover. Now this is not necessarily a bad thing, it is just something you have to deal with. There is a learning curve.
Thus my attempt here to try and lower that curve. First off I have an article with stuff you should start off reading to get over the first hump in the learning curve. If you have not already read this stuff, take a few minutes and do so, it will pay off ten fold as you work through IDM: FAQ: Getting started with IDM, what should you read?
On top of the learning curve, there are some reasonably well known common problems that beginners in the product will run into. I figured that trying to write them down can only help. If nothing else, Google ought to find it, if you search for it.
Thus I started this series, with the first article that you can read here: Common Mistakes Newcomers to IDM Make - Part 1
In that article I covered the concepts:
In the second article, Common Mistakes Newcomers to IDM Make - Part 2 I covered examples of:
In the third article Common Mistakes Newcomers to IDM Make - Part 3 I covered examples of:
Now on to part 4!
I think this is probably one of the least understood, and most confusing issues about Novell Identity Manager. (Ok maybe XPATH is worse, but this one looks like it is working wrong).
First off you need to realize that eDirectory has a schema flag called Per Replica. Simply put this means the attribute does not replicate. Yes, I meant that! Attributes flagged Per Replica can have one value on Replica A and a different value on Replica B, and will not replicate from one to the other.
From a purely eDirectory perspective this seems like madness. From an IDM perspective this makes strange and compelling sense. Imagine the classic example attribute: DirXML-ShimAuthInfo. This attribute is meant to store the connection ID to use to connect your driver to the target system. Well imagine you have two servers in your driver set running the engine, and you wanted to configure them as an active passive pair, where one is up and running and syncing users while the other points to a different Remote Loader, ready to go, but disabled.
Well of course you need to have two different values for the connection string. One server needs to have the production values, and the other server needs to have the backup values. So here you have a really useful case for a single attribute in eDirectory, that can exist on different servers, with different values.
What makes this one so painful is that if you use a tool like ConsoleOne or iManager there is no really good way to be certain which server you are talking too. Therefore if you try and look at the raw attribute value of the DirXML-ShimAuthInfo attribute then it depends which server you are looking at. Alas most tools do not show you all the values from all the possible replica copies of the attribute. In fact, only Designer does that. If you do a Compare of a driver and one of these attributes differs, then you will see an entry in the summary for each servers copy that is different.
Where this gets tricky is that while this makes a lot of sense, the Global Configuration Variable values (GCV) are stored in a similarly flagged attribute. Thus the GCV's on ServerA are in no way replicated to Server B. This too makes sense once you think about it, since you often configure information specific to a server in these values. Thus a very very common mistake is to look in Designer, and not realize there are two servers in the driver set, and see or not see the settings you expect. There is a little selector, that shows you the available servers to choose. Whichever one you select is the view of the world. Alas, it defaults to the first server added to the driver set all the time, so it can be a pain if you are working in a driver using the second driver.
To look at these attributes raw, which can be helpful in troubleshooting and understanding the contents of the attributes, your best bet is to use an LDAP browsing tool like ApacheDS or LBE Jarek Gawor's excellent LDAP Browser/Editor v2.8.2. Via LDAP you specify the server you are asking for data from, and thus do not have to worry about ConsoleOne trying to be clever and use different servers in the background.
Probably the worst part of this, is that the user interface in iManager is quite painful for managing these attributes. There is a server menu on the Driver Set Overview page that lets you choose from the available servers, however when you open up the Driver Properties page, it defaults back to the first server in the list again. This can be quite painful as it is easy to forget to switch over and make the change you need on the wrong servers copy of the attributes.
You can read more about the various Driver and Driver Set attributes in a series of articles I wrote on the topic:
The dead giveaway is when you have set a value in iManager or Designer, restarted the driver and it is not taking affect. You go look at trace, and you can see it set the wrong (old) value as if you had made no such change. Which in fact you had not, since you changed it on the wrong server instance of the attribute.
Many of the attributes have this behavior and once you know about it, there is no big issue, but if you are not aware, man is this a strange problem to figure out. After all, why is eDirectory not replicating your changes? After all, the whole point of a distributed replicated directory service is to replicate the darn data!
One of the powers of Novell's IDM solution is that the meta data about users are stored in the Identity Vault. Other competitors have a secondary database with the meta data, and thus need potentially two different lookup paths often. Novell IDM stores the association data, how this user in the IDV is associated to that user object in the connected system as an attribute called DirXML-Associations. This is an interesting attribute as it uses one of my favorite syntaxes, Path syntax in schema.
Path has three parts (when you see them in XML in trace they are known as components) that come from the need to represent a file system location in eDirectory. The first a namespace reference from way back in the day, where the name of the object could be stored in multiple namespaces, (DOS being 8.3, Macs having a different name, and NFS yet another, with OS2 later renamed LONG having yet another name.) so you needed to provide the namespace you are using to address the file. This is usually a low number from 0 to 3 or so, but in schema is actually defined as a full 32 bit integer, so it can be any number for 0 to four billion or so. In the context of DirXML-Associations this is only meant to be 0 to 4, with the following meanings:
0 Ignore this object
1 Associated
2 Pending
3 Manual
4 Migrate. Changing to this value asks the engine to generate a sync event for it.
There is a nice article with these values explained a bit here: LDAP Search Examples for Retrieving Associations
I recall reading that basically only 0, 1, and 4 are used any longer in modern releases of IDM. But I do not have a reference to back that up.
Second component is volume, meant to literally be a DN reference to the volume object holding the file system. Old style Netware volumes, and even modern NSS volumes have an object in eDirectory that references them. In the case of NSS volumes, it is mostly to hold a GUID like attribute (a large seemingly random number, globally unique to that volume) that references the NSS file system objects GUID so that eDirectory can connect the object to the actual file system somehow.
However in this case, the DN is referring to the driver object for which this association is relevant. I.e. You need to know that this is an association for a specific Active Directory driver, not the AS400 driver. Mixing the two up would be of little value to each other.
The final component of Path syntax is confusingly named path. But this is meant to hold the string value of the path to the file or directory in the filesystem referenced by the volume component. So this would have been something like \home\geoffc\articles\mistakes.txt and in the case of DirXML-Associations is actually the association value.
On a complicated side note, the path component can be a nodeset or a string, as a nodeset it would be a path.xml, and depending on what you address will control the output. This is probably fodder for a standalone article, and mostly applies to DirXML-EntitlementRef attributes. Either way you set it, you would set in XML looking text into the variable. However what it means differs. If you set it as path,xml then you can use XPATH upon it within the event document. (Which is true when you read it back). If you set it as text, then it will properly store the XML data in the attribute, whereas I found setting it as text into path.xml escaped the less than signs and stored it, so that it would not return correctly as XML when read out of the directory. You get a very funny error in trace that alas I did not save. This ends up being reasonably complicated for what seems like a simple thing. If the data comes back as path,xml in your query results then your XPATH should use the component[@name='path.xml'] to select it. But you can also select further down into the nodeset, say component[@name='path.xml']/ref/param on an DirXML-EntitlementRef.
Whereas when returned as path, say in a DirXML-Associations then you select it with component[@name='path'] and even if it looks like you stored some XML in there, you cannot XPATH into it, as it is really just a string not a nodeset of XML to the engine.
Now every driver has a different value and I tried to collect all the values I can find information about in one place, which you can read here: Open Call - IDM Association Values for eDirectory Objects
But as an example, the Active Directory value is the AD GUID reformatted as GUIDs are wont to be formatted. (I was surprised but there really is a standard way to do this, who knew?). http://en.wikipedia.org/wiki/Globally_unique_identifier
Now managing associations is a bit tricky because of the structured nature of the attribute. In LDAP you get it separated by # signs, and the ordering is changed. While the engine will return the order in a query or event as nameSpace, volume, path, in LDAP it will have the DN in LDAP format (instead of backslash format), but the order will be volume, nameSpace, and then path.
There is a really nice tool available for managing them, from Novell Consulting out of Hungary that I still like to use. It does require Client 32 and is Windows only, but the UI is just right for the task. Alas on large trees (20 thousand objects or more) it is a bit slow. You can find it at one of these links, as DAModifier:
This is great as you can select a tree you are logged into, pick the driver, and get all the associations and states for each object class in the tree. You can back them up to a file and restore them later. Great tool overall, you will not regret looking at it. I would love to see an LDAP version of this tool, and cross platform is some ways.
In a driver you can manage these sorts of attributes fairly easily using XPATH. I concede it looks a bit scary at times, but it is pretty easy once you get the hang of it.
As I mentioned a bit earlier, to pick out one of the parts of the structured attribute you use an XPATH of component[@name='volume'] or the like.
But because DirXML-Associations use the driver DN as the volume component, you can do an XPATH test of comparing that to the GCV dirxml.auto.driverdn which holds the current drivers DN in backslash format. This is helpful as it does not lock your policy down to one driver, since it will get the correct value where ever it is running.
This is useful if you have a policy linked into multiple drivers and want to maintain it once for all of them.
You can read more about some ideas on using XPATH on DirXML-Associations in this article:
That about wraps up this article. As always, if you have seen a common mistake first times, or even advanced users make, please let me know in the comments, via a message, or in the support forum and I will try and address it in a future article.
Stay tuned for part 5 where more common mistakes left on my list will be addressed. My list seems to stay the same length, as the more I write about it, the more I think of to add to the list!
Support
Documentation
Learning Services
Partner Programs