Directory Programming .NET

We have built a custom MembershipProvider, and everything had been running smoothly for about 3 months. Our ValidateUser method uses the normal ActiveDirectoryMembershipProvider.ValidateUser method, but around it sits code that will remove the "User must change password at next login" flag if it's set, so we can still validate that their password is correct.

Now, when people are having their password reset by our helpdesk (who also set that "must change on login" flag), they are no longer able to pass the ValidateUser step. Anybody without that flag set is able to change their password. Nothing has changed in the AD, or in the code since it went in to place in Feb, but what worked a few weeks ago no longer does.

We did have a problem with the server it runs on 2 weeks ago, and we had to reboot it. The only thing in the event logs around that time was a Windows Update which added KB948496, which after some "googling" reveals that people have had network related issues after it's installed.

Any idea if this patch could be the culprit, or any other ideas what it could be?

Thanks

Is it possible that your code to unset the "user must change password at next logon" flag is failing silently?  That sounds like the most likely culprit. 

There may also be something weird going on where you are making modifications to one DC and doing authentication against a different one, so the validating DC is not picking up on this change.

joe:

Is it possible that your code to unset the "user must change password at next logon" flag is failing silently?  That sounds like the most likely culprit.

It is possible, and we are attempting to load the code onto another server where we can debug it.

I am not too familiar with AD security, but is there a setting in the permissions that would remove the ability to toggle that flag on and off? If the account we are using could change that flag 2 weeks ago, but not now, is there something that could have been changed in its settings that would stop that, but still allow it to do an admin password reset (SetPassword)?

joe:

There may also be something weird going on where you are making modifications to one DC and doing authentication against a different one, so the validating DC is not picking up on this change.

+1  I have run into this before using serverless binds.  If you make a change that requires immediate update, you must hit the same DC each time.  This can especially happen if you have a large domain with many DCs and the service that does the update versus the password change are different.

 

---

Ryan Dunn
Extemporaneous Mumblings
The .NET Developer's Guide to Directory Services Programming

After looking at the AD, it looks like we have 4 Domain Controllers.

So if our connection string was "LDAP://COMPANY.NET/DC=COMPANY,DC=NET", where should "Server1" fit into that?

LDAP://SERVER1.COMPANY.NET/DC=COMPANY,DC=NET

Note the downside of this is that you lose the automatic failover you get by allowing DC locator to find a DC for you by only specifying the domain name.  As such, doing this is a trade off but may be necessary if you are doing writes and need them to be available for read immediately.

That solved our problem.

Thanks a lot.

It looks like our problem isn't quite as resolved as I thought.

Every 3 months (90 days), our passwords are set to expire. The problem now is that most aren't due to expire for another 5-10 days, but we have been getting lots of calls from people unable to change their passwords (their accounts appear to be perfectly fine).

Here is the bulk of the form's code:
        if (Membership.Providers["ServiceMembershipProvider"].ValidateUser(username, oldpass))
        {
            try
            {
                //Attempt to change password
                if (Membership.Providers["ServiceMembershipProvider"].ChangePassword(username, oldpass, newpass))
                {
                    ChangePassword1.ChangePasswordFailureText = "Password changed successfully!";
                    //Response.Write("Password changed successfully.
                }
                else
                {
                    ChangePassword1.ChangePasswordFailureText = "Unable to change password";
                }
            }
            catch (Exception ex)
            {
                ChangePassword1.ChangePasswordFailureText = "Your new password does not meet the security requirements (See above).";
            }
        }
        else
        {
            MembershipUser mu = Membership.Providers["ServiceMembershipProvider"].GetUser(username, false);
            if (mu.IsLockedOut)
                ChangePassword1.ChangePasswordFailureText = "Your account is locked out.";
            else
                ChangePassword1.ChangePasswordFailureText = "Your current password is wrong.";
        }

They are all getting the "Your current password is wrong" error, which means their credentials are not validating, and the account is not locked out. If I look at their accounts in the AD, I can't see anything that looks out of place (they look like a normal account that functions properly).

Could it be because their passwords are expiring in a few days that the ValidateUser method is failing? And if so, how could I get around this?

I don't know why this would fail unless the password is actually expired (which would cause an LDAP auth failure).  Are you positive the passwords did not expire before you thought they were supposed to?

You could try looking at the AD audit logs to try to determine what the detailed failure info might be.

About 2/3 of our employees work at various client sites, so they are not normally connected to our domain (and never get the "your password will expire in X days" warnings). Because they don't see the message telling them it has expired, they end up locking out their account when it does, thinking they just mistyped their password.

They then contact the helpdesk who will unlock their account, reset their password and require them to change it on next login. They then go to our web app to change their password from the temporary one, and it usually works just fine. (As stated previously, the application handles the "must change on next login")

Our problem only seems to occur every 3 months when their passwords expire. We haven't had this problem when someone locks their account by forgetting their password.

We don't have access to the audit logs for the AD, but I will see if we can get a copy of it.

I think I see.

In my company, we use a different approach for this.  We send out email warning messages on specific intervals to user's whose passwords are expiring (15, 5, 2 and 1 days I think) and direct them to a website where they can change password.

We also have a self service password reset system where they can reset their own password via security questions or a two factor auth mechanism like SecurID token (not all users have SecurID or we would just use that).

This way, if the password is expired, they still have a viable self service mechanism to correct it and don't need help desk.

Sending out the warning emails is very important to the whole process as well as we have a huge percentage of workers who are disconnected and not even using domain joined machines.