Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

problems with accounts when users change their passwords

Status
Not open for further replies.

gcazian

MIS
Dec 4, 2002
61
US
On our domain, user accounts expire after 60 days. The users are then prompted to change their password, which they do. Afterwards, everything seems to be okay. Yet, when they try to log back into their machine the next day, their passwords will not take.

We found that if we revert to their old passwords (resetting through Active Directory), they are able to login.

Anyone hear of similar problems? This is affecting only a handful of users, but we wish to resolve it...
 
What type of systems are these? Win9x has difficulty with password changes in a domain, but Win2k should not. Win9x requires you to change both the network and the local system password to keep in sync. It is also done differently then with NT or Win2k or XP.

PS: 60 days is way too long for good security, and you need to be sure they can not resue the same password for at least a year! Users like to change a password, then change it back the next day. :)

If you are changing the password back in AD to the old PW, why are you even bothering to force the change at all?

As a minimum, use the new password in AD to set it correctly. The fact that the password does not work could be because they had caps lock on, entered a wrong value, or a host of other reasons. When they change a password, it can take a long time until all the DC's get the change, and a different DC may be validating the user or you may also have a problem with the DC's being updated correctly. Lots of possibility here.

HTH
David
 
These systems are Windows 2000 Pro and XP. They really do not have anything in common that we can single out.

As far as password policies go, 60 days works fine for us and it is in line with the recomendations of an outside security audit.

We around 300+ users, 10-15 users are experiencing this problem. For those users, we have to manually reset their passwords in AD. The others can change their passwords from their machines with no problem. It doesn't make sense for us to go and reset the 300+ user passwords in AD if only 10-15 are having problems.

The users experiencing this problem are able to change their password when prompted and the new password works for a day or two, then it breaks. Once we set their password back to their previous, they are OK.

It might be a DC syncronization problem, but why would it work for a day and then break? I am thinking it may have something to do with the password cache in the user's local profile...

Thanks for the suggestions...
 
Have them, after they change their password, log off immediately and log back on with the new password.

I'm Certifiable, not certified.
It just means my answers are from experience, not a book.
 
If the users are able to log on after they change the password, then can not the next day, then my first suspecion would be there is a second dc in the domain that is not getting updated and that is the one being accessed when they try to log on the next day.

Once the password is changed and used successfully, there is no way the password would revert to the old one, unless there is another DC in the system which is being accessed to authenticate, and it is not getting updated when the change is made.

Note, this could be a secondary DC which is the initial logon, and the change gets done there, then not forwarded, and the next time the primary dc is the system doing the authentication and it still has the old password. Could be the reverse also, if the primary is the one they log on to when making the change, and the secondary fails to replicate correctly. With 300+ users I presume you are not using a single DC system????

I would trouble shoot the DC update/replication issue, not the users, unless all these users are on a common subnet or on a common hub, and they do not have a local DC to reach easily on their physical network. In that case, look at he physical network to see what path their systems get their authentication from, and start there.

HTH

David
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top