When a user changes their Active Directory password, I would like to sync it back into MIT Kerberos.
In its current form, this is too vague of a statement for it to really be answered in one shot.
Sending or "synchronizing" passwords from Active Directory to a 3rd party KDC (key distribution center/database) is not part of how Kerberos works. Nor can I think of a good reason to do it. Ever.
Active Directory uses a loosely-consistent database replication model to ensure that the database of usernames and passwords (and quite a lot else) is synchronized and kept up-to-date from one domain controller (KDC) to the next. Needless to say, MIT Kerberos KDCs cannot participate in that replication. (At least not in any sort of supportable fashion that is befitting of a professional organization.)
It is technically feasible to accomplish what you're describing, though very ill-advised.
Is it possible to programmatically change a user password's to something?
Of course. You can administratively reset a user's password in Active Directory to whatever you want, whenever you want, assuming you have the rights to do so. You can do this in either native code or managed code. Here is a simple example:
using (var context = new PrincipalContext( ContextType.Domain ))
{
using (var user = UserPrincipal.FindByIdentity( context, IdentityType.SamAccountName, userName ))
{
user.SetPassword( "newpassword" );
// or
user.ChangePassword( "oldPassword", "newpassword" );
user.Save();
}
}
The key difference is that "changing" a user's password requires knowledge of the user's current password. "Resetting" a user's password can be done without the knowledge of the user's current password, but requires administrative privileges.
Not sure what that has to do with your original question of synchronizing passwords from Active Directory to a non-AD database, though.
From the AD side, I see that there's something called Password Filters
Password filters may only be developed in native (C or C++) code. No managed code allowed. Password filters are modules that are loaded into the Lsass process on all domain controllers. You must take Extreme care if you plan on developing one, since if you cause a crash in lsass.exe, the entire domain controller goes down. And if one of them crashed because of your password filter, then they'll all probably crash since they're also all running your same password filter. And if all your domain controllers crash simultaneously, your entire company is down.
Yes, you could theoretically use a password filter. The password filter could record every password change that occurs into a text file or a separate database. Or it could transmit the password to another server over the network. How you choose to transmit and secure the password, is entirely up to you. You'd better use TLS at a minimum. I swear if you transmit or store the passwords in plain text I will come find you in hell and torture you myself.
(Just kidding about that last part.)
