Reputation: 407
I'm currently looking for some kind of a best practice on changing the active directory user password for a user for the cases when the user logs in to a asp.net based web application and the password is expired, and during a logged in session.
We're running the applicaiton on Windows Server 2008 R2, IIS7 with .net framework 3.5
So far I used this:
public int changeUserPassword(String _userID, String _oldPassword, String _newPassword, bool _change)
{
try
{
PrincipalContext oPrincipalContext = new PrincipalContext(ContextType.Domain, "do.ma.in", "DC=do,DC=ma,DC=in",
ContextOptions.SimpleBind, @"domain\admin_account", "admin_pw");
UserPrincipal oUserPrincipal = UserPrincipal.FindByIdentity(oPrincipalContext, _userID);
if (_change)
{
oUserPrincipal.ChangePassword(_oldPassword, _newPassword);
}
else
{
oUserPrincipal.SetPassword(_newPassword);
}
oUserPrincipal.Save();
}
catch (Exception e)
{
//error handling
}
return 1;
}
This method handles the cases for user initiated pw change after the login, the changing during expired pw login (ChangePassword method), and for a password reset, where a temporary password is generated etc. (SetPassword method).
The reason why we need the ChangePassword method is so there is a user confirmation about the current password and so the AD password history is applied, since we don#t allow the last x passwords. SetPassword just sets the password, no matter if it's in the recent history.
SetPassword seems still to work fine, but since the Microsoft patch KB3167679, the change password method doesn't seem to work anymore. KB3167679 The article specifically mentions that this only happens to accounts that are locked out or disabled, but it also doesn't work anymore when the account is simply active or in "password expired" mode. The exception message I geet is "One or more input parameters are invalid".
I previously used another implementation using DirectoryEntry, but it was faulty, since it sometimes worked and sometimes it didn't, which was quite annoying. So I'd rather not go back to that.
We observed this on an instance that has the new patch, an instance without it works fine. I was also able to reproduce the behaviour on a test server, the method stopped working after the mentioned patch was installed.
Unfortunately Microsoft doesn't provide a best practice in this article and I can't seem to find one myself. So the question is if maybe you have a tip for me what is the standard way to go here.
Upvotes: 2
Views: 2818
Reputation: 182
I have encountered a similar issue. Try changing ContextOptions.SimpleBind to ContextOptions.Negotiate
Upvotes: 2