Last week I was told by my boss to look into Identity Management 3.5.1 to see if it could fit our needs. There is more to it then that statement suggests, as we already have a home-built identity management system in place. I was asked to see if IDM 3.5 could possibly save us steps in developing the next version of our home built systems.
First, some background.
The home-built system began life as a series of programs written by an overworked NetWare admin in the 1998-2000 range. He needed ways to make his job easier, so he wrote scripts and programs in Visual Basic to automate things like account create. As we're a .edu, we have a lot of students coming in so this saved a lot of effort. Time moved on, and features were added. Soon, Exchange provisioning was added. Then Exchange 2000 came around and the system had to be extended to handle Active Directory in addition to NDS. The system was then tied in with the provisioning system we already had on the Solaris side of the house that dated back to the mid 90's.
Because we're a .edu we use SCT Banner for our HR functions and a lot of other things. Banner is our 'authoritative' source for who is permitted to have accounts. Unlike some other systems, Banner is actually updated very regularly for things like name changes and departmental moves. Our address book data is extracted from Banner.
Fast-forward to today.
Now, we're handling Exchange 2003 provisioning (soon 2007), and students now have AD accounts. We have a web page that allows us to delegate administrative functions to helpdesk users, such as group changes, home directory quota updates (one of the best features of NSS in my opinion, we make extensive use of Dir quotas), Exchange quota management, e-mail address management, and account enable/disable. It works, we love it.
Unfortunately, the back end is a decided kludge. The NetWare/eDir/AD/Exchange management piece is currently written in a mash of VB6 and C# and needs rewriting. The Solaris piece is written in C++, relies on NIS+, and most of the code was written in the mid 90's. Getting data out of Banner is mostly handled through extracts to .CSV files that are then parsed by the separate management pieces. Commands from the web page are transmitted to the management pieces through e-mail, a channel that is not reliable enough these days.
This is why we're looking at a serious re-write of our code. The NetWare/eDir/AD/Exchange stuff is going to be rewritten in a newer version of .NET. The Solaris stuff may or may not go away in favor of LDAP + the Solaris version of Novell Account Management. The command transmission channel may or may not be a relational DB table.
I was asked to see if IDM 3.5.1, which we get bundled with our NetWare and Zen licenses, has the right drivers bundled with it to be useful to us. I've spent the last week digging deeply into that. We get the Active Directory and eDirectory drivers, but not the Delimited or Scripting drivers. This could be a problem in the case of a full deployment.
As it happens, IDM 3.5.1 can replace some of the functions currently provided by the existing NetWare/eDir/AD/Exchange management piece; specifically the functions that manipulate the directories directly such as password changes and e-mail address management. IDM can't do some of the provisioning tasks we've taken for granted, such as creating user-directories on the right volume (we load-balance between 3 possible user-dir home volumes), and creating their Mailbox on the right Exchange store (also load-balanced between several Stores).
That said, what IDM can provide for us is a unified identity directory vault. IDM also provides a way to allow events in the vault to trigger actions in the home built systems, specifically through the use of e-mail Actions on events. Having a vault that gets updated by Banner then go and update the subscriber systems (production eDir, AD, and NIS+) we provide a more unified look to identity on campus. Events in the vault can trigger most of the actions currently triggered through Banner extracts or directly from the management web-page, and can be put into place with a minimum of customized code.
We have a big advantage over new deployments of IDM because we already have an identity management system in place. We've already handled the duplicate (and inconsistent) identity problems, and have already figured out who 'owns' which pieces of identity information. This is a possible upgrade path that won't involve much in the way of Banner developer time, and that counts for a lot.
Unfortunately, there are some drivers we'd like to have but simply can't afford. IDM 3.5.1 has a SPML/SOAP Driver, and last year at BrainShare I heard of an outright Banner driver (BrainShare 2007, TUT381). The Scripting or Delimited Text drivers would be very handy in interfacing with our provisioning systems. The Oracle or MS-SQL drivers would be another handy way to handle signaling to the provisioning systems, and are the best-bet for integrating Blackboard into the IDM family. Unfortunately, our funds for obtaining new software are non-existent.
So whether or not we use IDM 3.5.1 as a key piece of our next identity management system has yet to be decided. The management powers that be, and the owners of the existing management systems, need to figure out if there is less salary time expended in rewriting our current systems from scratch, or in making IDM work at the core of the system and in essence write our own custom Drivers for ID. That is a discussion for the coming weeks.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.