Novell Home

Cool Solutions

aburgemeister

Contact aburgemeister
Member since 1/3/2007

Bio

No author bio information

User Points

17805 points earned on legacy (former) Cool Solutions site
0 points earned on this site

Author Archives

WorkOrder Details

aburgemeister

June 13, 2007 10:19 am

Reads:4,931

Comments:1

In this AppNote, Aaron Burgemeister explains the inner “workings” of the WorkOrder driver, complete with tree design strategies, code samples, and test details.

+read more

2 – WorkOrder Detail

aburgemeister

June 7, 2007 12:12 am

Reads:3,912

Comments:0

Okay, where did we leave off? Ah yes, I believe we are working with the WorkOrder driver. The order (haha.. bad pun) of the day was to get a couple of these beauties working together to manage the beginning and end of a user’s life but let’s skip the beginning for now (people asking for demos now, not later). Eventually my plan (possibly revised from before) is to get it all in one driver. The developer says this will help things out. He also mentioned efficiency in keeping all WorkOrders for a given driver in their own container rather than having multiple drivers’ objects per container. So it is possible, but apparently not recommended by people who know things, to have those objects clumped together. Sorry for any misinformation. I’m trying to get this all done properly the first time but apparently my perfection is wearing thin these days.

So in the previous post I gave the example of how this could be used when a user is created having them enabled a couple weeks later when they officially started work or school. The other example was of a user being terminated for one reason or another. Setting their ‘loginDisabled’ attribute to TRUE should take care of them, but maybe deletion should not be done right away for some kind of legal/compliance reason. Working around this is what we’ll demonstrate today with disturbing amounts of detail. As one mentor of mine likes to say, “I hear and I forget; I see and I remember; I do and I understand.” As we work through this do it on your own as well. This is a free driver that comes with a product that has a 90-day evaluation and can run on eDirectory (no license required for this kind of thing) on Linux (again, free). You can even use various tools for the setup that aren’t command-line tools like iManager and Designer which are both $10,000,000,000 per CD at AB’s Shopping center (comes with setup and technical support), but free if you get them online.

So let’s move into the driver. I’m including the export of my current driver (testWO-0) with this entry for any who are wanting to use it directly. All examples will be from this example with its current policies. Importing the preconfigured driver is as simple as almost any other driver though, unless you name your driver ‘WorkOrder’ (case-sensitive), you must change a few things after the fact. With my first shot I did not name my driver ‘WorkOrder’ and it was a good learning experience so I’ll be passing that all along. To start with let’s import a default driver and look at the options in there.

Actually, let’s start at the very beginning, a very good place to start. For this walk-through I’m using Mobile/Workstation iManager 2.6 SP3 with the IDM 3.5 plugins. The same driver import can be done with Designer with a few differences but those should be fairly minimal. Open iManager, login as somebody with power, choose ‘Identity Manager’ and then ‘Identity Manager Overview’. Go ahead and search for a DriverSet in your tree. If you don’t have one go ahead and create one. If you just created a DriverSet you’ll be prompted to import a driver configuration. If not click ‘Add Driver’ and then choose the WorkOrder-IDM3_5_0_V1.xml. This is the driver preconfig which has the default settings in it. Moving to the next screen rename the driver to testWO-0 (case-sensitive for these examples). Choose a container for WorkOrder objects. At this point I need to explain my tree a little bit.

Many organize their trees by hierarchy or geography, which is a great model to follow. There are some problems that arise with these models, though, like where to put things that aren’t people. Where do servers go? Where do printers go? Where do IDM objects and DriverSets go? IDM especially does not lend better or worse when placed geographically and most of the time neither do non-users/groups, at least in my limited experience. With this in mind my tree tries to work around all that. At the root of my tree instead of an Organization I have Security along with two domains (DC) called ‘org’ and ‘system’. ‘system’ contains everything that isn’t a human or group and ‘org’ contains all of my organizations (‘novell’, ‘suse’, etc.). Having multiple Organizations underneath this common non-Tree object is really nice with IDM because you have a starting place for various queries that is not the Tree object. Rights can be assigned without affecting servers through inheritance. Life is generally good. Underneath the Os it’s fairly typical and broken down by whatever is best (geography, company hierarchy, etc.).

On the ‘system’ side is where the beauty lies. Under ‘system’ are ‘user’, ‘service’, and ‘server’ Domains. Under ‘server’ is a container (Domain) for each server in the tree (named the same as the server instance) which holds all of the server-related objects. Underneath ‘service’ is a Domain for each service in my tree including ‘lum’, ‘idm’, ‘rbs’, ‘mail’, and whatever else I throw in here. Finally under ‘idm’ exist all of my IDM-related objects including DriverSets, Organizational Roles (from which drivers receive their privileges), and for this driver the various WorkOrder and WorkToDo containers. See another blog entry later on for more benefits of the tree design.
Tree Layout in ConsoleOne
So with this driver import my containers are dc=testwo-0workorder,dc=idm,dc=service,dc=system and dc=testwo-0worktodo,dc=idm,dc=service,dc=system. These containers are where the physical WorkOrder and WorkToDo objects will live in eDirectory while waiting for processing or after completing all processing and waiting for deletion or administrator action. Note that the import actually wants these in dot notation and not LDAP format as I’m specifying them (for simplicity understanding the levels).

The default polling method is ‘By Interval’ which is great for this test. Set the Driver Heartbeat to ‘No’ because we don’t need it at this point. We’ll also be running this driver locally. On the next screen enter a polling interval in minutes. In real life this should probably be something like 60 but in this example we’ll use something from one to five (your choice).

On the next screen define the driver’s security equivalence. I created an Organizational Role called cn=testwo-0defaultdrvrset35,dc=idm,dc=service,dc=system specifically for this driver. It was given supervisor to Entry rights to a container under my suse Organization (cn=testwo-0,o=suse,dc=org) and also the same for the WorkOrder and WorkToDo containers specified earlier on. In a production environment the Organizational Role may need rights to more of the tree but, as I said, I do lots of testing so having things with rights assigned all over just for kicks leads to anomalies that are a pain to troubleshoot. Be sure to exclude administrative accounts. Having granular rights assignments and good tree design minimizes the impact of forgetting this step (my admin accounts are all separate under dc=user,dc=system) but excluding your own user is always a good idea when testing.

Finally complete the import. At this point a driver should be in the tree with the start option of Manual. If you are using the import I’ve included the start option is set to Disabled so you don’t inadvertently cache events. As with any IDM driver there is a TAO file caching events if the driver is in Manual or Auto-Start mode but not running, or when running but not keeping up with the incoming work load.

Go ahead and open the driver properties for this driver. First on the scren should be the driver class of ‘com.novell.nds.dirxml.driver.workorder.WorkOrderDriverShim’. The next few fields are, as far as I can tell, not really used. Like the Loopback driver this doesn’t have an application against which it needs to authenticate so the ‘Driver Object’ and ‘Application’ passwords don’t do anything. Similarly the authentication ID and context don’t do anything (I have no idea why they have values in them by default but, as in most things XML, extra doesn’t hurt). Below the Startup Options are some Publisher Settings. My ‘Work Order Objects DN’ is ‘system\service\idm\testwo-0workorder’, ‘Poll Interval (minutes)’ is 5, ‘Poll Time’ is blank, and ‘Heartbeat on’ is ‘No’. Feel free to look around the rest of the options in here as most things are fairly standard. A lot of fields are not present because that is the nature of the driver. While looking around go to ‘Misc’ and set the trace level to 3 and write the trace file to something like ‘/var/opt/novell/idm/testwo-0/trace.log’ after running `mkdir -p /var/opt/novell/idm/testwo-0` on your server or creating the appropriate directory structure some other way. Change these back before going into production but for now having the trace ready will probably help more than hinder.

Now finish up in the driver properties and move to the Driver Overview by clicking on the driver object itself. You should now be at the ‘fishbone diagram’ with both the Subscriber and Publisher channels shown. Here we are going to make some slight modifications. Choose the Filter and add the User class and, underneath that, the Login Disabled attribute. Set the class to Synchronize and the attribute to Notify on the Subscriber channel leaving the Publisher set to Ignore for both class and attribute. The WorkOrder and WorkToDo classes should be in there properly already.

Notice there is not Event Transformation policyset included nor is there any Matching policyset. There’s nothing to match here so that’s gone of course. The Creation policyset has one simple rule that verifies any WorkOrders coming in via the Subscriber channel are valid with all required attributes present.

Moving along to the Placement policyset is some important stuff that you MUST change for things to work currently. As the default driver was setup the placement policy looks like it will put WorkOrder objects in some \WorkOrder container with the name of the object moving through. This is not really the case and can be a cause for confusion so don’t let it do that. The Placement policy simply marks the object with the driver name which is case-sensitive and then the name of the WorkOrder object in the channel (which can be anything unique to that container where WorkOrder objects go). So if you had not renamed your driver it would be named ‘WorkOrder’ and the placement policy of \WorkOrder\Source Name() would work properly; however, the instructions were to rename the driver to testWO-0 so now things do not work and you will get a nasty error in the trace about how you have ‘No Destination DN’. Right before that shows up the trace actually tries to help you know what is expected so that was a nice addition from the developer. For some fun let’s look at a trace with this in it:

[05/02/07 17:19:01.474]:testWO-0 ST:Submitting document to subscriber shim:
[05/02/07 17:19:01.477]:testWO-0 ST:
<nds dtdversion=”3.5″ ndsversion=”8.x”>
<source>
<product version=”3.5.0.20070315 “>DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<add class-name=”WorkOrder” dest-dn=”system\service\idm\testwo-0workorder\wotest06″ event-id=”idm0lin-1a#20070502231901#1#2″>
<add-attr attr-name=”Description”>
<value type=”string”>\IDM0TREE\org\suse\testwo-0\test06</value>
</add-attr>
<add-attr attr-name=”Content”>
<value type=”string”>\IDM0TREE\org\suse\testwo-0\test06</value>
</add-attr>
<add-attr attr-name=”DueDate”>
<value type=”string”>1185707941</value>
</add-attr>
<add-attr attr-name=”DeleteDueDate”>
<value type=”string”>1185707941</value>
</add-attr>
</add>
</input>
</nds>
[05/02/07 17:19:01.494]:testWO-0 ST:##WorkOrder Sub —–:: WOSubscriptionShimm execute
[05/02/07 17:19:01.496]:testWO-0 ST:##WorkOrder Sub —–:: commandClass = class com.novell.nds.dirxml.driver.xds.XDSAddElement
[05/02/07 17:19:01.498]:testWO-0 ST:##WorkOrder Sub —–:: WOSubscriptionShim addHandler driverDN = \testWO-0\Object DN =system\service\idm\testwo-0workorder\wotest06
[05/02/07 17:19:01.502]:testWO-0 ST:SubscriptionShim.execute() returned:
[05/02/07 17:19:01.503]:testWO-0 ST:
<nds dtdversion=”2.0″>
<source>
<product build=”20070301_0812″ instance=”testWO-0″ version=”3.5″>DirXML WorkOrder Driver (Java)</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id=”idm0lin-1a#20070502231901#1#2″ level=”error” type=”driver-general”>
<description>No Destination DN</description>
</status>
</output>
</nds>

So we can see that this is the end of the document’s life on the Subscriber channel. It is off to the shim and it has a dest-dn that I ever-so-cleverly set to where my WorkOrder objects should go. The only problem is that I didn’t understand what was going on at all. The trace shows what is wrong at 17:19:01.498. It states that driverDN=\testWO-0\Object and then the actual DN which is system\service\idm\testwo-0workorder\wotest06. The part about driverDN is what it wants, only with something unique in the place of ‘Object’. So here we have worked past our first error that would probably catch most people new to the WorkOrder driver up for a fair chunk of time. It’s not very intuitive at all but if I hadn’t wanted some naming scheme for this driver it wouldn’t have happened. We’ll see what happens to this object on the Publisher side.

So we’re past the placement policy. The next thing to do is to get to the Command Transformation policyset. This is an important place for our driver because, as you may recall, the idea is to have a WorkOrder created when a user is disabled and to cause the WorkOrder to be used after a period of time finally deleting the user who was disabled. We have allowed the User object into the channel but we still don’t have a WorkOrder. It will be created in the Command Transformation policyset.

Note that a lot of the code to do this is actually in the WorkOrder driver documentation. One of the links with code doesn’t open very nicely in a browser that bothers to verify the XML but the files do work and can be viewed if you go after the source from the browser or save them directly to your system.

The first policy in the policyset creates the WorkOrder from the user synchronizing through.

<?xml version=”1.0″ encoding=”UTF-8″?><policy xmlns:jdate=”http://www.novell.com/nxsl/java/java.util.Date” xmlns:jformat=”http://www.novell.com/nxsl/java/java.text.SimpleDateFormat”>
<rule>
<description>Convert User object Add to Work Order object add</description>
<conditions>
<and>
<if-operation op=”equal”>add</if-operation>
<if-class-name op=”equal”>User</if-class-name>
<if-op-attr name=”Login Disabled” op=”changing-to”>TRUE</if-op-attr>
</and>
</conditions>
<actions>
<do-set-local-variable name=”order-dest-dn”>
<arg-string>
<token-text xml:space=”preserve”>\testWO-0\</token-text>
<token-src-name/>
</arg-string>
</do-set-local-variable>
<do-add-dest-object class-name=”DirXML-WorkOrder” when=”after”>
<arg-dn>
<token-local-variable name=”order-dest-dn”/>
</arg-dn>
</do-add-dest-object>
<do-add-dest-attr-value class-name=”DirXML-WorkOrder” name=”Description” when=”after”>
<arg-dn>
<token-local-variable name=”order-dest-dn”/>
</arg-dn>
<arg-value type=”string”>
<token-src-dn/>
</arg-value>
</do-add-dest-attr-value>
<do-add-dest-attr-value class-name=”DirXML-WorkOrder” name=”DirXML-nwoContent” when=”after”>
<arg-dn>
<token-local-variable name=”order-dest-dn”/>
</arg-dn>
<arg-value type=”string”>
<token-src-dn/>
</arg-value>
</do-add-dest-attr-value>
<do-add-dest-attr-value class-name=”DirXML-WorkOrder” name=”DirXML-DueDate” when=”after”>
<arg-dn>
<token-local-variable name=”order-dest-dn”/>
</arg-dn>
<arg-value type=”string”>
<token-xpath expression=”round(jdate:getTime(jdate:new()) div 1000)+60″/>
</arg-value>
</do-add-dest-attr-value>
<do-add-dest-attr-value class-name=”DirXML-WorkOrder” name=”DirXML-nwoDeleteDueDate” when=”after”>
<arg-dn>
<token-local-variable name=”order-dest-dn”/>
</arg-dn>
<arg-value type=”string”>
<token-xpath expression=”round(jdate:getTime(jdate:new()) div 1000)+21600″/>
</arg-value>
</do-add-dest-attr-value>
<do-veto/>
</actions>
</rule>
</policy>

This first policy works for add events for objects of the User class which have a loginDisabled attribute changing to TRUE. Once that is established a new object is created with a proper dest-dn (see previous paragraphs), a DirXML-DueDate set to one minute from the current time (when the WorkOrder will be processed on the Publisher channel, one minute isn’t the most-practical example but it does lend itself to faster testing), Description and DirXML-nwoContent attributes which both happen to have the DN of the original user object in them (for use later), a DirXML-DeleteDueDate set to 6 hours in the future, followed by a veto of the original User-add event. So the end document is a full DirXML-WorkOrder object with the required attributes set to process in one minute and to be deleted in six hours. So far so good.

The next policy finishes making the DirXML-WorkOrder object complete by adding a source DN (src-dn) as well as the object’s first status of ‘pending’ which is important. The publisher polling that takes place every few minutes looks for WorkOrders of different types. A ‘pending’ WorkOrder is ready to be worked on immediately assuming the DueDate has been reached. Other statuses include ‘error’ which are WorkOrders that will not be processed until somebody intervenes or the driver deletes them if the driver is set to delete erring WorkOrders. Anyway it’s a tangent I don’t want to explore right now but just keep the status in mind. The next policy in the Command Transformation policyset follows:

<?xml version=”1.0″ encoding=”UTF-8″?><policy>
<rule>
<description>Set Synthesized WorkOrders Source DN</description>
<conditions>
<and>
<if-operation op=”equal”>add</if-operation>
<if-class-name op=”equal”>DirXML-WorkOrder</if-class-name>
<if-src-dn op=”not-available”/>
</and>
</conditions>
<actions>
<do-set-op-src-dn>
<arg-dn>
<token-attr name=”Description”/>
</arg-dn>
</do-set-op-src-dn>
<do-add-dest-attr-value class-name=”DirXML-WorkOrder” name=”DirXML-nwoSendToPublisher”>
<arg-value type=”string”>
<token-text xml:space=”preserve”>true</token-text>
</arg-value>
</do-add-dest-attr-value>
<do-add-dest-attr-value class-name=”DirXML-WorkOrder” name=”DirXML-nwoStatus”>
<arg-value type=”string”>
<token-text xml:space=”preserve”>pending</token-text>
</arg-value>
</do-add-dest-attr-value>
</actions>
</rule>
</policy>

So we can see that if src-dn is not available one is added. The src-dn that is assigned is the one from the User that started this whole mess. Also the DirXML-nwoSendToPublisher is set to true so this document will be sent to the publisher. What does that mean specifically? When a subscriber WorkOrder is “sent to the publisher” it means it is written to the container you specified way back in the beginning. If we also added a rule that said ‘DoItNow=TRUE’ the Publisher would also fire up and process all WorkOrders, but that’s not the case for us now (doesn’t make much sense really since we’re planning on everything happening in one minute, not immediately, and this would probably be set to do things in thirty to ninety days in a production system).

That’s it for the Subscriber channel. We have told the new WorkOrder to go to eDirectory where it is waiting for some kind of action from the Publisher channel’s polling. That polling is where more fun takes place. Looking at that channel you may have noticed it is quite sparse. There is nothing populated except for the Schema Mapping policyset and the Placement policyset. Let’s skip over to the Placement policyset and see how mine has changed slightly from the default.

<;?xml version=”1.0″ encoding=”UTF-8″?><;policy>
<;rule>
<;description>Work Order Placement<;/description>
<;conditions>
<;and>
<;if-class-name op=”equal”>DirXML-WorkOrder<;/if-class-name>
<;if-src-dn op=”in-subtree” xml:space=”preserve”>\WorkOrder\<;/if-src-dn>
<;if-src-dn op=”not-equal” xml:space=”preserve”>\WorkOrder\<;/if-src-dn>
<;/and>
<;/conditions>
<;actions>
<;do-set-op-dest-dn>
<;arg-dn>
<;token-text xml:space=”preserve”>system\service\idm\testwo-0workorder<;/token-text>
<;token-text xml:space=”preserve”>\<;/token-text>
<;token-src-name/>
<;/arg-dn>
<;/do-set-op-dest-dn>
<;do-break/>
<;/actions>
<;/rule>
<;rule>
<;description>Work Order To Do Placement<;/description>
<;conditions>
<;and>
<;if-class-name op=”equal”>DirXML-WorkToDo<;/if-class-name>
<;if-src-dn op=”in-subtree”>\WorkOrder\<;/if-src-dn>
<;/and>
<;/conditions>
<;actions>
<;do-set-op-dest-dn>
<;arg-dn>
<;token-text xml:space=”preserve”>system\service\idm\testwo-0worktodo<;/token-text>
<;token-text xml:space=”preserve”>\<;/token-text>
<;token-src-name/>
<;/arg-dn>
<;/do-set-op-dest-dn>
<;do-break/>
<;/actions>
<;/rule>
<;/policy>

The first rule should catch your attention. It has that pesky driver name in there again. We have already modified the placement policy for WorkOrders on the Subscriber side to have the correct driver name and we should do the same here or anything coming back from the shim on its way to be written in eDirectory will fail. The first rule is designed to give WorkOrder objects a valid placement policy in eDirectory. This path came straight from the preconfig back in the beginning when we were asked for it which is why it has that in there already. With the proper conditional statements WorkOrders can now safely make it into the holding cell in eDirectory.

The second rule is geared toward the WorkToDo objects that come from the polling cycles the driver is set to do already. As a WorkOrder object is brought in from eDirectory it is made into a WorkToDo object containing the same attributes that the original WorkOrder object contained. It is this object that will cause all the fun to happen after the user has been disabled for thirty to ninety days (or one minute in our case). Note that the Publisher is polling regularly for objects whose DirXML-DueDate attribute is in the past. When that time is in the past and the polling cycle runs and the object is ‘pending’ it is processed. So after the period of time the Publisher Placement policyset eventually ends up with this object and by default puts it in the WorkToDo container specified back when originally setting up the driver. This is fine but doesn’t do anything for anybody. It is possible you could then have other drivers act on objects created in this container. You could also write scripts or applications in other languages that watched this container for additions and did things based on those additions. In this case, as this is a simple example, we’ll just delete the object of the user who was disabled. What follows is the Publisher Placement policy from my driver. Granted I have hacked it up a little because I didn’t know exactly what I was doing in the beginning but it still works nicely. Most of the hacking seems to be on the conditions for the placement policy for WorkOrder objects, not WorkToDo objects.

<?xml version=”1.0″ encoding=”UTF-8″?><policy>
<rule>
<description>Work Order Placement</description>
<conditions>
<and>
<if-class-name op=”equal”>DirXML-WorkOrder</if-class-name>
<!– <if-src-dn op=”in-subtree” xml:space=”preserve”>\WorkOrder\</if-src-dn>
<if-src-dn op=”not-equal” xml:space=”preserve”>\WorkOrder\</if-src-dn> –>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text xml:space=”preserve”>system\service\idm\testwo-0workorder</token-text>
<token-text xml:space=”preserve”>\</token-text>
<token-src-name/>
</arg-dn>
</do-set-op-dest-dn>
<do-break/>
</actions>
</rule>
<rule disabled=”true” notrace=”true”>
<description>Work Order To Do Placement</description>
<conditions>
<and>
<if-class-name op=”equal”>DirXML-WorkToDo</if-class-name>
<if-src-dn op=”in-subtree”>\testWO-0\</if-src-dn>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text xml:space=”preserve”>system\service\idm\testwo-0worktodo</token-text>
<token-text xml:space=”preserve”>\</token-text>
<token-src-name/>
</arg-dn>
</do-set-op-dest-dn>
<do-break/>
</actions>
</rule>
<rule>
<description>Work Order To Do Placement</description>
<conditions>
<and>
<if-class-name op=”equal”>DirXML-WorkToDo</if-class-name>
<if-src-dn op=”in-subtree”>\testWO-0\</if-src-dn>
</and>
</conditions>
<actions>
<do-set-op-dest-dn disabled=”true” notrace=”true”>
<arg-dn>
<token-text xml:space=”preserve”>system\service\idm\testwo-0worktodo</token-text>
<token-text xml:space=”preserve”>\</token-text>
<token-src-name/>
</arg-dn>
</do-set-op-dest-dn>
<do-delete-dest-object direct=”true”>
<arg-dn>
<token-op-attr name=”DirXML-nwoContent”/>
</arg-dn>
</do-delete-dest-object>
<do-veto/>
</actions>
</rule>
</policy>

So what is happening is that I have commented out some conditions for WorkOrder object placement. This doesn’t have much effect since I left the one condition to be sure it was a WorkOrder object in there and I only have WorkOrders coming from one location. The second rule is a disabled original rule for WorkToDo objects with tracing turned off. I prefer disabling rules I don’t use rather than removing them because I make a fair number of mistakes and it’s faster re-enabling than it is re-creating.

The final rule is the one that finishes off dead users. If the source DN (src-dn) is correct and if the class is correct then normally the dest-dn is set properly so the WorkToDo object can go out to eDirectory. That action is disabled, though, and instead a new action exists which tells IDM to (directly) delete the object whose DN is stored in the DirXML-nwoContent attribute of the WorkToDo object. As you may recall we set that to the original user’s DN way back in the first Command Transformation policy on the Subscriber channel. The last action is to veto the current event because I didn’t want to fill my tree with WorkToDo objects. This could be allowed to proceed as long as there was a valid dest-dn (the other action I disabled).

As the polling picked up the WorkOrder and turned it into a WorkToDo object the Status changed to Configured (as I recall) and there were more notes written to the initial WorkOrder object about the status of everything taking place. The ProcessLog attribute has this log built into it and the driver writes to it automatically. This is a neat little audit of this particular WorkOrder’s events. The WorkOrder should be around for another five hours fifty-nine minutes (give or take a minute) so you should be able to see things in there. You could also probably write rules to add notes in there directly due to your own custom logic. Hands-free auditing of each event could be very helpful.

Now there is a significant amount of potential for this driver in the DirXML-nwoContent and other attributes. Many of them haven’t been covered at all in these blog posts because they aren’t essential but do not limit yourself for just that reason. Knowing the basics will get you going but there is more to be done. For example making a driver do multiple things should be as simple as including something in the WorkOrder and/or WorkToDo object that has an action. We didn’t tell this driver to do the delete. It was just programmed to only delete disabled user objects. It should be trivial to put an action of some kind in Description (‘add’, ‘enable’, ‘reset password’, ‘changeGivenNameTo’, etc.) upon which you could base a lot of logic. The placement policyset could have a dozen different rules for different types of events that came through so this WorkOrder driver could handle dozens or hundreds of different types of regular activities. Entire XDS operation documents could be included and executed from a WorkOrder object.

So that leads me a little bit to scalability. What happens when you want to use this in an educational environment where users are added and removed each year, or group memberships based on a class schedule arechanged every semester/quarter. How long does it take for 1,000 WorkOrders to be processed? A commenter to my previous post asked that and I did a humble test with the driver we just went through. The test was to create 10,000 users in the container and then to disable the logins. Those disabled logins caused 10,000 WorkOrder objects to be created and, after the creates of those events was complete, the polling interval fired off (twenty minutes later) and took care of deleting the original user objects. Less-than six hours later all of the WorkOrder objects were also automatically deleted.

A note regarding my environment is due. I am running three servers. One Optiplex GX1 500 MHz server with 512 MB RAM is running Linux OES SP2 with eDirectory 8.8.1 and IDM 3.0.1 (not running this driver though, obviously). Another Dell desktop (one of those thin skinny things that goes under the monitor) with a 667 MHz processor and 512 MB RAM is running SLES 10, eDirectory 8.8.1, Security Services 2.0.4 (SS204) and IDM 3.5 with the WorkOrder driver that did all this work. The import and disabling of logins were both done via LDAP with the ‘user.pl’ script (a CoolSolution on Novell’s website). A third Dell workstation was also in the mix with eDirectory 8.8.1 and two instances of eDirectory, both in this same tree. So even with old hardware and four replicas (of the entire tree) spread out this test ran and impressed me a little bit.

The test of creating 20K objects (10K users, 10K WorkOrders), polling for objects, modifying the WorkOrders, and deleting the users took about one hour and forty minutes. This included replication to all other instances of eDirectory in the tree (the other three) across my awesome 10 Mbit hub. Granted the poor little desktop was really working hard during that time period and I probably should have disabled the trace file to help, but it all finished rather nicely. I had a hiccup at the beginning because I had my DeleteDueDate set to five minutes. The problem with this is that the WorkOrder objects weren’t finished being created within those five minutes so once they were finished the Polling took place and found all those expired WorkOrders and deleted them without taking care of the processing that would have deleted the original User objects. This is why you do testing, why you use better hardware, and why you don’t decide to delete disabled users immediately. It was a good learning experience in logic errors and timing issues if nothing else.

Now with all this under your belt and with a decent understanding of all things WorkOrder it is probably a good time to go read the documentation. Please provide suggestions in there to improve it. This driver is not terribly (in my opinion) intuitive to veteran IDM engineers and having some content in there that would help bridge the understanding would be great for all.

Any questions?

The driver mentioned in the post follows. It is a GZipped XML driver export. With the .gz extension most compression utilities should have no problem opening it. Linux has utilities to do so built in. For those on windows please use something like 7-Zip or WinZip or some other freeware with this built in.

GZipped Driver Export

+read more

1 – WorkOrder Introduction

aburgemeister

May 22, 2007 3:22 pm

Reads:4,557

Comments:5

Recently I came across a new driver that has been added in Novell Identity Manager (IDM) 3.5. The name of the driver is the ‘WorkOrder’ driver. Not to be confused in any way with ‘Workflow’ or the User Application (UserApp) and what those do, the WorkOrder driver is a completely new type of driver that will probably throw those familiar with IDM and its existing drivers for a loop. During my first implementation I relied a bit too much on my past knowledge and it bit me fairly hard. With that in mind I want to make this useful driver as easy-to-understand as possible for others out there.

So what is the WorkOrder driver? First let’s go over what it is not for those who are already familiar with IDM. It is not a driver that connects to another application or system by default. Therefore, similar to the Loopback driver, it is not a driver that synchronizes identities from one environment to another. This will become overly-obvious when you notice the filter does not have any User or Group classes in it by default. Without users Passwords become fairly dull so this driver doesn’t do any Password Synchronization. Similarly a lack of users means a lack of roles, so Role-Base Entitlements (RBE) are out as well. This isn’t a lack of functionality for the driver but, as a special driver, it’s just outside the scope of what the driver needs to do. This driver also primarily does its heavy lifting on the Publisher channel similar to the eDirectory driver. The driver’s object placement is not what you think if you have any experience with IDM and you will get errors if you try to treat it like a normal driver with regard to object placement.

So now hopefully the experienced IDM people are making few if any assumptions about the driver, and people newer to IDM are where they would be anyway. With this lack of presumptions let’s continue. The WorkOrder driver is made to handle odd little objects new to IDM 3.5 with a class of DirXML-WorkOrder. These classes have a few predefined attributes that meet the objects’ needs and that are needing some good explanation. We’ll explain this more later on but here’s some information to start with:

DirXML-WorkOrder

DirXML-DueDate: The date and time the workorder is to be executed

DirXML-nwoProcessLog: A log of things that happen related to this WorkOrder. Having this log means you get automatically (really, no configuration) logging with regard to this WorkOrder’s history from the WorkOrder driver.

DirXML-nwoStatus: The status of the current WorkOrder object. Pending, configured, resolved, canceled, error.

DirXML-nwoDeleteDueDate: When to delete the WorkOrder. This also works with the next attribute for situations when an error occurs.
DirXML-nwoDeleteOnError: If an error occurs (status = ‘error’) specify if the WorkOrder should be deleted when the DueDate comes. A WorkOrder with the ‘error’ status is done as far as automatic operations are concerned so manual intervention is now required. Without being deleted these will sit forever.

DirXML-nwoSendToPublisher: Specify if this WorkOrder should be sent to the Publisher channel immediately. Can be true or false and, if false, the WorkOrder waits until the next polling cycle or heartbeat for it to be processed on the Publisher side. If true it goes immediately.

DirXML-nwoDoItNowFlag: Interesting name for an attribute but it tells the Publisher channel that this WorkOrder must be processed now. As a result the documentation indicates that ALL WorkOrders that are ready to be processed (by DueDate) will be processed immediately.

DirXML-nwoDependentWorkOrder: DN of a WorkOrder object on which this WorkOrder depends. This WorkOrder won’t go until its dependency has a status of Configured.

DirXML-nwoContent: An attribute used to store custom information specific to this WorkOrder. It is passed through to the WorkToDo object.

There are quite a few other attributes but most of them are fairly self-explanatory (creator’s name, creation timestamp, a few other fields for miscellaneous data, etc.).

DirXML-WorkToDo

DirXML-nwoDN: The DN of the WorkOrder from which this WorkToDo object originated.

DirXML-nwoContent: Look familiar? This holds the data that was in the same attribute on the WorkOrder object that led to this WorkToDo object.

There are quite a few other attributes for this class as well and most of them are copied directly from the WorkOrder object. We’ll see why before this is all through.

So let’s move on to the default driver filter to see what happens there. As mentioned a large change for this Filter is what it works with (no Users, Groups, etc.).

filter0.png
Filter Screenshot1
What is interesting here is that WorkOrder objects are used in both channels, while WorkToDo objects are only sent out from the Publisher channel. We’ll see where they come from before this is all through.

So let’s try to get our minds wrapped around the driver’s functionality. The WorkOrder driver is made to create and process an object of type WorkOrder, possibly ending up with a WorkToDo object. Let’s use an example that fits with this driver. Imagine you have a driver from your Human Relations (HR) system, PeopleSoft. This driver creates users in your Identity Vault (IDV) as employees are hired on. What happens in the two weeks or months between when the user is added into PeopleSoft and they start working? Jack the evil cracker in marketing is trying to break into the new employee’s account. It’s out there, might have a default password, and is ripe for exploitation. To prevent this type of malicious user from having weeks to months with access to things they shouldn’t the account is logically disabled but now a new administrative chore surfaces. Who enables the account on the first day of employment? Does the new employee wait around while the administrator who would have enabled the system is out sick or do you give managers rights to enable and disable accounts and hope they remember how to do it, have the tools to do it and the ethics to be honest?

Enter the WorkOrder driver to save the day. When the user is provisioned from PeopleSoft a WorkOrder is created by that driver and placed where the WorkOrder driver will find it. This object is made to be processed by the WorkOrder driver and has some data relevant to the WorkOrder’s task in the object. DirXML-nwoContent has the DN of the user who was just hired. DirXML-DueDate has the date and time when the user should be officially enabled. The driver detects this object and processes it much like a normal driver would process a user creation.

The WorkOrder object is placed in a container where it is held until the DueDate comes along. In this first example we know this is the first day of work for the new employee. The WorkOrder driver differs slightly from others at this point in that it implements a Polling Interval, Heartbeat, or both to regularly check on the objects in the pending area. The polling interval can be a time period or a time of day (or both). An appropriate value for this example may be 0030 (12:30 a.m.) so that new users are enabled in time for their first day. The DueDate is set for the first day of work, sometime before 0030, and when the polling takes place the WorkOrder object is finally processed by the Publisher Channel.

The WorkOrder shim is sent a WorkOrder object (mapped in Schema Mapping policyset from DirXML-WorkOrder). A difference between this driver and others appears here. There is no application for the shim to send the object to so, if DirXML-nwoSendToPublisher is set to true this new WorkOrder object is sent right back into the Publisher channel where it is eventually written back into eDirectory. The object has an association to this driver in the Engine and subsequent polling intervals will affect it.

The WorkOrder driver shim picks up the new DirXML-WorkOrder object (through queries), verifies it should be worked on at this time, and starts it through the Publisher channel. On its way through the object is treated as a ‘WorkOrderToDo’ object (not DirXML-WorkOrder’) which is then mapped to DirXML-WorkToDo. When was the DirXML-WorkOrder object made into a WorkOrderToDo object? Once the shim determined that the DueDate had arrived and passed it built this new WorkOrderToDo object with the values from the original WorkOrder. From here on out the WorkOrder is simply used to log processes as they take place.

A normal DirXML-WorkToDo object is short-lived. It basically goes into the Publisher channel as an add-event, is optionally evaluated for things to do by the custom policies, and is written to a container in eDirectory made for WorkToDo objects. This object-creation could kick off a Loopback driver designed to do the actual enabling of the user along with a number of other tasks but in an example like this we could just as easily do this in the WorkOrder driver. For instance there is a Placement policyset created by default that really isn’t needed for our example. The desired behavior is to have the new employee’s account enabled. To do that a simple rule can be placed in a policy to set the destination-attribute of ‘Login Disabled’ for the user specified in DirXML-nwoContent to FALSE (was set to TRUE before as you might recall), effectively enabling the account. The actual creation of the DirXML-WorkToDo object can be vetoed as it’s not needed for this example and we are finished. A quick recap may be in order:

Create disabled User object with PeopleSoft in Identity Vault

Also create WorkOrder object at the same time setting its DueDate to the employees start date and the nwoContent to the new employee’s DN

Driver processes WorkOrder placing it in a directory made for WorkOrders. Polling available WorkOrders does a check to see if they are due.

When WorkOrder is due it is read and sent to the Publisher channel as a WorkToDo object.

Custom processing can be done here if desired to actually enable the user in the nwoContent attribute or it can be left to another driver.

Optionally write WorkToDo object to eDirectory for other processes to use.

Here we have seen one example of what the WorkOrder driver can do. Another practical example I am going to demonstrate in my next blog post will be a driver that ends a user’s lifecycle. Many companies may not have PeopleSoft or SAP or some other large HR system, but most companies terminate employment of users at some point and a few I have come across want to delete the users but not until a period of time has elapsed. This can be in case the employee comes back, for legal reasons, for auditing, or many other reasons. No matter what the reason there is a need for somebody with a fair amount of authority to spend time cleaning up users after a period of time. Again, do we have the senior administrators do this instead of hunting for bad guys or fixing the payroll system? No, this is something to automate and is a good example of a WorkOrder driver’s task.

This new driver will probably not depend on something else for the initial workflow creation. A simple way to work past this is to let the driver itself detect when a user is disabled or moved to a container for terminated employees. After detecting a disabled user a small amount of IDM policy (written via a GUI because that’s my kind of option today) creates the DirXML-WorkOrder object which then is sent through the remainder of the Subscriber channel. The biggest difference between this example and the previous example is what happens on the Publisher side. When the user is disabled and the WorkOrder is created its due date attribute is set for 90 days into the future. When those 90 days have elapsed and it’s time for the user to be deleted the polling picks up the WorkOrder and determines this is for a delete. A rule is added which sees a WorkToDo object coming back through the Publisher channel and has enough brains to know what the WorkToDo object is all about. Knowing it’s been 90 days since the employee was terminated the driver deletes the object from eDirectory and could optionally do other operations to clean the employee from other systems. Because this was the completion of an employee’s lifecycle in eDirectory the administrator determines there’s no need to leave the WorkToDo object around and veto’s the placement to prevent these objects from building up. It could have been allowed through but with no reason to store it we’d might as well save space.

So far we have seen what the WorkOrder driver can do and hopefully a few ideas for your own environment come to mind. For instance this is a fairly simple and customizable cron job built into eDirectory. IDM 3.5 also has “Jobs” but those are meant for other things. This driver can save a lot of time with tasks every administrator currently has assigned and always forgets because they are out of the office or the time delay causes forgetfulness. Policies for keeping the environment clean can be written once and run forever with minimal monitoring. Imagine the audit where your boss or a SOX auditor comes and asks for a forensics trail regarding users’ data removed from a given system. Picture yourself confidently referring to one little WorkOrder driver doing all your mundane tasks as needed all because of a process started by somebody over in HR who didn’t know a thing. Sounds like a good way to make life easy, and so I must get you ready for the price for all this functionality. All good things come with a price but thankfully this one is not that bad if you use a simple equation.

Calculate dozens of uses for this driver. Keep track of the time required to do this.

Multiple the amount of time it took to do that, plus some time to implement it, by your hourly wage.

Subtract the amount of time you would have wasted doing this work yourself.

Subtract the amount of stress received from your higher-ups over completion of various mundane tasks.

Add in a negative number for your personal bonus for meeting all your mundane-task objectives so well.

Add in a negative number arbitrarily chosen by yourself representing your job security’s worth to you.

If you are anywhere above $0 I’ll be surprised. As an IDM customer you already have full access to this driver. As one of the many IDM service drivers this one has no additional fees required. Labor is required of course but I think the benefits will make it worth your while.

Anyway, that’s all for today. Another post with at least the latter example above will be coming before too long.

If you have any interesting comments on this driver or uses you have found please post them. Any great implementations you want to share can be submitted as CoolSolutions to help others enjoy life more and to earn you points (so you can enjoy life more, up to and including a cruise for two to Hawaii).

Good luck.

+read more

0 – CoolBlogs Introduction

aburgemeister

May 14, 2007 9:34 am

Reads:3,043

Comments:2

Starting a blog is a lot like starting a journal except that it’s intended for the world to read so sounding dumb is bad. So there you go for an introduction. My name is Aaron and I currently support IDM, Audit and Sentinel (formally) but try to stay as involved and up-to-speed as possible with a few other products (eDirectory and company, Linux, NetWare, etc.). I’ve been asked to make some posts regarding IDM and, in planning for this, will probably try to write a few entries on basics, new things, and whatever else comes to mind.

Specifically I enjoy reading traces and a lot of people using IDM don’t find that an enjoyable task until they understand what is going on there so I hope to have a few entries on that specifically. Traces make troubleshooting IDM the easiest thing you can possibly do and unlocking that can make the vast majority of your support calls almost guaranteed to be bugs (or issues worth the money at least).

I also spend a fair chunk of time in the external product forums and recommend them if you haven’t tried them. The IDM and eDirectory forums are all very active. Some of the ideas for posts will undoubtedly come from issues in there as most questions in IT are repeats and having responses in this format may help many who don’t use NNTP enough yet.

As a note regarding my writing style be warned that I am fairly verbose. In most comments/posts/documents I try to be clear in what I write so there is not a lot of room for confusion regarding what is meant. I also use a few semi-standard writing conventions to delimit different contexts for text (backticks for commands, single-quotes for most literal strings, double-quotes for quotations, greater-than/less-than signs for environment-specific strings, brackets for optional strings, etc.). Knowing what these are will hopefully make life simpler for us both.

I’ll try to remember to attach large blocks of text instead of posting them inline. I’m a believer in Open Source Software (OSS) and contributing back to the community (part of my motivation to do this as well as interact in support forums) so there should be a lot of code samples for whatever is included where applicable.

Please let me know how I’m doing as time progresses.

Good luck.

+read more

LDAP Count Script

aburgemeister

February 12, 2007 1:29 pm

Reads:7,031

Comments:0

Aaron Burgemeister ABurgemeister@novell.com
This script is useful for benchmarking, performance testing, and debugging.

+read more

eLUM-enabling eDirectory Users

aburgemeister

January 10, 2007 8:44 am

Reads:3,424

Comments:0

Novell’s Aaron Burgemeister provides detailed instructions for getting your eDirectory users LUM-enabled on Linux systems.

+read more

Conversion Test Script

aburgemeister

November 6, 2006 12:27 pm

Reads:3,772

Comments:0

Learn ascii/hex/octal/decimal conversions for the most-common characters used in ASCII.

+read more

Conversion Test Script

aburgemeister

November 6, 2006 11:27 am

Reads:3,735

Comments:0

Learn ascii/hex/octal/decimal conversions for the most-common characters used in ASCII.

+read more

RSS

© 2014 Novell