Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Our current solution

At the moment, it is essentially a bunch of scripts which are executed by an in-house developed console menu that is Perl-based. Each script is associated to a step in the creation process. The menu looks something like this:


Student account creation

  1. Connect to database and dump new students into a CSV file

  2. Create LDAP accounts for students in latest dump

  3. Create ActiveDirectory account for students in latest dump

  4. Record new account in database

  5. Archive the CSV file

Enter choice: __


The menu has a configuration file which includes which passwords and scripts are needed by each step and the menu structure. The passwords are kept encrypted in memory.

Although this process works right now, we are trying to solve several problems with this approach:

  1. We need a sensible locking mechanism in place.

  2. We are moving away from using Perl and now using Python for SysOps development.

We are now in the research phase of this project.

My question

How do other organizations handle this? I'm especially interested in how other Universities manage account provisioning. During the middle of a school term, we normally have a dozen new accounts a week. However, three times a year for a couple of weeks, we have over 1,000 accounts that need provisioning.

One thing that is important to us is password management. These accounts are provisioned in about 5-8 systems during creation. All these systems have passwords that are unique and difficult---if not impossible---to memorize. Our current menu system allows us to leave the session open and the passwords are encrypted in memory. It would be nice to have a similar mechanism in the new system. Anyone have any ideas?

share|improve this question

2 Answers 2

up vote 5 down vote accepted

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
  • NIS-plus

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:

  1. Student is marked eligible-for-accounts.
  2. Once a day a CSV export is created and dropped onto the right server.
  3. 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)
  4. The file is then processed by the AD/eDir identity engine.
    1. 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.
    2. 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.
    3. 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.

share|improve this answer
    
+1 for your extensive answer. Now, why do you use compiled code for the agents? Why not use a light weight scripting language like Python for Unix and VBScript for Windows? And what is this "beer truck vulnerability" you speak of? –  Belmin Fernandez Nov 5 '10 at 0:54
1  
compiled code is a must when dealing with haveing to process ten thousand accounts in an hour or so. The beer truck / bus vulnerability is in reference to what would happen should a sys admin or programer meet an untimly end. –  Liam Nov 5 '10 at 2:04
    
@Nimmy The NIS+ stuff was first written about 1994 in the language the sysadmin knew best: C (also some Perl). The Windows stuff was first written in 1999 by what THAT sysadmin knew best, Visual Basic 6. Also @joe is spot on about speed and beer trucks. –  sysadmin1138 Nov 5 '10 at 4:34
    
@Nimmy Also, the Windows stuff will soon be rewritten. The event engine will likely be .NET, but it will be calling PowerShell scripts for many tasks. –  sysadmin1138 Nov 5 '10 at 4:39
    
We've been using Perl and Python for account creation and have been able to create about 1,000 accounts without a substantial lag. Can't give you a specific amount of time but I would say it was less than 10 minutes---maybe even 5 minutes. Perhaps your applications are doing something more complicated. Most of our scripts are just doing some data processing and LDAP calls. In fact, we used a Python script to migrate our users to a new appliance (60,000 accounts) and it took about 20 minutes or so. Doesn't seem that compiled code is a "must". –  Belmin Fernandez Nov 5 '10 at 11:54

As long as the systems they are logging into ask them to create a new password after the first log in, this method seems very effective. It may also be worthwhile to tie in the LDAP user creation with the creation of the user in the database, to reduce the number of steps required by IT staff.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.