In part 1 of this series I started explaining the driver configuration for the Ellucian Banner driver.
In this article I will start looking at the Global Configuration Variable values.
Many driver do a lot of configuration via the Global Configuration Variables. An interesting side point is that when writing a shim, it is very easy to get driver configuration values in the shim. But GCVs are not really exposed there. You could do it yourself, but it is a fair bit of work. A GCV can be set on the DriverSet, the Driver, and on each of those, can be set by a DirXML-GlobalConfigDef object linked in via value of DirXML-Policies.
On the flip side, in Policy (DirXML-Script), it is very easy to get GCV values but a bit of work to get driver configuration values. You can read in the DirXML-ShimConfigInfo (DirXML-ConfigValues is actually the driver level GCV storage attribute) parse it to an XML nodeset and then XPATH out the definition with the proper name. The GCV tokens in policy are much easier, since the engine does all the hard work for you already.
For this reason, there is a type of variable, called gcv-ref that references the value in a GCV.
I initially thought this existed for the opposite reason, that is, to make it easier to get Driver Config values in Policy, but discussing this with a shim developer recently, it turns out it is there almost as much to make it easier to get GCV data access in the shim. That surprised me, I had not considered that possibility before. This is why I enjoy IDM so much, always something new to learn.
Like all Packaged drivers, (as of IDM 4.0) the GCVs no longer reside just as an attribute of the driver object (DirXML-ConfigValues), but also as linked in GCV objects (DirXML-GlobalConfigDef class) via a linkage stored in the DirXML-Policies attribute.
This driver has no driver level GCV's (Good form!) and has the following linked in GCV Objects:
Managed System
Password Settings
Account Tracking
User Settings
Managed System, Account Tracking, and Password Settings are mostly the standard defaults you see in every driver, but there are some minor twists.
Normally these three packages (Account Tracking, Passwords, and Managed System Info) have a common design approach. They have custom packages per driver for all three. In the case of the Password management package and Managed System Info there is actually a shared driver that delivers just the policy objects and does not link them in, and the driver specific Password Management package delivers the linkage and the GCV object.
This way the GCV's can contain the standard ones, but extend them as well, while still using common NetIQ provided packages or approaches. This allows updates of the policies, but driver specific configurations.
However, this drivers Managed System Info package does not consume the NetIQ provided common package, which is interesting to note. These packages are used for the Data Collection Service of the Reporting module. These packages are designed to respond to specific queries that Reporting might inject into the driver (via the MSG or DCS drivers, injecting XDS direct into the current driver shim) and also, to reformat a particular class of query response (Mostly to avoid losing data in DN syntax attributes). You can read my series on the DCS (Data Collection Service) and MSG (Managed System Gateway) drivers at these links.
They do a lot of interesting things, and it is worth understanding what they are doing, since you will see their strange events in your driver if you pay attention.
The main consequence of not using the NetIQ provided common package for Managed System Gateway is that when NetIQ decides to change the Reporting modules approach in some fashion, they will probably require a package update to all drivers with the Data Collection Common package. This driver will require an update to this specific package, in addition to the standard common package. This is not a bad thing per se, rather it is worth noting. There are lots of valid reasons, and as we review the policies I will try and see if I can figure out why they made this decision. My initial guess is they wanted to do some of the policies differently for their driver. As we will see in a minute the Password Management and Account Tracking packages for this driver delivered additional GCV values for additional policies they use. Likely something similar happened in this case (It is just not yet obvious to me what it is!)
Managed System GCVs:
Let's start with the Managed System GCVs then first.
Normally I would not bother reviewing these, I would just point you back at my series on the MSG and DCS drivers, since these are basically all common to all drivers, and no need to repeat. Here, since they are clearly slightly different let me focus on differences I might see.
I see that they pre-fill the Vendor type with two options, ELLUCIAN or SUNGUARD, but that is normal in the driver specific package.
The one thing I can think of that might cause the break from the common package is the fact that the bottom set of GCVs are 'funny'. If you are not aware, there are a couple of items now that on first driver startup, the driver re-writes values into. The MSysInfo GCV object is one, and the other is the entitlementConfiguration object.
MSysInfo goes out and gets the connection information, ID, Type, Authentication ID, and whatnot of each driver, and records it. I always found this an annoying approach, I think I would rather retype this info once per driver, every time I create one, than have the driver do all this extra work every startup.
The reason they cannot use gcv-ref GCV types to point this value at the Driver Configuration values. is that the Authentication Address, ID, and Password are stored in specific attributes of the driver (DirXML-ShimAuthServer, DirXML-ShimAuthID, and DirXML-ShimAuthPassword).
Additionally, the Type needs to be hard coded to the specific driver. I remember when IDM 4.0 first released, I went through all the shipping drivers, and looked at the Managed System Info policies and found 4 or 5 typos, where they forgot to change the specific type in the policy to be proper for the specific driver. I.e. Several were left as AD, like one of the SAP driver modules. very definitely not Active Directory! They fixed those, and with packages it was an easy minor fix to push out. But this driver of course will need its own, though that component is usually delivered in the driver specific managed system package.
But in this case, the location of the Subscriber channel target, username, and password is not contained in the normal attributes of the driver location. Rather they are configuration settings in the Driver Config. A better question is WHY are they not set in the standard locations, but regardless, they are not.
Therefore the standard policies that parse out that data in the Input Transform probably will not work and needed to be modified anyway, at which point the standard NetIQ Data Collection Common package no longer provides value.
Password Settings GCVs:
This object has the standard Password GCVs that get 'rendered' into the view we know and love in iManager (Server Variables) and Designer (Password Management). But they add three new ones.
The issue is that Banner, on the UCIdentity object, does not really store a password. Therefore there is no password to sync from or to. But when Banner is your SIS system, generating accounts for all your students, what should the initial password be? Well some drivers use some silly standard value like D@rmx! or whatever.
This driver offers you four choices for the question "What to use for initial password".
Random Password
Attribute value from user
Universal Password Policy
No Initial Password
Lets see what each implies, so you can decide what make sense in your use case.
Random Password:
When you chose this option, you get two more sub choices. (I love how Groups work, I wish there was an editor to make generating these prompts easier, I always screw it up when I try by hand in the XML). How many alphabet characters to use in the Random Password (Min 2), and Plus how many number characters to use in the Random Password (Min 2).
I suspect this is a holdover from old code, since the Generate Password token in IDM is a much better choice, and in fact is used in the Universal Password Policy option anyway.
This is a very Novell Consulting approach, and in fact there are a bunch of sample functions like this in the Lib AJC (Advanced Java Class) ECMA library.
Attribute value from user:
This one is quite interesting, since it takes some existing data in Banner, and uses it to set the password. The default is surname which is probably a bad example, but you could imagine that student ID would make a lot of sense here. Of course, some combination of Student ID, last name, and maybe last 4 of Social Security number would be better.
The good news in, the policies will have an example of all 4 of these approaches, so changing it meet what you need, should be easy.
Universal Password Policy:
This asks you for the DN of the Password Policy object (Stored in the Password Policies. Security container under Root in every tree) to use as the rule set for the Generate Password token. Of course, the user does not yet exist, so the user does not yet have an effective Password Policy to read back and use.
But even more so, with later IDM and eDirectory (NMAS really) patches they changed something, and made Generate Password act more literally. What this means is, you probably need to create a standalone, unassigned password policy, just for the Generate Password token, if you intend to use it in IDM. This standalone policy MUST not require Unique Passwords. By definition, for an object that does not exist, there is no history, and therefore, no way to validate the generated password against the history and therefore throws an error, at the NMAS level, not a the engine level, so the engine cannot recover.
Seems like a silly thing, but it is what it is. Live with it.
No Initial Password:
This one is pretty obvious, create a user with no password at all. I would probably recommend against this, unless you have a loopback business logic driver somewhere watching creates and setting the password some other way.
Account Tracking GCVs:
There are a couple of extra settings here in this Account Tracking GCV. There is the usual stuff, Realm, Object Class, and Identifiers. But in Banner, it appears that you do not deactivate a user in the normal sense by setting an attribute value, or having a specific flag attribute, rather you remove all their Institutional Roles and thus they are inactive. (Since they have no roles to accomplish anything).
I suppose that vaguely makes sense as a model, since student systems can have a student come for a semester, disappear for a decade then return for a semester. Or become an alumnus then register for a course. So the inactive state is slightly more fluid and amorphous than in the normal employee case.
The last GCV of interest is the Publication Default Status. I find this one interesting, since it handles a case you would not necessarily expect, when a user comes in with NO initial Roles. What is that default state? Here you can control if that counts as Active or Inactive.
It seems odd that you might dump in new users who are inactive. Well I suppose you might consider a backfill of historic users in a data load for this case.
Anyway that about wraps up this article. Stay tuned for more in Part3!
Support
Documentation
Learning Services
Partner Programs