Strange account lockout problem with one particular user; network with two domains

[Cerulean]

Old network domain: company.com
Old network subnet scheme: 192.168.1-50.0 (1 = servers, 5 = WAPs, switches, and tech center DHCP, 10+11+12 city division DHCP, 20 = DHCP for division at edge of city lines, 30 = DHCP for division thirty-eight miles away) + a VLAN for each office at each division facility (exaggerated greatly, but no joke)

New network: company.local
New network subnet scheme: class C 172.16.x.x

To support certain legacy applications in our migration process, we had to connect the second NIC of one of the old domain controllers (DNS service disabled of course) to the new network and gave it a static IP.

HERE IS THE PROBLEM: in our full VDI environment, we have had some issues where user accounts get locked out. This happens because the domain name (not including the TLD) is the same -- COMPANY -- and the majority of usernames for accounts on the new domain match an account on the old domain. On the new domain, for the time being, everyone (except select few who have sensitive/critical functions and data) has exactly the same password abc123$ (made it up). On the old domain, everyone has a unique, insanely easy and insecure, and IT documented password.

We have gotten this problem for people using Zero Clients (configured for VMView server on new domain), laptops (still on old domain), desktops (old domain). The solution we have found is to make the user's password on both old and new domains be identical.

However, there is one particular user who stands out (will not name job position, but someone who has a critical role in the company). We've synchronized his password, but his account still gets locked out. He has a laptop (old domain) with VMware View Client.

I do not know what my co-workers have tried, I was just asked to post about this to see if anyone had any ideas. One idea I had which I think my co-worker was trying before I left work was to rename the username of this user on the old domain to something else (such as their full name instead of first initial full last name, or append a number to their username). Neither domain is aware of each other's GUIDs for user objects, so in my mind changing the username on one of the domains should stop conflicts -- will find out tomorrow of this works. My co-worker has sifted through event logs but isn't finding anything useful.

Does anyone know of any good way to troubleshoot or diagnose situations like this?

 

[/usr/home]

Why not just demote the old server and join it to your current name? You'd get rid of the two domains then.

 

[vr.]

Check the logs on the mail server. The idiot probably set up an iPod touch at home to sync that he forgot about.

 

[JBark]

Check the logs on the mail server. The idiot probably set up an iPod touch at home to sync that he forgot about.

Always that or saved credential on some PC somewhere. Saved credentials will really get yah, because Windows seems to retry the connection to a network share multiple times before giving up. Power on a PC/laptop with incorrect saved credentials and a few mapped drives, instant lockout.

As long as you are auditing Account Logon Success and Failure events in the Default DC GPO, it should show up in the Security log on one of the DCs. I just had a similar problem a few weeks ago, and the DC logged each failed attempt and had an entry specifically for the lockout. The lockout entry had the IP of the offending machine as well, so was super easy to track down the culprit.

Another less likely one is a logged in terminal services session somewhere from before the password changes. It will continue to try to authenticate network access with the old passwords.

 

[Cerulean]

Why not just demote the old server and join it to your current name? You'd get rid of the two domains then.

The main reason for not doing that is because there are some legacy apps on the old system that were hardcoded in nasty ways, and that the new system is at Rackspace "in the cloud" -- we won't be keeping 7+ year old hardware.

 

[AcidBurn]

http://technet.microsoft.com/en-us/library/cc738772(v=ws.10).aspx

Use these tools and search the DC's and see what is locking them out.

 

[Cerulean]

Thanks guys! I think we found it. User had a network drive and about a dozen printers that were using credentials with old password saved to remember. Was too late in delivering this "discovery", as the lockout policy was lifted entirely, but with your suggestions we can tackle this issue in the future if we ever have it again (which I'm sure we will when we hit our other divisions).