Since you asked...
I'm a sysadmin at a large University. We have anywhere from 20,000 to 24,000 accounts depending on where we are in the academic quarter and whether or not the State has mandated that we accept more students. Account provisioning is a problem we've been having to solve since we first started giving Students computer accounts en-mass (back in the VAX days if I remember right). Because of that, we developed account management well before there were real commercial solutions to this.
For most of the past decade we had three major identity silos we needed to provision:
- Microsoft Active Directory
- Novell eDirectory
over the last 12 months we have just managed to turn off the last two, leaving us with just one major identity store. However, the memory of doing three is still fresh.
The account-create process looks like this:
- Student is marked eligible-for-accounts.
- Once a day a CSV export is created and dropped onto the right server.
- The CSV file is processed against the NIS+ state, applying changes.
- New students are created and home-directory provisioned with quota
- Nolonger eligible student accounts are disabled (and after 2 weeks, deleted)
- Current students have their directory details updated, as needed (such as fullname, lastname)
- The file is then processed by the AD/eDir identity engine.
- Accounts are created as needed, including home directories, default groups, print quotas set, student email provisioned (Live@Edu), and some other stuff I'm probably forgetting.
- Directory details are updated for all users (fullname, lastname, and for staff a bunch of other details as well). This overwrites any manual changes made by native tools, which is a good thing.
- Deletes are handled same as the NIS side.
Because we ran three separate environments we engineered a completely separate password management system early on. This hooks into the same identity system as the creates do. Students go to the password reset page, go through the process, which in turn kicks off events to the ID engines to update passwords. We also do password aging and complexity rules as part of this home built system.
All of the above was code built by us, and is very automated. The human inputs are the data-entry into Banner, where the student details are initially entered. The eligible-for-accounts status is handled within Banner, so even deletes are fully automated.
Staff accounts are handled identically, though there is a lot more directory data in those updates (FERPA requirements say we shouldn't do that kind of thing with Students).
The one area that still has significant human input is in status changes, such as Student to Employee and vice versa. This is entirely due to a lack of consensus about where the fuzzy line in the sand should be between student-worker and employee-taking-classes. This has JUST been agreed to after nearly a decade of grumbling, so we hope to automate even these now.
Another area that has reduced our need to push passwords into ever more systems has been a ruthless drive to SSO-ify anything web-based. We use CAS for this, and it works decently well. Because of this, we don't have to push passwords into Blackboard, as well as the usual assortment of oddball apps that any University ends up with.
We've even created a web-app for our Helpdesk staff that leverages this system to handle things like intruder-lockouts, group membership changes, and computer-object location moves in AD. This has reduced the daily-grind load on the SysAdmin staff (hi!) to such a point that we're doing a lot more future-looking project stuff than daily grind tasks sent to us from the helpdesk.
If I had to do it all from scratch, I'd probably use some of the very nice identity-management frameworks that now exist. Novell's Identity Manager is very, very good, but sadly very, very expensive. Right now we're using compiled code for nearly every step of the way, which means we have two Systems Programmers (one for the Windows side, one for the Unix side) whose sudden death would cause the University as a whole a world of hurt. Using a 3rd party app for this critical function means we'd have greatly mitigated the 'beer truck vulnerability' we currently have.
However, this solution fits our needs like a glove; so getting off of it will feel like spending a lot more for something that does less, and therefore unattractive.