3

Having a problem which I've seen before but haven't yet found a solution to, I've got multiple AD sites in one domain physically separated and logically separated by different subnets and AD sites.

When a user account is enabled after being in a disabled state at one site and then attempts to log in on a workstation (at that site) they are receive a login message that their account is still disabled.

When checking against all DC's the local DC states the user is enabled but as replication has not yet taken place all others are still disabled. Testing with an enabled user entering wrong passwords shows the incorrect password event is hitting against the local DC and also the primary DC for the domain (but not at the users site) I haven't yet been able to find the right event id's in Win2k8 for wrong password attempts so I can't yet advise which DC the incorrect pw request originated from.

All Subnets are correct and there is no errors in %systemroot\debug\netlogon.log on the local DC, the server returns its in the correct site, the workstation return its in the correct site and its logon server is the local DC, all DFS paths return to the local DFS host and after logon I cannot see any traffic to another DC. Pinging the domain name resolves to the local DC also. We also set DNS to only point to the local DC.

Does anyone have an idea why this setup would require a DC other than the local DC to have the account unlocked? Users would like to use their accounts immediately so resolution of this be very helpful.

Win 7 clients, Win 2k8 r2 servers, 2003 functional domain in multi AD site configuration

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
Ben Bowman
  • 113
  • 2
  • 3
  • 13
  • This article will probably help illuminate what's happening and why: http://blogs.technet.com/b/kenstcyr/archive/2008/07/05/understanding-urgent-replication.aspx – joeqwerty Mar 01 '13 at 15:00
  • Thank you for the response but this article doesn't discuss at all how a workstation chooses its point of authentication, we know replication hasn't taken place and that isn't the concern. The problem is that the workstation device does not appear to accept that the account is enabled on the local DC as truth and refers back to another DC. – Ben Bowman Mar 04 '13 at 00:12

1 Answers1

1

So the question is you think that the authentication process is contacting a remote DC first, even though there is a local DC where the account is enabled.

I suspect there is more occurring here than is being observed.

Here are a few things that you can do to collect more information:

-Enable Netlogon debug logging on the workstation: 

   Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
    "DBFlag"=dword:24401F04
    "MaximumLogFileSize"=dword:3200000

That creates a very detailed log in C:\Windows\debug\netlogon.log with most of the activities and decisions that occur during the authentication, and site/DC locator process.

-Perform the test on a workstation where the symptom can be reproduced, just after the workstation has been restarted.

-Setup a NetMon packet capture to run on the computer when the workstation starts, using a scheduled task. Configure the task to run as SYSTEM with highest privileges. The commands would be something like: 

cd /d "C:\Program Files\Microsoft Network Monitor 3"
nmcap /network * /capture /DisableConversations /file c:\temp\test.cap:20M /StopWhen /TimeAfter 5 min /MinDiskQuota 100M

Wait for the capture to end gracefully at the end of five minutes before attempting to use it. The logon test would need to complete within five minutes of restarting.

This should enable you to confirm that the local DC is not being contacted at all. If there is a referral to the remote DC, there may be additional information to determine why.

If the authentication process succeeds on a workstation that is recently restarted, but fails on a workstation where the authentication had recently failed, that would be useful information.

Greg Askew
  • 34,339
  • 3
  • 52
  • 81