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

Problem: Creating and maintaining hundreds of student accounts

The school where I work runs Active Directory on Server 2008. Every year, our students have to sign up for accounts with a third-party SaaS school management system. That has created a lot of work in the past, as codes have to be generated for students, and students often lose the codes or can't figure out how to enter them. Later, the students who did manage to sign up may forget their usernames or passwords and come to me (the solo sysadmin) for password resets and so forth.

Solution 1: Ask users for their passwords

This fall, we moved to a new SMS, which apparently doesn't support any kind of batch student signup. The administration was planning to meet with every student, ask him or her for a username and password, and create an account for him or her manually. I thought, Wouldn't it be nice if we could integrate the two systems and avoid that? When I contacted the third-party company, though, they said they didn't integrate with Active Directory.

I decided to make my own system: a database coupled with a program that runs as a logon script for student accounts. It works like this:

  1. When students log into Windows for the first time, they are asked for their passwords
  2. The passwords are checked against the passwords stored in Active Directory
  3. If they match, the passwords are stored in the database (the passwords cannot simply be dumped from Active Directory into the database because Active Directory passwords are write-only)
  4. A server-side component of the program creates accounts for the students with the third-party company, using the Active Directory passwords stored in the program's database

New problem

Now, the problem with that is that if users' passwords are reset in Active Directory, they are not updated in the database. If users change their passwords from workstations, the passwords are not updated in the database. There is also the issue of the security of the database itself.

Solution 2: Reversible encryption

I notice that Active Directory can store passwords with reversible encryption. I know it is not officially well-documented, and am well aware that even writing the phrase "password retrieval" carries with it the possibility of bringing about The End of the World. But looking at the risk, I don't believe our servers are in much danger of being compromised, and even if they were, there is not much an attacker could do with the students' accounts.

Advice?

How would you recommend I solve this problem? Is there a way I can drop my middleman database and simply use information from Active Directory directly? Should I abandon trying to integrate the systems?

Any thoughts are welcome, including remarks on how harebrained my idea for single sign-on was in the first place.

share|improve this question
    
Your idea for single sign on was great. But whoever purchased the school management system needs to be smacked with a wet Ethernet cord, for not buying something with the features you need. –  Michael Hampton Nov 27 '12 at 15:59
    
@MichaelHampton: I got wind of the purchase around the time I was needed to help migrate the data from our last SMS. You have to wonder about how these things are done sometimes. –  Eric Eskildsen Nov 27 '12 at 16:07
    
I'm sure somewhere along the lines, some standards/requirement would be breached if you have reversible encryption enabled? no? I think the few limited options is to have a self-service panel that allows student to enter ID and perhaps their DOB to reset password? –  Cold T Nov 27 '12 at 16:10
3  
You have a process problem. Your IT purchasing process doesn't include you, and that's a big problem. –  Michael Hampton Nov 27 '12 at 16:18
1  
Reversible encryption is not a good idea. Example appropriate use cases are prisons and nation-states that need to spy on their users. To quote Microsoft: "Storing passwords using reversible encryption is essentially the same as storing plaintext versions of the passwords. For this reason, this policy should never be enabled unless application requirements outweigh the need to protect password information." –  Greg Askew Nov 27 '12 at 16:31

1 Answer 1

AD is not designed as a password synchronization tool; it is a directory. Scraping passwords from it and decrypting them (they are encrypted the same way the SAM hive is encrypted if memory serves) is not a viable production solution or a supported scenario.

There are lots of identity management solutions out there which can hook off password changes made in AD using an API similar to that of your login script and propagating them. Collecting this data yourself isn't a scriptable thing though; you would need to write a password policy DLL.

The correct, hack-free way to do this is to use AD federation, and have the other application authenticate users against AD instead of its own internal database. It doesn't sound like it supports this, but it might be something to look into.

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.