Unlocking an AD account via a web page?

[ICANSEEYOU7687]

This might not be well suited for AutoIt, and was curious if this could be done.

I know you could prob make a web site that generated a txt file with the user name and password, and then have a program scanning for new txt documents or something and then use the data inside of those, but this idea is horribly unsecure and im not going to do that.

If anyone has any ideas, please let me know, I dunno if its possible to have a form on a web page, and then with those credentials launch a an autoit script with those credentials.

Any ideas would be cool!

thanks!

[willichan]

I worked at a company that did something similar (though in ASP, and I had nothing to do with it). You might try something like this:

Web page asks for login ID and some kind of verification, like badge# or SS# (most people hate that one though).

The page then calls your script with those data as parameters.

The script could then verify the ID and data, unlock and set password for that ID to some generic password (assuming they need a new one), set password change required flag, email the associated email address and supervisor email address with a notice of the change request (in case someone is trying to hijack an account).

[ICANSEEYOU7687]

Well the verification would just be their AD passowrd. We currently have our system so X amount of bad password attempts gets your account locked out for X minutes. So even if the account is locked out, if the user puts in an "Unlock" request with their correct password, then I dont see that as a security risk.

In any case, always appreciate the ideas.

[willichan]

If the account is locked out, then verifying that they gave you the right password BEFORE unlocking them would be a nice trick. That is why we used a secondary authentication. If the secondary authentication matches, then you can unlock them.

If you are not worried about authentication, and just want to unlock the account, then it is all the easier. Just prompt for the user ID, and let the script remove the locked flag.

I recommend using a secondary authentication though. Employee #, Badge #, phone extension, or anything that would identify the individual. It isn't as secure as the password, but it filters out the casual account hijacking, and they will still need the correct password to log in afterward.

Edited November 1, 2010 by willichan

[ICANSEEYOU7687]

Well first I just want to see if I can get something working with the AD account and password. And then a badge number would be a great thing (and doable) to do.

So if I can get a basic model, then I will worry about implementing the secondary authentication (of course without that will just be for testing) but it seems that implementing this into a web page is the tricky part. I think asp might very well be more suited for the task.

As always, thanks for the replies!

[willichan]

Working with AD is no problem. There is a UDF that was created for that

http://www.autoitscript.com/forum/index.php?showtopic=10616

You will still hit the problem that you cannot verify the password on a locked account though. At least I have never seen a solution that would let you do that. I have been administering Windows servers since NT4, and have never seen a way to do it. That is why I say you either need to unlock the account without verification, or use some secondary verification.

Anyway, good luck. If I can be of any other help, let me know.

[Legacy99]

We looked at a self serve option, one company we worked with called Ensim did exactly that.

The way they did it is via a Proxy account on a non AD server but it had full rights AD. The users however, would have had to visit the initial site to setup securty questions. Once that was done it was all stored in a SQL DB. Scripts would run once the transaction was complete to unlock the account.

After seeing it done it didn't look to hard to replicate, however they also modified GINA so you could unlock your account from your own workstation, that part would be the challenge. Keep in mind that this was all on XP, not sure how it would translate to Vista/7.

The other consideration is the account you provide for AD will be exposed on the website without this model. That was one security hole that veto'ed the in house solution for us. Cost was the reason for the third party app.