Domain users change password - Referenced account is currently locked out, Windows 7 boxes

Greetings Experts!

I've been having an issue recently with domain users who recently changed their passwords getting locked out of their computers. I've run into this issue about three times now in the past week or two, and this time, the things I tried in the past aren't working.

Previously, I've been able to reset the password on both of my local DCs, and remove / rejoin the workstation from the domain and have the user successfully log back in to their workstations. Now I have a user who is unable to login after changing his password last week, and he's unable to login on any of the workstations he's usually working at.

He's a local admin on the PCs he's using (he's the leader of his particular team), so I thought maybe there was some issue with Windows storing his old credentials locally and not allowing him to login with his new password. I've tried removing the computer from the domain, deleting it in AD, and then rejoining to the domain, I've tried removing his local admin account access in User Account Management on the local box, I've had him reset his password on both of the local DCs to make sure it's not an issue of replication (since I'm not sure which DC he's authenticating to from his PC), but so far nothing has worked.

Can someone give me a hand? Is there a cause to this that I can fix to prevent it from happening to other users?
minileedAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

jrwarrenCommented:
Double check the time on the client and server.
   If the times are off significantly that can cause some problems.

If the times are off Run:

net time '\\domaincontrollerservername' /set

0
iedenCommented:
Also check to see if as Administrator he mapped a network drive using cached credentials.
If not too much to ask, delete his profile and have him recreate a new one.
You can also check to see if he has services running as himself.
0
Share-ITCommented:
Cached credentials is a fair bet and usually happens for something like sharepoint and the remember my password button.

I have also seen similar issue cased by a USN rollback. It happens if someone reverts to a snapshot on the DC or restores AD incorrectly. see here...

http://support.microsoft.com/kb/875495
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

minileedAuthor Commented:
So I went over to check the status of any mapped drives and to confirm the time is set correctly, and the user was able to login as himself without me taking any corrective action this time. Is it possible that there's just a huge delay for some reason between the time the password is reset on the server and the time the local credentials are updated? Is there a way to edit or reset local credentials to not cache somehow?
0
Share-ITCommented:
if the machine is physically connected to the domain, it should be instant as password changes are treated as urgent by default.
0
minileedAuthor Commented:
I just had another user with the same issue, who tells me that this has happened to her a couple of times in the past week. If I were to assume that there's something wrong on the server side, where would I go about looking? This problem is making me a bit paranoid that I've got replication issues on the server side or something. The fact that it's been popping up so much recently just has me worried.
0
jrwarrenCommented:
you can try gpupdate /force the next time.  See if that has any effect on the time it takes to trickle down.
0
minileedAuthor Commented:
The workstations are all on the domain, we have a single domain here with multiple DCs. At the admin office, where I appear to be having the issues, we have two servers, both of which are DCs, one is the Primary, one is just a regular DC and Exchange box.

We had a similar issue at a different site prior to me making the server here the PDC. We have seven different sites all connected to each other via VPN tunnels on Cisco hardware. There was a replication issue with one of the servers that used to be the PDC, which is why I changed the role to the server here.

This problem appears to only be impacting users who just changed their passwords. It'll work fine until they log off after changing their password, and then lock them out sometimes when trying to get back in. The most recent user was actually locked out in AD on the PDC, but not the secondary DC here, so it's got to be a replication issue between the two DCs, right?

But what's happening? And why isn't there something related to replication showing in the Event Viewer?
0
Share-ITCommented:
how many DCs do you have and are they all in the same site?

How long before the password change is recognised and works properly?
0
minileedAuthor Commented:
Is gpupdate /force something I'd run on the DC or the workstations?
0
Share-ITCommented:
and obviously, are there any errors in the event logs on either the DC or the client machines?
0
Share-ITCommented:
workstations but it won't fix the password issue. it will update the Group Policy nothing else.
0
minileedAuthor Commented:
Share-IT - We have seven different sites, with seven DCs total. Two here at our admin office, with one of them being the PDC. One site doesn't have a server at all, it's just connected using Cisco based VPN tunnels. I haven't had any users report this issue at any of our other sites thus far.
0
iedenCommented:
Perhaps you may want to check the replication of your DC's inhouse. If the traffic becomes too much for one server and is offloaded to the second, an infrequent replicating partner may be your culprit.
0
iedenCommented:
Sorry, AD Sites and Services would be where you check that.
0
Share-ITCommented:
do you have the AD sites setup correctly i.e. Subnets assigned to sites so that your users log on to local DCs?

you can also run replmon to check the replication between DCs.
0
minileedAuthor Commented:
We do have subnets assigned to each site, and as far as I can tell the replication topology is correct. The interval is set to 15 minutes. The only site that's having this issue, as I said, is our admin office. Both of the DCs here are on the same subnet, so I don't know where users are authenticating to. Is there a way to control that somehow?
0
minileedAuthor Commented:
Using replmon and doing a search for replication errors, there is an issue with one of my DCs apparently, but it's at a different site, and that server's replication partners aren't either of the servers here at our admin office. The error codes returned for that server are 1722 and 1256. That issue seems like it's a connection issue, it's saying the remote system is unavailable, but that doesn't appear to be related to the authentication problems I'm having here.
0
Share-ITCommented:
you would still need to configure a site for you main office. it will be in ad sites and services. Just ensure that all of your local subnets are assigned to the default-first-site-name.

I suspect your users are changing their passwords which happens on the PDC but then authenticating to a remote site as your main site doesn't have subnets assigned. Therefor, they ar being caught out by the 15 minute replication latency.

You can also type "set" at a command prompt on the client and it should list the logon servers name as well a bunch of other stuff.

0
iedenCommented:
MainDC to BackupDC replicationDoes your schedule for replication look like this for all your servers in teh DEFAULTIPSITELINK?
0
Share-ITCommented:
Those errors will probably be caused by either a firewall blocking the ports 389/3268 or the MTU is too large and you need to reduce it.

Let me what the "SET" command comes back with for the logon servers. ie local or remote.
0
minileedAuthor Commented:
The SET command shows the local PDC as the logon server. Admin is one of the defined subnets. The schedule for replication does look like the one above, set to four times per hour, except for the link between the two servers here, which are set (automatically generated settings) to replicate between each other once per hour. Is that delay the likely culprit then?

I still don't understand why, if I RDP to the PDC and have the user reset their password there, and the PDC is also the logon server (as verified by the SET command), that the workstation would still not allow immediate access for the user. I have to believe I'm still missing something here.
0
Share-ITCommented:
you're absolutely right - something is definately a miss.

Have checked the event logs as mentioned earlier?
0
minileedAuthor Commented:
Okay so I looked at the event logs, and I'm finding one thing that may be problematic.

Codes I'm getting are error event ID 1864 and information event ID 1955. Text of the error 1864 is shown below...I've already identified the one domain controller that it's not replicating properly with, but it's not the secondary DC here at the admin office. I can ping the servers from each other with no issue.

This is the replication status for the following directory partition on the local domain controller.
 
Directory partition:
DC=ForestDnsZones,DC=pdxmission,DC=org
 
The local domain controller has not recently received replication information from a number of domain controllers.   The count of domain controllers is shown, divided into the following intervals.
 
More than 24 hours:
1
More than a week:
1
More than one month:
0
More than two months:
0
More than a tombstone lifetime:
0
Tombstone lifetime (days):
60
 Domain controllers that do not replicate in a timely manner may encounter errors. It may miss password changes and be unable to authenticate. A DC that has not replicated in a tombstone lifetime may have missed the deletion of some objects, and may be automatically blocked from future replication until it is reconciled.
 
To identify the domain controllers by name, install the support tools included on the installation  CD and run dcdiag.exe.
You can also use the support tool repadmin.exe to display the replication latencies of the domain controllers in the forest.   The command is "repadmin /showvector /latency <partition-dn>".
0
iedenCommented:
Each server acting as a DC also acts as a DNS server. This is starting to look like a DNS problem.

To make sure they can talk to each other appropriately, try this as an example:
The primary good DC has an IP address of 192.168.0.1
The second nearby DC has an IP of 192.168.0.2
One remote DC has an IP of 192.168.6.1
Another remote 192.168.10.1
On the local good DC, ensure the IP addresses in DNS appear as such:
first - 192.168.0.1
second - 127.0.0.1
On the local Bad DC, ensure the IP addresses in DNS appear as such:
first 192.168.0.1
second - 192.168.0.2
third - 127.0.0.1
The remotes you say are not having issues. Leave them alone.
Once you have changed the DNS IP addresses, close out of all windows and log off and back on again. Then run from C:\>"ipconfig /flushdns" without quotes and press enter.
Then run from C:\> "ipconfig /registerdns" without quotes and press enter.
Give the DC's at least 3 hours to sync and negotiate amongst themselves.
Reboot the bad DC once, log back in and change the DNS IP addresses to:
first - 192.168.0.2
second - 127.0.0.1
rerun "ipconfig /flushdns" and "ipconfig /registerdns"
This should clear up your replication issues if they are DNS related.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Share-ITCommented:
what is your domain functional level? if it's 2000 you may want to go up to 2003 asuming you domain suits. searching around for 1955 seems to reveal others having the same issue after a migration from 2000. Sound familiar?
0
minileedAuthor Commented:
The PDC is 2003, and I'm currently in the process of upgrading it to 2008, though I'm moving it from a physical machine on very old hardware to a VM on newer hardware. So I'm essentially building the new server from the ground up, and am not literally migrating the server. I'll be migrating the databases and shares to the new server once I've got all of the roles configured on the VMs.

We have one 2008 box, most of the others are 2003, there's one 2000 box but that's not a DC, it's just hosting our maintenance request software.

ieden - Is changing the IP addresses of my servers going to cause issues for users on the network or for software on the network that relies on those servers? They'd no longer be part of the subnet that they're based on, so I'm concerned that making these changes would cause instability with some of the software. Not that I can't do this after hours, of course.
0
minileedAuthor Commented:
My apologies for my ignorance - still kind of new to this stuff. I just checked in domains and trusts, and our functional level is 2000. I believe I've fixed the replication issue based on the advice given from ieden to check my dns settings, and share-it's advice as well. After correcting a DNS issue on a remote server, dcdiag isn't bringing back the errors anymore, though I am seeing another error on my only 2008 server, which is having some interesting issues of its own.

I should state that I've been trying to untangle a bit of a cobbled together network, left behind by a fellow who had supported this place for nine years. I'm trying to bring some order to the chaos, and every time I get some progress made on moving forward, I'm running into snags that I'd like to clean up before really calling the job done.

Should I post a new question and close this one? My new error is a failure to pass NCSecDesc when running dcdiag. I'll check in the morning to see if I'm having any other issues between the DCs at different sites.
0
iedenCommented:
The IP addresses were examples and not meant to be hard coded.
I'm sorry, I didn't know your level of understanding.
If you could provide the internal IP addressing scheme of your network, I could write a clearer set of instructions to follow.
IP Address of Server 1
Subnet mask of Server 1
Default Gateway
IP Address of Server2
Subnet mask of Server 2
IP Address of Server 3
Subnet mask of Server 3
IP Address of Server 4
Subnet mask of Server 4
IP Address of Server 5
Subnet mask of Server 5
IP Address of Server 6
Subnet mask of Server 6
IP Address of Server 7
Subnet mask of Server 7
Is WINS installed and running as a service?
0
minileedAuthor Commented:
I figured it out after looking through it again. Initially I thought you'd intended for me to put everything onto an internal scheme that was separate from the subnets, hence the 127.0.0.1 addresses. When I actually read it more thoroughly it made more sense.

Our admin office is 10.10.25.0, this is where servers 4 and 5 reside. Server 5 is the PDC. Server 2 is on the 10.10.21.0 subnet. Server 1 is another remote server on 10.10.28.0. Both server 2 and server 1 are replication partners with server 6, on 10.10.20.0. When I remoted to server 1 to check the connection, pinging server 6 from server 1 gave me the wrong IP address, even though in DNS it looked fine. I changed the primary DNS on server 6 from itself to server 5 (the PDC), secondary to sever 2, and third to itself, did the dnsflush / dnsregister, and pinging it returned the accurate IP address.

I also ran dcdiag again on servers 1, 2, and 6, and the error I'd received before about replication was no longer there. Unfortunately I've still got a bit of a tangled mess in general, and I'm just trying to clean up EVERYTHING as I replace older hardware with VMs on better equipment.
0
iedenCommented:
As the DC's become reaquainted with each other, you will need to point them at themselves in their DNS address order to search field for IPV4 properties. A good rule would be each servers IP address is first in the list, followed by what you would consider the PDC, again followed by the loopback address of 127.0.0.1.
DHCP credentials should also be confirmed to contain the most current password used for the account used to register IP addresses with DNS.
If you do not have a DNSProxyUpdate group in AD, make one, add all DHCP servers and assign security to DNS zones with what equates to modify rights to each zone.
Once DNS is happy, you need to verify the DEFAULTIPSITELINK is present in sites and services. It should contain all the DC's with the same cost and value. You can create other site links with more attractive values but there must always be a DEFAULT.
WINS is one of those things that everyone loves to hate because there is so little in the way of management. Set it and forget it.
In no time, you will have a happy AD and network traffic will settle down to the normal file, print, surf, app, blah, blah... OK, I'm rambling.
0
minileedAuthor Commented:
Zero AD Domain Service events in the past 48 hours, thanks so much!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Utilities

From novice to tech pro — start learning today.

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.