Improve company productivity with a Business Account.Sign Up


Implementing A Custom Password Change Utility for AD Logon

Posted on 2009-05-18
Medium Priority
Last Modified: 2013-11-13
I've been looking around online all day for some information on this, and I can't find the "right" answer(s) for what I'm trying to accomplish.  First off, though, let me start by saying that I've seen something similar to this done in a large corporation environment.  That being said, though, I don't know how easy or difficult it is to make it happen.

What I'd like to do is create a very simple, custom application for changing a user's password for their Active Directory logon that will also update the login credentials for other servers (database and mail) at the same time.  Of course, that isn't the difficult part as I can put together the actual application code and such with a little time and effort.  The "problem" I'm running into is that I want this custom application to replace the existing password change dialog that Windows uses when a user's password has, or is getting ready to expire.

The implementation I saw was a little different than this in that the company I worked for had modified the "CTRL+ALT+DEL" security dialog to redirect a user to a Web interface that reset a number of passwords (AS400, mail, AD, and several custom applications) all at once.  I suppose this is an alternative to the way I'd like to do it, but I'm not sure about how to accomplish that either.  Either way, I'd really like to make a simple application that will synchronize the login credentials for all of the servers to which the user has to connect during the normal course of their job functions.  The important piece is the ability to access this application without actually being logged into the domain.  Of course, I'll have it check/confirm some identifiable piece of information before actually allowing the password to be changed.

Any suggestions, pointers or other assistance in this would be greatly appreciated.  Thank you so much for your time.
Question by:khufford19
  • 6
  • 3
  • 2
LVL 23

Expert Comment

ID: 24417326
Yes, they normally have a custom application, or some sort of Service Management Service like Tivoli, but Microsoft passwords like SQL server etc can be sync'ed to AD anyway, allowing the single change of a password to be enterprise wide.

Its not hard to write a change password application (vbscript) but to make is centralized, multiuser, multi platform control with a secure interface is going to be difficult to retain your security rating and no easy task to do properly.

As a hack, you could script something up in a webpage with DOTNET, effective but dangerous.


Author Comment

ID: 24418245
Thank you, debuggerau.  I'm also concerned about security impact of this whole scenario, and I'm trying to determine the best way(s) to mitigate the dangers.  The thing about this particular implementation, however, is that I won't be accessing other Microsoft server applications.  I'll look a little further into the possibility that these servers may have built-in interoperability with Active Directory for the purposes of synchronizing user login credentials, as I may have missed something there.  Admittedly, most of my research has been done through the liberal use of Google.  Of course, the results of such a method can certainly be a somewhat hit-or-miss prospect.

Barring success with some sort of integral functionality in the server applications, my concept for this "home-grown" solution includes alternate user identification methods (perhaps a secret question, PIN or some other piece of user-verifiable information) to validate that the person requesting the change is the one that has the right to do so.  All of this can be handled through a limited-access account to the database with encrypted data using stored procedures/functions so that the risk of the data being compromised is minimized.  Either this, or even the possibility of using the original user account credentials at the time the password change is requested to establish the necessary connections to the servers.

Assuming this is the scenario, my biggest hurdle is figuring out how to replace the existing Microsoft functionality with the new password-change application I create.  I'm sure there's a DLL or EXE that's called by the OS.  The question then becomes how to either redirect the call that the OS makes to the default system file over to my application, or replace the existing file with my own.
LVL 23

Assisted Solution

debuggerau earned 800 total points
ID: 24418946
just think of the AD as a big database and you'll be connecting and updating some records, not real complex, but they don't leave you much scope for variations. You'll need to work out the method, so you choose the right toolset.
Like C++, C#, VB NET, or even an older technology like vbscript or Perl..

MS would recommend a DOT NET solution, to get with the bleeding edge..

I still don't know enough of the scope for a recommendation but you seem to be aware of the dangers and hurdles.

And while in a domain, your group policies will have many messages to forward  your application for error reporting, like password not complex enough, was previously used, does not conform to complexity and the such.

The actual technology to connect to AD is ADSI and more info here:

happy drilling, be back tomorrow if you need more arrows :-)
Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to and use offer code ‘EXPERTS’ to get 10% off your first purchase.

LVL 71

Accepted Solution

Chris Dent earned 1200 total points
ID: 24419661

'lo guys

> company I worked for had modified the "CTRL+ALT+DEL" security dialog

I suspect they modified GINA. Documentation for that particular task is dotted around the place, with some fairly reasonable examples here (all C++, most of the deeper MS parts require that):

Security is a big concern with this. As it stands the users password is never ever sent over the wire, only a hash of the password when it is changed. With the implementation you're looking at how would you get the password to the other systems? And do so in a way that would stop people watching network traffic from decrypting it?

Do none of the other systems support LDAP Authentication? Or anything else that can hook into AD?


Author Comment

ID: 24423139
Thanks for all the information.  To be more specific, my intention is to synchronize the passwords for individual users between the Active Directory, a MySQL database server and a CommuniGate Pro mail server.  Because none of these are "standard" MS server systems, I admit I made an assumption that I'd have to make my own customized solution to accomplish this.  With the comments here, however, I'm delving deeper into the possibility of LDAP authentication for these servers.

Again, if this isn't possible for some reason, I'm also looking at how to implement my own simple interface to accomplish the same goal.  While the user interface and general functionality of such an application is "simple", the security concerns are most certainly something that will take a lot of research to ensure everything is as locked down as possible.  Basic hashing of the data between the interface and the system may be useful to some extent, but I realize a lot more is going to have to go into it.

I know that what I want to do here is definitely a major undertaking - much more than the very simplistic visual aspect of what the user will experience - and all of the resources that have been provided to this point will be extremely useful in coming up with a viable solution.  I'm almost certain that I can pass a hash of the password directly to MySQL without a problem, but I'm not sure yet about CommuniGate.

Regardless, however, I'm fairly certain I won't actually be able to get to the final implementation of this piece for quite a while.  My biggest issue has been simply figuring out how to get to the point where I *CAN* do the synchronization myself if need be.  I definitely wanted to be as prepared as possible before stepping into a project like this, knowing all of the potential pitfalls and problems that could arise.  If anyone else has any comments or suggestions, I'd still love to hear them, but I think I have enough now to do a little more research on my own.  Thank you all for all your assistance.

Author Closing Comment

ID: 31583063
I believe that GINA is the piece I was looking for from this puzzle.  While I'm aware of the potential for a number of security holes or issues here, I'm certainly not 100% sure how to protect myself from them yet, but I'm going to keep looking.  Working in C++ definitely isn't my forte, and perhaps I'll actually end up giving up on trying to make this happen in any sort of automated fashion.  Still, at least I have a much better idea now of where to look for answers.  I really appreciate all of your assistance and ideas.  

Any further information you may have that might be helpful (such as any additional concepts or articles on mitigating, negating or eliminating the security issues that arise in this type of implementation) would certainly be welcome, but I greatly appreciate all of the reference material you have given me.  Thank you again.  Time to get back to digging.

Author Comment

ID: 24426832
Well, the more I look at this, and the more sources I look into, I'm becoming less and less confident that I can successfully deploy the type of solution I'm really wanting to.  Here are the problems (besides the potential security concerns) that have come from my research so far:

1) The fact that GINA is no longer used by Windows Vista, while not immediately an issue, could render this whole project useless if I try to create my own custom DLL and the higher-ups decide to upgrade the computers at any time.  Of course, with VERY limited C++ programming experience, this route was probably going to cause me no end of headaches anyway.  :-P

2) While there are several posts and threads I've found about people "working on" a tie-in for MySQL and Active Directory, I've been unable to find anything that's really usable.  Some of the "for-profit" companies may have useful tools, but I don't see my company being willing to spend the money on any of them at this time.

3) I haven't even gotten to the CommuniGate piece of my research yet, but these other points lead me to believe that, even if it does have the ability to use the LDAP authentication to communicate with the Active Directory, I'm still going to need some alternative anyway.

So, I'm thinking of the possibility of making a user-initiated application that they'll have to run after they've logged into the Windows OS and changed their password.  Another thought is possibly using some sort of stored procedure/event trigger in AD to automatically launch this application automatically once the user has successfully updated their password.  I'm running out of ideas at the moment, but hopefully I'll get an epiphany (or be able to latch on to someone else's epiphany ;-D) that'll point me in another direction.

Thanks again for all the info, resources and help you've provided.
LVL 71

Expert Comment

by:Chris Dent
ID: 24429511

I certainly don't envy you this task, I don't know enough about the internals of ADs authentication systems to come up with reasonable comments about how else you might approach it. Other than forcing external systems to authenticate against Active Directory (rather than trying to replicate changes) of course :)

Vista: I hadn't realised GINA had been replaced, but you're right. CredSSP is the new one with associated documentation here:

Although I suspect there's even less practical detail on hooking something else into it.

I don't know if it's relevant or useful, but CommuniGate do seem to support external authentication, which would allow you to pass authentication requests back to Active Directory (or another LDAP Directory).

Sorry it's not more help.


Author Comment

ID: 24432953
Thanks for the follow-up, Chris.  Yeah, when I saw that Vista ignores GINA files, I realized that the custom solution I was trying to put together was a sinking ship, and it was time to jump in a lifeboat and abandon ship.  Integrating my own functionality to the OS login controls is just not a viable option.

The information on CommuniGate is definitely helpful.  Thank you for the link.  I'll have to go check it out and talk with my network/mail admin about the possibility of setting that configuration up, but it certainly may be worth it.

Interestingly enough, I found this on MySQL's Web site:

So, it looks like they'll have the ability to perform external authentication in an upcoming release.

Now for the good news.  I think I've come up with a solution that will help me accomplish my goal of automating the synchronization of new passwords through the use of the domain's login scripts that my network admin already has in place.  Here's my thought:

My plan is to write a program that, upon launch, checks the age of the password in AD for the currently logged on user.  If the age of the password is greater than 0 days old, then just get out of the application and complete the logon process.  Otherwise, if the age of the password is 0 days (meaning the user just changed it during this logon attempt), prompt them again for the new password and run a series of quick procedures that update the MySQL and CommuniGate login credentials.

Using MySQL's hashing functions will encrypt the password before making the change there, and I should be able to do some form of encryption before passing it to the mail server as well.  There are a few things that I'll need to try to take into account as I go through this, but this should help make things work much more like I had originally intended.  This ensures the user has been authorized for the domain before allowing any other operation to take place, as well as gives me the ability to create new user accounts "on-the-fly" in the case of a new employee.
LVL 71

Expert Comment

by:Chris Dent
ID: 24433051

Yeah, that does sound rather easier to implement. It would be easier to concentrate on securing the update of the password over the network there than trying to rewrite the authentication layer in its entirety :)


Author Comment

ID: 24433722
Yeah, I can't believe I didn't think of using logon scripts for the "automatic" piece.  It's one of those "can't see the forest for the trees" things, I guess.  :-P

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Native ability to set a user account password via AD GPO was removed because the passwords can be easily decrypted by any authenticated user in the domain. Microsoft recommends LAPS as a replacement and I have written an article that does something …
You have missed a phone call. The number looks like it belongs to the bunch of numbers which your company uses. How to find out who has just called you?
Simple Linear Regression
Finding and deleting duplicate (picture) files can be a time consuming task. My wife and I, our three kids and their families all share one dilemma: Managing our pictures. Between desktops, laptops, phones, tablets, and cameras; over the last decade…

579 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question